Chapter 4

Conduct a Stakeholder Analysis

In This Chapter:

Stakeholders are persons and organizations such as customers, sponsors, direct and indirect users, providers, advisors, the performing organization, and the public that are actively involved in the project or whose interests may be positively or negatively affected by execution or completion of the project. A stakeholder may also be a person or organization that exerts influence over the project and its deliverables.¹ Project stakeholders are potentially sources of requirements.

The stakeholder identification and analysis process is designed to provide a common understanding among the core project team members regarding project stakeholders, their roles on the project, and their level of interest and influence on the project. The stakeholder list is then used, and often taken to a more detailed level, by the business analyst to determine the appropriate experts to participate in the requirements elicitation and validation activities. The stakeholder list, accompanied by descriptive information for each stakeholder, also provides guidance for communications during the elicitation process.

Outbound from the project. Information about the status of requirements elicitation activities is communicated to relevant stakeholder groups.

Inbound into the project. Information that is gathered during the elicitation activities is determined by the needs and level of influence of each stakeholder group.

A formal process should be used to determine stakeholder involvement. Tips for success:

Use team brainstorming to identify initial stakeholder categories or actual stakeholder names.

Focus on all stakeholders, not just the end-users of the solution.

Vague stakeholder definitions and vague needs represent risk to the project objectives and business solution adoption and should be identified and managed as project risks.

A five-step process for conducting a stakeholder analysis is presented in this chapter.

Identify Project Stakeholders

A complete stakeholder analysis can significantly increase the probability of securing accurate and complete requirements, especially if the following situations exist:

The project is critical and, therefore, quite visible.

The business solution is likely to significantly change user behavior and/or organizational processes.

The team expects management or stakeholder turnover, and therefore documentation of stakeholder positions is invaluable in ensuring new stakeholders maintain formal organizational commitments of their predecessors.

Stakeholder identification begins by listing all stakeholders that may be impacted by the project execution or the deployment of the new business solution. The project manager typically facilitates a brainstorming session (discussed in detail in Part III), involving the core project team to identify all potential stakeholders. The group uses the project charter and business case information to provide guidance to determine the organizations, groups, and individuals that will be impacted. This list needs to be further elaborated with the specific names of individuals representing stakeholder groups so the team can begin to communicate directly with appropriate personnel. Examples of stakeholder group representatives include:

A designated customer contact, who has the authority to commit resources and make decisions for the organization

A user champion for a specific business unit, who prioritizes requirements and coordinates user acceptance testing for that team

Identify Stakeholders’ Roles

To document and clarify key stakeholder roles, a RACI (responsible, accountable, consulted, informed) model is a useful framework. Each stakeholder will have one of the following roles for specific project activities:

Responsible: The stakeholder performs the project work activities.

Accountable: The stakeholder is accountable to the sponsor or to the customer for the result of the work activities.

Consulted: The stakeholder is asked for opinions on objectives, assumptions, constraints, or methods of planning and developing products or process due to expertise or position in the organization.

Informed: The stakeholder is notified of the outcome of project decisions.

The roles interact as follows:

The responsible business analyst consults with the core project team or a subject matter expert to identity the requirements elicitation techniques to use on the project.

The responsible business analyst works with the core team and the accountable project manager to make the decisions on how many elicitation techniques will be included for the different stakeholders.

The responsible project manager then develops a budget and schedule for the elicitation activities.

The responsible project manager then communicates the individuals needed to participate in elicitation sessions to informed managers.

Use the information provided in the stakeholder analysis to begin to understand if there are significant requirements elicitation risks due to an inability to involve the appropriate stakeholders. The stakeholder analysis will also help determine if too many stakeholders want to: (1) only be informed, i.e., there is low interest in the project, or (2) be consulted on all requirements, i.e., there are potentially conflicting requirements that must be resolved.

Assign Project Deliverables

A well-designed project will not only clarify key stakeholder roles but will define as much as possible how these stakeholders participate in specific activities. The RACI resource assignment matrix is a useful framework for identifying project stakeholder roles and responsibilities. Table 4-1 depicts a sample RACI responsibility assignment matrix.

Formally allocate time in the schedule for the core project team to conduct a complete stakeholder analysis and secure agreement from management that the individuals will be made available to the project when needed. Review the information captured in the stakeholder analysis with the stakeholders on the list to clarify roles and expectations. Through this process, the core team might discover that stakeholders have differing ideas about the project scope or the elicitation process; the planning team then explores disconnects and drives to consensus among different stakeholders on how to meet the project objectives. The goal is to resolve conflicts on the requirements activities, deliverables, and resource requirements early in the project, prior to beginning elicitation sessions.

Table 4-1—Sample RACI Responsibility Assignment Matrix

Tips for success:

Ensure all elicitation activities have at least one stakeholder or stakeholder group participating.

Explore and reconcile differences in viewpoints if multiple groups believe they are the primary source of certain requirements.

Confirm the roles and activities assigned with all stakeholders.

Secure management approval and commitment to provide access to the stakeholders when needed.

Identify Stakeholder Interest

It is helpful for the business analyst to make it clear to the stakeholders that they have an important stake in the positive outcome of the project. Clarify the expected business value, e.g., cost reductions, revenue improvement, unique approaches for solution adoption, productivity enhancements, and end-to-end process improvements—whatever is predicted in the business case for the project.

The business analyst interviews key stakeholders to explain their role in requirements elicitation and to validate that project objectives are aligned with something that is perceived by them as important. When conducting initial interviews with stakeholders, ask open-ended questions to determine their level of interest in the project. Ask questions such as:

What are your project expectations?

Do the expectations align with the stated project objectives?

How does the organization benefit from the project implementation?

Which stakeholders are impacted by the project execution or implementation?

Once all stakeholders have been interviewed individually or in small groups, categorize their input. This allows the business analyst and the project manager to develop a preliminary prioritization mapping interest levels to stakeholders. There may be significant mismatches in the interest levels needed versus the reality. If so, the project should not proceed until conflicts are resolved. Table 4-2 shows typical interest areas for different stakeholders.

Table 4-2—Sample Interest Areas for Stakeholders

Stakeholder	Interests	Project Priority for 1st Release
Users	Enhancement in business process functionality	1
Sponsor	Improvement in perception of organizational responsiveness Quick strike technical delivery capabilities	2
Operations	Reduction in costs associated with maintainability and supportability	3

Tips for success:

Identify and prioritize each stakeholder’s interest.

Align interests to the project scope:

If new expectations emerge through these early interviews, it may be necessary to expand the scope of the project or even refine the project objectives.

Recognize which expectations cannot be satisfied by the project and provide escalation paths for resolution.

Identify Stakeholder Power and Influence

At this point, sufficient information is available to analyze the level of influence of the stakeholders. The business analyst works with the project manager to determine the stakeholders’ capability to positively or negatively impact project success. This helps determine the communication and expectation management strategy for the project. This information can be used by the project manager and the business analysts as shown in Table 4-3, depicting the relationship between interest level and power to influence the project.

The information can also be visually mapped to provide a view of all significant project stakeholders, as shown in Figure 4-1. Individuals or groups are ranked to understand where to allocate time and resources to keep the stakeholder groups and individuals informed and involved. Requests should be answered from people in the high importance and high interest section of the graph first.

Tips for success:

Stakeholder power and influence is sensitive information and is not meant to be distributed outside the core project team.

Use this tool to identify additional stakeholders based on:

Political power

New user groups

Tailor both the communication medium and frequency to stakeholders:

Face-to-face meetings versus e-mail reports

Frequent communication to critical stakeholders

Balance competing demands (scope, time, and cost) in reaching project decisions by understanding the relative power associated with the stakeholder groups. Some groups may be approached only as a courtesy, while others will be solicited for direct input into requirements.

Table 4-3—Relationship between Interest Level and Power to Influence the Project

	Low Power	High Power
Low Interest	Keep informed—lowest priority group	Use for opinion dissemination—important group
High Interest	Empower if interests aligned with project—important group	Manage stakeholders—most critical group

Figure 4-1—Project Stakeholder Map

Revisit Stakeholder Analysis

Reexamine the stakeholder analysis information often. It is likely that new stakeholder groups will surface as information emerges about the business area undergoing change. This iterative approach to the stakeholder analysis is illustrated by adding feedback loops to the process, as shown in Figure 4-2.

Figure 4-2—The Iterative Nature of the Stakeholder Analysis Process

Tips for success:

Establish consistent communication checks and feedback loops with stakeholders.

Inform all stakeholders of current project decisions or enterprise environmental changes that impact the project requirements.

Produce a User Analysis

Business analysts complete a user analysis to identify the specific end-users impacted by the implementation of the new business solution. While stakeholder groups were identified as part of the stakeholder analysis effort, this activity decomposes stakeholder groups into user categories. Through the user analysis effort, all the different user groups and individuals are identified to ensure full participation in elicitation activities. The process is the same for any type of project or improvement initiative, and includes five steps.

1. Identify the End-Users

Using the stakeholder analysis information, identify all end-users who will be participating in the requirements elicitation sessions by name, department, and role.

2. Document Rationale for Participants

Documenting project justification as to why different sets of users are needed is essential before attempting to secure the resource commitment from the individuals’ management team. Examples of rationales for the participants needed for requirements elicitation are as follows:

Companies that merge or even different divisions within a company have different processes.

Individuals performing differing roles often require different processes.

Roles require different security levels.

Users have different expertise.

Wealth, gender, or other characteristics that are relevant to the business solution must be taken into account.

Users have different physical, cultural, and environment needs.

The user analysis attempts to identify the users of the new business solution and provides high-level assessments of how the solution should work for each user category to ensure that the requirements are accurate and complete. When planning elicitation activities, simply identify the users at this point and confirm with key project stakeholders that it is a complete and accurate list. It is not necessary to conduct a comprehensive user analysis to determine the unique needs of each user group at this point. Elaboration for user profiles, personas, or usability studies will be conducted as part of the analysis phase.

Each relevant user category requires an elicitation approach that must be incorporated into the RMP. If all the users are not included, adverse project results can be:

Unusable systems

Dissatisfied users

Loss of public reputation

Low usage by the intended users

Missing requirements

Project cost and schedule overruns caused by late discovery of requirements

3. Communicate to User Groups

Communicate the elicitation techniques that are planned activities to each user group. Examples of elicitation techniques by user group appear in Table 4-4.

4. Identify a User Champion

Identify a user champion who is authorized by the customer to speak for each user category and is available to participate in project elicitation activities. Although enlisting the help of a user champion is critical for projects using agile methods, it is important regardless of the project life cycle that is followed. The customer owns the requirements, and having a customer and/or business representative on the team and highly involved is an invaluable element of improved project outcomes.

5. Establish Ground Rules

Document the project guiding principles or ground rules relevant to categories of users. They state how decisions will be made. Examples of ground rules may include:

Allow for division or geography differences; this accommodates unique practices but is more expensive in terms of construction and maintainance.

Table 4-4—Examples of Elicitation Techniques by User Group

User Group Name	Elicitation Technique
Senior management, i.e., corporate	Interviews
Customers, i.e., lines of business or sales territories	Voice-of-the-customer surveys
Sales support, i.e., lines of business or sales territories	Facilitated workshops to develop use-case scenarios
Direct sales, i.e., lines of business or sales territories	Voice-of-the-business surveys

Document differences to provide effective training on new processes.

Requirements from one user group take priority over another.

Summary

Use a process for stakeholder analysis before beginning requirements elicitation.

A user analysis decomposes stakeholder groups in categories of users.

User groups have different requirements based on their role in operating the business system.

Action Plan for the Business Analyst

Bridge the gap between the project team and the stakeholders by establishing creative partnerships, conducting voice-of-the-business surveys, and securing customer input by establishing focus groups, business panels, and cross-functional decision teams.

Review the business case for a list of business drivers; continually link project work to the expected benefits outlined in the business case.

Explain the business value expected from the project to all stakeholders to continually confirm the primary needs that are driving the project.

Develop or refine the stakeholder analysis prior to beginning elicitation activities.

Use the stakeholder analysis to determine and manage early requirements-related risks.

Identify a champion for each user group.

Make the user champion a key member of the requirements elicitation team.

Establish and document ground rules for making requirements decisions and resolving conflicts.