Fallout Strategy for IT Project Managers

When an IT project goes wrong, the project sponsors have a right to ask you, the project manager, tough and incisive questions, especially when it’s the public’s money or their personal reputation on the line.

How to handle the blame game

If the project bombed in spectacular fashion then the post-project autopsy can quickly turn into an interrogation, rather than an intelligent review or inquiry into what and why it went wrong, what to do about it now, and how to do better next time.

Witch hunts are all the more common if a key part of the project failed e.g. the scope crept way beyond the initial mandate, the funding went seriously over budget, or the IT system suffered a security breach. None of these things may have been your direct fault but because you are the project manager you are rightly or wrongly presumed to have the answers.

Whatever the questions or accusations, you do of course have a right to reply, asking questions of your own and giving answers to explain and justify your decisions. That is fair, that is reasonable. Even so, being in the spotlight and facing the prospect of being labelled a scapegoat is risky business. Alan Sugar’s wannabe apprentices are a shining example of fair weather team members being far too willing to stick the knife in and blame the project manager for everything, as though they were meant to be all knowing and all seeing and capable of solving each and every problem the project faced.

Invite people to take a very close look at what went wrong and why

In spite of the risks, and speaking as an experienced project manager myself, I’d say close scrutiny and accountability is nothing to fear, if anything your best strategy is to embrace it. Bring it on. I’m never too proud to learn from my mistakes, try harder, and do better next time. If you’re a good PM you shouldn’t be either. If that sounds pious or at best naive, think of the alternative. If you dodge questions or give deliberately obscure answers, that will most likely invoke accusations of “there’s no smoke without fire!” If that happens you’re as good as guilty. Taking an obstructive approach will frustrate and rob your audience of the will to listen to anything other than their suspicions, false or otherwise.

So how should you handle close scrutiny? How should you respond to questions that seek to understand what went wrong and yes, apportion blame? The five things I can think of that serve me well and could serve you well include:

Define the scope - Ask to help define the scope of the review. Say that no stone should be left unturned. If it’s going to be a full and fair review then everything should be up for grabs right from the wording of the sponsor’s mandate to the point it all collapsed. If it’s only going to be a review of your performance then it’s probably a witch hunt.

Describe your authority - In general, as project manager you should only ever implement what has been signed off by the sponsors. If the sponsor signed it off, they are accountable for their decision but if their decision isn’t in doubt, the question then becomes “how well did you execute their decision?”

Describe your role - You sit between the rock and the hard place. You alone have to take a wishlist from the sponsor and somehow turn it into a tangible product or service. Coordinating and tying together multiple pieces of the puzzle, sometimes poorly defined and rapidly moving pieces, that job is incredibly hard. But the people asking the questions are unlikely to understand just how hard it is unless they’ve done it themselves, so you have to describe it. Then they’ll be able to understand the context of your decisions and the intensely complex balancing act you do. If you don’t give them the context, they’ll add their own, however ill-founded.

Double check everything - did you do everything you should and could have done, especially to avoid the most common pitfalls? Go back through your project, from the general to the specific. Review your checklists and plans - did you follow all the steps? If not, make sure you have a clear answer to explain why not. With respect to the examples above: if the scope changed, did you ask your sponsor’s for guidance? If spending was out of control, were the right controls in place? If there was an IT security breach, when was an IT security health check last carried out?

Basically, was everything in good shape to begin with?

Tackle hindsight - "Life can only be understood backwards; but it must be lived forwards." This quote by Soren Kierkegaard says it all. When you start an IT project you are looking forward, trying to understand and plan how to get all the things done that need to be done, and defend against all the things that could go wrong. But you cannot predict the future. You cannot always know everything or foresee all potential outcomes or risks. Sometimes the true nature of a project or a problem with it only reveals itself halfway through. Sometimes only at the end or not at all.

Your perspective as project manager is unique. Only you can truly know if you should, would, or could have done things differently. Anyone else looking back upon your actions does so without the benefit of having been in the situation you were in, without being under the pressure to make decisions that may, in hindsight, have been based on nothing more than anecdotal experience or instinct - but that doesn’t make them wrong or poor decisions.

All you can really do in the moment you are managing is decide what to do with the time and tools you have available to you then get on and do it. No project is perfect.

By Lee Carnihan - Rock Paper Digital Nov 18, 2013