Understanding, extracting and solidifying documented project requirements is one of the most difficult tasks. Often the customer must first be taught how to give clear requirements. Project managers and personnel frequently compound the issue by automatically assuming requirements will change; yet, they fail to plan for, or proactively anticipate changes.

Requirements go beyond hard and fast product technical specifications. It is equally tough to satisfy each end user's definition of functionality in delivered products. Also, often forgotten project requirements dealing with "softer," human-oriented needs and expectations have the potential to make or break a project. For example, a technical sponsor may insist that certain information be relayed to them at definite times in a specific format during the project life cycle. Or, a project manager may need to fulfill requirements with key players outside of the project's environment. These are examples of a derived requirement that is primarily communications oriented. Not surprisingly, project managers spend a significant amount of time clarifying requirements for 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 change during different phases of the project. This may cause other technical requirements-assumed to be stable-to likewise change. Interestingly, there are a number of nontechnical requirements that usually never change, but are forgotten. For example:

• Each team member is required to know the project goals and their individual, specific role throughout all project phases.
• A financial sponsor assumes up front that his money will be effectively spent and that information of the project's progress at milestones will be communicated to them as requested.
• A functional manager must provide an expert for strategic planning activities who can be used in cost and schedule estimating activities.

How can you reach an understanding on these types of requirements? The answer lies in discovering and then aligning project requirements with the communicated and non-communicated derived requirements of all parties interested in the project. Fulfilling project management requires focus.

"Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. Meeting or exceeding stakeholder needs and expectations invariably involves balancing their competing demands among:

• Scope, time, cost, and quality.
• Stakeholders with differing needs and expectations.
• Identified requirements (needs) and unidentified requirements (expectations)." [1]

Used as a general term, stakeholder describes 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." [4] Project stakeholders usually include the project manager, the customer, users, 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 attention or resources, now and in the future, that list can become quite large. Some can become winners or losers as a result of the project, or participate as intermediaries in project execution or product development. These stakeholders can hold individual views and objectives, which may differ and conflict with those of other stakeholders.

Not meeting the needs or expectations 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 are the project stakeholders.
• Discover and align stakeholders' expectations and individual impact on the project.
• Outline requirements change processes knowing that requirements (i.e., needs and expectations) will likely change.
• Relate needs and expectations to risk planning and risk response activities.
• Conscientiously plan project communication strategies.

Stakeholder analysis typically refers to the range of techniques or tools used to identify and understand the needs and expectations of major interests inside and outside the project environment. Understanding the attributes, interrelationships, and interfaces among and between project advocates and opponents assists in strategically planning the project. Herein lies a large portion of project risk and viability, and ultimately the support that must be effectively obtained and retained.

On significant projects this endeavor requires a certain level of political astuteness or street smarts. You need an understanding of the internal project environment along with the entities and including interfaces extending into the external environment. This requires multiple skills to discriminate among project groups, help develop potential support coalitions, or if necessary, reduce the impact of unseen opposition. For example, during times of limited supply computer component vendors must be savvy when multiple buyers are competing against each other for a high market position.

Projects typically require human solutions to reach completion. Using the metaphor of a stage production, consider the benefit of visualizing not only the actors on the stage, but also the producers, financiers, stagehands, marketers, benefactors, and the ultimate customer-the audience that we wish to return night after night. The ultimate for 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.

Stakeholder analysis is often considered the first step in strategic planning activities on an organizational level. Here we allow (or force) our minds to layout a future business concept considering all parties' needs in addition to our own. If stakeholder analysis is a valued and consistent activity at the organizational level, then its thrust can be felt on the project level. Attitudes and results can also filter down and be applied to multiple projects.

Stakeholder awareness and the need for analysis is prevalent among project management principles and accompanying artifacts. For example, its application is found throughout every project management knowledge area of a leading, industry-accepted project management standard, A Guide to the Project Management Body of Knowledge (referred to as the PMBOK Guide ® ), published by the Project Management Institute (PMI ® ). Table 1 outlines some of the definitions of terms or processes within the PMBOK Guide ® showing the need for proper stakeholder awareness.


Table 1: Prevalence of the need for stakeholder analysis
(Click on image above to show full-size version in pop-up window.)

It becomes obvious that an understanding of stakeholders' needs and expectations is crucial to success. "The project management team must identify the stakeholders, determine what their needs and expectations are, and then manage and influence those expectations to ensure a successful project."[3]

When should stakeholder analysis be accomplished and by whom? Although worthwhile throughout the project 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. The team should be aware of sensitive information and maintaining confidences. Team members should be trustworthy and careful in dealing with information.

The following sections outline a simple stakeholder analysis approach. The first few stages may be sufficient for small projects with few stakeholders. Time spent doing the analysis should match project type and complexity. A few hours may be sufficient to clarify project objectives, key assumptions, and risks.

1. 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. Stakeholder interests must be understood, along with understanding potential project impact if a need is not met.

The first effort should be a brain-storming 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. Figure 1 depicts an example of this high-level analysis using a notation similar to [3].


Figure 1: Example of a stakeholder analysis context diagram
(Click on image above to show full-size version in pop-up window.)

2. Identify stakeholders' interests, impact level, and relative priority. To refine the previous stage, stakeholders should be listed in a table or spreadsheet with their key interests, potential level of project impact, and priority in relation to other stakeholders. Be careful to 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 stakeholders' perspective in mind, not your own. This is difficult as interests are usually hidden and may contradict openly stated aims. Each interest should be related to the appropriate project phase; that is, interests change 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 project expectations?
• How do you benefit from successful project completion?
• Which stakeholders do you believe are in conflict with the project interests?
• Do stakeholders have contradictory interests?

3. 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 [3] include: expert knowledge, negotiation and consensus building skills, charisma, holder of 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 can 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 addressed in a common manner. Figure 2 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 than targeting individuals in the opposite corner quadrant.


Figure 2: Importance-Influence classification
(Click on image above to show full-size version in pop-up window.)

Those that are in the low importance-high influence quadrant have the potential becoming a high project risk. For instance, an individual that does not have any apparent needs or provide any technical requirements to our project, but has undue influence over a key funding source, should be monitored carefully.

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.

4. 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 project's objectives 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. Table 3 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 Table 2 and Figure 2.

This information provides a critical portion of a project's risk management plan. Using classical risk management methods, the project team could add another column in Table 3 for their pertinent risk mitigation strategies and action plans [6, 7].


Table 3: Importance-Influence classification assumptions risks
(Click on image above to show full-size version in pop-up window.)

5. 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 life cycle phases. Previous analysis has helped us identify potential groupings of stake-holders. 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 Figure 3 is a method outlined in [5] that can assist project managers in categorizing their strategy for involving stakeholders. The life cycle stages should reflect the phases of the project (those shown are from [1]). Likewise, the types of participation shown are generic and should reflect those desired by the project team.


Figure 3: Stakeholder participation matrix
(Click on image above to show full-size version in pop-up window.)

For example, Stakeholder A has been identified as someone who we want to inform at the beginning of the project and then, if possible, not involve them until the end of the project but in a more active manner. Stakeholder E is a subject matter expert that we want to maintain a close partnership with during critical project phases because of this advanced design experience. Stakeholder G is skilled as a facilitator conducting peer review sessions that we wish to hire during the product design phase.

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.

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 describes a two-year project involving large 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 into 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.

Figure 4 highlights this situation in the project implementation phase. Key points to note are: The primary customer was deemed of little importance; the secondary customer went from being important in the design phase to not existing in the implementation phase; 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 were ruining the project.


Figure 4: Case study A
(Click on image above to show full-size version in pop-up window.)

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. A relatively large amount of time was spent planning and defining the activities of the project and who would accomplish them. Furthermore, the customers and vendors had to be involved in all phases of the project, particularly at the beginning. Figure 5 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, at least according to the project team. Marketing concerns were not really known until a recent product review meeting where the representatives loudly expressed their apprehension at a potentially delayed shipping date.


Figure 5: Case study B
(Click on image above to show full-size version in pop-up window.)

The project team considered its communications strategy key to the success of its project. Although there have been some problems along the way (particularly growth issues), design and implementation barriers were made known before they became critical.

Stakeholder analysis is a technique that can help 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 organizational or office politics often appear to cloud a project's progression, stakeholder analysis provides the team with views and some basic measures that can help uncover and remove barriers. Consequences of completing such an analysis include information for additional tools that could prove valuable for the project team: a communication management plan, a risk management plan, and possibly a set of previously unspoken project requirements.

The technique described here compels project leaders to identify and support the interests of the key individuals or 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 knowing project advocates and opponents, understanding their respective needs and levels of influence, and aligning the project accordingly.

1. Project Management Institute (PMI ® ), A Guide to the Project Management Body of Knowledge. Four Campus Boulevard. Newtown Square, Pa. 19073-3299. 1996. "PMI" is a trade and service mark of the Project Management Institute, Inc., which is registered in the U.S. and other nations. "PMBOK" is a trademark of the Project Management Institute, Inc., which is registered in the U.S. and other nations.
2. IBID.
3. IBID.
4. Cleland, David I. (ed), Field Guide to Project Management, John Wiley and Sons, 1998.
5. Overseas Development Administration, Guidance Note on How to Do Stakeholder Analysis of Aid Projects and Programmes, Social Development Department, July 1995.
6. Continuous Risk Management Guidebook, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pa., 1996.
7. Williams, Ray C., Pandelios, George J., and Behrens, Sandra G. Software Risk Evaluation (SRE) Method Description (version 2.0), Software Engineering Institute, Carnegie Mellon University, CMU/SEI-99-TR-029, Pittsburgh, Pa., 1996.

Larry W. Smith is a software engineer for the Software Technology Support Center at Hill Air Force Base, Utah. He has provided software engineering, software process improvement, and project management consulting for the Air Force and DoD as well as commercial and nonprofit organizations. He has also authored and managed technology evaluation contracts in support of these efforts. Smith has a bachelor's degree in electrical engineering from the University of Utah, a master's degree in computer science from Utah State University, and is a certified project management professional (PMP ® ). He is a faculty member at the University of Phoenix and provides PMP ® certification instruction.

Software Technology Support Center
OO-ALC/TISEA, 7278 4th Street
Hill Air Force Base, UT 84056
Phone: 801-777-9712
Phone: DSN: 777-9712
Fax: 801-777-8069
E-mail: larry.w.smith@hill.af.mil