This post discusses the most urgent part of a project to stabilize, stakeholder management. It has served me well always to start here. This means that you should concentrate your time on finding and fixing the big problems with stakeholder management ahead of all other areas of a project in trouble.
Why have I found that stakeholder management is the most urgent of all? If you cannot be confident who the key stakeholders are, what their top concerns are, and how you will meet their expectations for timely & informative status, then nothing else matters on the project. If confusion about stakeholders goes unanswered, you might as well give it all up and walk the Appalachian Trail looking for the meaning of life. In the end, all projects start and end with the stakeholders. Everything else serves this.
Maybe it’s just intrinsic to the species. We are, after all, a social animal with an exorable tendency for stratified social dynamics. In any village, in any herd, in any company, and on any project, someone is the alpha. Anyone who thinks a team can run without leadership hasn’t actually been part of a team. On a well-run team, project direction originates with the key stakeholders and project status goes back to them. Key stakeholders are not just the alpha; they are the omega.
As an example, I was part of the replacement management team on a project to develop a custom product for an external customer. The contract was fixed-price. Part of the project malaise was that unmanaged, close involvement with the external customer led to a loss of control of the requirements. It’s no revelation to the world that lack of control over requirements on a fixed-price contract is really bad for business.
So what does this have to do with stakeholder management? Doesn’t this example just show the need to manage the requirements better? Yes it does. In fact, requirements volatility was a really important problem. But it was actually not the most urgent problem. Let me explain starting with some fundamentals.
In the contract business, it is common for the contractor to fund the work. The external customer then reimburses the contractor at payment milestones. Because the contractor funds a project, the project sponsor is not the external customer. A project sponsor is internal to the performing company. But on this particular project, this really important point became blurred. The project staff began to bypass the sponsor and established process to cater to the external customer. Serious disarray in the stakeholder management was a root cause of the requirements problems.
So in rescuing a project, you must really nail with unmistakable clarity who the sponsor is. For that matter, you must also nail who are key stakeholders and any negative stakeholders with significant influence. It must be clear enough to put in clear terms in your project status. (You might not actually put it in writing, but it must be that clear to you.)
Much has been written about project stakeholders and how to manage them. Broadly generalizing all of this information, a project manager’s responsibilities fall primarily into two categories, stakeholder analysis and stakeholder management.
Stakeholder analysis is fundamentally for identifying who they are, what each hopes to gain from the project, what influence and authority they have, what direct involvement they expect to have, and to include them on status, issues, and decisions. Managing stakeholders is a very broad category because stakeholders range from full-time members of the project team to external individuals with only a passing interest to by-standers who stand to gain from the projects failure (known as negative stakeholders).The project manager is not necessarily required to execute all of this personally but is responsible for seeing that it is done and done effectively.
To continue with my example, we worked as the team to clarify that the requirements were firm. Anticipating that the customer would become frustrated with this change, we coached the team on how to manage this transition with the customer. And then, we completely supported the team in this tough, new role. This support went all the way up to the division president. In a short time, the team was convinced they had management’s support and held firm.
Before we tried to tackle the requirements problem, we first fixed the stakeholder problem. Both were very important. The stakeholder issue was more urgent. If I had tried to tackle the requirements problems first, I would not have truly fixed the problem. The root cause of requirements problems would persist and continue to cause conflicts. By analogy, if you treat infection from a splinter without also removing the splinter, the splinter will continue to re-infect the area.
As you meet each stakeholder, find out exactly what is truly important to them even if it’s supposedly already captured somewhere in the project documentation. Get it from them in person. It’s okay to ask the uninformed questions when you are new. Actually, it’s your last chance to ask dumb questions. So get right on that.
There is inevitably some down time when you can’t proceed with stakeholder analysis. Usually, it’s because you are waiting for access to people. You can use this time to ramp up on the project in general or to get starting on #2 in my list (see next article). But the instant you can make more progress on getting your stakeholders all squared away, set aside these other tasks.
You could get lucky and find that the stakeholder priority is really all set. In other words, you search and interview and dig only to find that there is nothing here to fix. The odds are against it, but it could happen. Be open to the possibility that you will turn over all the stones and find nothing. Even if this happens (which would be great news), stakeholders are still the best place to start when rescuing a project.
Here’s a pitfall to watch out for. When you are brought onto the project, there are usually a few people to help you ramp up. They will advise you of the stakeholder situation so you are armed with this critical information. The pitfall is to accept this information at face value.
When a project gets into trouble, one or both of two things have happened with the key stakeholders. One is that the team has lost sight of what the key stakeholders have been saying all along. The second is that the stakeholders might have changed their expectations to adjust to the new business reality, and these changes were not communicated faithfully to the team.
You are done with this part when you now have a relationship with each of the stakeholders, you know the stakeholder problems, and you have fixed all the big ones. Once you are satisfied that the stakeholder management is in good shape, you can shift your focus to the next most urgent part of the project, which I cover in the next post.
(Stay tuned for part three of this series, later next week)
I highly recommend Bob’s whole series on this blog discussing project rescue. I’ve been doing program management for over 23 years and was wowed by how well Bob’s articles solved a problem that was really happening in my present role. The series hit so many nails on the head in so many ways. He immediately answered questions I’d wrestled with about a very difficult project I’d been brought in to run. His message about the importance of clear sponsorship and the costs of sponsorship ambiguity helped illuminate why certain decision makers seemed to operate in irrational ways. Their actions were consistent with their various evolving models of who really owned the decision making. Bob’s message about working key issues early on with top management for the project also paid dividends.