Stakeholder Identification | Business Analysis

Every project comes with stakeholders. These players have enormous influence over the project and its outcome.

Getting the right stakeholders involved at the right time is the single most effective step a business analyst can take to ensure a project’s success, but identifying these stakeholders is not always easy.

The type and number of stakeholders you need to include will depend on the type and size of the project. So it’s important to spend a few minutes figuring out who your stakeholders are.

1. What is a Stakeholder?

Basically, stakeholders are groups of people who have something to gain or lose from the project’s outcome. If that sounds a bit nebulous, you’re right. We’re talking about a complex group of people with different – and often competing! – goals.
Stakeholders can exist both within the organization and outside of it. They may be end users, or they might simply be affected by the process. Either way they have a vested interest in the final product.
Stakeholders typically include:
1. Direct users
  - Those who will use the system directly. These are the people who are currently performing and most knowledgeable about the current process and its features, as well as any shortcomings and pain points that need to be resolved.
  - These stakeholders are usually referred to as subject matter experts.
2. Secondary users
  - Secondary users rely on the output of the system or provide input into the system. These are “downstream” users and “upstream” contributors of the system which may include other systems or any external parties impacted by regulations or legal considerations, like regulatory bodies, partners, vendors.
  - The new system needs to be designed to consume input and produce results in a format that fits into the secondary users’ workflows.
  - Forgetting about this group can cause one problem while solving another, like generating data in a format secondary users can’t integrate into their analytics.
3. Beneficiaries
  - These are all the people and products affected by the system. This term encompasses the people who focus more on results than process.
  - Their input typically revolves around the services, information and benefits the system will provide.
  - Typically, this includes project team members and project sponsors.

2. Why Are Stakeholders Important?

Stakeholders are significant for several reasons:
1. Input from stakeholders helps the business analyst understand what kind of system is needed.
2. They provide critical information about features the system needs to include or problems it needs to solve.
  - Stakeholders are in the best position to offer specific input on needs at their level.
    - They know what will or won’t work within their workflows. Plus,they have a handle on any unique needs that may conflict with other stakeholders. Having that knowledge early helps to define a compromise before serious problems arise
3. They aid in constructing use-case diagrams and map workflows which guide the new system’s design.
4. As a group they evaluate the merits of each others’ ideas, assigning an initial priority to the prospective feature list.
Involving all stakeholders from the beginning is the single most impactful step a business analyst can take.
You cannot know that you have effectively discovered all of your requirements until you have surveyed a representative from every stakeholder group.
In the case of missed stakeholders, the initial time and budget requirements may need to be increased to cover missed requirements or the users may be hesitant to use the new system.

3. How to Identify Stakeholders

To identify stakeholders for a project, consider who will be using or affected by the final product.
Consider these questions when building the stakeholder list:
- Who will use or be affected by the final product?
- Who uses the current tool or process that the new system will replace?
- What legal restrictions and regulations apply? Who knows enough about them to advise you?
- Are there any people whose support is absolutely vital to the project’s success? Whose buy-in is needed?
As the first step, use your project charter and any other project plans and documentation to compile a complete list of your project’s stakeholders, both internal and external.
- The identification of stakeholders early in the project will often result in a list of personnel with manager and sponsorship powers. These are definitively key stakeholders that have to make decisions about the project’s scope and direction, but are not the people who can help you understand the detailed process and functional needs of the system.
Next, meet with the project manager and project sponsor(s) to review your initial list and identify any additional stakeholders.
- Consider not only people, but existing systems, processes and documentation that might also be sources of requirements.
As you delve deeper into the requirement elicitation and modeling of the system, it is possible that the stakeholder list may need to expand to include those more familiar with the inner workings of a particular department, system or team.
- Failure to identify additional stakeholders as the drill-down continues can often lead to products or processes that are not deemed usable by the very people that the project is designed to serve.
Finally, schedule a “Kick-Off” meeting to facilitate introductions, establish the logistics for upcoming meetings (e.g., communication method and frequency), and begin the process of relationship building.
- Building trust with stakeholders is a critical step for the business analyst; without trust, the success of the project is at risk.
- As you interact with the stakeholders by phone/email/meetings, the relationship will continue to strengthen and your ability to manage and influence business decisions increases.
It’s important to get the right stakeholders actively involved at the right time. Having more stakeholders than necessary can bog the meetings down in irrelevant detail or unnecessary explanations. But overlooking an important stakeholder can result in missed requirements and “buy-in”.