“[Harvard Business Review article] reach that grim conclusion, they say after poring over the budgets, actual costs, and results of 1,471 IT projects with an average tab of $167 million. The average cost overrun of those projects: 27%. But more alarming, they say, is their finding that one in six of those projects incurred an average cost overrun of a whopping 200%. That is, the biggest IT projects tend to run over budget, and a significant percentage of them run way over budget. Furthermore, almost 70% of those biggest budget-busters also overrun their schedules, at a time when business technology executives see speed to market as their No. 1 priority …. The HBR researchers argue that the biggest IT debacles typically occur at companies under financial duress.” IT Greatness Versus IT Risk, Rob Preston, Informationweek, Sep 19, 2011
What jumped out at me when reading this article was the average cost overrun was 27%. In my career and practice, I found that the typical schedule overrun was at least 20% for organizations that normally and regularly missed their schedules. When we got organizations to finally consistently deliver on-time (i.e., when they promised to deliver) then problems and arguments about cost overruns, requirements creep, and time to market … died way down. I’ve observed that costs are proportional to the schedule (for IT and software intensive projects in particular) and if the schedule runs longer than expected, not surprisingly, the costs are greater than expected. So a schedule that overruns its duration by 25% unsurprisingly often sees a cost overrun of roughly the same amount.
Rob writes his review with a focus on cost and then says “almost 70% … also overrun their schedules ….” This is where I think too many managers stumble when trying to find a solution to these kind of problems. They focus on cost control (more upfront analysis, more detailed tracking, more reviews, more project steering and guidance meetings, more approval levels, etc.) but maintain the same aggressive but never achieved project schedules.
Bring The Schedule Under Control To Bring Costs Under Control
A lot of this can be attacked by breaking up projects into smaller, incrementally implemented chunks (e.g., Scrum in software development, etc.). However, I’ve also had great success with using our average recent past performance as the best estimate for how long a current project will take (i.e., doing it in one large project, but with an accurate schedule). The key lesson here is to bring the schedule under control (i.e., make them realistic but still aggressive) as a method to bringing costs back under control.
Finding the root causes of any problem is undeniably the key to solving that problem. It is often too easy to get wrapped up in what are symptoms and then to try to fix them directly rather than finding the primary underlying reason and solving it. Often times the root cause is not always intuitive nor obvious and the relationship of cost and schedule is one of these tricky areas. So make it a practice of asking ourselves if we’ve really found the root cause and in the case of cost overruns, take a good look first at what is going on with our schedules.
Have you ever delivered a project on time where the costs still far exceeded your estimate?