85% of IT projects fail. I know why.

We’re all being suckered here, and not just in IT. Why does every house ever built seem to go over budget and over time?

  1. People thinking they can be Project Managers;
  2. People not knowing the true cost of change;
  3. Not having enough money to get the job done.

These problems extend to IT quite easily.

If we think of all the IT projects that fail (or if we want to feel better, think of the 15% that are successful), we must examine what it means to fail:

  1. Over time.
  2. Over budget.
  3. Didn’t deliver what the customer wanted.

The first two can be stamped out with a good Project Manager. But the real problem is number three, not delivering what the customer wanted.

Sometimes this is accidental, and sometimes this is on purpose.

One example is RFQs. Companies make a bid on IT work using an RFQ. There are two methods a company can approach this:

  1. Include as much detail as possible, and create as detailed as possible quotes. This can take a lot of time, make you seem unresponsive to requests, and have quotes that far exceed competitors (more on this in a bit).
  2. Include as little as required to gain the RFC. Externalise costs to things outside the scope of the RFC. This means you can reply quickly in the RFC process, and have quotes that appear better value than competitors.

Now lets examine the outcomes:

  1. By having high quality Project Managers, a robust change control process (that captures the true cost of change), you have a project that can be delivered on time and on budget. Depending on how good the requirements gathering was at the start, and taking into account the shifting target of meeting customer requirements now (and in the future), you might have a successful project.
  2. Or by not exploring the true scope of the project, you can easily get overwhelmed in trying to deliver a solution using nothing by elbow grease and hard work. As costs rack up, these are presented to the customer as unforeseen costs that are not typical of a project, and hence are outside the RFQ and must be paid for separately. In the end morale slips, and you have a project that met some requirements at some point in time, using most of all of the budget and time available (if not more).

So why would anybody pick option two, when it leads to near certain failure?

Greed. When we were examining those RFQs in the beginning, we were seduced by the quotes given to us, without really thinking about the true total cost of ownership. And we couldn’t since we weren’t provided with the true cost of the project by the bidders. And they didn’t do that so they could get more business. And businesses don’t punish vendors as they just see IT projects as being inherently risky.

They’re not. We’re just being taken by a ride by all the people in the system, leading me to believe that this is a systematic flaw, not just a specific component.

To fix:

  1. Businesses need to better understand their requirements. Seriously. Seriously. I’m not kidding. Gather the requirements for now. Gather the requirements for the future. Think of all the possibilities for the process. Is everything covered?
  2. As requirements change throughout the project, scope the change, go through a formal change control process (not just lip service either), cost the change in terms of resources and time, take the value of the benefits to the business and ask, is it worth risking all this (the risk you’ve calculated, and the cost) for the change to meet the requirement?
  3. Push your vendors for accurate quotes. Maybe this needs to be enforced through contracts. Sure, you didn’t foresee that the SCSI drivers were only for Windows not Linux. Sorry, that’s not a valid reason to not include the cost of having an alternative driver solution.

Finally, lets not accept that IT projects should fail. They should never fail. Never fail 85% of the time, never fail 0% of the time. I refuse to accept that projects should fail in this manner, and if they’re always failing, then we’re doing something wrong.