Is Our Project’s Cost Overrun Really Just A Schedule Problem?
“[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?
Comments from around the web:
Mike Clayton • In high tech industries, the root cause of over-runs is often the changes in priorities due to CEO/COO/CIO refocus efforts during the quarter or two that the project was supposed to have high priority in IT group. And of course its worse when outside contractors are used, since you cannot really stop people who are writing code in mid stream and not increase the final cost of completion (perhaps with new coder).
So you can blame it on bad scheduling, or you can learn from that for given industry and break up all IT and CIM projects using Agile (SCRUM et al) methods, so that projects can shift priority to some extent, without losing all effort thus far. Start, stop, restart is nasty, but better than cancel and lose since no standalone segments were ever completed. Some contractors of course hate those limitations, preferring full project requirements, then design with signoffs, and then full coding and then full integration effort…or similar “all of nothing” efforts. It boils down to billing by hours spent vs billing by whole-project-low-bid with contingencies for delays, etc etc. Pay-as-you-go vs Pay and Pay. Governments are like IT departments in that regard, due to changing priorities leading to cost over-runs.
Agile is less risky it seems if you can get sub-cons with critical skills to agree.
But with high rate of priority change, all methods risk benefit delay and cost over-run.
But my personal experience is that rapid prototyping of project code modules with review by end customers before next steps is necessary in high tech manufacturing, within an overall architecture of standards. Thus the success of Agile, and scripting language results before performance enhancements like C code. Integration with other factory systems and finance systems can be majority of the cost in any case.
Bruce Benson • MIke,
Agreed, I like the agile/scrum approach (I’ve used incremental development successfully for, er, decades) for minimizing risk and keeping things flexible for the inevitable changes.
“So you can blame it on bad scheduling ….” What we did was fix the scheduling, as clearly one of the problems that needed fixing. The surprise, for most people, was that many of the other problems went away with just the schedule fix. We delivered on time, quality didn’t improve — it improved dramatically, and it didn’t take us any longer than it had taken similar projects in the past (which is what we based the improved scheduling on.). This “fixed” (greatly improved in any case) what were primarily large waterfall efforts by government (military) and industry (consumer electronics, etc.).
While I love scrum for its “self adjusting” velocity I recall a Google Tech Talk by one of the founders of scrum. He relates how a scrum team claimed they could finish a number of requirements/stories in a given period of time (sprint) that was at odds with their past performance based velocity number. Did they? Nope. Many folks would look at all sorts of things (programmer performance, testing, story completeness, quality of work, etc.) to explain the problem and look for solutions. Yet by getting the team to believe in their velocity they started to deliver functionality as expected.
So the key lesson learned is that when root causing things that go wrong, when we pick a schedule that is shorter than needed (or too many requirements for the given schedule), then that compression can break so many other processes. Those broken processes might look like a cause, when in fact, a least based upon my experience, they are often just another symptom of a schedule that was way too short.
(More on this subject: pmtoolsthatwork.com/its-the-project-management-schedule-stupid/).
Great feedback. Thanks.