When you put the project first you put the blame game to rest

As you execute your project, you will find that things go differently than planned. Do I mean they go wrong? No, things change and to be successful you will need to adapt to the change not try to make the change adapt to you. The project technical processes used to adapt to change are risk management, scope change, and communication planning. Having a good relationship with the team and the sponsor will help you make the most out of change.

Let’s start with the team. Have you ever been on a project where the first risk management strategy is to find out who is to blame? I’ve worked on projects where it seems to be a step in the initiation phase – first figure out the scapegoat group. What happens to the team in this environment? It starts with an expectation that things will go wrong, not that the project will be successful. It puts people on guard, always taking steps to lower their profile. It kills any spirit of innovation, which means no one is likely to offer new solutions to problems. The projects rarely do more than just meet expectations in this type of environment. The lessons learned tend towards, who did it wrong, who should have done something, and every other blame statement you can think of.

If you put the project first, you can focus the team on resolutions. Things always go awry, if you can focus the team on “what happened” and “what do we do to move ahead,” no one takes the blame. Understanding what happened will start the ball rolling towards solutions. If testing failed on a process, it’s not because Joe didn’t create a great process. It failed for a reason and it needs to be fixed. If the client isn’t satisfied with the first iteration of the solution, it’s not because Mary didn’t understand the requirements. They aren’t satisfied, that’s what needs to be fixed. The words you want to hear from your team are, “ABC product isn’t working as expected because of the volume of traffic wasn’t anticipated; here’s the solution.” Definitely not, “ABC product isn’t working because Alan screwed up and you need to fix it.”

Let’s turn our focus to your relationship with the sponsor. If it’s an environment of blame, guess who wears the hair shirt in this relationship – the PM. Your sponsor knows that things change and relies on you to manage that change. So, let’s say your project budget needs to increase because the organization restructured and your key team members are gone. You can complete the work on time with contractors but it’s a 20% increase in cost. Do you say to the sponsor (even subtly) “because you laid off all these people you need to give me a bigger budget.” Or, do you say “Let’s confirm that the project is still active, if so, there are a couple of options. We can keep the same scope and probably hit the date if we hire contractors, it will cost XX. The other option is to reduce scope by XX or extend the timeline.” My guess is the first approach may add your name to the list of people looking for work; the second approach accepts reality and puts the project first with solutions.

It may or may not be reassuring to know this isn’t unique to project environments. Put this search in Google “finding solutions not scapegoats” to find all kinds of examples of this phenomenon.

Tip- I know you don’t really say the second examples, but you might say it in your body language or tone.

Change your project vocabulary

Use, “What happened?” Not, “who screwed up”

Use, “How do you think we can fix it?” Not, “How do we deal with the screw-up?”

Use “How do we avoid this in future projects?” Not, “how do I keep the screw-up off my projects?”

You’ll find people are excited to be on your project and part of a supportive successful environment if you can be successful in dropping blame.

Please visit my website and contact me if you have any questions.

Follow me on twitter

Have a fabulous day