Conduct Stakeholder Analysis - Business Analyst

Purpose

This task covers the identification of stakeholders who may be affected by a proposed initiative or who share a common business need, identifying appropriate stakeholders for the project or project phase, and determining stakeholder influence and/or authority regarding the approval of project deliverables.

Description

Stakeholder analysis is performed as soon as a business need is identified and will usually be an ongoing activity as long as business analysis continues. Stakeholder analysis begins with identifying stakeholders who may be affected by the business need or a new solution. Stakeholders may be grouped into categories that reflect their involvement or interest in the initiative. The roles, responsibilities, and authority over the requirements for each stakeholder or stakeholder group must be clearly described. Stakeholder analysis also involves understanding stakeholder influence on and attitude towards the initiative, and assessing positive and negative attitudes and behaviors which may affect the outcome of the initiative and acceptance of the solution.

Inputs

Business Need: Identify and analyze the position of the stakeholders affected by the business need. As the understanding of that need evolves through definition of business requirements, solution scope, stakeholder requirements, and solution requirements, that additional information will be used to assist in identifying additional stakeholders or understanding how existing stakeholders may have changed their position.

Enterprise Architecture: Describes the organizational units that exist, their interactions with other organizational units, customers, and suppliers, their responsibilities within the organization, and the roles and relationships within each organizational unit.

Organizational Process Assets: These include organizational policies and procedures, forms that must be completed, suggested or prescribed methodologies, templates, and project authorization guidelines. They may be mandated or expressed in the form of guiding principles.

Elements

Stakeholder roles must be identified early in the project in order to help ensure timely delivery of requirements deliverables. Note that some individuals may be called on to play a variety of stakeholder roles on the same project, as well as on different roles on different projects.

1. Identification

Understanding who the stakeholders are and the impact of proposed changes on them is vital to understanding what needs, wants, and expectations must be satisfied by a solution.

Because requirements are based on stakeholder needs, wants, and expectations, those that are uncovered either late or not at all could require a revision to requirements that changes or nullifies completed tasks or tasks already in progress, increasing costs and decreasing stakeholder satisfaction. Change - driven approaches may better accommodate this risk, but cannot eliminate it, as late stakeholder identification can still result in alterations to the project roadmap and release content.

Who participates in which business analysis activities can vary between projects, methodologies, and organizations. For example, some organizations may encourage members of the technical team to attend requirements workshops to provide costs, technical effort estimates and information on technical impacts while others may rule that no technical discussion is permitted during these meetings.

2. Complexity of Stakeholder group

The complexity of interactions with a stakeholder group may be affected by factors such as:

Number and variety of direct end users in their constituency. Different approaches, plans, reports, amount of formality, and the amount of documentation can be customized based on the number of stakeholders each subject matter expert represents. Stakeholders with fewer constituents may be able to represent their stakeholder group without much difficulty. Stakeholders representing a large number of constituents or representing those from different functional areas or divisions may need to research information or engage in requirements elicitation themselves.

Number of interfacing business processes and automated systems. The planning for stakeholders who represent those performing complex, interfacing, or overlapping business processes is different from those whose processes are more self-contained. Since not all stakeholders can or want to attend all requirements workshops, they can be more easily persuaded if the workshop pertains to their process and the associated software application.

3. Attitude and Influence

Assess stakeholder attitudes toward and influence over the initiative. Factors to consider include:

Attitude towards:

The business goals, objectives, and solution approach:

• Do they believe that the solution will benefit the organization?
• Will the benefits affect them directly?
• Will the benefits be accrued elsewhere?
• Are the possible negative effects of the initiative on this stakeholder greater than the rewards?
• Do they believe that the project team can successfully deliver the solution?

Attitude towards business analysis:

• Do they see value in defining their requirements?
• Do they present solutions and expect the requirements to be contained in that solution, and believe that this will enable them to avoid requirements definition?

Attitude towards collaboration:

• Have they had success on previous collaborative efforts?
• Does the organization reward collaboration?
• Is the organization hierarchical in nature, rather than being team-based?
• Are personal agendas the norm?

Attitude towards the sponsor:

• On cross-functional efforts, do all the SMEs support the sponsor?
• Are there SMEs who would prefer another sponsor?

Attitude towards team members:

• Have key members of the project team (including but not limited to the business analyst) built trusting relationships or have there been prior failed projects or project phases involving those people?

Influence: Understanding the nature of influence and the influence structures and channels within an organization can prove invaluable when seeking to build relationships and work towards building trust. Understanding the influence each stakeholder may have, as well as their attitude, can help develop strategies for obtaining buy-in and collaboration. Some factors relating to influence to consider are:

• Influence on the project. How much influence does the stakeholder have on the project? For instance, because sponsors obtain funding, including resources, and make vital decisions, they usually exert more than end-users.


• Influence in the organization. There are usually formal and informal structures within organizations, and one’s title or job role, while it can provide what is called authority or positional power, does not always reflect the actual importance or authority a stakeholder has.


• Influence needed for the good of the project. The business analyst should analyze how much influence is needed to make the project succeed compared with the amount of influence the key stakeholders, such as the project sponsor, have. For example, on a large, complex project requiring many internal and external resources, the project will need a sponsor who has effective relationships with funding groups to ensure that adequate resources are available for project work. Projects that are smaller may require sponsors with less influence. If there is a mismatch between the influence required and the amount of influence the stakeholder has or is perceived to have, develop risk plans and responses and other strategies that might be needed to obtain the required level of support.


• Influence with other stakeholders. Within most organizations there is an informal way influence occurs. It is best to be aware of this informal influence structure. For example, if there are stakeholders who consider themselves project champions, they can be helpful in converting those who are less enthusiastic or even outwardly hostile to the project purpose and designated outcomes.

4. Authority Levels For Business Analysis Work.

Identify which stakeholders will have authority over business analysis activities, in relation to both business analysis work and product deliverables. Stakeholders may have authority to:

• Approve the deliverables
• Inspect and approve the requirements
• Request and approve changes
• Approve the requirements process that will be used
• Review and approve the traceability structure
• Veto proposed requirements or solutions (individually or in a group)

Additional information on authority levels can be found in Plan Requirements Management Process.

Techniques

1. General Techniques

Acceptance and Evaluation Criteria Definition: The business analyst should, as part of the stakeholder analysis, identify which stakeholders have sufficient authority to accept or reject the solution.

Brainstorming: May assist in identifying needs and requirements that lead to possible stakeholders, or in creating a listing of possible stakeholder roles.

Interviews: Interviewees may be able to identify other stakeholders.

Organization Modeling: Assess to determine if the organizational units or people listed have any unique needs and interests that should be considered. It will describe the roles and functions in the organization and the ways in which stakeholders interact and so will help to identify stakeholders who are affected by a change.

Process Modeling: Any person involved in the execution of business processes affected by the solution will be a stakeholder. Process models can be a source for identifying additional stakeholders, since related processes may be affected. In addition, categorizing stakeholders by the systems that support their business processes can be useful when changes need to be made to those processes and systems.

Requirements Workshops: During requirements workshops, the business analyst may ask participants if they can suggest other stakeholders.

Risk Analysis: Risks to the initiative may result from stakeholder attitudes or the ability of key stakeholders to participate in the initiative.

Scenarios and Use Cases, and User Stories: Identified stakeholder roles may serve as a useful starting point for identifying actors and roles.

Scope Modeling: Scope models should show stakeholders that fall outside the scope of the solution but still interact with it in some way.

Survey/Questionnaire: Useful for identifying shared characteristics of a stakeholder group.

2. RACI Matrix

The RACI matrix describes the roles of those involved in business analysis activities. It describes stakeholders as having one or more of the following responsibilities for a given task or deliverable:

• [R]esponsible does the work,
• [A]ccountableis the decision maker (only one)
• [C]onsultedmust be consulted prior to the work and gives input
• [I]nformedmeans that they must be notified of the outcome

An example of a RACI Matrix may be seen below:

Sample RACI Matrix

3. Stakeholder Map

Stakeholder maps are visual diagrams that depict the relationship of stakeholders to the solution and to one another. There are many forms of stakeholder map, but two common ones include:

• A matrix mapping the level of stakeholder influence against the level of stakeholder interest
• An onion diagram indicating how involved the stakeholder is with the solution(which stakeholders will directly interact with the solution or participate in a business process, which are part of the larger organization, and which are outside the organization)

Stakeholder maps often include lines of communication between stakeholders.

Stakeholders

Domain SME: May be able to recommend other business experts to assist in defining requirements.

Implementation SME: May be able to identify and recommend stakeholders.

Project Manager: May be able to identify and recommend stakeholders. In the context of a project with a designated project manager, responsibility for stakeholder identification and management must be shared with the project manager. The business analyst and project manager should collaborate on performing this task. The project manager is accountable for ensuring that the project team meets commitments made to the stakeholders, managing the assignment of stakeholders to project tasks and their involvement in the execution of the project, and ensuring that changes that impact the project scope are appropriately managed and approved. The business analyst will also assist the project manager in defining which project team members should be involved in developing, reviewing or approving business analysis deliverables.

Tester: May be able to identify and recommend stakeholders.

Regulator:May require that specific stakeholder representatives or groups be involved in the process.

Sponsor: May be able to identify domain subject matter experts to help with requirements definition.

Output

Stakeholder List, Roles, and Responsibilities:This may include information such as:

• List of required roles
• Names and titles of stakeholders
• Category of stakeholder
• Location of stakeholders
• Special needs
• Number of individuals in this stakeholder role
• Description of stakeholder influence and interest
• Documentation of stakeholder authority levels