Abstract
Stakeholder management is one of the key soft skills a project manager needs. Keeping the stakeholders engaged and happy is critical to project (and project manager) success. Those who have failed know the pitfalls. This paper will give an overview of stakeholder management as well as provide some practical tips to improving communication and relationships with stakeholders. It will cover the following areas: identifying and analyzing stakeholders, managing stakeholders, dealing with problem stakeholders, and listening to stakeholder concerns.
Introduction
The following is how A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute [PMI], 2008) defined stakeholder management:
Stakeholders are persons or organizations (e.g., customers, sponsors, the performing organization, or the public), who are actively involved in the project or whose interests may be positively or negatively affected by the performance or completion of the project. Stakeholders may also exert influence over the project, its deliverables, and the project team members. The project management team must identify both internal and external stakeholders in order to determine the project requirements and expectations of all parties involved. Furthermore, the project manager must manage the influence of the various stakeholders in relation to the project requirements to ensure a successful outcome. Exhibit 1 illustrates the relationship between the project, the project team, and other common stakeholders. (PMI 2008, p. 23)
Exhibit 1: Project relationships (PMI, 2009, p. 24)
What Are Other Definitions of a Stakeholder?
Here are some other definitions of stakeholder:
- A person, group, organization, or system who affects or can be affected by a project's actions. (Wikipedia 2009)
- Stakeholders are the specific people or groups who have a stake, or an interest, in the outcome of the project. (Visitask, 2009)
- A person, group, or authority who is involved in or may be affected by project activities and who could act against the project if their needs are not considered. (Wideman, 2002
To me the last one is the best definition: “Someone who could act against the project if their needs are not considered.” (Wideman, 2002)This type of stakeholder needs to be kept happy by delivering a successful project to him or her.
Failures in Stakeholder Management
Failure to identify stakeholders, understand stakeholder needs, and meet their needs can result in spectacular project failures.
Here are some publicized examples taken from an article by Jake Widman (2007) in CIO magazine.
FoxMeyer ERP Program
In 1993, FoxMeyer Drugs was the fourth largest distributor of pharmaceuticals in the United States and was worth $5 billion. In an attempt to increase efficiency, FoxMeyer purchased an SAP and a warehouse automation system and hired Andersen Consulting to integrate and implement the two in what was supposed to be a $35 million project.
One of the reasons for failure was the warehouse employees whose jobs were affected—more accurately, threatened—by the automated system were not supportive of the project. After three existing warehouses were closed, the first warehouse to be automated was plagued by sabotage, with inventory damaged by workers and orders going unfilled. By 1996, the company was bankrupt; it was eventually sold to a competitor for a mere $80 million.
Canada's Gun Registration System
In June 1997, Electronic Data Systems and U.K.-based SHL Systemhouse started work on a Canadian national firearm registration system. The original plan was for a modest IT project that would cost taxpayers only $2 million—$119 million for implementation, offset by $117 million in licensing fees.
Then politics got in the way. Pressure from the gun lobby and other interest groups resulted in more than 1,000 change orders in just the first two years. The changes involved having to interface with the computer systems of more than 50 agencies, and since that integration was not part of the original contract, the government had to pay for all the extra work. By 2001, the costs had ballooned to $688 million, including $300 million for support.
However, that was not the worst part. By 2001, the annual maintenance costs alone were running $75 million a year. A 2002 audit estimated that the program would wind up costing more than $1 billion by 2004 while generating revenue of only $140 million, giving rise to its nickname: “the billion-dollar boondoggle.”
Homeland Security's Virtual Fence
The U.S. Department of Homeland Security is bolstering the U.S. Border Patrol with a network of radar, satellites, sensors, and communication links—what is commonly referred to as a “virtual fence.” In September 2006, a contract for this Secure Border Initiative Network was awarded to Boeing, which was given $20 million to construct a 28-mile pilot section along the Arizona-Mexico border.
Congress learned that the pilot project was being delayed because users had been excluded from the process and the complexity of the project had been underestimated. In February 2008, the Government Accountability Office reported that the radar meant to detect illegal aliens coming across the border could be set off by rain and other weather, and the cameras designed to zoom in on the subjects sent back images of uselessly low resolution for objects beyond 3.1 miles. In addition, the pilot's communications system interfered with local residents’ WiFi networks. The project is already experiencing delays and cost overruns, SBInet program manager Kirk Evans resigned citing lack of a system design as just one specific concern—not an auspicious beginning.
Not all projects are large enough to get into the headlines but smaller projects also fail due to lack of stakeholder management. Failure of stakeholder management can result in issues that are more mundane: a project being delayed a few months for rework or a key stakeholder being unhappy with the project. It can also cause an unhappy stakeholder to ask for the project manager to be replaced.
Identifying and Analyzing Stakeholders
The first step in a successful stakeholder management strategy is identifying and analyzing stakeholders. Follow these steps.
- Identify the stakeholders,
- Understand their needs,
- Manage all stakeholders, and
- Confirm that stakeholder roles or needs have not changed.
Identify the decision makers. Then identify who may be impacted by the project. Who are the key subject matter experts? 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 found to nominate others.
Understand: The project manager should take some time to understand and analyze the stakeholders and their potential impact on the project. What are the impacts? When do they occur? How does the impact affect the stakeholder?
Manage: Project managers need to manage stakeholders’ requirements and manage them through the constraints (time, budget, etc.) They need to make sure their expectations are set appropriately and that the team does not over promise on the solution. Project managers should get commitment from key stakeholders and work to have them sign off on the charter or some other document stating they agree with the approach.
Check: On a regular basis, project managers need to go back and check with existing stakeholders whether anything has changed. Are there new stakeholders? Have impacts changed? Have priorities changed? The more frequently project managers check, the quicker they will pick these issues up and be able to deal with them.
As Freeman and McVea (2001, p. 12) stated, stakeholder management is a never-ending task of balancing and integrating multiple relationships and multiple objectives.
Project managers need to ensure criteria for success has been defined and agreed to. Getting this defined early will make the final phase run more smoothly. As well, the process itself may expose new stakeholder needs.
Who Are the Stakeholders?
Defining the stakeholders is a critical task. Who are project managers’ most critical stakeholders?
- Not the team,
- Not absolutely everyone who could potentially be involved or be impacted by the project, and
- Not the management who has directed the completion of the project.
Stakeholders who can affect the success of the project could come from any of the groups shown in Exhibit 2:
Exhibit 2: Stakeholder groups
So who are the most critical stakeholders? The key stakeholders are usually the business users, often senior management on the business side. They are, in effect, the clients who have purchased the product or service. They are the customers! It is similar to running a small business and they are the customers. They can make or break the small business.
Interest/Influence Chart
For each stakeholder, his or her position should be mapped in an interest/influence chart such as the one in Exhibit 3.
Exhibit 3: Interest/influence chart
Stakeholders who fall in the up right quadrant are critical to keep informed and can be big assets to the project. Stakeholders in the upper left quadrant can be the biggest risks and should be managed as such.
As Freeman and McVea (2001, p. 14)) stated, the stakeholder approach is about concrete “names and faces” for stakeholders rather than merely analyzing particular stakeholder roles. Knowing that “business users” are impacted is not enough. It is necessary to communicate directly with the senior manager (“John Smith” or whoever) of the business team.
Managing Stakeholders
The Project Management Triangle
Exhibit 4: Project management triangle
Exhibit 4 is highly useful in efforts to explain the inevitable trade-offs in a project. If stakeholders or sponsors want more in the deliverable (i.e., more features) then something has to give. The project will take longer or it will cost more or a little of both. If they want to lower cost, they probably cannot do it without decreasing scope or increasing timelines. Stakeholders will need to understand that and the project manager needs to be consistent on this point.
What if they don't understand this or don't want to abide by this key rule of project management? Project managers need to remind them they are increasing risk and the net result will be either a project that is late or over budget anyway. It may be a project that fails all together.
I like to tell this story. I once managed a team coming up against a very tight timeline on a development project. They were very late. One of the senior developers put in a heroic effort and stayed all night to finish the work. He didn't get to sleep. We congratulated his efforts. However, the next week when we started testing and found problems in the code written late at night. Not only was it buggy but the design itself was flawed. The whole thing needed to be redesigned and rewritten. Code written at 4:00 am is usually not good quality! In fact with the time spent with testing, we probably ended up delivering later than if he had not stayed up late.
In this case we didn't increase the time and budget as we should have. What suffered? The quality.
Understanding Stakeholders
How will stakeholders react to the following from a project manager?
- Gives untruths about status,
- Hides problems until the last minute,
- Ignores requests,
- Argues when a change is requested,
- Bills for every small item.
These are common occurrences on many projects. As has been discussed, stakeholders are critical and these types of responses are risky at best.
Steering Meetings
Joint steering meetings are critical in ensuring that the senior stakeholders are aware of project progress and issues. For this reason, it is important tailor the materials for these senior stakeholders. The following are guidelines for these meetings:
- Create a joint issue list,
- Give crisp presentations to the sponsor,
- Don't gloss over challenges, and
- Review issues and risks.
Project managers should create simple, crisp presentations for the sponsors. Don't gloss over problem areas, risks, or issues. Sponsors want to know about potential problems, they do not want to be surprised at the last minute. They want to know while there is still time to act. Project managers need to remember these are the people who can them help overcome obstacles. They should let them help and give them the information they need to help.
Joint Action Items
A key challenge in project management is not only managing the team's deliverables but monitoring the deliverables of stakeholders and business partners. An action items list is a great way to do this.
- Keep their deliverables in sight every week, and
- Update them regularly.
Don't just include items for the project team here. Project managers should ensure they have the business action items and stakeholder action items as well. They should be reviewed every week. This will ensure that action items and tasks are not forgotten or lost (which can happen easily in a complex project).
Some people like to use issues and action items interchangeably. I like a clear distinction. Issues are items for management attention, items they should be aware of and either monitor closely to take action on immediately. Action items are used to document items that may not appear in the project plans but that need to be tracked and should not be forgotten (a to-do list as it were).
Joint Risk Reviews
Risk management is important and involving stakeholders ensures a more thorough job:
- Make sure they know what the project risks are, and
- Don't assume they understand their internal risks.
If one of the risks documented comes about, they cannot say the project manager didn't warn them. And you never know by talking about them, the team may even end up avoiding those very risks that they document! Of course, it is not the project manager's job to analyze stakeholder risks for them. However, the project manager can help them and may well help himself or herself. And they will appreciate it.
Under Promise—Over Deliver
This is common sense. However, it is surprising how many project managers, especially junior ones, who do not do this or do not do this well.
- Give the team some buffer,
- Don't give in to dates the team can't make, and
- Try to beat your own deadlines.
Missing deadlines and having a stakeholder who does not believe the dates and estimates is risky to the relationship. Project managers need to set conservative deadlines and then meet them! Project managers will never gain points by agreeing to unrealistic timelines—they will almost certainly miss them. Setting reasonable dates early on is much easier.
Tell Them What You're Doing for Them
Project managers may see the team working hard each day and overcoming hurdles. However, stakeholders likely will not. Project managers should let them know.
- If the team is working hard, say so.
- Report internal successes.
- Talk about project hurdles overcome.
They will appreciate the team's efforts more and maybe cut the team some slack later on. In other words, project managers should promote the team and their successes when they can.
What shouldn't project managers do? Bad mouth the team to stakeholders. Telling stakeholders they do not have the greatest team will only cause them to lose confidence in the project, question everything more closely, and will reflect badly on the project manager.
Heads Up on Problems
Stakeholders and managers hate surprises. If trouble is brewing, project managers should give them enough notice.
- When's the best time to report a problem?
- After it's been solved!
- When's the worst time to report a problem?
- When it's too late to fix!
This is not about pushing the panic button before it needs to be pushed but about keeping them informed. Hiding problems will not get them solved or get any credit if the problem blows up. If project managers only tell them about a problem when it's too late to fix, it's not a career enhancing move. On the other hand, no one wants Chicken Little as a project manager: always warning that the sky is falling. If a project manager tells them about a problem that has been successfully resolved, it is one more success to report.
I remember one case where I was told a new critical bug had appeared an hour before a stakeholder meeting. This was late in the test cycle and could have derailed a multimillion-dollar project. I did not bring it up until I had a chance to look into the issue. In the end, it was just a tester who entered a typo in an URL.
Problem Stakeholders
There will always be problem stakeholders. Here is my list of some typical ones:
- Micro-managers,
- Pushies,
- Doubting Thomases,
- Procrastinators,
- Scope creeps, and
- Saboteurs.
Micro-managers
Micro-managers will want to manage all parts of the project. They may be very nervous about project success or have already made up their mind that the project team cannot do the job. They may call up individual team members to get updates from the horse's mouth or even try to direct their work.
Let's look at an example: the stakeholder has lost confidence. He is constantly calling up the team members to get updates from them directly. He wants to go to all the meetings and he is giving them direction on the project. The project manager needs to manage who on the team the stakeholders know and deal with the situation. The project manager should keep communications between the stakeholders and the team to a manageable number of senior individuals who know how to deflect stakeholder inquiries. Make those team members aware of what they should say and what direction they should take from stakeholders.
Pushies
Pushies are always pushing for more: lower budgets, tighter timelines, and greater scope. Project managers need to be firm: Let them know you can increase the scope but the budget and timelines have to increase. Remember the iron triangle? Project managers need to hold the line here because if they give in to unrealistic demands, the team will not be able to deliver the project and neither the project manager nor the stakeholder will be happy with the outcome.
I worked with a manager that always tried to get estimates and delivery dates moved up by one day. Even if the squeeze of the day did not give the team enough time to analyze the problem. He did not realize that he was trying to shortchange himself and would end up getting rushed answers or solutions.
Doubting Thomases
Doubting Thomases are ceptical about the project manager's ability or the team's ability to deliver the project. They constantly question the progress and what the project manager tells them.
The best way to handle this situation is to gain their trust slowly. The project manager should deliver consistently on commitments and schedule demos to show that the team has made progress. The project manager should take the initiative to schedule these rather than wait for the stakeholders to demand them.
Doubting Thomases can morph into the micro-manager if the project manager is not careful! I dealt with one client manager who insisted she be invited to all the internal technical meetings even though she had no technical background. Of course, she became impatient with the long-winded technical discussions she could not follow and complained to management that the meetings were not crisp enough. But the technical items being discussed were complex and critical to the success of the project. Time needed to be spent to discuss them in detail. Her presence became counterproductive.
Procrastinators
Procrastinators will closely monitor the project's progress but will not worry too much about their own deliverables. When the team needs their deliverables, they are not there and a crisis results.
Project managers should give stakeholders milestones to meet and remind them of upcoming deliverables. They should ask how it is going on a regular basis. If the project fails and it is their fault, the project manager still will not look great. I recall a customer who had many internal issues. They kept pushing our (the vendors) delivery date back. Then they insisted that when we missed some of our dates, that our projects had to go yellow because of the squeezed timeline. Then they delayed the dates again due to their own internal issues.
The best way to improve this situation is for the project manager to do what they can to manage the stakeholder. If they do not know what they need to do on their end, the project manager should either tell them or put milestones in place for them. If they are not tracking their issues properly, the project manager should do it for them. At the end of the day, everyone wants a smooth project both on the project side and on the stakeholder's side.
Saboteurs
Saboteurs can be the most difficult stakeholders to deal with. The may want the project to fail perhaps for their own political reasons. A project manager should try to find a way to convince the stakeholder the project will benefit them or even modify the project better to meet that stakeholder's needs and concerns. It is important to understand that if not resolved they could end up working against the project.
If a project manager cannot find a way to get this stakeholder on board, they should be aware that the stakeholder might passively or actively work against the project. A project manager may use tools such as status reports, risk registers, and steering meetings to identify project areas that are lagging or not yet fully cooperating with the project.
Listening to Stakeholder Concerns
Project managers need to take stakeholder concerns seriously, which on some project does not happen. Some project managers fall into the trap of thinking concerns come about because they are dealing with a problem stakeholder. A project manager is best advised to understand the issue first before coming to that conclusion.
- Remember that stakeholders probably have extensive experience;
- Listen to their concerns; and
- Understand the concern and reassure.
If they are concerned about an aspect of the project, even if the team is not concerned about the issue, the issue needs to be reviewed. The project manager should explain to them why the team is not concerned and why they should not be concerned. However, the project manager should also realize that the stakeholders may have been in the business for a long time, might understand the environment better, and might know some things the project manager does not.
Often stakeholders may not understand the project management process. If it is an IT project, they may know little about IT. Some of their concerns may be based on that unfamiliarity. Not all their concerns will be valid in other words. However, the project manager must take the time to educate them and confirm that their concerns are unfounded. Remember, if someone is a senior businessperson, he or she understands the environment and production intimately, wouldn't it be foolish not to make use of his or her knowledge?
