When a Project is Falling Apart

We’ve all been there.

The project manager is complaining about the consultants. The stakeholders are dissatisfied with the project manager. The software vendor has “concerns” over the likelihood of the team making its deadline. And the project update meetings go off-track in minutes.

Net, net: the situation is bad and you have to get involved.

It’s Always Someone Else’s Fault

It’s funny, but nearly all bad IT projects have one thing in common. When you ask anyone involved with the project about what’s wrong, they always blame some other person or group. It’s always the other guy’s fault.

And is that really so surprising?

Not at all. No one wants to take the blame when things go badly wrong, so we push that blame onto others, just to make sure no one considers us the guilty party.

Unfortunately, playing this blame game rarely fixes a problematic project. For starters, project problems are almost never just one person or one group’s fault. And, what’s more, it’s never up to just one person or one group to solve these problems. To fix a problematic project, everyone needs to work together and harmoniously.

In short, fixing these projects requires wading into a thorny nest of politics before you can start to address the project’s actual issues. Playing politics isn’t much fun for IT folk, and successfully navigating the many personalities and priorities bundled with a problematic project is a difficult challenge.

But, difficult or not, handling the political side of a failing project is necessary.

So, how do you get to the heart of the issues on a problem project and help everyone see the situation a less personally?

Leave the Blame Game Behind

I know what you’re thinking… it’s just about that time in the article when I should offer up a checklist. Or maybe I’m give you a pithy set of rhyming “action items” to help you remember what to do.

But you don’t really want all that, do you?

Of course not. And I don’t really want to give it to you either. I hate that stuff, too.

Instead I’ll share a case study from a client who faced this same situation and resolved it with the below email:

——

Dear Every Aggrieved Member of this Floundering Project,

I’ve been hearing concerns from everyone involved in this project about our ability to deliver on our commitments, and to a certain extent, even what those commitments are.

So, since I’m a believer in listening and learning . . . can I ask each of you to list your three main/biggest/most threatening concerns.

I promise to hear all of your concerns, but it will be interesting to first see what the most pressing concerns are for all of us and then proceed from there.

I know some of you may not want to copy everyone and that raising issues sometimes causes people to defend their position. So, just reply to me on this request and I will consolidate the responses and send them to the group. Then, we’ll meet (briefly) and review.

OK?

Just the top three, please . . . the issues that have the most significant likelihood to derail the project and/or delay our timelines.

Thank you everyone

——

What Happened Next

My client wrapped up the problem and the solution in one tidy communication:

• Have everyone list their top problems.
• Compile and combine everyone’s top problems.
• Address and resolve these top problems as a group.
• Suddenly, the project has rebooted—and it’s moving forward again.

This is truly best-practices IT management.

P.S. Thanks, DL.