Best Practices to Identify Stakeholders on a Software Development Project
- 416 views
- 10 min
- Dec 24, 2020
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.
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.
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 know who our project stakeholders are, we classify and prioritize them.
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.
One 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 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 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 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 stakeholders should be monitored, yet excessive communication with them is not needed since their influence on the project outcome is limited.
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.
How we engage and cooperate with stakeholders
If there’s no support from stakeholders, an entire development team’s work may go to waste. Engaging stakeholders in software development helps us get a fresh look at project plans or decisions. Stakeholders often have a better understanding of why a particular feature or flow is necessary and can help our team understand how to build it. On the other hand, if they don’t understand the necessity of a feature, they may resist its implementation.
Engaging with stakeholders is necessary to make sure that each of them is aware of the decisions made on the project and the impact these decisions can have on them. This helps prevent disappointment and objections when the product is ready.
The more stakeholders are involved in the work, the better the chance they’ll be pleased with the result. Although managing stakeholders can be a job in itself, and though it might seem that business analysts don’t have much time for all the needs of different stakeholders on a project, the efforts are worth it. Below, we share our approach to engaging with stakeholders.
We engage with stakeholders individually
We build a customized communication plan for each stakeholder or each group of stakeholders since they all have different levels of power and interest and play different roles in the project.
Moreover, each stakeholder or group of stakeholders has specific needs and preferences regarding communication.
As the project progresses, business analysts continue monitoring the level of stakeholders’ engagement. During the software development process, new stakeholders can join the project while other stakeholders leave. An individual approach and continual monitoring of stakeholders’ involvement allows us to determine why engagement changes and whether additional engagement is needed.
To ensure a high level of stakeholder engagement, our business analysts first figure out how much time we need to request from individual stakeholders, especially for executives. Then we schedule dates and times for meetings with these stakeholders. In this way, we continually remind them of their importance to the project.
Now that you know how our team takes an individual approach to each stakeholder, let’s see what topics we discuss with them.
We discuss all critical aspects of the project
One of the major topics to discuss with stakeholders is project goals. The aim is to ensure that all stakeholders share the same vision of how software development should be carried out and what outcomes it should lead to.
Setting objectives is one mechanism that can help us understand what’s important for the project at a particular time. Discussions with stakeholders let our team clearly define the steps we need to take to achieve the project goals.
Another aspect we discuss with stakeholders is the project scope. Establishing the scope of the project means defining key characteristics of the software product and its functionality. The scope depends heavily on what stakeholders expect from the final results.
Later in a project, stakeholders are involved in software product testing and reviews.
Now let’s talk about determining the most effective way to communicate with stakeholders.
We build a transparent communication flow
Before communicating with stakeholders, our business analysts need to define the format, contents, and timing of communications. There are various formats that can be used for communication such as emails, meetings, and phone calls.
Content is another variable to consider. Business analysts need to decide what type of information will be shared, how many details will be discussed with stakeholders during a meeting, and what these details will be.
Business analysts also need to determine the timeframe and frequency of communication. They have to specify why specific information is required at a particular time and what the expected result or impact will be when stakeholders receive it.
One of the most efficient tools to maintain communication with stakeholders is a communication plan. This document describes the means, topics, and schedule of communication and enables us to effectively deliver information to stakeholders.
Below, we demonstrate a communication plan we created for one of our projects:
A communication plan doesn’t have to be complicated, but it has to be thoughtful. A business analyst shouldn’t be the only person who collaborates and communicates with stakeholders. At RubyGarage, project managers as well as team leaders and key team members also work directly with stakeholders.
To make communication with stakeholders even more efficient, our team uses minutes of meeting (MOM). MOM is a written record of topics discussed, decisions made, and the next steps planned during a meeting.
At RubyGarage, we use the following MOM template:
MOMs allow meeting attendees to keep track of meeting results and inform those who didn’t attend the meeting about questions discussed and decisions made.
Identifying and engaging with 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.
The most useful approaches to identifying stakeholders are stakeholder interviews and brainstorming.
To classify stakeholders, experienced business analysts use power interest grids, RACI matrices, and stakeholder value checklists.
Business analysts at RubyGarage follow three principles to ensure a high level of stakeholder engagement:
- Take an individual approach
- Discuss all critical aspects of the software development project
- Build transparent communication flows
If you’re looking for a software development company that knows how to satisfy your business needs, add value to your software product, and reduce development costs, contact RubyGarage and tell us about your project!
Subscribe via email and know it all first!