Planning effective stakeholder management strategies to do the same thing!
Stakeholder management is a renewed area of focus for project managers; yet, many project teams fall short in this critical area. This paper will focus on how to set and manage expectations (SAME) of the stakeholders through a structured step-by-step approach. You will be presented with tools and techniques designed to walk you through the processes of stakeholder identification, stakeholder classification, and stakeholder management strategy development. The output of these processes will lead directly to the development of an effective communication management plan, our plan to keep project stakeholders informed regarding project status, progress, and forecasts.
Successful projects depend upon a variety of people, and it is the wise project manager who actively determines who they are and what areas of the project they influence. A forgotten stakeholder often rears his or her head at the most inopportune time, wreaking all sorts of havoc in the project. But many project teams do a poor job of identifying project stakeholders and gaining their commitment to the project objectives. In a survey conducted by Moorhouse Consulting (2012), it was determined that “Half (50%) of respondents are leading business critical projects and yet only a third (36%) feel that they have got stakeholders and key staff ‘bought in’ very well to the projects aims and benefits of the change; this is despite the fact that ‘lack of ownership’ from stakeholders is seen as the most important threat to a successful outcome” (p. 1). It is critical then, that the project team does a good job of stakeholder analysis, so they can create the stakeholder management strategy, which in turn, forms the foundation for the project's communication management plan.
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) outlines the “what's” and “why's” of project management, and even does a good job listing some effective tools and techniques for performing some project tasks. But it leaves the “soft skill” parts to the individual project manager and team. How do they do this demanding job? This paper will introduce some thoughts on the topic of stakeholder management and provide process flow and tools for doing a stakeholder analysis and creating the strategy to manage the expectations of the stakeholders.
People – Process – Technology Balance
It has always been my contention that things work when there is a balance between an organization's processes, the technology it uses to support these processes, and the people who execute the processes. Where there are welldefined processes in place, tools and technology that support these processes, and people who have been trained in the process and the technology, things seem to work. Many organizations have experienced some improvements in project results simply by establishing standard processes and tool usage. But the people side is often the most overlooked one, and of course, stakeholders are people (Exhibit 1).
Problems can occur when we don't take care of the people side. Problems often happen when one or more of the sides are out of balance. For example, we may have poorly defined processes, processes that produce errors, or undesirable outcomes. Rather than fix the broken process, we often invest in a new technology or toolset, one that ends up producing the errors faster! Another illustration of this concept would be when we have established processes, but the tool doesn't support the process, so the people become the glue between the technology and the process. And, finally, improved processes and technology will not fix people problems! People problems require people solutions and that leads directly to stakeholder management.
Definitions of Stakeholder
There are various definitions for a stakeholder:
One that has a stake in an enterprise.
One who is involved in or affected by a course of action.
Merriam-Webster Online Dictionary (Stakeholder, n.d.)
Someone with an interest in the outcome of a project, either because they have funded it, will use it, or will be affected by it.
The Scrum Primer (Deemer, Benefield, Larman, & Vodde, 2010)
A group or person who has interests that may be affected by an initiative or have influence over it.
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) (International Institute of Business Analysis, 2009, p. 232)
These definitions are drawn from the general business environment and generally refer to what most people agree upon—a stakeholder is an individual or entity that can affect, or is affected by some outcome. What about the project management community? Here are a few from this group:
Any individual, group or organization that can affect, be affected by, or perceive itself to be affected by, an initiative (programme, project, activity, risk)
PRINCE2® 2009 Glossary of Terms (Office of Government Commerce, 2009, p.313)
The interesting perspective added here is that if someone or group believes themselves to be a stakeholder, then they are, in fact, a stakeholder! The PMBOK® Guide seems to agree:
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.
PMBOK® Guide—Fourth Edition (Project Management Institute, 2008, p. 23)
Without a doubt, the most detailed definition belongs to the PMBOK® Guide, but the message is clear—stakeholders hold a lot of influence within a project and managing their expectations is a very important job.
Definitions of Expectation
Given these ways of looking at stakeholders, what would best describe an expectation?
the act or state of expecting : anticipation
the state of being expected
Merriam-Webster Online Dictionary (Expectation, n.d.)
Definitions for expect complete this discussion:
Definition of Expect
to consider probable or certain
to consider reasonable, due, or necessary
to consider bound in duty or obligated
Merriam-Webster Online Dictionary (Expect, n.d.)
The last one listed looks more intense than the others, but it gives insight into a very important idea about one's expectations for anything.
Expectations ARE Requirements!
When looking at how to set and manage stakeholder expectations, we have to realize that from the perspective of the stakeholder involved, what they are expecting as a project outcome, they consider a project requirement. Even the PMBOK® Guide suggests this idea:
Requirements include the quantified and documented needs and expectations of the sponsor customer and other stakeholders.
Collecting requirements is defining and managing customer expectations.
PMBOK® Guide—Fourth Edition (Project Management Institute, 2008a, p. 105)
The thing to remember about requirements is that any project contains two types of requirements: product requirements (things that define the features and function of the project's end product) and process requirements (how we'll keep stakeholders informed about project progress, any problems, or constraints, etc.). And although the project may have succeeded on the product side, (that is, it delivered what was promised), many fail on the process side by not keeping stakeholders informed about what was going on within the project. And because of that failure, the stakeholder was left with a bad impression of the project team, which may lead to rejection of the completed product. Stakeholder management and communication are project deliverables and deserve as much attention as any other deliverable.
While we're on the subject of expectations, there is one additional thought to be considered.
Everything we do, or don't do, creates an expectation!
Actions create an expectation for future behavior. For example, you might require that team members document their assumptions, or state the basis of their estimates, as part of the planning process. Reinforcing this idea at every team meeting will make it far easier to develop the consistent and ongoing behavior of the team. In a similar manner, actions that you do NOT perform will also create an expectation as sure as if you did something! For example, if you allow team members to be late submitting status reports, the expectation set is that timely submissions is not important—it's OK to submit reports late.
These are the questions to ask:
- What are the expectations of my stakeholders?
- What expectations do YOU want to set for your stakeholders?
- So, as a project manager, what is your job when it comes to project stakeholders and their expectations for the project's outcomes?
Role of the Project Manager
The PMBOK® Guide is very clear in this regard: “The project manager is responsible for stakeholder expectations management.” (Project Management Institute, 2008a, p. 262) What does that mean and why should a project manager care? “Actively managing stakeholder expectations decreases the risk that the project will fail to meet its goals and objectives due to unresolved stakeholder issues, and limits disruptions during the project.” (Project Management Institute, 2008a, p. 262) I realize that this sounds good and all that, but how exactly does one go about the whole idea of managing stakeholder expectations? The first thing is to realize what project management can and cannot do.
Project Management—It's a recipe, not a guarantee!
Project managers and professional gamblers have at least one thing in common: neither can guarantee success, but take great care in tilting the odds in their favor. That is the essence of project management—following prescribed processes and best practices to increase the likelihood of a successful outcome. Good project managers use information from the past in the present to plan the future. And since the future is uncertain, present day activities are all focused on increasing the odds of achieving the project's objectives.
Many stakeholders have a mistaken notion about all of this. They ask for definitive estimates at the beginning of the project—the time where the greatest amount of uncertainty exists. Cost and schedule reserves are questioned and reduced, as if they were padding added just to make the project team look good. It takes a strong, confident project manager to explain the rationale behind sound project management principles. Remember, it's not about guarantees, but rather about doing what's best to achieve the desired outcomes.
So, how do I get the stakeholders to agree upon the objectives for a successful project? My phrase is simple: “It's all the SAME to ME!” The key is to consider the job of project manager as that of an expectations manager and to continually Set And Manage Expectations (SAME).
It's ALL about ME! (Managing Expectations)
“You increase the likelihood of customer acceptance and delight at the end of your project if you manage stakeholder expectations from concept through delivery.”
What's your reaction to this quote? Would you agree?
Did you observe that not once were the phrases “on time,” “on budget,” or “within specifications,” used? The operative phrase used was “Manage Stakeholder Expectations,” which interestingly was significant enough to be included as a PMBOK® Guide process, 10.4 – Manage Stakeholder Expectations (PMI, 2008a, p.261) and will become a new Knowledge Area, Project Stakeholder Management, in the upcoming PMBOK® Guide—Fifth Edition. Using this quote as our guide, we can see that the primary responsibility of a project manager is to manage stakeholder expectations and a more apt job title might be “expectations manager.” If that's the case, then a phrase that every project manager can use as a guideline would be:
“It's All About ME!”
Of course, in this context, ME is short for Managing Expectations (Baker, 2006). The job of project manager, then, is to SET and MANAGE stakeholder expectations throughout the project. This translates to defining and defending scope, identifying, analyzing, planning responses and monitoring and controlling risks, proactively planning and delivering quality, and so forth. Managing communications with the stakeholders would also be a key part of this process. Everything we do should be from the point of view of expectation management. In short, expectations management IS project management!
Stakeholder Management Process
Since the view presented here is that stakeholder management is one of the primary keys to project success, how does the project manager go about following a defined process for doing this? Sure, it takes a number of interpersonal skills, such as listening, managing conflict, and negotiation techniques. But there are some defined steps to the stakeholder management process:
1. Identify stakeholders: The first thing the project team needs to do is to make up a list of project stakeholders. The goal here is to produce a large list that will be prioritized later on in the process. Remember, it is the stakeholder you fail to identify that is often the one who puts a wrench in your plans later! There are a number of techniques that can be used to identify project stakeholders. Here are a several:
a. Brainstorming with the project team, subject-matter experts (SMEs), and key identified stakeholders. Nominal group technique, Crawford slip method, and affinity diagrams may be helpful tools in this regard.
b. Interviews with SMEs and key stakeholders
c. Prior projects lists of stakeholders
d. Contracts with vendors and suppliers
e. Social network analysis—This technique shows all the stakeholders in the project and any social links between the actors; here, we acknowledge any functional and organizational links, but we also focus on the important, and often undocumented, social relationships among the stakeholders. Of particular interest are the centers of a cluster (PM, BA, and Tim in Exhibit 2), and anyone who spans clusters (BA). The diagram also shows relationships that can be leveraged throughout the project that could be beneficial. For example, in the diagram below, you can see that Tim is a very influential end user, because he is at the center of that cluster. Yet, neither the project manager (PM), project management office (PMO), nor the business analyst (BA) have any direct connection to him. Not addressing Tim's concerns during the project could scuttle the acceptance of any new system that the project team may be creating, so it is important that the project manager and team reach out to Tim and address any of his concerns.
2. Classify the stakeholders: Not all stakeholders will have equal influence or interest in the project, so it is important to separate the identified stakeholders into groups, so that an approach to set and manage their expectations can be developed. There are a few tools that allow for a quick partitioning of stakeholders into groups:
a. Power-interest grid: This is a simple 2 X 2 matrix (Exhibit 3) in which stakeholders are classified according to the power they have, either within the organization or within the project context, and their interest in the project or its outcomes. As a result of this analysis, we can tailor our communications approach for each group. For example, stakeholders with high power and high interest would probably represent our key stakeholder group, and we would want to manage the expectations of this group carefully. This suggests that interactive and push would be two of the major communications methods used with this group. On the other hand, with the group that has high power, but low interest, we might want to limit the amount of information with which we bombard them. Spamming this group with multiple updates for a project that they may have little concern for would not be in either party's best interest. Perhaps using a pull communications method, where information is kept in an executive dashboard or on a common SharePoint site, would work best here. In the group with low power but high interest, we would typically encounter those stakeholders who are affected by the project's execution or completion. This group typically has change management issues, and if not addressed, could hamper the project work or its acceptance at the project's conclusion. We might want to consider getting this group accustomed to the change long before it happens by actively marketing to them in the form of product announcements, project updates, prototyping, and so forth. Jeff Berman (2012) says, “Through proper communication, leadership, and support from team members, however, stakeholders can be managed to have a positive perception of the change” (Berman, 2007, Chapter 3, π13). Keeping these stakeholders informed about what will come often assists the project team in overcoming any resistance to change emanating from this group. The last group, those with low power and low interest, would call for a minimum stakeholder management effort. We would just keep an eye on these stakeholders in case they drift into one of the other groups, and therefore demand a more proactive approach.
b. Salience model: This model (Exhibit 4) expands the previously mentioned technique to account for power, urgency (need for immediate action) and legitimacy (truly appropriate stakeholders). The intersection of these three items produces eight different stakeholder groups. We might devise a unique strategy to deal with each group and tailor our management approach for each.
3. Develop Stakeholder Management Strategy. The PMBOK® Guide says “The Stakeholder Management Strategy defines an approach to increase the support and minimize negative impacts of stakeholders throughout the entire project life cycle” (Project Management Institute, 2008, p. 251). Basically, this is the project team's plan to leverage the influence of stakeholders who support the project and limit the disruptions caused by stakeholders opposed to it. This confidential document outlines the plan the team will use to set and manage the expectations of various project stakeholders.
4. Plan stakeholder communications. Use the stakeholder analysis, and the Stakeholder Management Strategy, to plan the various communication deliverables that each stakeholder group will be sent, and what communication needs to be received by the project team. These are then documented in the project's communications management plan.
5. Execute the communication plan. Distribute information and report performance to manage stakeholder expectations.
Use this five-step process to help the team plan how the various stakeholders will be identified and managed throughout the project.
Once the project team has decided how to address the various concerns of the stakeholders, the next step is to go about setting and managing the expectations of these stakeholders. First, on any project, the project manager would want to determine what a successful outcome for the project would look like with the sponsor and other key stakeholders. These project objectives are part of the project charter, and the project manager should work hard to assure that all key stakeholders have the same definition of success. Of course, this is easier said than done. Fortunately, there are project documents like the project charter, project scope statement, and (work breakdown structure (WBS) that can assist in this regard.
Once the project's success criteria have been set, then it is time to come to agreement on the product and project scope. This process generally starts with some sort of requirements gathering. Remember, expectations are requirements, too, and so all product and process requirements need to be elicited from all appropriate stakeholders. Like other requirements, these need to be prioritized and worked into the various project documents like the requirements documents, scope statement, WBS, and so forth.
The final step in setting the stakeholder's expectations is to gain agreement and buy-in from the key stakeholders on all project foundation documents and baseline plans. I've often found that people generally associate a different level of commitment to documents they sign, so I try to have the key project stakeholders sign off on any key success definitions, project scope agreements, and any other key project documents.
Once the expectations are set, then they must be proactively managed. Edgardo Gonzalez states “During the length of the project, stakeholder's expectations are in a constant state of transition…. In most projects, the agreed-to ‘shared-vision' tends to depart from the one set by its originator (usually the project sponsor).” (Gonzalez, 2002, p. 3) One constant in life is change, so there needs to be agreement on how any project expectations will be adjusted. In these cases, it is often the “how” and “why” questions, and not the “what” ones, that prove more significant when it comes to a change in expectations. Having a defined process for dealing with such changes is beneficial.
For example, as stakeholders, your project team members have expectations that need to be managed. Creating a team charter is often one way where the expectations for team behavior are stated and agreed to. Also, having some processes in place to inform other stakeholders about good news, bad news, or any changes within the project, should be established. Issues often arise when stakeholders don't feel that their expectations are being met.
Teresa Yancey Crane, founder of the Issue Management Council, defines an issue as “a gap between your actions and stakeholder expectations.”(Crane, 2007, π3) In this case, any gap between the project's reality and the stakeholder expectation would be considered an issue. Using this definition of an issue, then, we can define Issues Management as any action, or activities, used to close the gap between a stakeholder's expectation and the project's reality. These strategies can be summed up as follows:
- Change the stakeholder's expectation to meet the project reality.
- Change the project reality to meet the stakeholder's expectations.
- Change both the stakeholder's expectation and the project reality.
The PMBOK® Guide does include issues management as part of both the Project Human Resource Management and Project Communications Management Knowledge Areas. Coincidentally, they are both “manage” processes, Manage Project Team (Project Management Institute, 2008a) and Manage Stakeholder Expectations (Project Management Institute, 2008). It is interesting to note that “resolved issues” is an output of the Manage Stakeholder Expectations process, and it is fair to say that until an issue is resolved, it remains an issue.
Tools for Setting and Managing Expectations
Tools for doing the SAME (Setting and Managing Expectations) thing are quite diverse and include, but are limited to these:
- Stating the success criteria (project objectives) in the project charter.
- Defining what is in and out of scope in the project scope statement.
- Defining and getting agreement on the project deliverables documented in the WBS.
- Creating and sharing the project schedule or release burn down charts.
- Documenting who on the project team does what in a responsibility assignment matrix (RAM) or RACI chart.
- Creating and using a communications planning table to show how stakeholders will be kept in the loop about project information.
- Creating and posting project dashboards for the PMO or senior leadership.
- Creating, leveraging, and using project subsidiary management plans to handle all the processes necessary to define and manage the various parts of the project. These sets of guidelines, or rulebooks, list the “how's” to do the various project management processes.
- Conducting project kickoff meetings to publically state project objectives and set stakeholder expectations.
Program Stakeholder Management
The Standard for Program Management (Project Management Institute, 2008b) adds a few more steps and tools to those processes listed earlier for program stakeholder analysis and engagement:
- Understand the environment/culture;
- Determine stakeholder support/opposition;
- Determine the degree of stakeholder influence;
- Prioritize stakeholders;
- Develop the communication strategy;
- Develop the stakeholder register;
- Update/revise Stakeholder Management Plan; and
- Determine stakeholder receptiveness.
The Standard for Program Management—Second Edition (Project Management Institute, 2008b, p. 230)
Stakeholder Management is a new area of focus and concern for project managers and this paper focused on some concepts, tools, and techniques designed to help working project managers cope with the various challenges presented to them while setting and managing stakeholder expectations. Some ideas were presented to assist the project manager and team with structured processes and tools to assist in this important area. Project teams need to do the SAME thing to insure that the project's stakeholders are identified, analyzed, engaged, and managed throughout the project.
Baker, E. (2006, October). It's All About ME (Managing Expectations)! PMI® Global Congress 2006— North America, Seattle, WA.
Berman, J. (2007). Maximizing project value: Defining, managing, and measuring for optimal return. New York, NY: AMACOM.
Crane, T. Y. (2007, May). An issue ignored is a crisis invited. Oman Executive Review [Electronic Version] Retrieved from http://www.oeronline.com/php/2007_may/special_report_pdo.php
Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2010). The scrum primer. Retrieved from http://assets.scrumfoundation.com/downloads/1/scrumprimer121.pdf
Expect. (n.d). In Merriam-Webster's online dictionary (11 ed.). Retrieved from http://www.merriam-webster.com/dictionary/stakeholder?show=0&t=1345513249
Expectation. (n.d). In Merriam-Webster's online dictionary (11 ed.). Retrieved from http://www.merriam-webster.com/dictionary/expectation
Gonzalez, E. (2002, December). Expectations management [Electronic Version]. Retrieved from http://www.prsl.ca/pdf/PPMWPEXPMGMT_V4.pdf
International Institute of Business Analysis. (2009). A guide to the business analysis body of knowledge (BABOK® Guide) 2.0. Toronto, Ontario, Canada: International Institute of Business Analysis.
Moorhouse Consulting. (2012). Barometer on change – The 2012 results. London, UK: Moorhouse Consulting White Paper.
Office of Government Commerce. (OGC). (2009). Managing successful projects with PRINCE2™. Norwich, England: TSO (The Stationery Office).
Project Management Institute. (2008a). A guide to the project management body of knowledge (PMBOK® Guide) — Fourth edition. Newtown Square, PA: Author.
Project Management Institute. (2008b). The standard for program management—Second edition. Newtown Square, PA: Author.
Stakeholder (n.d). In Merriam-Webster's online dictionary (11 ed.). Retrieved from http://www.merriam-webster.com/dictionary/stakeholder?show=0&t=1345513249
©2012, Ernest Baker, PMP
Originally published as a part of the 2012 PMI Global Congress Proceedings – Vancouver, BC