Are you familiar with the TV show “It’ll Be Alright In The Night?” It’s a TV bloopers show, presented nowadays by Griff Rhys Jones, where the mistakes of the great and the good of the acting and television world are broadcast for a laugh. This last few weeks alone I’ve come across so many IT Project Management mishaps that I’m going to pitch a new show called “IT’ll Be Alright On The Night”.
Thing is, it’s no laughing matter. The bloopers highlighted here are all signposts on the road to IT Project fail and I have seen all of these played out in the last month or so!
Although not, I hasten to add, in any of my projects … where we are blooper free.
Blooper One – The Answer Is Always “YES”
I think that this comes from the same chapter in the client relations book as the phrase ‘the customer is always right’.
Sometimes the customer isn’t right and sometimes the answer has to be ‘no’ … or at least ‘yes’ with clear and transparent consequences agreed by everyone up front.
This week I got a call from a friend who is running an IT project that was due to deliver before Christmas but now won’t until sometime in the new year. The reason is our old friend scope creep. Actually, when you drill down, the reason is not feeling able to say ‘no’ to mid-life-cycle requests to change the project – that’s what caused the creep.
My friend admits that he has a “the answer is always yes” policy when it comes to client requests. That’s fine, but what will his answer be when the client asks if the project will be delivered on time. It certainly won’t be yes.
That’s the thing, most of the time when you say ‘yes’ to something in an IT project you usually end up saying ‘no’ to something else.
Blooper Two – Don’t Invent a Sponsor
Interesting one this.
When a project has a sponsor, it has a motivated go-to person who would wrestle their own granny to sign off on a successful delivery. You have someone who feels the pains and the pleasures, someone with an as deeply entrenched, visceral passion for the project as you.
An IT Project needs a sponsor, right?
Not all projects have a sponsor. Some just have touch points and it’s a mistake to confuse the two.
An old colleague is managing a Public Sector project right now that is floundering. When the Project team call their ‘sponsor’ there seems to be no urgency, it can take a day or two to get an answer. The problem is that the sponsor isn’t a sponsor – they are a nominated contact with a whole package of other duties to attend to as part of their day to day role.
Since every project needs a sponsor, the project team elevated this poor chap. They invented a sponsor. Subsequently, when the project hits a snag the delay caused is amplified by overblown expectation. Just this last week, the project team asked for sign off on an issue on the Tuesday. It was a ‘job stopped’ moment and the kind of thing that I’ve had passionate sponsors give same day approval for. The team had built in extra time for moments like this but when I spoke with my friend at close of play Thursday he was still chasing a reply and his team were getting frustrated.
Seeing things from the contacts point of view, he is a nine to five salaried purchasing and procurement manager, for him, this IT Project is probably no more crucial than the great price on janitorial supplies he has to negotiate. He doesn’t make the decision that the project team needs and every time they call I bet he is thinking, “I didn’t sign up for this!”
The team is frustrated because they have unrealistic expectations of the sponsor who isn’t a sponsor.
Blooper Three – No Return on Investment, No Mission
An IT Project that I thought was guaranteed for a green light this week got sent back to the drawing board because the proposal didn’t have a clear return on investment (ROI). Without that, the board would not proceed.
The fact that three departments were crying out for the change and that implementation would make all the firm’s employees more efficient and connected was not enough. The fact that the legacy IT systems being used had long since passed their best and one of them even required Windows XP to run didn’t have the impact expected. As far as the board could see … they worked … and “in the current climate” any expenditure needed a clear ROI.
The team is now having to create projected ROI based on hypotheticals, things like future downtime and notional improvements to productivity. It’s what Lisa in the Simpsons once called “pointless busy work.” The need for change is clear and transparent but to see it the board needs a monetary value attaching.
ROI is important but it should not always be the be all and end all when it comes to green lighting IT projects.
Blooper Four – Adding Too Many Plates to Your Plate Spinning Act
I got a call enquiring about Project Management as a Service (PMaaS) from a project manager who was, as she put it, “at the end of my tether”. When someone in your organisation is a brilliant crisis manager, it’s human nature that they become your go-to expert whenever you have a crisis.
Combine this with blooper number one and you have a real recipe for disaster on your hands.
IT departments never seem to have enough staff, this often leads to key personnel getting spread too thinly across the portfolio.
Every project should start with adequate staff to see the job through but when budgets don’t allow for this a more creative solution has to be sought. PMaaS can deliver Project Management, Technical and Service Delivery Professionals through a flexible, on-demand resourcing model.
Inevitably, spinning too many plates leads to a calamitous crash or staff burn out!
Blooper Five – Service Level Agreements are the Only Measure Of Success
There is a temptation to write up SLAs, get everyone to sign up and then make that the only benchmark for success.
When an IT Project is held to account, in this way alone, you miss out on the potential benefits that come through human relationships.
As with any “contract”, there is the black and white, literal meaning of the words and then there is the spirit of the contract. When you have a relationship built on trust both sides tend to be more open to working together to find a solution to a problem.
However, when SLAs become a stick with which to beat ‘the other side’, erosion of trust can quickly occur to the detriment of project outcomes. ‘The other side’ is actually the way that a sponsor referred to his colleagues in the IT department on a project recently!
Governance is important and SLAs have their place, but use them to govern process, and treat people the way you would expect to be treated yourself.
In conclusion, IT Projects are hard enough without simple errors and easy to avoid mistakes making it any harder. These five things happened across just a few weeks, imagine how many unchecked mistakes are robbing projects of the outcomes that they deserve! There is a universe of Project Management as a Service assistance available, that’s skills, people and resources already and waiting to help. Don’t wait until Griff Rhys Jones turns up.
Find out more about Project Management as a Service from Stoneseed