Don’t Ignore The IT Project Warning Signs

by David Cotgreave / 3/2/2018 12:08:33 PM

I was sitting on the M1 in traffic the other day, the gantry lights above were displaying a huge red X above the inside lane, signifying that it was closed due to an accident. Most cars got over into another lane as soon as it was safe for them to do so. However, three lorries ignored the warning signs and raced past the queueing traffic and then, eventually, tried to barge in.

Those massive, unmissable red X gantry signs mean something, and it isn't that Simon Cowell or David Walliams don't like your act. They are there as a warning sign that there is danger ahead, they are there to keep all road users safe from harm.

The same is true of IT Projects, OK, the warning signs don't get lit up above your head like motorway gantry signs and some of them can be harder to spot, but they are there and, if you take notice of them, they can keep you from harm.

This is by no means an exhaustive list but, off the top of my head, these are just five IT Project warning signs that I've witnessed just over the last year or so. I'd love to hear from you about warning signs in your IT Projects and whether you heeded the warnings or not.

1 - Scope Creep

The thing about scope creep is that it is rarely one huge stakeholder request that causes damage to a project. It's called creep because it's a number of seemingly insignificant requests that gradually chip away at your timescale or eat away at your budget.

Project Managers are, on the whole, accommodating souls who like to be able to say "yes". That can do attitude can be your downfall. This was the case with a project I was asked to run an eye over last year. A fairly innocuous request from a key stakeholder was incorporated into the schedule, it took an hour or two, diverted a team member away from their current task and cost a few hundred quid from the contingency budget - but that's what it's there for.

This was fine, except that the team member who was diverted didn’t finish his task on time causing a delay to the next dependent task. These things happen and over the course of a project's lifecycle you can catch up. The problem here was that the little requests kept on coming ... and they all added up until the project was over budget and late.

That first little request is a warning sign that stakeholders or your sponsor think it's OK to tinker with the agreed project plan ... it is ... but rarely without any consequences and should never be signed off without everyone being utterly clear about what those consequences would be.

My friend joked that he thought that his sponsor thought he was a rapper called Kanye Juste, every conversation seemed to begin with "Can you just ... do this", "Can you just ... do that". He ensures that before he agrees any scope shift that potential consequences are agreed, this could be negotiating extra budget or delaying the delivery date, but he always works a scope change request in his favour!

2 - Weak Project Manager

As a CIO you should be looking out for warning signs that your project manager is, for want of a better word, weak.

Sometimes it's not weakness, per se, it can be a lack of authority or a cultural issue where project teams don't feel they can say no to a change request. This is what happened in the case above. The PM had set his stall out beautifully - there was no reason why the project would fail. BUT those requests came from the project sponsor, a quite intimidating senior executive, and the young PM didn't feel he could refuse.

It takes guts to say "no" but remember that every time you say "yes" to one thing you may be saying "no" to another.

Empower your team with the right to say "no" to or challenge a scope change request or at least set a system whereby a project team facing such a request can get advice.  

3 - Compliance

I can be stubborn at times, or so I'm told, personally I stubbornly refuse to accept that I am! Apparently, it's a Project Manager trait. We like to lead, we like to make the rules not follow those set by others. Sometimes, though we need a little reminder that the rules are there for a reason.

An IT Project that I was asked to give a view on recently failed through a pretty serious compliance breach. The warning signs were there ... the Project Manager was playing fast and loose with compliance. Breaking the odd rule here and there and that is OK, right? I suppose it is, as long as you get away with it. Those lorry drivers probably make a habit of thundering past queueing traffic and ducking in as late as possible but one of these days the cause of the lane closure is gonna come into viewer quicker than they were expecting, and then what?!

Small compliance breaches can be a warning sign of a bad habit that could one day lead to greater consequences.

4 - Limited Stakeholder Engagement

IT Projects have a lot of people with their finger in the pie, if they aren't occasionally licking those fingers and expressing their delight you may have a problem. Actually, it's a two way street. Ensuring that you engage your stakeholders, through regular updates, gives you another pair (or many pairs) of eyes that can spot when your project is off course.

This happened with a project last year that had engaged its eventual end users through regular progress bulletins. The project team had been thorough, the project had been planned and all was going well ... until one guy mailed back with an enquiry that apologetically asked if something in the bulletin was right. It wasn't but no-one had spotted it. This engaged stakeholder saved the day, and a not insignificant amount of money, time and hassle.

5 - Lack Of Business Case

Amazingly, I have seen this HUGE flashing red warning sign a number of times in recent months. I'd say it's the most important one to watch out for!

Every IT Project starts closely aligned with business case otherwise it wouldn't get a green light but things change during the lifetime of a project that can impact the level of return the business will get for its investment.

For instance, last year a team was working on a project that would have disrupted their market - everyone was really excited, the team, the board, all stakeholders - everyone really engaged! Then a competitor went and launched a product that kind of made this project look like a poor attempt at replicating the competitor's innovation.

No-one flagged this, no-one measured the ROI based on the new reality, no-one asked what the point of continuing was. If they had they'd have killed the project months before it eventually spluttered onto the market practically unnoticed.

Business case is paradoxically quite an easy and a really hard thing to measure - a lot of it is subjective - but there are clear data markers that can be leveraged to give you a running commentary on what the benefit to the business will look like upon delivery.

Business case warning signs are perhaps the most important ones to look out for.

I guess, by way of conclusion, on the roads and in IT Project Management the warning signs are there for a reason, they are there keep us all safe, and you ignore them at your peril.

Latest Book

Cover for Management of Portfolios