Why Software Projects Fail

We described two widely differing development days. The first is still the most frequently found; the second contains several ideas due to be tried out by 60 percent of the Information Technology (IT) shops in the immediate future. Frequently, this is why projects fail because required documentation hides how the project is doing.

We can see in Figure 1.1 that the project slowed when it reached 90 percent done. We call this 90-percent dumb, because there is no way to tell if it is true. Does it mean 90 percent of the documentation, the code, or the completed solution? Note that the project seems to be steadily marching toward completion. That is, until the 90-percent barrier is reached. You can almost hear the project manager: We re 90 percent done. We just have a few bugs to wring out. We do not know exactly how long removing the defects will take, but we re over 90 percent done. We re 98 percent done. And in the final week: We re done. Nearly half of the project s elapsed time is often spent being 90 percent done.

Figure 1.1: The life cycle curve of a typical software development.

Software development is nonlinear. As an example, a consultant friend of ours is out of town a lot. A new fence project at his home was postponed for over a year. He got a neighborhood boy to dig the postholes. Late in the afternoon, having dug all but one hole, the boy came to the door and said that he needed to quit and clean up, could he have the pro-rated pay for the holes he dug? The boy said that he would come back the next Saturday and finish. The consultant did as he was asked, but the boy never again showed up. A few weeks later, the consultant had some free time, so he went out to dig the last posthole. He found a boulder that would take more time to extract than the time it took to dig the other postholes. That is what we mean by nonlinear. People rarely have any idea how far along they are with this way of measuring development. They can be 100 percent done with 90 percent of the tasks , and the next task could take 50 percent of the project time.

Looking again at Figure 1.1, earned value tracking can take care of this uncertainty. Using earned value, your project does not get credit for a task until it is completely done. In other words, if the task is to document the architecture, using earned value in agile methods you would not get credit for documentation until the last iteration. Appearing constantly on a white board counts for nothing. Therefore, every iteration may be done 100 percent, but the tasks in an iteration may be worth only 20 percent of the tasks on a project. For example, doing the postholes the first Saturday resulted in the boy doing 100 percent of his work that day, but only about half of the total task. When somebody finished the last hole, that task was 100 percent complete, but a few weeks late. By having concrete tasks and subtasks , actual progress can be measured, and 90 percent done can really mean something. Some years ago, Dick Tausworthe, of NASA s increases, the accuracy of the estimate increases as well [Tausworthe81].

One cause for software failure, then, is blown schedules for chunks of the project, making those parts of the project almost impossible to finish on time because their estimates of completion are so poor. Nonlinearity takes its toll. This book contains stories of software successes and failures. Looking at them, we find that small granularity of tasks and frequent iterations are the key to success. The next chapter talks about some software development methods that have these characteristics. Obviously, additional reasons and factors influence the success of software projects, such as customer involvement in the development process.

Tasks  

1. How does earned value work?

2. What is Tausworthe s Principle?

Discussion

What physical changes have to be made in the workplaces in the case studies?