I really enjoy playing guessing games – you know, the types that you would do in a case interview, in business school, or with your nerdy, analytical friends (and yes, my friends and I would fall into this category). It’s fun to try and give your guesstimate on how many golf balls could fit into a 747 or how many cigarettes are smoked a day in Montana. Even though I enjoy it quite a bit, I couldn’t imagine having my job hanging in the balance based on the accuracy of a hypothetical exercise. However, that is exactly what happens to an overwhelming number of leaders on a regular basis with their technology projects.
A McKinsey-Oxford study found that large IT projects go over-budget 45% of the time, over-schedule 7% of the time, and under-deliver 56% of the time¹. This translates to an awful lot of Steering Committee meetings where a Project Sponsor is forced to have an uncomfortable conversation with company executives on why their project is not meeting the metrics that were promised. But why does this happen? Why do very capable individuals (who called in experienced implementation teams) consistently find themselves in the hot seat with their projects? In many cases, the projects were doomed from the beginning due to basing the foundation of the project off of hypothetical exercises and guesstimates. Let me show you what I mean…
Projects tend to start by following a fairly predictable pattern:
MSS was recently brought in by a client that was experiencing significant difficulties during a Back Office Transformation project. The implementation partner was well over a year into the project (and already several months late from the planned go-live date), with very few tangible deliverables to show for their efforts. After a brief assessment we were able to quickly determine the cause of the issues: there was not enough effort early in the process focused on the true needs of the organization and the development of a corresponding scope. Instead, the organization was focused on finding a cost-effective supplier based on limited information of the business needs. This lead to the organization selecting a solution that did not meet their future state vision with an implementation partner that did not have experience in delivering the necessary scope (focusing on developing what they did have experience in delivering, instead). Fortunately, we were able to work with the client in developing a relatively quick course correction, but not until after they had already accrued a significant amount of sunk cost before realizing the project was doomed from the beginning.
In this case, the project failed its metrics the moment it is approved based on a rough, uninformed estimate. However, we have seen that this is not a unique case – it happens to a surprising number of companies regardless of company size, budget, industry, or even level of experience of the Project Sponsor. Bad things happen to good executives, but there is a way to avoid being put in this situation.
How to Avoid Project Estimation Errors
Chances are, you know all of this already – you have had a project (or maybe several projects) that quickly grew over-budget and/or under-delivered. But what can you do about it?
The single biggest thing you can do to set yourself up for success is to live in cost/timeline ambiguity during an early assessment phase to get an accurate scope that focuses on the true success of the project.
Once the initial problem is identified and documented internally, allowing an experienced team to evaluate your environment, account for potential complexities, and develop an agreed upon scope upfront can help provide a far more accurate understanding of the true efforts needed. It is critical to also use this initial assessment to identify what is needed to truly make this project successful. Answering questions like ‘Which resources will we need for this project?’, ‘What success metrics will we orient our decisions toward?’, and ‘How will we prepare our End Users for success on day 1?’ will go a long way in achieving the goals of the project.
This re-imagined launch of the project is as follows, focusing on a more success-oriented process and list of activities:
We live in a world where rapid technology changes and advancements are more than the norm – they are a requirement to survive in business. Before the whirlwind of a project begins, make sure to take the time to set your organization up for a successful project, rather than for a project doomed to disappoint. Being comfortable with living in temporary ambiguity will save you from a revolving door of unfortunate conversations with your Steering Committee.
¹ Bloch, M., Blumberg, S., Laartz, J. (2012) Delivering large-scale IT projects on time, on budget, and on value. https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value