Previous IT Project Failures Do Not Matter When Choosing An IT Service Provider

by Tim Sheedy
A factor that tends to be considered when choosing an IT service provider is how many project failures they have had – particularly when some of those failures are large, costly, and well-publicized. And if that is not a formal consideration, project failures are often on the mind of sourcing organizations. In fact many companies that I have spoken with over the past 12 months have actively excluded some players from their short list due to their previous failures. These types of metrics tend to work against the large players as they have more contracts and therefore, if they run at an industry average failure rate, they are most likely to have more failures. IBM, as the company that probably does the most IT projects, has the most failures (assuming that their failure rate is the same as that of their competitors) – and this works against them. I have actually heard people say that they would never have IBM in as an IT services partner because of the fact that so many of their projects fail. And this does not only refer to IBM – you could switch in any large IT services vendor’s name here as the sheer number of projects they work on means that they are likely to have more problems too (as very few IT projects go smoothly). If the failure rate is 1 in 10 (and this is just a guess) then a vendor that has undertaken 1,000 projects will have more failures than one who has undertaken 10…

In my humble opinion, focusing on failures or project problems is a short-sighted view. Project failure is rarely the fault of your IT services partner – even if it is, it is your fault for not managing the process effectively and pulling them up before it turns into a failure. The only time when the partner is to blame is when they promise to do something that simply is not possible – and again, they are probably just responding to your impossible requests.

The “X-factor” that seems to separate the average from the excellent in IT implementations is not their ability to avoid failure, but how they respond to failures and issues when they invariably do happen. I just completed many client reference interviews for the ANZ SAP Implementation Wave that I am working on at the moment, and nearly every client had a major issue at some stage within the project. Now remember that these client references were actually supplied by the providers themselves, so these are the GOOD ones – which means that in the real world the number of major issues within projects is even higher! It is how the provider responds to these challenges that sets them apart. Some have great project management to resolve the situation, some have individual experts who went above and beyond the call of duty to fix the problem, and some have management who were happy to step in and do whatever it took to ensure the project gets back on track.

So therefore when you speak to client references (which you should do before undertaking a major project or outsourcing a large chunk of your IT) focus more on the problem resolution aspect and less on the rate of failure or the number of issues – for you will have issues no matter how much planning and prep work you do! What you will find out in the process can be hugely valuable when looking for the right partner. For example, one company I recently spoke with mentioned that whenever things went wrong, the senior management of their partner always stepped in to make things right. On the surface that sounds great – exactly what you are after in a partner – commitment at the management level! But they then went on to say how the CEOs of both their companies are good personal friends and look out for each other. This should ring warning bells (unless, of course, your CEO is good mates with your IT services partner’s CEO!). Others mentioned how whenever there were problems they were resolved due to their own company’s great project management methodologies. If you don’t have these great methodologies then this is something to watch out for as well.

Projects do go off the tracks. And while I have no empirical data to prove this, my gut feeling is that the number of failed projects has decreased significantly over the past few years as project implementation methodologies improve, IT departments are closer to the business to ensure project alignment, and project sizes have decreased (or at least implementation times have shortened). It is how you and your partner respond to the issues that will define not only the outcome of the project, but how much grey hair you get along the way.

Comments

re: Previous IT Project Failures Do Not Matter When Choosing An

What are the metrics by which projects failures are determined. Especially in a scenario where they are resurrected by methodologies and processes. Do we need to call them failures or should we call them project derailment which can be brought on track.

re: Previous IT Project Failures Do Not Matter When Choosing An

Past behavior can be a good indicator of future behavior, and prior work can be a good indicator of future work. We recently addressed this problem in our blog in reference to web design and web development work, but the principals hold true.http://blog.confluentforms.com/2008/08/how-to-select-right-web-design-and-web.html

re: Previous IT Project Failures Do Not Matter When Choosing An

This is an total load of garbage from an analyst who really has no idea of the real business world of IT services. Forrester should seriously examine the caliber of its analyst staff before letting them loose making statements like this, for example: "The “X-factor” that seems to separate the average from the excellent in IT implementations is not their ability to avoid failure, but how they respond to failures and issues when they invariably do happen."What planet are you from Mr Sheedy?

re: Previous IT Project Failures Do Not Matter When Choosing An

Can I know which service provider sponsored this excellent "research" and subsequent path breaking concluson!?