Mani Masood
I’m not one of those who is unrealistic or oblivious about ‘the truth’.
I accept, maybe a bit reluctantly, that companies need to try and manage the way they’re perceived by the outside world. We all do that to some extent and companies aren’t any different. So, I can live with the fact that they’ll sometimes put a particular ‘marketing spin’ on something to make them look better or maybe just less bad.
Yet a line in the sand needs to be drawn when the ‘marketing spin’ goes on internally within an organisation specially on IT project failures.
An unwelcome surprise
Let’s call the source of this story ‘Bill’. He’s an experienced IT project auditor – which basically means he goes in to IT projects and checks that they’re being run in accordance with all quality and best-practice governance standards.
He was asked to go and inspect a big combined business and IT project that was due to go live in about 2 months’ time. By ‘big’ here, we’re talking a seven-figure budget.
Initially, he got lots of co-operation from the team. However, his experience told him that there were a few warning signs – fidgeting from the project manager, evasion, key documents that couldn’t quite be found, team members looking a bit ‘down’ and so on.
As he dug deeper, the true magnitude of the catastrophe started to become clear.
The software and processes weren’t even remotely close to being ready and there wasn’t a snowball’s chance in hell of meeting the delivery date. Standards had been abandoned, the budget was shot to pieces and the ordinary team grunts were demoralized.
Worse, progress reports had been sanitized to such an extent that the business sponsors and IT executive management were both still laboring under the impression everything was going well.
The problem was, a couple of executives at the top of the project had simply been increasingly living in ‘dreamland’ and deluding themselves – that’s why they’d been cutting corners to try and save time.
They still thought they’d ‘somehow’ make it while all of their techie team were desperately trying to tell them otherwise.
Bill described it as the worst piece of project mismanagement he’d ever come across and one which had resulted in a project that was so badly off-track it couldn’t possibly be retrieved. It really would be a case of demolishing it down to the foundations and starting again – very probably a 12-month hit on the planned delivery date.
Taking his conclusions to the IT executive team, he summarized the position as best he could.
Let’s focus on what’s important
Their first reaction, perhaps understandably enough, was to immediately get security to escort the IT Project Manager and Administrator out of the corporate HQ.
What shocked Bill though was the next step.
The CIO asked for ideas on damage limitation and communication of the catastrophe to outside parties.
Bill showed his naiveté by talking about getting a joint group together of IT and the business sponsors, plus corporate communications, in order to formulate a way of informing the outside world of the delays whilst minimizing the reputational damage to the company.
How pathetic of him!
The CIO politely corrected him by saying “I’m talking about the damage limitation for my department”. He then went on to say “we need to identify a mechanism for getting the business sponsor to accept his share of the culpability for this”.
Over the next few minutes, the IT leadership team went into overdrive, asking Bill questions about where elements of the project were lacking in terms of the sponsoring business department’s input and contribution. He did so but was concerned to see that over the next quarter of an hour the discussion centered entirely round business shortcomings and not a word was being put forward relating to IT project failings.
Bill eventually stepped back in to point out that the business side of the project was broadly ready and that the catastrophic overspend, progress report lying (sorry, occasional unintentional ambiguities) and likely 12-month consequential delay, were due almost entirely to IT’s own incompetent management.
He was quickly slapped down “that’s just your opinion and there are broader issues here, anyway, thanks for your work and I don’t think you can add much more to this discussion”.
Speak when you’re spoken to
Bill says he was back at his own office within no more than 15 minutes. Upon arrival, his boss called him in to say that he’d just heard a summary of events from the Director of IT and that they’d agreed all communications and management of the issue going forward would come out of IT.
The message for Bill to shut right up was loud and clear.
Spinning the night away
Over the next couple of weeks, Bill saw a very professional campaign of misinformation and half-truths released by the IT guys.
The news was delivered to the sponsoring department along the lines of IT had been reluctantly forced to call a halt to the project and re-schedule due to a marked lack of input of specialist skills from the business. The dismissal of the IT PM was attributed to him having been “too easy going” on the business and failing to draw to anyone’s attention just how the project was suffering due a lack of business resource.
This was accompanied by an orchestrated covert whispering and smear campaign relating to the business area head, suggesting he’d always been lukewarm about the project – something that was entirely untrue.
By the time the news was formally announced to the group as a whole, the business area head was pressurized by his board colleagues to ‘step up to the plate’ and take significant front-running responsibility for the disaster. At the same time, the Head of IT faded quietly into the background, making noble noises that “we’re all a little to blame”.
What’s the conclusion?
This sort of nonsense is so distasteful it’s untrue.
What’s really wrong here is that people pay little attention to key issue and planning. Attention to detail or planning both have become an over used cliche in the world, and the sad part is that while you hear about them – you rarely see them in to action or in the right way to say the least. Projects are conducted on whims, their gains or benefits to business are perceived on pipe dreams that rarely come true, and worst of all most people involved in the project have no idea why they are doing the thing they are doing.
A key take away from experience is every effort (not just project) should be put through a litmus test of cost and business justifications. “What problem am I trying to solve?”. If the solution of this problem does bring genuine savings in time, effort or cost to the organization it should be considered otherwise it should be revisited barring some exceptions, like a project bringing a technical edge but no cost, effort or time savings.
Mani
