Which of the following are classifications of the engagement level of stakeholders?

Since this Process Group Task “2.4 Engage Stakeholders” is about stakeholders who are people, it should be no surprise there is considerable overlap with the content in some of the People Group Tasks. These include 1.9 Collaborate with Stakeholders, 1.2 Lead a Team, and 1.8 Negotiate Project Agreements. However, rather than send you over to those tasks to read about them, the key points are repeated here.

Stakeholders are anyone affected by our project or anyone who can affect it. They can be individuals or groups. The PMI definition of a stakeholder is “Any individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project, program, or portfolio.”

Stakeholders include:

• Sponsors and executives who envision and commission new products and services, or fund changes to existing ones
• Team members who help analyze the work, define what is required, then build and deliver the project outcomes
• Business representative who explain what is required and provide feedback on work products
• Customers and users of the new or modified products and services who use it
• Vendors and suppliers who help deliver portions or significant components of the solution
• Other stakeholders such as advisors, reviewers, subject matter experts and third party contributors

While these stakeholders act as their own communities, projects bring them together as a single ecosystem.

We need to understand the stakeholders within our project ecosystem. This includes understanding their attitudes, requirements, influence and authority. Then create a plan to engage with them.

Stakeholder Identification

Activities to identify stakeholders include:

The usual suspects – Review each of the common Stakeholder Groups categories and list who is impacted or can influence this project.

Ask the team – Take the same questions to the team, ask them to individually, then collectively brainstorm who the project stakeholders are.

Surveys and questionnaires – Ask other stakeholders to tell us who we may have missed. Using surveys and questionnaires, we can canvas relevant stakeholders for their opinions on additional stakeholders or stakeholder groups we should consider.

Document analysis – Look at the other project documentation that might already be available such as the project charter. Anyone or group identified will be a stakeholder. Also, review the risks, assumptions and constraints. Do any point to people or groups we should be considering? Refer to other project documents that share some common characteristics. Review their stakeholder registers, lessons learned, communication plans, risk and issue logs, etc., looking for stakeholders relevant to us.

2.4.1 Analyze Stakeholders

Analyze stakeholders using approaches such as Power Interest Grid, Influence, Impact, etc.

After we have identified our likely set of stakeholders, we should gather information about them. Such as are they in support of our project or opposed to it? Also, do these people possess significant influence or impact on the project outcomes or other stakeholders? Understanding these characteristics will help us better plan how to communicate and engage with them during the project.

Some popular approaches for stakeholder analysis include:

Power/Interest Grids

These are plots of stakeholders categorized on a grid showing their power to influence the project on one axis and their interest in the project on the other axis.

(There are a few permutations on these grids. Sometimes instead of plotting power and interest on the axes, they may plot “Power and Influence” or “Impact and Influence,” but the concepts are the same.)

Salience Model

The Salience Classification Model is a way to classify stakeholders based on the three attributes of

• Power – their authority
• Legitimacy – how appropriate their involvement is in the project
• Urgency – their immediate need

Where these influence circles overlap, we get subgroups of Core, Dominant, Dangerous and Dependent. Stakeholders in the central Core area need the most attention since they have power, legitimacy and urgency. Your project sponsor would be an example of someone with Core influence.

As we move further away from the Core, the strategies for working with people can flex based on their influence and the project needs. Stakeholders in the Dominant, Dangerous, and Dependent regions still need plenty of attention since they mix two influence factors. The outer Dormant, Discretionary and Demanding groups would typically be served third, behind the other groups.

The Salience Model is a useful classification tool. It helps us consider stakeholders based on their level of authority (Power), how appropriate their involvement is in terms of the project (Legitimacy) and their immediate needs (Urgency.) However, in real-life, personalities often have a strong influence on how much attention we need to dedicate to them to be effective.

During the Stakeholder Analysis of a project, we:

• Determine which stakeholders to manage closely and which will require less effort
• Determine the level of participation required from each stakeholder
• Document the interests and motivations of stakeholders in a project
• Identify the stakeholders that can make the project unsuccessful
• Look for any conflicting interests and relationships between stakeholders
• Determine communication strategies and medium best suited for each stakeholder

This analysis helps us focus our time and energy on the stakeholders that can make or break the project. It also allows us to create a communication and stakeholder strategy.

2.4.2 Categorize Stakeholders

Once we have identified the likely stakeholders and assessed their characteristics such as power and influence, these details get recorded in the Stakeholder Register.

Stakeholder Register

Stakeholder registers typically contain the following information for each stakeholder or stakeholder group identified:

• Name
• Contact information
• Project role
• Project requirements
• Outcome Expectations
• Impact and influence scores
• Likely attitude about the project
• Stakeholder classification
• Associations

In the example above, we see basic contact information for the stakeholders along with their role, requirements, likely concerns and measures for their potential Impact (low, medium, or high represented by the black circles) and their likely influence (low, medium or high shown by the black squares.)

Agile projects tend not to create detailed documents recording all the project stakeholders. Ironically, for approaches that encourage adaptability and experimentation, they typically have more static roles and recommendations for engaging stakeholders. For instance, the Product Owner decides on release candidates and priorities.  One document type that is commonly produced is customer personas.

A persona is a description of a customer that helps keep their goals, requirements, concerns and frustrations in focus to the development team. So, while more a requirements aid, it does describe some of the same information as a Stakeholder Register.

2.4.3 Engage Stakeholders by Category

After identifying and analyzing the project stakeholders, attitudes or support may not be where they need to be for project success. A tool for collecting and presenting engagement levels is a Stakeholder Engagement Assessment Matrix.

Stakeholder Engagement Assessment Matrix

A stakeholder engagement assessment matrix allows for a comparison between the current engagement levels and the desired engagement levels of stakeholders for successful project delivery.

The engagement level of stakeholders can be classified as follows:

• Unaware – Not aware of the project and its potential impacts. (“What is the Trough Chow project? I have never heard of it”)
• Resistant – Aware of the project and potential impacts, but resistant to it. These stakeholders will be unsupportive of the work or goals of the project. (“That pig feeding project is a lawsuit waiting to happen, and don’t get me started on the poor message it sends about measuring food intake!”)
• Neutral. Aware of the project, but neither in support or opposed. (“Oh, yes, I have heard a little about it”)
• Supportive. Aware of the project and supportive of the work and its outcomes. (“I think it is a useful opportunity to boost visitor satisfaction, visitation and should pay for itself quickly”)
• Leading. Aware of the project and actively engaged in making sure that the project is a success. (“This is great, a hands-on experience no online or large-scale zoo can compete with. It plays to our strengths”)

Once we know where our main stakeholders stand on the project, we next need to plan a strategy for stakeholder engagement.

2.4.4 Develop, Execute and Validate a Strategy for Stakeholder Engagement

Our stakeholders include the team, and the items within the WBS or product backlog represent much of what we will do. Likewise, Team Charters, Team Ground Rules and work procedures explain how we will engage with the team, but what about all the other project stakeholders? How will we engage with suppliers, sponsors, customers and all the other people and groups we identified in the Stakeholder Register?

Guidelines for engaging stakeholders include:

Create a shared view of the goal

Unite people with a common view of where we are trying to get.

People must understand and share the same vision of “Done” for the final solution and ideally incremental steps. So, spend time ensuring everyone knows where we are trying to get to. That way, when faced with their own local decision points, or forks in the trail towards project completion, they make decisions aligned with the larger goal.

Maintain the shared vision of success

Frequently remind people about where we are trying to get to and why it is essential that we get there.

Product and project priorities can change quickly. People come and go from projects, and the market is continuously evolving. With all these changes occurring, we must frequently remind people of where we are trying to get to and why that is important. So, don’t let the end goal shift or become fuzzy in people’s minds. Align their expectations towards the success criteria to keep the end goal clearly in focus.

Share progress, good and bad

Share information. Make sure people know what is going on, whether this is good news or bad news.

It is crucial to be open and honest about progress, issues, and threats. People are astute and recognize if things are not being discussed. They will begin to withdraw their wholehearted commitment if they feel information is being withheld. So share information, both good and bad, with the team and business representatives –  often people surprise us with novel solutions to problems. People want to know what is going on, and we should be able to discuss topics openly.

Share forecasts to help planning

By sharing accurate updates on progress, we help people plan their work and improve their ability to prepare for the future.

When sharing forecasts and plans, we also need to share our levels of uncertainty. Future predictions are more useful when we also know the uncertainty connected to them. This can be achieved by including a confidence level, such as +/- 10%. Or using a hurricane path graph that shows the expected path for a metric with a widening margin of uncertainty the further we go into the future.

Build required involvement in project plans

If people are needed for activities, make sure they are included in the project planning. Ensure they know they are part of the plan and failure to do their part will impact that activity. Consider adding them to the critical success factors for the project.

If there is a risk that their failure to act when required might impact the project, create a risk in the risk register to reflect this. However, do not wait for the risk to become an issue. Instead, prime and confirm planned participation ahead of time. Contact them before they are needed and check they are ready to participate. It is easy for part-time roles to forget what they agreed to, when they are required, or the impacts of their no-show.

Don’t forget to thank them after their contribution. Sure, it might be their job to assist, but creating small circles of goodwill can pay dividends to help future contributions and change acceptance.

Frequent Communications

The most common way we interact with stakeholders is through communicating progress, issues, status and other metrics. The Communications Management Plan is a critical document on traditional, predictive projects to explain how stakeholders will be engaged via project communications. It describes the format, frequency and distribution channels that will be used for communications.

Agile Communications

 Given the high rates of change often experienced on agile projects, we might expect more emphasis on communications to keep everyone on the same page. However, agile projects do not create communication plans. Instead they favor these strategies

Show, Don’t Tell
Despite the lack of a formal communications management plan, agile approaches emphasize communication and information sharing extensively. In fact, transparency and sharing of information are baked into many of the agile practices. Let’s examine a few…

• Demos – Having the team demonstrate increments of functionality at the end of every iteration shows what the project has achieved to date. The demonstrations are often accompanied by project spend summaries and updates on expected completion dates. Together they provide a snapshot of progress and an opportunity for business representatives to ask questions and provide feedback.

Agile projects frequently surface to show progress and discuss issues. They are like dolphins, frequently surfacing never too far from where they last submerged.

Predictive projects may have less to show the business and so have an increased reliance on communication management plans to keep everyone informed. After kickoff, a traditional,  predictive project might be busy in analysis and design for long periods with only internal deliverables to show for their work. In these circumstances, agilists claim they behave more like submarines, disappearing from view for long periods then emerging to present the solution. 

Communication Realities
The dolphins-and-submarines analogy is a cute starting point to help explain some of the differences between traditional and agile communication styles. However, real-life projects are usually more complicated. Traditional projects that incorporate a proof-of-concept phase resurface and show progress. Phase-gate reviews may not demonstrate increments of a solution, but they are planned review points to assess progress, issues and funding. So in reality even traditional projects behave more like whales surfacing more regularly.

• Kanban boards – The concept of “make work visible” is applied on agile projects to show what tasks are being worked on currently and the status of pending and completed items. Since knowledge work is often novel or unprecedented in the organization, it helps to have visual cues for it so people can point to it or examine its position on a Kanban board to determine its status in the development process.

• Information radiators – A common theme across agile approaches is to show and share information. XP has the practice “informative workspace,” Scrum encourages “transparency,” and Kanban development talks about making “process policies visible.” They all promote graphing and sharing information—both good and bad—via large charts and graphs known as information radiators.

Information radiators can show any data the team wants to display. They are used by the teams but also shared broadly with other stakeholders. Development team members, rather than a project manager, typically create these information radiators and, in doing so, broaden the set of stakeholders reporting on the project.

• Daily stand-ups – Daily stand-ups are short (15 minute) meetings where team members share their progress, plans and raise any issues or impediments they have. It is an inter-team communication session rather than a reporting up of status to a scrum master or project manager. It facilitates collaboration, load-sharing and team planning. Other stakeholders may occasionally drop in to observe, but the goal is to help team members communicate among themselves.

• Retrospectives – At the end of each iteration (typically every week or two), the team members meet to review how things are working and if any improvements can be made. This meeting is another scheduled event focused on information sharing.

The Agile Alternative to Communications Management Plans
By having multiple communication-focused events as part of the core agile practices, it removes some of the need for creating a separate communications management plan. Instead, people working in or with agile teams know there are events like demos, stand-ups and retros they can attend to learn about project performance. Likewise, there will also be task boards and other information radiators available online to get project metrics.

Downsides to Agile Information Sharing

Not everybody can attend a demo—nor wants to watch a recording of one to get a single question answered. The data on agile information radiators may not make it to all interested stakeholders, and pull systems for providing project data from websites will only work if people request (pull) the data.  To overcome these issues, organizations sometimes adopt hybrid strategies.

Hybrid Communications

It is normal and often necessary to schedule additional demos or review points within predictive projects. It may also be required to create communication plans for agile projects, especially those with distributed stakeholders. We should not assume that just because the information is available that it is being consumed or understood.

So, while agile projects frequently surface to show their progress and predictive projects can seem to disappear sometimes if we do not keep close tabs on them, we need to ensure stakeholders remain engaged. We need to ask people how they want to hear about the project and ensure they know where to find the information. Check-in with them to make sure they were able to access and interpret it correctly.

We can use retrospectives and surveys in any project to learn about communication needs and wants. Given that the cost-of-change curve ramps up quickly, it is better to know about good news and bad news (in particular) as soon as possible. So, we need to keep communicating and keep asking for feedback.

Deliverables and Tools

• Stakeholder register
• Stakeholder engagement plan
• Assess work performance information
• Organizational process assets
• Expert judgment
• Meetings
• Power or Influence vs. Impact Grid
• Interpersonal skills
• Management skills

Related Topics

• 1.1 Manage Conflict
• 1.4 Empower Team Members and Stakeholders
• 1.5 Ensure Team Members and Stakeholders are Adequately Trained
• 1.7 Address and remove impediments for the team
• 1.8 Negotiate Project Agreements
• 1.9 Collaborate with Stakeholders
• 1.10 Build a Shared Understanding
• 1.11 Engage and Support Virtual Teams
• 1.13 Mentor Relevant Stakeholders

Further Reading

• Article: Agile Communication Plans

What are the 5 engagement levels of stakeholders?

Which of the following are stakeholder engagement levels?

What are the types of stakeholder engagement?

What are the 3 steps of stakeholder engagement procedure?