Stakeholder analysis

a pivotal practice of successful projects

 
 
Share
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).
Exhibit 4. Interest-Influence Classification

Assess Stakeholders for Importance and Influence

Determining whether stakeholders in a position of strong influence hold

negative interests may be critical to project success. This level of
understanding can best be reached by conducting a formal assessment of
each stakeholder’s level of importance and influence to the project.
Influence indicates a stakeholder’s relative power over and within a project. A
stakeholder with high influence would control key decisions within the project
and have strong ability to facilitate implementation of project tasks and cause
others to take action. Usually such influence is derived from the individual’s
hierarchical, economic, social, or political position, though often someone with
personal connections to other persons of influence also qualifies. Other
indicators identified in ODA (1995) include: expert knowledge, negotiation and
consensus building skills, charisma, holder or strategic resources, etc.
Importance indicates the degree to which the project cannot be considered
successful if needs, expectations, and issues are not addressed. This
measure is often derived based on the relation of the stakeholder need to the
project’s goals and purposes. For instance, the human resources department
may be key to getting the project new resources at a critical time and the
accounting department key to keeping the finances in order and the project
manager out of jail. The users of the project’s product or service typically are
considered of high importance.
These two measures, influence and importance, are distinct from each other.
A project may have an important financial sponsor that can shut down the
project at any time for any reason, but does not participate at all in the day-to-
day operations of the project. The combination of these measures provides
insight not only into how stakeholders interact, but also help identify additional
assumptions and risks.
A diagram of these relationships can be useful to understand potential risks
and highlight groups of stakeholders whose needs can be address in a
common manner. Exhibit 3 shows such a diagram. The interest-influence
measures can be annotation with a range of numbers (0–10) or high (H),
medium (M), and low (L). Note that stakeholders in the high influence—high
importance quadrant would be considered key stakeholders. Although counter
to typical approaches, this area is where we may need to focus our attention
at times when the project is suffering rather that on “beating up” individuals in
the opposite corner quadrant.
Exhibit 5. Stakeholder Participation Matrix
Exhibit 6. Case Study A
A more interesting picture would be a dynamic view over the life of the project
rather than this static view. For instance, a key indicator of project success
may be where the key customer is located at the conceptual, implementation,
and closeout phases of the project.

Outline Assumptions and Risks

Project success also depends on the validity of key assumptions and risks. In
relation to stakeholders, risks are manifest when there are conflicting needs
and expectations. For example, the interests of a stakeholder with high
influence may not be in line with the objectives of the project and can block a
project’s positive progression. To bring to light key risks, the project manager
needs to clarify unspecified stakeholder roles and responsibilities, play “what-
if” scenarios using unfulfilled needs and expectations, and double check the
plausibility of assumptions made. Exhibit 4 provides an example of
documenting assumptions and risks in relation to key stakeholders. Note that
a spreadsheet could be used to capture this information as well as that
indicated in Exhibits 2 and 3.
Exhibit 7. Case Study B

Define Stakeholder Participation

Now that we have made an effort to understand the stakeholders, we need to

assess their level of participation and information needs. A well-designed
project will not only clarify key stakeholder roles, but will define as much as
possible who participates when. Not all stakeholders need to be involved in all
aspects of the project in all lifecycle phases. Previous analysis has helped us
identify potential groupings of stakeholders. Similar individuals may have
similar project information needs. We can use this information to reduce
project report development costs and accompanying communication costs.
The participation matrix shown in Exhibit 5 is a method outlined in ODA (1995)
that can assist project managers in categorizing their strategy for involving
stakeholders. The lifecycle stages should reflect the phases of the project
(those shown are from [PMI, 1996]). Likewise, the types of participation shown
are generic and should reflect those desired by the project team.
Although a relatively difficult set of data to analyze and document, this
information can be used to further highlight assumptions and risks. For
instance, a project will be endangered with multiple key stakeholders all
wishing to participate in project controlling functions. This matrix can be
overlaid with the stakeholder information requirements (type, frequency, and
format) to assist in developing the project communication plan.

Case Studies

This technique has been used on a number of projects differing in application

area, duration, and complexity. Two projects are described here. They have
been simplified to allow presentation of key concepts.

Case Study A: Where’s the Customer?

Case Study A describes a two-year project involving large teams in the

banking industry that fortunately has not yet been completed. At the outset of
the analysis (that started in the beginning of the second year), it was clear
what the key risks were. Team members had become frustrated with the
project for primarily two reasons: (1) functional managers continually added
secondary projects to their plate, and (2) project requirements never seemed
to be clear. The analysis showed that the primary customer was never
brought in project planning discussions, the project team members were not
encouraged to talk with customers, and the precisely defined secondary set of
project requirements did not really belong to anyone.
Exhibit 6 highlights this situation in the project implementation phase. Key
points to note are the primary customer is deemed of little importance, the
secondary customer switched from being important in the design phase to not
existing in the implementation phase, and the functional managers wielded
too much power in the matrix environment of the project. To improve the
chances of success, the project manager realized that he must have both
project sponsors more on the side of the project, and tactfully convince them
to help the functional managers understand that they are ruining the project.

Case Study B: Planned Alignment

Case Study B describes a four-year project involving an international technical
sponsor and a remote financial sponsor. The project manager understood well
that this project would not work well unless all parties understood their roles
and responsibilities. Furthermore, he realized that the customers and vendors
had to be involved in all phases of the project, particularly at the beginning.
Exhibit 7 shows a static view of the project taken at the middle of project
execution. From the data collected there has been some shifting of key
stakeholders, but the alignment has roughly stayed the same. The project
team considered their communications strategy key to the success of their
project. Although there have been some problems along the way (particularly
growth issues), design and implementation barriers were made known before
they became critical.

Conclusion

Stakeholder analysis is a technique that can assist the project team members
understand the variety of stakeholders that have an interest in the project and
the individual nuances that can affect project risk. In an environment where
office politics often appear to cloud a project’s progression, stakeholder
analysis provides the team with views and measures and that can help
uncover and remove barriers.
The technique described here compels project leaders to identify and support
the interests of the key groups. When interests that cannot be supported
arise, the knowledge that they exist and what level of influence the
stakeholder may impose can be a great asset to the project team. The
difference between success and failure can be simply in knowing project
advocates and opponents, understanding their respective needs and levels of
influence, and aligning the project accordingly.

References

David I. Cleland (ed). (1998). Field guide to project management. John Wiley

and Sons.
Kujala, Johanna. Analyzing Moral Issues in Stakeholder
Relations: A Questionnaire Development Process. School of Business and
Economics. Online at
htttp://www.mcb.co.uk/services/conferen/jun98/bale/kujala.html 
Overseas Development Administration. (1995, July). Guidance note on how to
do stakeholder analysis of aid projects and programmes. Social Development
Department.
Project Management Institute (PMI ). (1996). A guide to the project
®

management body of knowledge (PMBOK  Guide). Newtown Square, PA:

®

Project Management Institute.

This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI or any listed author.
Proceedings of the Project Management Institute Annual Seminars &
Symposium
September 7–16, 2000 • Houston, Texas, USA
ADVERTISEMENT

ADVERTISEMENT
 Related Content
 ARTICLE  Strategy , Stakeholder Engagement  1 May 2021

PM Network
New Urban Utopia
By Thomas, Jennifer, Proximity evoked peril. Density brought danger, if not death. As the pandemic
gripped the globe, the hallmarks of urban living—public transportation, high-rises with shared amenities,
crowded…
 ARTICLE  Innovation , Stakeholder Engagement , Financial Services  1 May 2021

PM Network
Fintech Reckoning
By Fister Gale, Sarah, Fintech adoption rates among consumers have nearly doubled every two years
since 2015—and the pace only accelerated during the pandemic. As people in lockdown turned to their
smartphones and…
 ARTICLE  Innovation , Stakeholder Engagement , Education  1 May 2021

PM Network
The Future of Learning
By Fister Gale, Sarah, More than 1 billion children in at least 185 countries were impacted by school
closures related to the global pandemic last year, according to the World Economic Forum. For many, a
shift toonline…
 ARTICLE  Stakeholder Engagement  1 November 2020

PM Network
A Towering Legacy
By Parsi, Novid Rising 165 meters (541 feet) into the air and tilted at a 45-degree angle, the Montréal
Tower in Québec, Canada is an iconic emblem of the city. Yet aside from being home to a popular
observatory,…
 ARTICLE  Stakeholder Engagement  1 June 2020

Project Management Journal

The Influence of Justice Perceptions and Affective States on Project
Managers' Responses to Client Opportunism  
By Chaudhry, Smita | Srivastava, Bharatendu Nath | Joshi, Chetan The contribution of psychological
factors in project relationships has received limited attention. Taking the standpoint of vendor project
managers, we examine their justice perceptions, affect, and…
ADVERTISEMENT

 Privacy
 
 Sitemap
 
 Terms of Use
 
 Purchasing Terms and Conditions
 
 Advertising Sponsorship
© 2021 Project Management Institute, Inc.14 Campus Blvd, Newtown Square, PA 19073-3299 USA