Stakeholder Analysis enables the identification, classification and communication of project stakeholders
Your new system just went live and the project, that replaced a critical legacy system, is coming to a close. Business analysts gathered requirements and worked closely with users and developers, but did you capture all of the requirements? You sit in your office waiting for the phone to ring or the emails to begin pouring in and that’s when the thought first crosses your mind:
- Did we consider all of the regulatory requirements?
- Are all of the data consumers and providers accounted for?
- Did we get all of the system interfaces right?
Now you begin to sweat as you recount each of the people who contributed to requirements. Running through how they interact with the system. Unfortunately it is too late. The requirements are done, development is over, and the system is live.
This scenario keeps project sponsors, CIOs, and business analysts, up at night. Each of the questions above, and others like them, can dramatically impact project success. But how do we know who to talk to? Did we ask the right people the right questions? Questions like the ones above need to be answered by the right people for a project to be successful. Each question represents one or many stakeholders who need to contribute to the project. Stakeholders can vary greatly from project to project and organization to organization, but in one form or another they always exist. The trick is to know exactly who the right stakeholders are for your project.
Stakeholder Analysis is a business analysis activity that reduces the risk of missed requirements by focusing on stakeholder identification, classification and communication. Regardless of how much time you spend defining requirements one truth that cannot be ignored: You will miss requirements if you do not ask the right questions and the art of asking good questions beings with the right people. Skip stakeholder analysis and you may discover some unexpected and unfortunate surprises later in your project when they are more difficult and more expensive to correct.
Stakeholder Analysis brings three recognized benefits to any project:
- An understanding of the impact of change and an accurate gauge of the scope of the project
- Minimizes the risk of missed requirements
- The clear communication of expectations and roles to all project stakeholders
Business analysis and requirements efforts typically focus on two stakeholder groups: those who will use the system and those who will build it. These two groups generally yell the loudest and traditionally have been the primary stakeholders on system and software projects. However, with interconnected systems/organizations, legacy software, third party products, data warehouses and numerous other complexities, polling these two stakeholder groups is not enough. “Hidden stakeholders” and the information/requirements they provide can easily come back to haunt a project in the form of re-work, higher costs, and missed schedules if stakeholders are not thoroughly examined from the start of a project.
Get the Scope Right
Understanding who your stakeholders are begins with understanding the scope of your project. The systems that are impacted, process that are affected, and the areas of your organization involved will govern you scope and which stakeholders you need to include.
Consider the last time you flew on a commercial airline. If we equate that flight to a project then the pilots and the cabin crew, would be the developers and all of the passengers onboard would be the users. In this case, taking the traditional approach to stakeholder analysis and only speaking with these two groups would lead to a solution that does not represent all of the other stakeholders who are part of the in-flight experience. For instance, the members of the flight crew are not the only airline employees who have a hand in getting that plane into the air. Mechanics, gate staff, caterers, air traffic controllers, and many others all work together to get passengers to their destination. If one of these stakeholder groups is not consulted, then your in-flight experience or the success of your project could be compromised.
Stakeholder identification should begin right when a project is first coming together and the scope is being defined. Determining the correct individuals to bring into the project, exactly what their involvement will be, and how to communicate that information goes a long way and will aid scope definition. Business analysts have several tools at their disposal to facilitate the identification of stakeholders, but a powerful technique and simple start is the Business Context Diagram.
Business Context Diagram
Essentially a level 0 Data Flow Diagram (DFD), the Business Context Diagram sets the scope of a project by examining a process or business area using five factors: goals, stakeholders, users, technology employed, and guides/constraints. Identifying stakeholders using a Business Context Diagram starts by asking the following questions:
-
Goals: Who is responsible for the execution of this goal
-
Process: Who is impacted by this process or what area is under investigation?
-
Users: Who can represent this user group?
-
Systems: Who owns these systems and will they be impacted by your project?
- Externals: What internal organization and externals (upstream and downstream) will provide or consume data
- Guides/Constraints: What policies or regulations must be adhered to?
To facilitate the examination and the communication of this information to others build a basic model which describes each of these components and identifies the stakeholders. This model can easily be built during a facilitated session on a whiteboard and/or in a modeling tool.
Business Context Diagrams, and other brainstorming technique, are excellent tools for identifying stakeholders who have a direct impact on the business process, system, or business area being investigated. However, this is step one. It is also important to understand how stakeholders relate to one another.
Identify All the Stakeholders
Some stakeholders have secondary and tertiary relationships to the process or business area being investigated. Even though they are not as obvious, these stakeholders also impact projects and systems therefore need to be considered during requirements definition.
Stakeholder Relationship Modeling
Stakeholders are often interconnected and identifying those relationships is a powerful brainstorming technique. Stakeholder Relationship Modeling documents stakeholders by starting with a single stakeholder, often the primary user, and describing how other stakeholders are connected to that person. The business analysts should ask the question “who else interacts with this individual throughout the execution of any business processes or in conjunction with this system?” Repeat that same question again and again for each stakeholder that is identified until all options are exhausted. The use of this technique often leads to secondary and tertiary stakeholders. To avoid getting stuck in “analysis paralysis” set a clear boundary that states how many degrees of separation will be considered from a primary stakeholder.
Identifying stakeholders and their relationships to each other benefits business analysts by allowing them to perform impact analysis on a proposed change. For instance, if the airline decides to introduce a new beverage it is easy to see that not only the Passenger is impacted by the new beverage, but that the Cabin Crew, Caterer and Beverage Supplier are all related to each other and will be impacted by this change.
U
nderstanding stakeholder relationships aids impact analysis and mitigates the risk of missing stakeholders who might be one or two levels removed from a business process or system under investigation.
Once stakeholders have been identified, the next step is to document pertinent information about each stakeholder using a method which is easily understood by project participants. The scoping and identification techniques described above rely on diagrams, but their limitation is that they provide a minimal amount of space to capture details about each of the stakeholders they have helped us identify. Creating a Stakeholder Profile gives the project team a single document to capture important stakeholder details.
Stakeholder Profile
Understanding your stakeholders means having information about them at your finger tips. This information can change depending on your organization and your project, but the need to document it remains constant. The Stakeholder Profile is a simple table that lays out each of the stakeholders that you have identified and provides space to fill out information on each stakeholder. Examples of information that you may wish to capture include:
Employing a Stakeholder Profile on your project allows all participants to easily access stakeholder information so that it can be taken into consideration as they begin project work. Scheduling meetings, holding elicitation sessions, and managing change throughout the project are just a few examples where the Stakeholder Profile can be leveraged to ensure that the right people are included and that you and your team are prepared to work with them.
Communicate Expectations and Involvement
Identifying and documenting stakeholders is a great start, but stakeholder analysis is about enabling future interaction. Future interaction begins with communicating expectations and involvement to ensure that everyone who needs to be involved in the project is included. Classifying how these stakeholders will contribute and the role that they will play in the project based on their position in the organization or area of expertise is the next step in stakeholder analysis. A common approach used to set expectations and establish involvement in the project is RACI Analysis.
RACI Analysis
RACI is an acronym for Responsible, Accountable, Consulted, and Informed. RACI Analysis is a business analysis and project management technique used to classify stakeholders and how they will need to contribute and/or participate in completing various projects, business processes, or initiatives. To perform RACI analysis, build a Responsibility Assignment or RACI Matrix which lists the potential stakeholders on one axis and the specific project activities or business processes on another. Next, step review the list of stakeholders and indicate the degree to which each stakeholder will be involved in each project activity using an R, A, C or I. Use the chart below and descriptions of the following terms as an example.
-
(R) Responsible – Stakeholders who will be directly working on or performing project activities (Example: Business Analysts and Project Managers)
-
(A) Accountable - Stakeholders who are ultimately accountable for the successful completion of the activity (Example: Project Sponsor)
-
(C) Consulted – Stakeholders whose information and opinions will be needed to successfully complete the activities (Example: Subject Matter Experts)
-
(I) Informed – Stakeholders who will be told about the progress and outcome of activities (Example: Outside Business Units)
The benefit of using a RACI Matrix for Stakeholder Analysis is that it presents, in an easily consumed manner, the degree to which each stakeholder will be involved in a project or business activity. The matrix then becomes a communication vehicle which informs each stakeholder of what will be expected of them during a project. At the same time business analysts and project managers can use the matrix to plan and execute project activities accordingly.
After roles and contributions have been clearly documented within the RACI matrix the next challenge is getting this information out to the proper stakeholders using a medium that they can access and understand. If you do not set up an effective way to communicate with your stakeholders then it will be impossible for them to properly contribute. Email and phone calls are the old standards, but with IM, message boards, social networks and a litany of other tools at our fingertips it makes sense to formally document how communication will take place. Establishing a Stakeholders Communications Plan in the early days of a project solves this problem.
Stakeholder Communication Plan
How will we communicate? This is the question that the Stakeholder Communication Plan addresses. By documenting communication standards and formalizing how information will be distributed the Stakeholder Communication Plan prevents individuals from being left out of project discussions or missing out on important project information. At the same time, the communication plan establishes the proper means and times of communication, maximizing the ability for stakeholders to contribute effectively. To develop a Stakeholder Communication Plan, just ask yourself five questions:
-
What?: Type of Communication
-
How?: Means of Communication
-
Who?: Recipients of Communication (hint: look at your stakeholder profile)
-
When?: Time and Date
-
Where?: Location (yes, online is a location)
Answering each of the questions listed above for all of the communications that you want to engage your stakeholders with aids planning and sets clear expectations of stakeholder involvement from the beginning. Setting up this platform of consistent communication enables collaboration and gets your project and business analysis efforts off to the right start.
In Conclusion
Whether you are an Enterprise Business Analyst defining the direction for your organization or the focus of your work is on the maintenance of an existing product or system, stakeholder analysis is an important business analysis activity that will help you scope your project and define who needs to be involved. Clarifying scope, identifying “hidden stakeholders”, properly setting stakeholder expectations, and communicating those expectations reduces the chance that requirements will be missed due to a lack of stakeholder involvement. In some circles, stakeholder analysis is seen as the job of the Project Manager. However, stakeholder analysis is an activity that must involve the business analyst in order to guarantee that requirements are being gathered from the right individuals. Begin each project with stakeholder analysis and continue to revisit the artifacts that it produces throughout the life of your project. You’ll know exactly who will be providing your requirements and you will be asking good questions to the right people.
Author: Matthew Leach is a Senior Consultant with Doreen Evans Associates, Inc. (http://www.doreenevans.com) a professional services firm committed to business analysis and requirements excellence. A recognized thought-leader in the business analysis profession Matthew works with clients to improve their business analysis practices and successfully execute projects. He can be reached at: [email protected]