Avoiding Olympic-Sized Overruns: Set Realistic Expectations

Avoiding Olympic-Sized Overruns, Football players in linePrior to the start of the London Olympics, many stories aired about the colossal budget overrun. These types of overruns are not uncommon for large, complex projects.

Major IT projects in particular are often victims to “black swan” events − extremely rare, unexpected events that have massive impacts. In fact, one in six projects has a cost overrun of 200 percent and goes over schedule by 70 percent, according to research conducted by Oxford University and McKinsey and Company.  Despite this, the Oxford University study found that on average, IT projects overrun in costs by just 27 percent.

If you’re tracking your project performance internally, then you already know how much your own projects tend to run over budget. The problem with IT projects is the very large number of massive overruns.  Since the Oxford research does such a wonderful job explaining the reasons behind this, I’m not going to rehash it or attempt any clever insight.

However, it did prompt me to think about some of the common problems that that I’ve personally had the misfortune to experience. These include:

Scope Creep

Consulting firms have a tendency to underbudget projects.  This is in part because of the competitive need to provide lower bids. Sometimes, though, the bids can be ridiculously low. Then once the client is on the hook and committed to the project, what can they do?  I was always amused by a consulting organization in New York that liked to use the phrase “five minute no-brainer,” referring to a quick programming enhancement or feature that inevitably took about four days to get done.

But it’s not always just underbudgeting. When clients start to see a project take shape, they start to think of ways to make it better. If these enhancements are not required, you have to push them into phase two. Otherwise, your risk of not finishing on time goes up correspondingly.

Lack of Funding

One of my former employers was a software company in the Bay Area that was notoriously cheap.  It had a history of underinvesting in projects, despite having a significant pile of cash available.  Some of these projects were sound strategic initiatives, but were doomed to die a slow death. In my particular case, it was an e-learning project − a great idea of introducing web-based training that would appeal to customers and help address a serious user-adoption problem. Alas, the money could not be secured. What at one point looked like a promising business model was eventually squandered, due to an unwillingness to invest at any level.

Lack of Resources

It’s not just lacking resources directly available that can sink you. A common problem is getting support from other groups.  If your success is dependent upon other teams delivering results − and they’re not aligned, committed, or otherwise compelled to help − then your chances of success go down significantly. This situation often arises in companies where there is internal competition for limited resources in product development, sales support, and other teams.

Lack of Executive Support

It’s unlikely you’ll get an absolute “No.” Maybe you’ll get lukewarm support. But even with a “Yes,” it might be not enough. Where does your project rate in terms of priority? How much clout do your sponsors really have? When push comes to shove, and you really need action, will they come through for you? You might already know where you stand, and if you have a strong relationship, then you’re probably OK. But to me, this comes down to actions speaking louder than words. If your executive sponsor can get you the resources you need, that’s definitely one for the “plus” column.

Unrealistic Timetable

I used to think of timetables in terms of competence. If it can’t be done quickly, then clearly there’s a competence issue. Not true. Sometimes, teams lack the skills and experience to complete a project successfully. In this case, the project will never get done unless these issues are addressed. It is more often the case, though, that the pressure to deliver quickly and cheaply results in setting unrealistic timelines. In my experience, if you multiply the initial timeline by four, you’re probably closer to the mark.

Unproven Technology

In a project that I worked on early in my career as a software developer, the company was developing a cutting-edge application that involved receiving data via satellite. It was being developed on an evolving operating system that ultimately was scrapped by the vendor. The lesson: untested, unproven platforms are highly risky.

Unclear Requirements

If the customer can’t clearly tell you what they want, then you surely will be dealing with “scope creep.” It could be they can’t give you the data you need because they don’t have it or can’t interpret it correctly themselves. I worked on a project where the client had a data-cleansing issue. Frighteningly, this was a large utility, and the data in question was billing information! In some cases, it becomes apparent over time that things are a lot more complicated than first thought. This means the project must be redefined midway – inevitable scope creep.

Regardless of the challenges your projects might face, work hard to ensure they come to fruition and are not disbanded along the way. In the midst of all the excitement that events like the Olympics generate, we can celebrate the success and come back to worry about the cost afterwards. Time will tell how successful the London Olympics will be from an economic, infrastructure, tourism, and other standpoints.

Malcolm Faulkner is a solutions marketing manager with the enterprise performance management team at SAP. Prior to joining SAP, Malcolm was a pre-sales consultant at OpenPages and Siebel Systems.