Best Practices to Identify Stakeholders on a Software Development Project


In a previous article, we explained that business analysts help software products and teams stay intact. Let’s explore in-depth the business analysis processes necessary to ensure the longevity of projects and how they work. The first process we’re going to look at is stakeholders identification.

Without correctly identifying and prioritizing project stakeholders, chances are looser that your development team’s endeavours will be wasted. At times it can be challenging to answer how to identify stakeholders and who they are, but in this article, we’ll show you the best practices and approaches business analysts to use when looking at these situations head-on!

Who are the stakeholders?

During the early development of a company, business analysts work closely with key contributors to ensure that the analysis of individual features will not only impact the product but also any other part of the company. These key contributors are usually referred to as stakeholders.

Stakeholders are anything that holds a stake in some event. In some cases, they may even have two stakes, depending on the potential outcome of that event. For example, if one was to have a coin toss, then those that held a stake would be teams A and B, but they would also be mutually held stakes as different outcomes could result in a win for either team.

Stakeholders are often considered those who are affected by the project. However, the notion of a stakeholder can vary significantly. We also consider those who will affect our team and overall workflow on the project as stakeholders. For example, regulatory entities like permits need to be obtained for building structures, which will impact the final schedule of our project so this is something we always have to keep track of.

Any individual or group that has specific needs that must be met for them to get involved with your product can impact the development of a project, and business analysts generally know how to anticipate not only how certain decisions will affect your project team but also how these internal and external stakeholders will ultimately make an impact on the success of your endeavour.

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 counting them in too) - here at Distinct Clouds 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 internal such as (project sponsors) and external such as end-users and integration support teams like wireless hardware suppliers.

How we identify stakeholders 

Our clients use several methods to identify project stakeholders, and one of them is conducting interviews. Interviews are conversations that help our clients collect information, which can lead to better decisions about the project or how it will affect other areas in the future. By asking questions during interviews with customers, we can also target key stakeholders who have specific knowledge of the project or possess information that may impact the project in any way. Some examples of questions we often conduct with our customers are:

  • Who could be affected?
  • Who could be affected during the project?
  • Who could be affected after the project?
  • Which groups could be impacted or have an interest/stake?
  • Who needs to know about what you're doing and when?
  • Who will fund the project?
  • Who sets the vision/goals?
  • Who approves changes impacting the budget?
  • Who approves changes impacting the schedule?
  • Who will test the end product?
  • Who will use the end product?

Now you have the general idea of how we interview our clients and what questions we ask to uncover who our stakeholders are.

Another useful tool is brainstorming, which can be used for this same purpose. We gather our client and the rest of the project team for an impromptu group discussion where we pose a question that will guide us during this session:

Once we have a list of the stakeholders, we look very closely at the most important of these:

  • Business stakeholders - these are the people who help determine what you want to do with your business and how you get there. They can play a big role in helping you stay on task and get your project accomplished according to plan.
  • Technical stakeholders - These are the ones who can help with a technical approval-for example, if your customer’s CTO was involved in the planning process, they’re more likely to be able to provide more useful input during this course. Having more of them involved from the early stages will only mean that you get a better result all around!
  • Target audience. These are the most important stakeholders since you're building for them! To get a better idea of who your customers are, you need to put together an ideal customer profile and persona.

    Once you know who's on the other end of your product, then you can start differentiating among them and figuring out how best to prioritize helping them - starting with those of the highest value who will amass the greatest return on investment of your time and resources.

How we classify and prioritize stakeholders 

Not all stakeholders are equal. And that's why it's vital to look at them all about the project itself, because different people may have varying levels of authority and interest in the goings-on about a company. Some may have varying degrees of decision power or simply want to be passive onlookers. But whatever the case may be, it's imperative you know exactly who they are and where they stand when it comes time to make plans for a new project.

First of all, let's create an Accounts Register - which aims to list all the people who will contribute to the project. Let's take a look for example at our client/customer who relies on us to take care of this aspect of their network. This is what it could look like.

Another tool that we use in the workflow is a power interest grid

In this grid, we can categorize our stakeholders based on both their power and their interest.

  • High power, high interest (Manage closely) stakeholders mean a lot to the project and have the potential to affect all of its facets directly. We keep these people close because they will be amongst those with a major say in how the project turns out - so we must satisfy their needs so as not to lose them or have them sabotage our efforts!
  • High power, low-interest stakeholders need to be kept in the loop with what’s going on with the project. They may not be very interested and they may not be involved with your development work directly but they still wield a lot of power and they can easily influence the project. A good idea would be to ask them what they would like to see in an ideal product and try to set up short interview meetings as often as possible as that will allow you to keep them satisfied without offending them or moving forward too quickly.
  • 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 in giving us a detailed definition of the project requirements.
  • Low power, low interest (Monitor) stakeholders should be monitored but excessive communication with them is not needed because their influence on the project outcome is limited.

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

A RACI matrix—this is a tool for classifying stakeholders, supporting the tasks needed to complete a project. The acronym stands for responsible, accountable, consulted and informed parties. Let’s see what each label refers to:

  • The first category, responsible, addresses those people who take on a task as their responsibility and complete it as they should.
  • The second category, accountable, outlines those individuals who will liberally delegate tasks to others and will closely monitor the progress of those tasks before providing input at later stages of development. This means they will review deliverables and make sure they’re up to par with the original objectives.
  • Ensured — A person who ensures that everyone is aware of the project’s progress and high-level decisions and who is also aware of the outcome after a specific task has been completed

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

We also have a checklist that assists our business analysts to assess the possible contributions of each stakeholder or group of stakeholders. You must be recognized as a valid stakeholder by demonstrating that you possess one or more of the following traits:

  • Have access to valuable resources
  • Can influence decisions through your position
  • Are able to provide information Business Analysis requires
  • Are able to deliver added value and insight Provide the data and access required for Data Analysis

Our business analysts work with clients to identify the project’s key stakeholders. This is because it helps them identify who’s got their hand on the pulse of what makes your idea tick. Knowing who your key stakeholders are will help our business analysts understand how they can approach engaging with these individuals, and ultimately it will help them figure out where their project might need more support.

Wrapping up

Identifying stakeholders may take a lot of time and effort, but it’s best to ensure that stakeholders are happy with the result than to deliver a product that completely fails to meet their expectations. Keep your stakeholders happy by taking an active role throughout the development cycle.