22 May 2007

An Introduction to Stakeholder Management

The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtual teams, across matrix companies, they may be stakeholders, as their roles extend to beyond the project. They are thus committed more to their local business unit than the project’s success and have an impact on whether the project goes ahead and whether it is considered successful.

When tackling stakeholder management ask yourself what you are trying to achieve with stakeholder management. The bottom line is that you are trying to improve the project's chance of success. And you are doing it through analysing and understanding stakeholder needs, which may become either requirements or constraints, and communicating them effectively back to the project team (and sponsor.)

The cycle of stakeholder engagement
You don’t just do it once, either. Stakeholders needs and priorities are constantly changing as the environment around them changes, and as they learn more about your project. This is especially pertinent to projects that span many months or years.

So, to be effective you need to manage stakeholders cyclically. Here is a four step cycle you could follow when managing stakeholders.

Who will be impacted? Who are the decision makers in that area and who are the subject matter experts? A good technique to apply to identifying stakeholders is to ask each one you do find to nominate others.

What are the impacts? When do they occur? How does the impact affect the stakeholder?

You need to manage stakeholders’ requirements and manage them through the constraints (time, budget etc.) Make sure their expectations are set appropriately and that you don’t over promise on the solution.

On a regular cycle go back and check with your existing stakeholders whether things have changed. Are there new stakeholders? Have impacts changed? Have priorities changed? The more frequently you are in contact the quicker you will pick these issues up and be able to deal with them.

An aside: I like to model stakeholder and communications plans around the ADKAR framework which drives you to see your stakeholders multiple times anyway, but then you are integrating change management and stakeholder management and that’s a more advanced discussion.

Importance v Supportive
Neville Turbit has an article on the concept of mapping importance and supportiveness. This is a variation on the influence and engagement paradigm. In this model there are two key attributes

  • Importance (influence)
  • Supportive (engaged)

Usually they are mapped into quadrants and you have an action plan for each quadrant. Neville expands the theory and maps it onto circles of importance and supportiveness creating a more tiered effect with room for more flavours of action plans.


  • If someone is important but not supportive they are a risk to your project
  • If someone is not supportive but they are not important, they are less risky for the project.

Read more about this stakeholder management framework at Project Perfect.

No comments:

Post a Comment