Why 90% Of All Projects Finish Late

Activities classed under the term "project" are so diverse that it is sometimes difficult to appreciate commonalities among them. For example, social activities like the organisation of parties, picnics or weddings are projects. Construction work like building a bridge, developing a housing estate, power plant construction, expansion of a fibre optic network also constitute projects. So do producing a movie, developing software, launching a marketing campaign for a new product, implementing an ERP system or the relocation of a family from one city to another.

For each of the examples mentioned above, the following hold true:

The objective is a unique, non-routine outcome.

The effort required to achieve the outcomes desired is temporary. That is to say projects have a start and finish date. This is in contrast to operations which are ongoing.

The non-routine nature of projects accentuates the impact of uncertainty.

In spite of the many unknowns, executors of the project must make three commitments at the outset. These are commitments as to content or scope, commitments as to delivery date and commitments as to cost.

In spite of these commitments, the existence of a rich and detailed body of knowledge on how to manage projects, and the availability of purpose-built project management software tools, almost no projects are delivered on time. Unless there are major trade-offs in content and/or cost. Why is this the case?

Enter the human factor.

Project Time Estimates

The uncertainties involved in projects mean that time estimates used for planning are just that, estimates. What does estimate mean? It means that the time given for each project task is an average number. But wait a minute. Using truly "average" figures for time estimates would mean that chances are fifty-fifty that the task will be completed early or late. No one will give an estimate that has a fifty percent chance of failing.

So what actually happens is that the estimates are padded to account for uncertainty. The level of padding depends on how badly the estimator has been burned in the past when he/she provided inadequate "cover".

In addition for padding provided by each task performer, there is also an overall padding by their boss. For example if three resource persons working on various tasks in a project estimate 5 days, 7 days, and 3 days as their respective task completion times, will their manager report an estimated completion time of 15 days to his own boss? Highly unlikely. He most probably will offer 20 days and only very reluctantly allow it to be negotiated down to 18 days minimum.

If as described above, project times are already padded from the start (through padding of each task and further padding at each level) how come most projects still end up finishing late?

There are two psychological mechanisms at work that thwart individual attempts to protect the project against uncertainty and cause all the safety provided to be wasted.

Student's Syndrome

At the conclusion of a lecture, a professor informs students that they will be taking a test on the material taught in one week from today. What is the typical reaction of students? They will protest that they are not ready, that the time is too short... If the professor relents and gives an extra two weeks for preparation, do students immediately begin to study for the test? They do not, if they are typical students - until the night before exam.

In projects, having padded the time estimates, resource persons will typically delay (probably busy working on things unrelated to the project) to the latest possible moment before commencing work on the project task. And while they're working Murphy strikes. Since the extra time was already consumed by Student's Syndrome, the task is finished late. The next dependent task is forced to start late.

Parkinson's Law

Parkinson's law states that work expands to fill the time available for it. What is the implication for completion times of project tasks? Assume that a particular task estimated to take 7 days actually is completed in four days, does the performer deliver it to the next resource person? Not likely.

Because the time estimates given are negotiated numbers, reporting an early finish of a task means that future estimate given by the project worker will be trimmed by the manager. To avoid this possibility, rather than report early task completion, the worker is likely to spend the extra time performing checks and adding nice to have "bells and whistles" not strictly required by the specifications.

Result? Extra time gained is wasted.

Integration Requirements

In most projects, the final stage is an integration of the outputs of several previous paths. Assume in a particular project that the final stage is the integration of the results five paths. Assume again that the time estimates for each of these five paths is such that there is an 80% chance of on time completion, what is the change that integration will commence on time?

For the integration to commence on time, all the five paths must be complete. The chance that one path is completed on time is 80%. The chance that two paths are finished on time is 80% X 80% which is 64%. The chance that four paths are finished in time for integration is 64% X 64% or about 40%. The probability of all five paths being finished in time for integration to commence is about 33%! More likely than not, integration will commence late.

Multi-Project Environments

A further killer of time in multi-project environments (software development companies, construction companies, engineering departments) where more than one project is going on simultaneously and resources have to be shared between the resources, is multitasking.

The resulting lack of focus, combined with constant "set up" requirements leads to late delivery of all the projects being worked on.

Conclusion

We have shown that original project time estimates are padded to protect against uncertainty. However, a combination of Student's Syndrome and Parkinson's Law lead to a frittering away of the enormous safeties embedded in the estimates.

In addition the need for integration in most projects, and the incidence of "bad" multitasking in multi project environments lead to added delays, virtually guarantee that projects are delivered late.

What is the way out? A different way to manage projects is needed.