Stakeholder analysis
a pivotal practice of successful projects
CONFERENCE PAPER Stakeholder Engagement 7 September 2000
Seminars & Symposium
Smith, Larry W.
How to cite this article:
Smith, L. W. (2000). Stakeholder analysis: a pivotal practice of successful projects. Paper presented at Project
Management Institute Annual Seminars & Symposium, Houston, TX. Newtown Square, PA: Project
Management Institute.
Reprints and Permissions
Larry W. Smith, PMP, Project Manager, Software Technology Support Center
Introduction
One of the most difficult aspects of a project is to understand, extract, and solidify in documented form
the requirements of a project. Often, for example, the customer must first be taught to give clear
requirements. Project managers and project personnel frequently compound the issue by automatically
relying on the fact that requirements will change yet not doing much to plan for it.
The issue of requirements extends beyond the hard and fast technical specifications we often spend time
collecting. The oft-times forgotten derived requirements range from the need to have certain information
relayed to us a certain times within the project lifecycle to the smart politics of fulfilling innate
involvement requirements with key players. This type of requirement is primarily communication
oriented. Consequently, project managers spend a significant amount of their time communicating by
clarifying the “requirements” of a variety of project participants and customers.
Each project has many interested internal and external parties or “customers.” Often these individuals
change or their interests in the project change during the different phases of the project. This may cause
the other “technical” requirements—which we may have assumed to be stable—to likewise change.
Interestingly, there are a number of nontechnical requirements that usually never change but are
forgotten. For example:
•Team member’s requirement of knowing the project goals and their individual, specific role in the
project throughout all project phases
•Financial sponsor’s requirement of having sufficient confidence at the beginning of a project that their
money will be effectively spent and the accompanying requirements of being informed of the project’s
progress at time periods agreeable to them and reported in a manner that suits their preference
•End-user’s requirement that the resulting product delivered at the project’s conclusion will be functional
based on his or her own definition of functional.
Experience has shown that when requirements such as these are not met the project suffers.
What is a Stakeholder?
How do we reach an understanding of these types of requirements? The answer lies in discovering and
then aligning our project requirements with the communicated and noncommunicated derived
requirements (i.e., needs and expectations) of all parties interested in our project. The term stakeholder is
used as a general term to describe individuals, groups, or organizations that have an interest in the project
and can mobilize resources to affect its outcome in some way. A formal definition of a stakeholder is:
“individuals and organizations who are actively involved in the project, or whose interests may be
positively or negatively affected as a result of project execution or successful project completion” (Project
Management Institute (PMI®), 1996). Project stakeholders usually include the project manager, the
customer, team members within the performing organization, and the project sponsor. However, there are
more than just these few.
If we expand our perspective to include those that can make a claim—any claim—on our attention or
resources now and in the future, the list can become quite large. There are those that can become
“winners” or “losers” as a result of our project or participate as intermediaries in the execution of our
project or development of the project’s product. These stakeholders can have their own objectives and
views, which may differ and conflict with others stakeholders.
Forgetting to meet the needs of just one influential and powerful stakeholder at a critical time can
possibly ruin a project. Who is that stakeholder and when is that critical time? Typically, very little time
is taken to:
•Clarify who the project stakeholders are
•Discover and align their expectations and individual impact on the project
•Outline a requirements change processes; knowing that their requirements (i.e., needs and expectations)
will likely change
•Relate needs and expectations to risk planning and risk response activities
•Conscientiously plan the project communication strategies.
All members of a project team want to be successful. A project is more likely to be successful if it begins
well. A good beginning includes setting aside a relatively small percentage of time at the outset to get the
project team together and discuss, evaluate, plan, and document the basic requirements of the key project
stakeholders and their impact and influence on the project. This information can then be monitored and
revisited as necessary throughout the project to diminish the sometimes innate tendency to focus solely on
moving forward, forgetting that project expectations change and that communication habits may need to
be altered. Stakeholder analysis is a method that can help us tackle these issues.
Importance of Stakeholder Analysis
Stakeholder analysis typically refers to the range of techniques or tools to identify and understand the
needs and expectations of major interests inside and outside the project environment. Understanding the
attributes, interrelationships, interfaces among and between project advocates and opponents, assists us in
strategically planning our project. Herein lies a large portion of our project risk and viability, and
ultimately the support that we must effectively obtain and retain.
On projects of any significance, this endeavor requires a certain level of being politically astute or street
smart. One must reach an understanding not only of the internal project environment, but also the entities,
including interfaces, extending into the external environment. This requires multiple skills to discriminate
among project groups and help develop potential coalitions of support or, if necessary, reduce the impact
of unseen opposition.
Our projects typically require human solutions to reach completion. Using the metaphor of a stage
production, we benefit from visualizing not only the actors on the stage, but also the producers,
financiers, stagehands, marketers, benefactors, etc., and possibly the ultimate customer—the audience that
we wish to return night after night. The ultimate in our project would be to design a similar script and
accompanying choreography to outline policy, identify existing and potential interactions among players,
design interventions and negotiations, accurately predict risks and thresholds, and anticipate sources of
conflict and cooperation.
Organizational and Project Spotlight on Stakeholders
Stakeholder analysis is often considered the first step in strategic planning activities on an organizational
level. Here we allow (or force) our minds to consider the needs of all parties besides ourselves, and layout
a business concept for the future with that in mind. If stakeholder analysis is a valued and consistent
activity at the organizational level, then its thrust can be felt on the project level. The attitude and results
can also filter down and be applied to multiple projects.
The concept of stakeholder awareness and the need for analysis is prevalent among project management
principles and accompanying artifacts. For example, its application is found throughout every knowledge
area of the PMBOK® Guide (all references from [PMI®, 1996] and italics added in some cases).
•Definition of Project Management: Project management is the “application of knowledge, skills, tools,
and techniques to project activities in order to meet or exceed stakeholder needs and expectations” and
balancing their competing demands (p. 6).
•Organizational Planning Tool: Stakeholder analysis is a success-oriented technique: “The needs of the
various stakeholders should be analyzed to ensure that their needs will be met” (p. 96).
•Project Plan Development: “Every stakeholder has skills and knowledge which may be useful in
developing the project plan. The project management team must create an environment in which
the stakeholders can contribute appropriately” (p. 41).
•Project Organization: “The nature and number of project stakeholders will often change as the project
moves from phase to phase of its lifecycle … techniques effective in one phase may not be effective in
another” (p. 94).
•Project Plan Updates: When making modifications to the project plan (including all subplans),
“appropriate stakeholders must be notified as needed” (p. 46).
•Scope Statement and Scope Verification: Successful project managers ensure that stakeholders have
common understanding and acceptance of project scope (pp. 52, 56).
•Project Cost Management: Successful project managers consider the information needs of stakeholders
since “different stakeholders may measure project costs in different ways and at different times” (p. 73).
•Quality Planning: The project management team “is responsible for ensuring that the project
stakeholders are fully aware” of the organization’s quality policy (p. 85).
•Project Team Directory: Communication is enhanced when there is a published directory that is
maintained and “lists all the project team members and other key stakeholders” (p. 99).
•Team Building: Creating teams that succeed is a process of improving “interpersonal relationships
among key stakeholders” (p. 100).
•Communication Planning Tool: Project managers should carefully design the approach they use to
communicate with their stakeholders: “The information needs of the various stakeholders should be
analyzed to develop a methodical and logical view of their information needs and sources to meet those
needs” (p. 106).
•Information Distribution: A project manager must make “needed information available to project
stakeholders in a timely manner … including responding to unexpected requests”(p. 106).
•Risk Identification: In understanding project risks, a project manager should conduct “risk-
oriented interviews with various stakeholders [to] help identify risks not identified during normal
planning activities” (p. 114).
•Risk Quantification: The threshold level of a potential project risk cannot be understood until there is
an understanding of stakeholder risk tolerances. “Different organizations and different individuals have
different tolerances for risk.” An opportunity for one may be a threat to another (p. 115).
•Procurement Planning: In a procurement situation, the customer relation switches and the “buyer
becomes the customer and is thus a key stakeholders for the seller” (p. 123).
It becomes obvious that an understanding of stakeholders’ needs and expectations is crucial to success:
“the project management team must … manage and then influence those [stakeholder] expectations to
ensure a successful project” (p. 15).
Exhibit 1. Example of Stakeholder Analysis Context Diagram
Stakeholder Analysis Approach
When should stakeholder analysis be accomplished and by whom? Although it is
worthwhile throughout the project as a tool to reassess key issues
(particularly when the project is in trouble), stakeholder analysis is
best accomplished before a project is initiated or at some beginning
phase. Since the analysis involves sensitive information, the facilitator
should be aware of the possibility of uncovering unproductive interests
and hidden agendas when discussing stakeholders. The team
members should have sufficient levels of trust amongst themselves to
carefully reveal these issues and deal with potentially undiplomatic
information.
The following sections outline a simple approach to accomplish
stakeholder analysis. The first few stages may be sufficient for small
projects with a small number of stakeholders. The time spent doing
the analysis should be tied to the type and complexity of the project. A
few hours may be sufficient to clarify project objectives, key
assumptions, and risks.
Identify Project Stakeholders
To be classified as a stakeholder, the person or group must have some
interest or level of influence that can impact the project. We would
benefit not only from understanding their interests, but also from
understanding the potential project impact if a need were not met.
The first effort should be a brainstorming activity with appropriately
selected members and an optional facilitator. All stakeholders should
be initially considered and possibly dropped in later stages of the
analysis. It is often difficult to force classifications into groups and
determine who is considered truly inside and outside the project
context. To gain a more powerful understanding of needs and
expectations, it is usually helpful to identify these stakeholders by
name rather than generic terms such as customer, owner, sponsor,
etc. Exhibit 1 depicts an example of this high-level analysis using a
notation similar to (Cleland, 1998).
Exhibit 2. Stakeholder Interest and Impact Table
Exhibit 3. Interest-Influence Classification
Identify Stakeholders Interests, Impact Level, and Relative Priority
To refine the previous stage, the stakeholders should be listed in a table or spreadsheet with their key
interests, potential level of impact to the project, and priority in relation to other stakeholders. We want to
be careful and outline multiple interests, particularly those that are overt and hidden in relation to project
objectives.
The key is to keep in mind that identifying interests is done with the stakeholder’s perspective in mind,
not ours. This is difficult since interests are usually hidden and contradict openly stated aims. Each
interest should be related to the appropriate project phase; that is, interests changes as the project moves
from beginning to ending phases. With some stakeholders it may be crucial to extract interests by
formally asking them questions such as:
•What are your expectations of this project?
•How does the successful completion of the project benefit you?
•Are there any stakeholders that may conflict with your interest?
•Which stakeholders do you believe are in conflict with your interests?
Once the major interests are identified, it is also useful to outline the how the project will be impacted if
these are or are not met. In most cases, a simple annotation of positive (+), negative (–), or unknown (?)
can be used as well as high (H), medium (M), low (L), or uncertain (?). To align project success criteria
with interests, an additional step is to give a rough prioritization of each stakeholder and their
accompanying interests. Since not all needs can be met with the same level of intensity or at the same
time, a prioritization schema would also be beneficial. Exhibit 2 provides an example of this information
contained in a table adapted from ODA (1995).
[Link]
%20Project%20Stakeholders,a%20need%20were%20not%20met.
