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.
