No one would be shocked to hear, but not all software projects are delivered on time. Research shows that only 1/3 of major software projects are completed on the original schedule. There are few human endeavors, baseball batting averages aside, where failing 2/3 of the time is considered a success. In this article I am going to look at three factors that frequently contribute to missed delivery dates.

Changing Requirements

Changing requirements are a major cause of project overruns. Most changes increase the scope which  adds time to the original schedule. Even small accumulate and have a significant impact. It is therefore vital that the impact of any change be estimated, communicated to the stakeholders, and a formal decision be reached to drop the changing requirements or extend the delivery date. When stakeholders are explicitly asked to sign off on delaying the project, they will frequently decide that the change is not as essential as they had originally stated.

Spending more time gathering requirements and having stakeholders, product, and engineering discuss can reduce the number of change requests. This reflects the old adage of measure twice and cut once. There is a balancing act. It is all to easy to sit and discuss requirements for meeting after meeting; analysis paralysis. Having an accurate estimate is less valuable if you start the project weeks later.

Interruptions

A second cause of project overruns, that particularly impacts smaller organizations, are interruptions to the team working on the project. Pulling team members away to handle production issues or work on some other urgent issue will invalidate the estimates. Taking a team away from a project for a week will delay it by more than the week. It takes time for engineers to switch their focus back to the project.

Estimation Errors

The third cause for overruns are that the estimates used to get the planned completion date were wrong. In my experience engineers are optimists; they will tend to estimate based on everything going well. More tasks in a project will be under-estimated than over-estimated. To help improve the accuracy of estimates, I use the following approach.

Obtain estimates when you have a detailed set of requirements or a list of user stories. People are better at estimating small tasks than large ones. Trying to get a useful estimate from a few sentences of project summary is doomed to failure.

Have multiple engineers, preferably the whole team, estimate each task/story. This should be done blind, so they are not influenced by the guesses of others.

If you have outliers in the estimates do not discard them. The estimate may be based on information or understanding that other engineers lacked. When there are outliers, have the team discuss and reach a consensus. If there is no agreement assume the worst case.

Once you have effort estimates, these need to be converted to elapsed time. Engineers are not able to work on a project forty hours in a week. As a rule of thumb, I assume that thirty hours of effort can be completed in a week. It is important to identify dependencies between tasks. A project with an estimated effort of 300 hours (10 weeks using above assumption) and a team of 5 may not complete in 2 weeks. If there are a set of tasks that need to be done in order (critical path), that will impact the elapsed time.

One last thing to avoid when calculating a completion date is to plan the start date immediately after the previous project is due to be delivered. Most projects require some polish and finish after deploy. Give yourself a buffer.

Engineering teams get better at estimating as they work together and gain familiarity with the applications on which they are working. To offset this, it is advisable to add time to estimates made by newly formed teams or when working in an unfamiliar part of the stack.

Conclusion

Being aware of the reasons for project delay enables you to reduce the chances of them occurring. Unfortunately, you will never eliminate delays from all projects. You need to recognize when a delay is possible, probable, or certain and inform the project stakeholders. Communicate early and with transparency. No one likes to be the bearer of bad news. However, being told after 4 weeks that a 3 month project is likely to overrun by a couple of weeks is far better than finding out a few days before the planned date. Early information enables others who had plans based on the delivery date time to adjust.

Working in software, we have all heard stakeholders frustrated jokes about delivery dates for software projects. If it helps you, remember that plenty of other projects run far later. The Boston Central Artery (aka the Big Dig) was delivered nine years late and five times over budget. Your delayed projects are going to look timely compared to that.