After you've gathered critical information about the stakeholders in your project, you'll need to make sure you use it wisely. We'll show you how to plug this information into various project stages to ensure that the project runs smoothly and ends well.
Consultants who expect to be successful often do plenty of work before the project is complete to assess the needs and expectations of the project’s stakeholders. In order to ensure that the projects I work on go smoothly and end well, I’ve developed a system for analyzing stakeholders and keeping them involved.
This system is based on three Ps:
- Process: How can I best discover the needs of my stakeholders?
- Preparation: What information do I need to collect from stakeholders, and how do I plan to use that information?
- Performance: What is the most effective way to act upon the information gleaned from the stakeholder analysis?
In this article, we’ll focus on the final “P” (Performance), or how we can best put our stakeholder data to use.
Last in a series
This is the third article in a series that examines ways to work best with project stakeholders. The first article discussed the stakeholder analysis process and the role of the Stakeholder Assessment Map (SAM) and the Stakeholder Reporting Matrix (SRM). The second suggested questions you need to ask stakeholders before the project begins.
Analyzing stakeholder data
In the final step of the upfront assessment, you’ll use the information collected to develop a strategy for handling stakeholders. A useful tool in this process is an Analysis Table, which can help you determine the significance of each stakeholder to your project. Your Analysis Table should be based on four factors: level of interest, influence, impact, and support. Figure A shows an example of an Analysis Table:
The numbers allow you to rate the stakeholders on each factor on a scale of 1 to 4: 1=None, 2=Minimal, 3=Average, and 4=Significant. For level of support, however, you can also enter a negative number. For example, if your project’s technical expert has indicated he is strongly against the project, you can score his “negative” support as well.
Use the example table above as a template to build your own project-specific table. Once you’ve listed your stakeholders in the table, circle the appropriate level for each stakeholder in each column, and total each stakeholder’s score. Any stakeholder who scores above 10 is considered a “key” stakeholder.
Strategies for dealing with stakeholders
While there are many ways to effectively handle stakeholders, the key stakeholders should always be the driving factor in any strategy you adopt. Get them to share their views about the project, and make sure you communicate with them on a regular basis.
One general strategy involves the “3 Ws”: Work together, Watch, and Ward off.
- Work together refers to collaborating with stakeholders to produce the deliverables for the project. This goes beyond just getting their input. In essence, they become limited members of the project team. This strategy should be reserved for stakeholders that have the greatest influence. Keep in mind, however, that these stakeholders may be supportive, neutral, or opposed to the project.
- Watch means monitoring stakeholder behavior for indications of possible red flags. This strategy generally applies to stakeholders who marginally support the project. They could have average to significant influence, interest, and/or impact. Consider regularly gauging the reactions of all key stakeholders.
- Ward off means implementing strategies to defend against undesirable actions or influences of key stakeholders. This strategy generally applies to stakeholders who are unsupportive of the project (indicated by average-to-significant opposition on the Analysis Table).
Putting your stakeholder information to work
Once the general strategies you feel are relevant to your stakeholders become apparent, you are ready to put the stakeholder information and strategies to use. If you’ve been thorough about gathering your stakeholder data, you should be able to apply it as I did on a recent project involving both a major organizational change and business process reengineering. Anyone who has been involved with a similar initiative knows that resistance and obstacles to this type of change can be significant.
I was responsible for first conducting a performance analysis for the customer service areas and then for recommending and managing the implementation of performance improvement solutions for the first rollout. This project was particularly complex because three regional centers had recently been merged into one, and there were labor unions involved, which meant that clear communication and the involvement of the appropriate stakeholders were critical.
We started our process by interviewing our contact in the organization to get background information about the project. As part of the interview, we asked him to identify the key stakeholders for the project and to provide what he thought were their interests in and impacts on the project, as well as their influence in the organization.
We then repeated this process with 15 other key individuals identified in the interview with our contact. Comparing information about the same stakeholders garnered from different sources helped us to cross-validate our data, giving us a fuller picture of the stakeholders in the organization.
We took this information and drafted our Stakeholder Assessment Map (SAM) and Stakeholder Reporting Matrix (SRM), analyzed the results, and applied it to the project.
Here are a few tidbits we learned along the way that proved useful:
- Make sure all stakeholders get the same project information. During the course of our project, we were caught in a power struggle between two senior managers. One was in charge of the business process area and the other was responsible for the customer service area. The business process manager had the funding to implement the performance improvement solutions that customer service needed badly.
It turned out that this power struggle was one of the factors that led to previous failed implementations. The business process manager would often not communicate decisions made to the customer service manager, and she would drag her feet on customer service issues. So, to minimize some of these issues, we had regular meetings with both managers simultaneously. We also made sure both managers always got the same project information as well.
- Engage stakeholders early and get them talking to each other. We found that the customer service representatives (CSRs) involved in our project were negatively impacted by the merger of the regional centers. This was not surprising, but it turned out that the pockets of CSRs who seemed to be the most resistant to the organizational change were the more senior representatives who yielded a lot of influence. So, to gain their buy-in, we engaged them early on in the process by meeting with them to get their input and to give them status reports on the project.
Because the situation was delicate, we thought it was more important to meet with them face to face instead of, for example, communicating through newsletters. This tactic worked to both break down their personal resistance to the process and to encourage them to use their influence on others to gain support for the project.
If we had not attended to this issue early on, resentment on the part of those stakeholders could have increased and snowballed before we knew what had happened.
Integrating stakeholder information into your project
The stakeholder information you collect won’t do you any good in and of itself; you must plug it into your project to reap its full value. Here are some guidelines that I use to make the most of stakeholder information.
During the scoping phase, you, as project manager, construct a Project Definition document, which includes the parameters of the project, assumptions, and constraints. The information from the stakeholder analysis can help you flesh out the assumptions and constraints. Key stakeholder information that may be relevant is:
- Stakeholders who provide inputs, including equipment, information, or other resources, that are critical to the project.
- Stakeholder issues that indicate possible difficulty in meeting project success criteria (delivering on time and within budget; meeting quality standards; satisfying the customer).
The stakeholder information you’ve worked so hard to gather can now enable you to provide clear and refined assumption and constraint statements to the client instead of a more generic view.
The project plan
A detailed project plan incorporates a work breakdown structure, timeline, budget, and resources used. As the plan is developed, project managers often put in “fudge” factors to make sure that the project plan is reasonable.
Some stakeholder issues can represent “fudge” factors that should be taken into account. For example, you should consider how you'll deal with any negative impacts that key stakeholders may have on the project. Evaluate both the likelihood of these impacts occurring and their level of criticality. For any negative impact that is highly likely or very critical, think of methods to prevent and/or minimize the impact to the project.
Project communication and reporting
Applying what you know about stakeholders’ needs, expectations, and personal interaction styles should help you determine the appropriate project communication and reporting methods and develop a brief communication plan.
Submit the communication plan along with the project plan for client approval. It is also helpful to develop samples of regular reports or communication to get client buy-in. Samples of reports, such as the project status report, can be presented for review to your client and key stakeholders during the project start-up meeting.
A brief review
Now that we have worked through the stakeholder analysis process, let’s review the key aspects:
- Identify stakeholders.
- Determine the interests and goals, influence and power, and impact of stakeholders on the project.
- Construct a Stakeholder Assessment Map (SAM) and Stakeholder Reporting Matrix (SRM).
- Review and finalize the SAM and SRM with the project team.
- Construct an Analysis Table to analyze stakeholder information.
- Choose appropriate strategies to handle stakeholders.
- Plug the information you’ve gathered into your project.
Have you ever left stakeholders out of the mix?
Have there been times when you’ve either begun or inherited a project where stakeholders concerns were poorly represented? Tell us about it: Send us an e-mail or post your comments below.