How Business Analysts can Identify Stakeholders in a Project Environment

Being a business analyst means working with a wide range of people, spending time gathering information, analysing information, clarifying information, asking questions, negotiating, and making recommendations. We achieve these tasks by interacting with different people in and out of the project environment. Those we interact with from time to time to help drive the project forward are referred to as stakeholders.

A stakeholder is someone or a group of people who have an interest in the project's success; they are affected by the project's outcome and can also influence the outcome of the project.

Being able to identify the stakeholders and the contributions they can bring to the table, at the early stages of the project, could greatly impact your ability to progress the project through the different phases in a positive way; it will also help with minimising some of the issues relating to managing difficult stakeholders.

However, one of the challenges you may encounter is that most stakeholders will have their normal day jobs, which they need to fulfil. They will also have a project-related job, which they also need to give some time to in order to make the project a success. Another challenge you may encounter is identifying all who will play a key role in the project, even if you haven’t been handed down a comprehensive list by the project manager.

Having a list of stakeholders should not be considered as the final destination when it comes to identifying all your stakeholders. Additional stakeholders, you didn’t know about at the kick-off phase may be identified and added as the project progresses and some stakeholders might drop off the grid. So how do you go about making this phase of the project life cycle a success? There are many techniques and methods to achieve this goal, but in this blog, I will be sharing the approaches I have used countless times, and they always work, so happy reading.

Look in the Project Initiation Document/Project Charter:

In my experience, I have always started off with sitting with the Project Manager (PM) to ask for a list of those involved in the project by way of analysing the Project Initiation Document (PID). You may find that the PID is always in a Work in Progress State (WIP) because it’s a very detailed document and most PMs don't have the capacity to complete it pre-kickoff. However, if a PID doesn’t give you the information you need, ask for a Project Charter, which is usually an easier document for the PM to complete. Whatever the scenario, ask for one of these documents because they will usually contain the list of stakeholders.

Check the Organisation Chart:

Also, if you have been doing some research and asking questions, one of the artefacts you should consider asking for is the organisation chart (org chart). This document will usually have a diagram of the key people in the organisation and the various reporting lines. Helps to quickly check who may be impacted by the transformational or change related projects to that is underway and it also helps to ensure you don’t miss out on key influencers or powerful people in the organisation, who have the ability to make or break the project.

Conduct a Document Analysis:

A good place to also take a look is the document repository used by the organisation, it could be anything from DropBox to SharePoint, and the list goes on. What you should be looking to analyse are documents relating to similar projects, projects with dependencies, lesson learnt logs and associated program management documents. Alternatively, request for all project-related document from the Program Management Office(r) (PMO). Request for access to different folders because some documents will contain links to other documents used as a reference point for related projects. some of these documents are only accessible to those with the right viewing. It doesn’t hurt to speak to people to find out who else may be impacted by, or needs to be informed of the project. Once you have all these details, deciding on the next steps is important. Below are some steps to help you remain on top of your Business Analysis game:

Step 1: Find answers to some of the questions below:

• Who are those directly involved with the project?

• Who are those indirectly involved with the project?

• Who may be affected by the project or the outcome of the project?

• Who will gain or lose from the project’s success?

• Who wants to complete the project successfully and who doesn’t?

• Are there any suppliers, if so who are they?

• Who are the end-users of the result of the project?

• Are there any external parties that will be impacted by the project or its outcome?

• Who has the authority to influence the project or its outcome?

• Who can make your project fail?

Step 2: Create a Stakeholder Knowledge Matrix

This is a simple document that will help you to conduct a Know Your Customer (KYC) on the stakeholder. By completing this one simple activity, you will save yourself from stress further down the line, because this will help you to know your stakeholder better and guide how you interact with them. The best way to get the information is to ask them directly for some of the details required during an informal conversation and ask others especially the PM to fill in any gap. In this document, you want to list the names of the stakeholders on the left, top to bottom and across; you want to have the following headings:

• Name of Stakeholder

• Title of stakeholder (official title)

• Role of stakeholder in the project (project title)

• Best time to contact (Morning/Afternoon/Evening)

• Preferred communication style (Face-to-Face/Email/Phone/Instant Message)

• Level of interest in the project (High/Medium/Low)

• Level of influence on the project (High/Medium/Low)

• Perceived impact of the project on stakeholders (High/Medium/Low).

Step 3: Identify the roles ascribed to the stakeholders in the project:

As mentioned earlier, some of the stakeholders you come across in most projects will have a day job, within the business and they will be expected to play in role in the successful delivery of the project. Sometimes their project titles will completely be different from the Official roles in the business and so it is important to understand what these project titles may potentially be and what it means. Below are some of the project titles you will come across in your business analysis journey:

• Business Architects: Ensures business guidelines and procedures are followed and ensures any decision made are consistent with the overall business model/ blueprint.

• Business process owner: Provides insight into the current business process and makes suggestions for improvements.

• Change Manager: Responsible for ensuring all change requests follow the right protocol and all financial/non-financial implications have been considered before providing the final approval.

• Customers (internal/external): They are the project beneficiaries and have a closer encounter with the problem being resolved.

• Product Manager/owner: Provides input regarding how the proposed changes will impact the business, including a no-change decision.

• Programmers: Responsible for writing the codes and ensuring there are no bugs in the new/proposed systems prior to going live with the end product.

• Project Manager: Responsible for managing the end-to-end delivery of the project; ensures the project teams are working together and following a well-defined project framework.

• Subject Matter Expert (SME): Provides expert knowledge relating to products, services, systems, or any other area within their remit.

• Testers: Responsible for ensuring the requirements can be tested and the end products/services meet the standards prescribed

Step 4: Create your RACI Matrix:

You will need to sit with the PM to understand what role each stakeholder will play in the analysis phase of the project and plot it in the RACI matrix. RACI is an acronym that stands for:

• Responsible

• Accountable

• Consulted

• Informed.

You can set up a RACI matrix by listing the activities relating to the analysis phase on the left (confirm with the PM) and across you introduce the R-A-C-I and add the names of the stakeholders into the grid. Alternatively, you can list the activities on the left, names of the stakeholders across and then map the R, A, C, I roles under each of the stakeholders. The key to remember is that only one person can ultimately be accountable for a task, while one or more people can fit into the other roles (responsible, consulted or informed).

It is important to kick off your project activity by carrying out the important task of identifying your stakeholders. In addition, you should ensure you review your stakeholders from time to time, as a way to check that you have all the right stakeholders helping you to drive a successful project analysis. If you omit a stakeholder you could potentially be risking the successful completion of your project, in extreme cases, your project could be delayed or canned (discontinued).

To learn more about how to identify your stakeholders, I have created an online course titled “The Business Analyst’s Playbook”. The course aims to help you hit the ground running on any project as a business analyst, with a proven process that hundreds of my students and I have used to successfully deliver multi-million pounds projects in some of the top organisations in the UK.

Click here to learn more about The Business Analyst’s Playbook.