Ask yourself the following questions:
◗ Have you ever heard of projects taking longer than scheduled?
◗ Have you ever heard of a project being completed much quicker than originally scheduled, without a lot of expediting and pressure on the project team?
◗ Have you ever heard of a project going over budget?
◗ How many projects are you aware of that were completed for significantly less than the original proposed budget?
◗ Have you ever heard of projects that had to redefine their scope or specifications because they could not meet the original scope or specifications?
◗ Are customers usually delighted with project results?
In each case, the answers are usually in the undesired direction; that is, projects often underdeliver, overrun the budget, overrun the schedule, and end up with unhappy customers.
1.2.1.1 Two types of projects
Table 1.1 lists examples of two types of projects. The answers to the preceding list of questions are slightly different for the two project types. The first type is the absolute deadline–driven project. Examples include proposals and major events. Because requesters simply do not accept proposals after the specified delivery time, proposal teams rarely deliver proposals late. Management usually responds decisively to a proposal manager who spends the time and money on a proposal and delivers it late—they give the manager an opportunity to seek employ- ment elsewhere. Likewise, although there may be much adjusting of scope and expediting, other deadline-driven projects usually happen on time. They do not delay the Olympics; they finish the stadium (some- how). People do not very often fail to have things ready for a national meeting or a prebooked trip. People rarely bow out of elections because their campaign is behind schedule. In those types of projects, the money and the scope usually change, while the schedule is held.
The second type of project does not have a specific externally driven end date (although management may set one internally). All projects are performed to make money (e.g., new-product development and oil platforms) and most government projects fall into the second category, as do many improvement projects. All benefits are not lost because of project delay, just some benefits for some time. (The loss is usually understated or unknown.) In the case of projects that are not end-date driven, all three project variables (scope, schedule, and cost) may change.
1.2.1.2 Anecdotal data
Project management has a long history, which is reflected in the man- made wonders of the world. But, did they do it on schedule? Did they do it to an approved budget? Did they comply with all specifications and regulations? More and more in recent years, the answer to each of those questions is “No.” Most people are aware of the major projects that have suffered from problems, for example, the new Denver Airport or the Chunnel connecting England and France. Besides being late and over budget, they also experienced scope problems. The Denver Airport bag- gage system did not work for a long time after the airport opened. The Chunnel had an opening ceremony but could not transport passengers.
Many people are also aware of the “vaporware” problem in the software industry: Almost all software releases are later than predicted, and most have bugs in the initial release.
T a b l e 1 . 1
Two Major Types of Projects
Absolute-Deadline Projects Relative-Deadline Projects
Proposals New-product development
Major meetings Marketing or advertising (most) Major events (e.g., the Olympics) Construction
Election campaigns Computer software Regulatory compliance Improvement projects
Annual budgets Maintenance projects
Contest submissions Research projects Seasonal marketing
A recent newspaper article summarized the saga of the Denver Air- port. The project was over two years late, and the cost rose from $3 billion to over $4.2 billion. The scope was not—and, as of this writing, still is not—complete. Besides the baggage problem, people cannot find their way around, leading to the spending of more than a million dollars to change the signs. Is it not likely that signs were in the original scope of the airport? The newspaper wrote the report to give the good news that the airport made a $28-million-dollar profit in 1996. Let’s see: $28 million on a $4.2-billion-dollar investment works out to a return on investment (ROI) of 0.6% per year. How many investors would put their money in a project like that? Bond investors have filed a lawsuit.
Table 1.2 is found throughout the project management world and is distributed worldwide across the Internet. It is only one example of many with similar themes, attesting to the fact that projects often fail to achieve success. It is instructive to note that the effects appear to transcend all
T a b l e 1 . 2
Immutable Laws of Project Management
Law 1: No major project ever completes on time, within budget, and with the same staff that started it, and the project does not do what it is supposed to do.
Corollary 1:The benefits will be smaller than initially estimated, if any estimates were made at all.
Corollary 2:The system finally installed will be late and will not do what it is supposed to do.
Corollary 3:It will cost more but will be technically successful.
Law 2: One advantage of fuzzy project objectives is that they let you avoid embarrassment in estimating the corresponding costs.
Law 3: The effort required to correct a project that is off course increases geometrically with time.
Corollary 1:The longer you wait, the harder it gets.
Corollary 2:If you wait until the project is completed, it is too late.
Corollary 3:Do it now regardless of the embarrassment.
Law 4: Everyone else understands the project purpose statement you wrote differently.
Corollary 1:If you explain the purpose so clearly that no one could possibly misunderstand, someone will.
Corollary 2:If you do something that you are sure will meet everyone’s approval, someone will not like it.
Law 5: Measurable benefits are real. Intangible benefits are not measurable, thus intangible benefits are not real.
Corollary:Intangible benefits are real if you can prove they are real.
cultures and national boundaries. Many project management books include a section on why projects fail and offer remedies to the various causes.
1.2.1.3 Quantitative data
The government is willing to compile and publish results of quantitative review of a project performance. Usually, they do not bother to publish good news on contractors, so the published information may be biased.
Two quantitative examples are described next.
T a b l e 1 . 2 ( c o n t i n u e d )
Law 6: Anyone who can work effectively on a project part-time certainly does not have enough to do now.
Corollary 1:If a boss will not give a worker a full-time job, neither should you.
Corollary 2:If a project participant has a time conflict, the work given by the full-time boss will not suffer.
Law 7: The greater the project’s technical complexity, the less you need a technician to manage it.
Corollary 1:Get the best manager you can. The manager will get the technicians.
Corollary 2:The reverse of corollary 1 is almost never true.
Law 8: A carelessly planned project will take three times longer to complete than expected. A carefully planned project will take only twice as long.
Corollary:If nothing can possibly go wrong, it will anyway.
Law 9: When the project is going well, something will go wrong.
Corollary 1:When things cannot get any worse, they will.
Corollary 2:When things appear to be going better, you have overlooked something.
Law 10: Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.
Law 11: Projects progress rapidly until they are 90 percent complete; then they remain 90 percent complete forever.
Law 12: If project content is allowed to change freely, the rate of change will exceed the rate of progress.
Law 13: If the user does not believe in the system, a parallel system will be developed.
Neither system will work well.
Law 14: Benefits achieved are a function of the thoroughness of the postaudit check.
Corollary:The prospect of an independent postaudit is a powerful incentive for a project team to deliver a good system on schedule and within budget.
Law 15: No law is immutable.
Following a review of major systems acquisitions (projects over
$75 million) by the U.S. Department of Energy (DOE), the Government Accounting Office (GAO) reported the following [4]:
◗ From 1980 through 1996, DOE carried out 80 projects designated as major system acquisitions.
◗ Of those 80 projects, 31 were terminated prior to completion, after expenditures of over $10 billion.
◗ Only 15 of the projects were completed, most of them behind schedule and with cost overruns.
◗ Three of the 15 completed projects have yet to be used for their intended purpose.
◗ The remaining 34 projects are ongoing, many with significant cost increases and lapsed schedules.
In another report evaluating management of a recent version of a space station by the National Aeronautics and Space Administration (NASA), GAO noted the following [5]:
◗ The cost and schedule performance under the prime contract had been deteriorating for some time.
◗ Between January 1995 and April 1997, the costs associated with the schedule slippage increased from $43 million to $129 million.
◗ During that same period, the difference between the actual cost to complete specific work and the budget for that work went from a cost underrun of $27 million to a cost overrun of $291 million.
◗ As of July 1997, costs associated with the schedule slippage had increased to $135 million and the cost overrun to $355 million.
According to GAO, “The rate of decline for the cost variance is especially worrisome because it has shown no particular inclination to lessen” [5].
Your tax dollars at work! The DOE and NASA are two separate government agencies with very different projects and very different constraints, yet their performances are equally miserable.
The Department of Defense (DOD) shows similar tales of woe. Lewis [6] reports on the cancelation of the A-12 Avenger Program in 1991, which caused the loss of 9,000 jobs and entailed a lawsuit by the govern- ment for $1.35 billion in contractor overpayments. Lewis notes, “It has been acknowledged by reliable DOD sources that the C/SCSC manage- ment systems were implemented properly, and were functioning well at both the principal contractors.” (C/SCSC stands for cost/schedule con- trol system criteria, the most sophisticated project management system currently available.)
One now somewhat dated study from Australia found that construc- tion projects completed only one-eighth of building contracts within the scheduled completion date and that the average overrun exceeded 40%
[7]. Chun and Kummaraswamy reported that in a recent study of the causes of time overruns in Hong Kong construction projects [8]. The same study noted, “Delays in construction projects are still very common in most parts of the world, even with the introduction of advanced construc- tion technologies and more effective management techniques.”
Software projects are also prone to failure. Recent studies indicate that as many as 30% of software projects are canceled before they complete, and only 15% of the remaining can be considered successful in terms of the three necessary conditions.
In other words, many types of projects in many industries and in many countries (implying many cultures) seem to experience high rates of failure. The only common thread is the project system: They all use the present theory of the critical-path method, as defined by the PMBOΚ
Guide. They may not all use it the same, and they may not all use it well, but they all use it.
Improving project management is, in itself, a project. To that end, several precursor conditions should be satisfied before the start of any project (in addition to the three necessary conditions of scope, budget, and schedule).
◗ The right problem. Be sure you are working on the correct problem.
◗ The right solution. Ensure that the overall objective of the project, when achieved, solves the correct problem.
◗ The right design. Develop a scope and a design that deliver an imple- mentable solution to the correct problem.
◗ The right implementation. Execute the project to deliver the designed scope, achieving the objective within the planned schedule and budget.
The last point reiterates the three necessary conditions for any project.