Roberts & Roberts Associates
THE 'JUST DO IT' STYLE OF MANAGING PROJECTS
Lon Roberts, Ph.D.
There's a story in the annals of business about a couple of entrepreneurs - Edgar and Olaf - who decided to go into the hay haulin' business. Since hay was in short supply in their neck of the woods, they came up with the idea of buying a truck and hauling in hay from upstate where it could be bought for $3.00 a bail. Much to their delight, they discovered they could corner the market by reselling the hay at $2.50 a bail. After several weeks, while swiftly approaching bankruptcy, Edgar said to Olaf, "You know, we're workin' hard and we have the highest market share, but for some reason we're goin' broke. We must be doin' something wrong." After pondering this observation, Olaf replied, "Edgar, you're absolutely right. What we need is a larger truck."
Now that we've had some fun at Edgar and Olaf's expense, we need to be honest and acknowledge that this story is emblematic of the kind of provincial thinking that goes on within most organizations. Fallacious reasoning is easy to identify when the perceptual distance between cost and payoff is relatively close, as in the case of our hapless hay-haulers, but not so easy to detect when there is a complex chain of events that contribute to a particular outcome.
What I'm suggesting is a prevalent condition that can be framed more accurately as a "requirements-definition" problem, rather than a reasoning error. Intellectual prowess is an asset in preventing the latter but it would seem to have little bearing on the former. Intellect notwithstanding, it's apparent in Edgar and Olaf's case that the focus should have been on how to price for profit rather than how to increase market share or how to haul more hay. The profit-link becomes muddled when the issue involves something on the order of whether or not to upgrade a network system or whether or not to conduct a wide-scale training program.
Perhaps I shouldn't, but I never cease to be amazed at how often projects fail due to requirements-definition problems. But, requirements-definition problems are often more insidious than simply allowing special interests to prevail over the profit motive, how ever typical this may be. When it comes to projects, requirements-definition problems take on the form of unstated requirements, misstated requirements, assumed requirements, conflicting requirements, and, a condition that's common in today's world, changing requirements. In their variety of permutations, requirements-definition problems are one of the two most significant causes of less-than-successful projects. The other I would characterize as a project leadership void -- a subject that deserves special attention in its own right.
Government projects, as we know, are often fraught with requirements-definition problems, typically of the "changing-requirements" variety. These projects tend to be planned years, even decades, in advance of their actual delivery -- there are too many things that can change between concept and delivery. One example where conflicting requirements played a role is the now-defunct Superconducting Supercollider (SSC) project. Whatever the functional requirements of the SSC may have been in the minds of a handful of high-energy physicists, the paying public (i.e., the customer) apparently did not share or understand those views.
While various watchdog agencies make government projects an easy target, we have no way of knowing how pervasive the requirements-definition problem is in the private sector. Based on my observation, the condition is pandemic. The costs run into the billions of dollars which, in the case of internal projects, frequently gets disguised as "operations expenses." The success or failure of such projects is seldom apparent by examining the financial statements.
We may not have a good way of accounting for projects that miss the mark, but it is estimated, in the case of technology-intensive projects at least, that there is a 68% failure rate. This seems consistent with the findings of a study a few years ago involving a number of software development projects that averaged approximately a million dollars each. Of these, it was discovered that 2% of the software was used as delivered, 3% was used after changes, 19% was used but extensively reworked or later abandoned, 29% was paid for but not delivered, and almost half, 47%, of the software was delivered but never used. Delivered but never used?!? Where does this fall on the success-failure continuum?
If asked to identify the factors that requirements-definition problems have in common, I would place the "just do it" mentality at the top of the list. However compelling this phrase may be to those who see themselves as being action-oriented, it's clear the emphasis is on the "do" with little regard for the "it." In a project context, the "it" is tantamount to the requirements. Perhaps it's too late for our friends, Edgar and Olaf, but it's important to bear in mind that if being action-oriented keeps you on track, then being results-oriented will ensure your projects are on the right track.
© Copyright 1997
This article may be copied and disseminated if copied in whole and the following credit and contact information is included with the article:
Lon Roberts, Ph.D.
Roberts & Roberts Associates Home Page