Dealing with the Doomed Project

Yesterday I was asked this question by a member of the Project Leadership Network – it’s such a good question I wanted to share it with everyone:

“When you work for a software consultancy SOMETIMES there isn't much choice over which project you take-up. Sometime we get so-called 'doomed' projects wherein the customer has tried his level best and when the deadline was right in his face, decided to cry for help to a software vendor. In such situations, what are the things we need to do to safeguard against failure of the Project?”

Here are my thoughts – I’m sure that there are many other prespectives too, so please feel free to comment:

“I'm familiar with the situation of taking-on a "doomed" project, in former roles I've been there myself - at times I've even specialised in being the "white knight". But remember that these recommendations are based on my experiences and assumptions about the situation you've described. Here's what I would do:

“First identify the stakeholders for the project, but don't stop asking at the first set of responses; there are often hidden stakeholders. Once that is clear, I would say that the most important thing to do is ask lots of wide-ranging questions of the stakeholder group and the internal group that allocates the work to you.

“Create a time-box for yourself to conduct this investigation, so that the client’s expectations are set reasonably.

“The key thing to avoid is placing blame, but also avoid becoming partisan in your allegiances in the client; as a new player in the "game", there is every possibility that you are getting embroiled in a political quagmire. (As you're probably aware there are few technically impossible software projects; they tend to fail for other reasons.)

“Identify some previous successes from the project and emphasise the good progress that has been made - in this way you should be able to defuse the failure/blame/disassociation spiral. Start to manage the client's and team's perceptions of the project.

“Look for specific answers about what constitutes success, and what are the consequences of success and failure. To define it as failing, the project must be time-boxed, resource-boxed, and scope-boxed - however it is rare that all of these "boxes" are vital. Try to understand the reasoning behind their priorities. Clarify the highest value adding outcomes, and focus on delivering them - get the easier ones done first; look for quick wins.

“As the leader of a project in crisis mode, you have leverage - you can use the urgency of the situation to your advantage, to gather the best people around you.

“Naturally, you will want to ensure you organisation is protected with the right sort of client agreement; the client is in a poor negotiating position, and this should enable you to isolate yourself substantially from the outcome, or take on risk aggressively if you are convinced success can be plucked from the jaws of defeat.

“If you are not the leader of the project, you should take your time in discussions about whether you should be assigned to it. As a talented resource you have more negotiating power than you might expect, but be careful not to over-play your hand. If you take it on, be sure to document your concerns going in, so that the risk is acknowledged.”

(My legal folk tell me I have to say this: This advice is offered without prejudice. I hope this has been helpful; stimulated thoughts at the least.)

Tags: Coaching, Project+leadership+network, Doomed+Project