Best Practices to Identify Stakeholders on a Software Development Project

In a previous article, we explained who a business analyst is and why proper business analysis is required when developing a software product. Now we’d like to dive deep into key business analysis processes. The first process we’ll look at is stakeholders identification. 

Without correctly identifying and prioritizing project stakeholders, the chances are high that your development team’s endeavors will be wasted. Sometimes it’s hard to answer how to identify stakeholders and who they really are, but in this article, we’ll show you the best practices and approaches business analysts at RubyGarage use for these purposes.

Who are stakeholders?

At the beginning of the development process, our business analysts identify anyone who might be impacted by our business analysis or by decisions based on this analysis. These people are usually referred to as stakeholders. 

A stakeholder is any individual, group, or organization that may be affected by or have an impact on a project’s decision activities or outcome. Stakeholders can include groups or individuals who initially proposed the project, those who will benefit from it, those who have special knowledge of the current situation, and those that will use, support, or implement the final product. 

Stakeholders are often thought of as those affected by the project. However, the notion of a stakeholder can vary significantly. We also consider those who will affect our team and the overall workflow on the project as stakeholders. Usually, these are regulatory entities. For example, if we need to get a permit and it takes forever to get it approved, that can impact the project schedule. 

Any group, either internal or external, that imposes specific requirements towards your product can impact the work on a project. An example of an internal stakeholder is a group of investors. External stakeholders are individuals or groups outside your team. These may be suppliers, creditors, or the government. Our business analysts are aware of and anticipate not only how decisions on the project can influence stakeholders but also what impact stakeholders may have on the project. 

The number of project stakeholders depends on a lot of factors, but this number is never small. To identify project stakeholders is one of the first steps our business analysts take when a project begins. Let’s see how we perform the stakeholder identification process at RubyGarage.

Since the stakeholders for a software development project may include a huge number of individuals, groups, and organizations, even the development team itself (it’s considered a typical approach to count them in too) - here at RubyGarage we typically divide them: we don’t include the development team itself into the stakeholder register - we add them to a separate team set document, that keeps the stakeholders register focused on the internal (eg project sponsors) and external (end users, integration support teams - for instance, if we’re planning to integrate with some third-party applications) stakeholders and stakeholder groups.

How we identify stakeholders 

We use several methods to identify stakeholders, and interviewing stakeholders is one of them. Interviews are one-on-one conversations that aim to elicit project-related information and suggestions from stakeholders. Interviews help us target key stakeholders who have specific knowledge of the project or possess information that may impact the project in any way. Some of the examples of questions that we ask during interviews that we usually conduct with our customers are:

• Who could be affected?
• Who could be affected during the project?
• Who could be affected after the project?
• Who could have an interest in the outcome?
• Which groups could be impacted or have an interest/stake?
• Who approves the funding?
• Who set the vision/goals?
• Who approves changes impacting cost?
• Who approves changes impacting schedule?
• Who will test the end product?
• Who will use the end product?

Now you have the general idea of how we interview the stakeholders and what exact questions we ask to get the list of stakeholders.

Another helpful method we use to find out who project stakeholders are is brainstorming. Brainstorming is a simple yet powerful tool for identifying stakeholders. To start a brainstorming session, we gather our client and the whole project team. Then we ask the question that will guide the session: Who are the stakeholders for this project? We usually spend at least 15 minutes throwing out suggestions and writing them down. 

Once we get the list of the stakeholders, we look very closely at the most important segments of stakeholders:

• Business stakeholders - the ones that are the source of business requirements - they are helpful because they guide the project to its business goals - which is actually why the software project takes place.
• Technical stakeholders - these are the ones who can help with technical approval - for instance, CTO on the customer’s side can do the code review. Also, they are the source of technical requirements.
• Target group of end users. These are the most important stakeholders - because the software product is actually built for them we need to focus on their needs. To do that, we create an ideal customer profile and persona.

Once we know who our project stakeholders are, we classify and prioritize them. Let’s imagine that we are working on a product - an online medical consulting app - and make up stakeholder artifacts bearing that in mind.

How we classify and prioritize stakeholders 

Not all stakeholders are equal. Some have a vision and some are deep down in the weeds. The first thing we do after identifying stakeholders is evaluating their significance to the project. We need to understand which stakeholders know the project and can make valuable decisions. Some external stakeholders may not be interested in the project’s results and prefer being passive. But no matter how interested our stakeholders are, we properly assess who they are and how they’re involved. 

First of all, we create a Stakeholders Register - an artifact that contains a list of the parties/personalities that influence the project delivery and outcome. Let’s imagine we have several stakeholders on the customer side: CEO, CTO, and two end users, who will be taking part in the development process as subject matter experts and acceptance testers on the customer’s side.

Here is an example of the stakeholder register we could create.

One more tool we use in our workflow is a power interest grid. 

This grid allows us to evaluate a stakeholder based on their power (ability to affect the project) and their interest (perception of how the project will affect them). 

• High power, high interest (Manage closely) stakeholders are likely to be the decision-makers and have the biggest impact on the project’s success. We keep these stakeholders close and frequently communicate with them to meet their expectations and consider all the requirements they relay to our team.
• High power, low Interest (Keep Satisfied) stakeholders need to be kept in the loop with what’s happening on the project. Though they may not be interested in the outcome, they yield power and can easily influence the project. This type of stakeholder should be dealt with cautiously because they can use their power in a negative way if they become unsatisfied with what’s going on with the requirements and the general development flow.
• Low power, high interest (Keep Informed) stakeholders should be kept informed. Our business analysts communicate with them to ensure no major issues arise and nothing is overlooked. These people can often be very helpful with defining the project requirements.
• Low power, low interest (Monitor) stakeholders should be monitored, yet excessive communication with them is not needed since their influence on the project outcome is limited.

Here is an example of the power interest grid we could create bearing in mind the stakeholders we work with

A RACI matrix is one more handy tool to classify stakeholders. RACI stands for responsible, accountable, consulted, and informed. Let’s see what each role means:

• Responsible — A person assigned to complete a particular task
• Accountable — A person that delegates a task to others and reviews and approves deliverables
• Consulted — A subject matter expert who provides input necessary for completing a task before that task is started
• Informed — A person who should be kept in the loop regarding the project’s progress and high-level decisions and who should be informed of the outcome after a specific task has been completed

Here’s how our business analysts use a RACI matrix to classify stakeholders:

We also have a checklist that helps our business analysts assess the possibilities and contributions of each individual stakeholder or group of stakeholders. Stakeholders are considered valuable and important if they:

• Can provide access to valuable resources
• Have decision-making power
• Can provide the data BAs need for analysis
• Can provide perspective and insights on activities being assessed
• Can help with completing the business analysis and creating the required documentation

At the end of the assessment, our business analysts identify which stakeholders really can help satisfy the project’s business needs. 

Understanding stakeholders helps us identify where BAs might need to spend more time and resources. It also helps business analysts figure out how to engage with stakeholders. All of this is part of an early but essential step in determining the business analysis activities that are required for success.

Wrapping up

Identifying stakeholders may take a lot of time and effort. However, it’s best to consider each stakeholder’s requirements and ensure that most requirements are satisfied than to deliver a product that completely fails to meet stakeholders’ expectations.