The Unexpected Consequences of Missing Deadlines in IT Projects

Those who know me well know that I prefer fixing broken things to building new things. The appeal of a blank sheet of paper fresh for a new systems architecture design does not interest me anywhere near as much as taking some limping, banjaxed, and otherwise knackered project over the finish line.

Within the concept of project failure there is a continuum. Projects don’t just go from a binary state of “OK” to “failed” overnight, although I remember one occasion where I had been brought into a project where the business had spent close to ￡250k on a project over two years, but the management had not had any oversight over the project over the entire period. The board signed it off and left the senior staff member who was running the project to get on with it. Two years and ￡250k down, delivery was nowhere to be seen. To cap it all, the staff member who was running the project left. The board in that case did “wake up” to find a project that they thought was OK was not even on life-support, it had outright died. It was never going to get delivered, and the board were now in damage control mode trying to work out what happened.

The continuum of failure states that we see on a project go from “suspect” to “failing” to “failed”. At each stage in that project, you need to do different things. At “suspect”, you need to work out if your suspicions are right. At “failing”, you need to take active steps to remediate the project. At “failed”, you need to go into a mode that itself has graduated steps but ultimately ends up flirting or actively engaged with litigation. (But like all litigation, alternative dispute resolution measures are usually more effective.)

To add more colour to this, when you suspect something is wrong, you need to expend time and attention. When a project is failing, you need to spend some money, but you’re still in a mode of trying to get a working system installed. When a project has failed, you need to spend a lot of money, and the objective is to mitigate a big loss into a smaller loss.

Like everything in the IT world – or like every project-type work – the more effort you apply early, the better. It’s much better to catch a project when it is at “suspect” phase before it moves into “failing”. Apart from anything else, you have more options.

There’s a famous figure in computer systems implementations called Fred Brooks. He recently died, but he’s something of a philosopher. He wrote several famous essays that are still helpful to systems implementers today, but the most relevant one here is one of his invented phrases: “How does a project get to be a year late? One week at a time.”

If you are unfamiliar with how an IT project runs, missing deadlines – even if it’s just a small one – should get your antenna twitching. If you are reading this and there is a project underway and you do not know what the milestones and deadlines are, run – don’t walk – to get this information today. If you haven’t been given them by the supplier, some light panic is in order. (If they won’t or can’t hand them over, panic as much as possible – this is no time to heed the wisdom of Douglas Adams.)

The reason why missing deadlines is so critical is that although players in the IT industry make a lot of money, profitability is relatively fickle. When a supplier prices a project, they are using applied guesswork. To implement your project, they will need to buy a set amount of labour and sell it on to you at a markup and they have to estimate the “number of days that it will take to do this” figure. Small errors in the time estimates lead to reduction in profit for the supplier – and you as the customer will always pay for reduction in profit, either directly or indirectly.

IT supply is always a partnership relationship. The cost of acquiring big ticket IT solutions customers is frankly astonishing, and when one a good working relationship gets established it tends to be quite “sticky”. Your value as a customer is always looked at as being way more than the value of the project. Reduced profitability eats away at the relationship in quite insidious ways, and the supplier knows this – as a result, most suppliers will do anything they can to preserve profit. Ergo, most suppliers get very, very good at getting their estimates right. An incorrect estimate – which to you looks like a slipped deadline – is your first indicator that something is going wrong.

There can, of course, be innocent reasons why a deadline slips, but to govern the project well there has to be checks and balances, and that has to be bilateral. Healthy suspicion early on is always rewarded by a reduced chance of project failure. Being an informed customer is the Number One skill you need to develop when it comes to increasing the chances of successful IT project delivery.

There are other ways to pick up that a project may be in a suspect state and on its way towards failure, but this is by far the easiest one. To summarise, a) don’t trust it when a deadline slips, and b) be mindful of the commercial footing that the IT supply relationship is on from the supplier’s perspective. They’re not a charity, and a project slipping makes them start to look like they may be having to operate as one.