Why do software projects go awry?
There are five common elements to the answer of this question:
- Techniques for estimating are poorly developed.
- Effort does not always equal progress.
- Our estimates are not stubborn enough.
- The overall progress of the schedule is often poorly monitored.
- The traditional response of adding more manpower to late projects is flawed.
All programmers are optimists, but this can lead to thoughts such as “all will go well” and “each task will take only as long as it ought to.” This is not only untrue, it’s reckless. This is exemplified during the implementation phase of software development, where design ideas are shown to have flaws such as bugs or incomplete requirements. The presence of bugs alone show overly optimistic thoughts are unjustified. Bugs happen.
Cost varies by number of developers and number of months; progress does not. Men and months are interchangeable commodities only when a task can be delegated which requires no communication amongst one another. A possible example of a task which requires no communication is reaping wheat. Software development is not reaping wheat.
When a task cannot be partitioned because of sequential constraints, more effort does not affect the schedule because the amount of communication required increases. The extra communication is found in training and intercommunication amongst team members.
Because communication effort is great, adding more men lengthens, not shortens, the schedule.
Sequential constraints in the schedule are predominant in debugging and system testing portions of the project. This is often the mis-scheduled portion of the overall deliverables.
While the project sponsor may govern the urgency, it cannot govern the actual completion. However, false scheduling to match the sponsor’s desired date is more common in software than any other engineering discipline. Individual managers will need to “stiffen their backbones” and defend their estimates.
Regenerative Schedule Disaster
What happens when a software project is behind schedule? There are four possible approaches:
- Assume that only the first part of the task was estimated incorrectly and add more manpower to make up the difference for the first portion misstep.
- Assume the entire project estimate is off and add more manpower for all phases of the project.
- Carefully reschedule.
- Trim the tasks.
The first two cases are disastrous. For example, adding two new men, no matter how competent, will require training by the existing experience project member for a month. Thus, three man months (two new, plus one existing member) is invested without any progress on the project itself.
The bottom line is adding manpower to a late software project makes it later. One cannot conform to a previously estimated project schedule by using more men and fewer months.
Featured Image credit: https://flic.kr/p/5hPZom