Follow us...

Business Analysis Core Concept Model (BACCM)
Understanding Stakeholders

By Julian Sammy, Head of Research and Innovation, IIBA   
In the second BACCM column, back in November 2012, the Core Concept "Stakeholders" was very short. Unlike Value (where we think we know what it means, but don't), "Stakeholders" is fairly easy to understand. It's just people.
Unfortunately, understanding the definition of “stakeholder” doesn't mean we know how to deal with them effectively in practice. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) v2 has a lot of information about stakeholder identification and analysis, and v3 will extend this with a Task called “Manage Stakeholders” in 2014. In this article, we'll look for insights using the Business Analysis Core Concept Model (BACCM).
Definition: a person or group with a relationship to the change or solution.
The most general version of this idea is "relevant people". BAs usually shouldn't focus on people with no relationship to the solution or the change, as they are usually not relevant. But what makes a person relevant to a change or to a solution? What turns a person into a stakeholder?
A person is a stakeholder if a change or solution causes them to experience a change in value, or if they can affect value experienced by a stakeholder. Experiencing a change in value doesn't mean that you're a change agent, or directly involved in a controlled transformation of organizational systems. For example, consider a project that is going to move staff to a new office. The families of the people being moved are stakeholders, not because they are part of the change, but because they affect the value change experienced by the employees.
Relationship to a Change or Solution
The BACCM definition of Stakeholders focuses on the change and the solution because those are usually a meaningful place to start, and a useful way describe the kinds of relationships that BAs care about.
  • Change Stakeholders: While there are many relationships a person may have to a change, in practice BAs usually care about three: Sources, Reviewers, and Approvers. These people will be directly involved in the change. They may be Solution Stakeholders as well.
  • Sources have Needs which are elicited by the BA, and transformed into requirements. Many sources are also change targets and solution stakeholders.
  • Reviewers are change agents who will do work based on requirements. Reviewers may also be solution stakeholders, who support the solution after the change.
  • Approvers make a go/no go or a stop/don't stop decisions based on the requirements. Approvers may be external solution stakeholders, such as regulators, or staff.
  • Solution Stakeholders: In practice BAs usually care about four types of people who interact with the solution: Customers, Staff, External, and Support. These people use the solution, sustain the solution, or are part of the solution—now, after the change, or both. They may be internal and external to the organization. These Stakeholders will have to change their behaviour or receive some communication related to the new solution. They are not necessarily involved in making the change (see Change Stakeholders, above), but may be represented by a selected group such as a focus group.
  • Customers make use of the solution, and are usually external to the organizational change being considered. Depending on the nature of the solution, these stakeholders may be called many things, including constituents, clients, voters, patients, users, members, taxpayers, or consumers.
  • Staff are usually stakeholders because they are part of the solution. Staff have operational roles and some reporting relationship within the organization, but may not be employees. Volunteers, consultants, outsourcers, and interns all fit this category. Managers, leaders and other decision-makers are also Staff.
  • Supporting stakeholders ensure that the solution continues to operate. People in support roles are often staff (and may be reviewers of a change), but may not be. For example, a mechanic may be independent of the car owner or work on a company fleet. Supporting stakeholders are critical to sustainable solutions, but are easily overlooked by project teams.
  • External stakeholders do not use the solution and are not part of the solution, but they have some interest in the solution. The organization may be a customer of an external stakeholder, such as a tool vendor or a landlord. Regulators, auditors, and legislators are common external stakeholders.
Change Agents and Change Targets
Some stakeholders are change agents, like the BA, testers, and sponsors. These people are actively involved in causing and controlling the controlled transformation to organizational systems. Others are change targets (occasionally called 'victims' by the humorous and cynical).
  • Change Agents catalyse change: they make changes happen but are not themselves altered. For example, when a project is done, a BA is still a BA, but a customer service representative (CSR) might have a completely new set of responsibilities. The BA is a change agent, is part of the change, and is not changed.
  • Change Targets are the ones who have to alter their behaviours to adapt to the new solution. The previously mentioned CSR is a change target, and a solution stakeholder. A few CSRs may be stakeholders in the change as well, especially as sources of requirements—they may be interviewed or have the requirements elicited from them.
Outside of these two groups, there are many stakeholders who are part of the context. They may be considered interested parties or influencers, but they are not part of the change.
Changes in value are strange beasts. A person can experience a decrease in value by having an expectation of loss: I might lose my job in the next reorg, so the value I derive from the work I do is lost. At a recent conference, they held a big, free raffle. People who walked in with nothing, paid no price for entering the raffle, and walked out with nothing felt a loss. But what did they lose?
The value that a stakeholder experiences before, during, and after a change are often quite different from the value the same stakeholder experiences when operating a solution. Note that there are four distinct categories here.
Normal operations occur when a person is doing their job and participating in various organizational systems. Most organizational systems are operationalized at some point, with standards, processes, rules, automation, and so on. Unexpected and uncontrolled changes often occur during this time—bugs, breakdowns, problems, failures, underperformance, and so on. Any of these may flip a person into any of the other three categories. For example, “before the accident” is a period of time that can only be identified in retrospect, so there is no experience of “before the change”. (Anxiety and similar experiences of loss-anticipation are discussed in “before the change”, below.)
After a change refers to the period when a person is aware that a change has happened, and is still adjusting to that change. Habits and expectations from the previous “normal operations” still affect the experience of value from the new solution. Requirements that anticipate this period may define training, communications that reinforce the value of the new solution, measures and reports on the value, and feedback mechanisms to address stakeholder concerns.
Project teams are notorious for declaring this time as “out of scope” for analysis, or pretending that the change will be adopted quickly and easily.
During a change is the time when change agents are most actively engaged. In many changes, the change team is actively engaged for much longer than other stakeholders—which means that from their point of view, they are in the time before a change. 
“Before a change” refers to the period when a person is aware that a change is coming. They may care about it, or not, but they know about it. If a person is not aware of an impending change, they are operating normally (see above). During this time, all kinds of strange value adjustments occur, which makes setting expectations a key activity for business analysts.
Note that a person can anticipate a change that is not real, highly unlikely, or even impossible. If the person is anticipating a loss, we may call this pessimism, anxiety, angst, alarmism, or even paranoia. This is a powerful force in most people, and can provoke dread and fear. Don't underestimate this: a person may experience relief—a gain in value—when the dreaded event occurs. This can be powerful enough to provoke a person to seek out the loss event. This may be called “self-sabotage” or “fear of success” or “self-destruction”.
Anticipation of gains that are unlikely or impossible can be just as problematic. Dashed expectations can make an otherwise phenomenal solution feel worthless; this is commonly experienced when something "didn't live up to the hype".
Risk identification, analysis, and management are necessary for good business analysis, but they are not sufficient. The capacity to assess and address the consequences of anticipation are just as important.
Develop your technical skills in dealing with risks—identifying, analysing, and managing them. You're going to need them to deal rationally with change, and to make evidence-based decisions.
Develop your underlying competencies for interacting with people—especially facilitation, negotiation, and leadership. You're going to need them to deal with the emotional side of changes. Stakeholders are complex animals. You should know: you are one.