Unrealistic Schedules: It doesn’t have to be this way!

I’ve been beaten up in the “project management” business for over 20 years – and I discovered that there was no good reason for it!  

I’ve worked on technology development projects my entire career.  It didn’t matter if the projects were large or small. Invariably, mid-way through the effort, it became obvious to everyone that we were driving toward unrealistic schedule goals. The options to recover a slipped schedule in the middle are always limited. In most cases, either the schedule is re-baselined or the team is asked to “step up” and work nights, weekends, and holidays to salvage irrational schedule commitments. If this happens occasionally to support a key milestone or delivery you may be forgiven, but if it is a chronic problem, action needs to be taken, and the actions taken rarely address the root cause of the problem.  The result is poor morale, high turnover, and product quality issues. 

What is the root cause of 90% of development projects failing to hit their original timelines?  

The short answer: “It’s the math!” Novel tasks that are estimated have natural variance with actual performance.  Experts do their best, but estimates are educated guesses, not accurate predictions of the future.  Estimates cannot be simply just added directly together, a guess plus a guess results in a guess. Two-dimensional math is needed to account for the variance and sum the probabilities. 

Microsoft Project uses deterministic scheduling to create timelines using simple addition. This might be sufficient for well understood tasks in schedules that have been repeated multiple times by the organization performing the project since these tasks would likely have documented histories with minor variance.  Unlike the uncertainty and risk in a typical estimate, the simple math in Microsoft Project can predict a reasonable project end-date when tasks exhibit minimal variability between estimated duration and performance. 

Hardware and software development projects however, are filled with estimated tasks rather than known fixed-length tasks, and the variance among the best case estimate and worst case estimate for these tasks can be significant.  When a deterministic scheduling tool like Microsoft Project is used to come up with a development project timeline comprised of true estimates, invariably the project-end date presented by the tool is overly optimistic. Further, the higher the variability of the tasks, the more the schedule is off. Committing to these overly optimistic schedules can be devastating to the individuals involved, the development team, and the business as a whole – the more critical the schedule to the company’s business, the more devastating the results. 

A “better way” for development project schedule calculation is to use probabilistic scheduling techniques using statistics-based two-dimensional math… continue the conversation here contact us