The term “stakeholder” has gained broader usage since Edward Freeman’s 1984 publication of Stakeholder Management, which firmly established the term and the importance of stakeholder management as an active task. However, over the years it has come to mean any and all parties touched by the system, with the net result that “managing stakeholders” is often interpreted as a downstream public relations activity rather than an upstream process identifying and serving potential customers.

We distinguish beneficiaries from stakeholders to help resolve this challenge. Beneficiaries are those who benefit from your actions. Your architecture produces an outcome or output that addresses their needs. You are important to them. It is beneficiaries whom we must examine in order to list the needs of the system.

By contrast, stakeholders are those who have a stake in your product or enterprise. They have an outcome or output that addresses your needs. They are important to you. This is much closer to the original concept of stockholders, who supply cash (which the firm needs), in return for a stake in the firm, notably a share in the firm’s profits.

These two concepts are distinct but they overlap, as shown in the Figure 11.2. At the center of the diagram we have Beneficial Stakeholders, who both receive valued outputs from us and provide valued inputs to us. Beneficiaries who aren’t stakeholders we call Charitable Beneficiaries, in that the firm receives no return (however indirect) from the outputs provided to them. Stakeholders who aren’t beneficiaries are Problem Stakeholders, in the sense that you need something from them, but there is nothing they need that you can provide in return.

There are many beneficiaries and stakeholders of a product/system, both internal and external to the organization. Internal beneficiaries and stakeholders include technology developers, design teams, implementation, operations, sales, service, management/strategy, marketing, and so on. External beneficiaries and stakeholders include regulators, customers, operators, suppliers, investors, and potentially competitors.

There is a further issue that influences the identification of beneficiaries and stakeholders: There may be an operator who is neither the primary beneficiary nor the primary stakeholder. In a taxi, the driver is not necessarily the primary stakeholder if the driver’s cab is owned by a firm. The driver is also not the primary beneficiary, because that role is filled by the passenger. Therefore, we distinguish among operators, stakeholder, and beneficiaries. In a consumer context, these are often the same actor; the consumer buys the car, operates the car, and benefits from the car. However, in most corporate and government settings, these are distinct roles with incentives that skew their behavior. This division of roles causes us to realize that to deliver value, we must focus on the stakeholder who is the primary beneficiary.

The first step of any stakeholder analysis is identifying stakeholders and beneficiaries, as shown in Figure 11.1. Stakeholders are identified by asking, “Who provides inputs that are required to make this project successful?” Beneficiaries are identified by asking, “Who benefits from the outputs of this project?”

Typically, beginning to list potential stakeholders and beneficiaries is not difficult. Starting with existing products on the market, existing customers, existing shareholders, and existing suppliers can quickly give rise to a long list. Additionally, as we saw in Chapter 10, we can source possible stakeholders and beneficiaries from upstream and downstream influences on the architecture.

The main difficulties in identifying stakeholders and beneficiaries are setting the boundaries of the analysis and setting the granularity of the analysis.

First, we must set bounds—that is, decide how far from our system or enterprise the analysis should extend. For example, the economic concept of the multiplier effect of government spending states that for any direct payments to contractors, there are reverberations in the broader economy as those contractors engage suppliers, and as the employees of the contractor spend discretionary income at local businesses. Where should we draw the line? Later in this chapter, we will illustrate a quantitative analysis by which we can prune downstream stakeholders if the impact diminishes, but the reality is that this depth of analysis is challenging to undertake (indeed, there is substantial discussion on measuring the multiplier effect). ^[1], [^2]

Second, it can be challenging to set the right granularity—in other words, to choose the right abstractions for stakeholders. Should we consider individual suppliers, or should we abstract them as “Suppliers”? Are individuals important, or just their department or their firm as a whole? Do individual suppliers have different needs and different influence, or are there many suppliers with similar needs and influence? Is the purpose of the stakeholder analysis to understand the market context at a 30,000-ft level, or is it to develop product specifications?

Our guidance for setting the bounds of the analysis and choosing abstractions is to test for architectural impact. Testing for architectural impact involves understanding whether the choice among architectures under consideration could be important to the stakeholder or beneficiary. If all architectures will deliver the same benefit to them, they will still need to be managed as stakeholders, but they may not merit consideration in making the architectural decisions. Further guidance on stakeholder identification is given in Box 11.1. In Part 4 we discuss quantitative methods for conducting this test.

The output of this procedure is a first-pass list of stakeholders and beneficiaries. Subsequently, we will prioritize stakeholders, which offers us an opportunity to revisit the list.

• Driver/owner (primary beneficiary)

• Regulator

• Producing enterprise or company

• Investors in the enterprise

• Suppliers

• Local community

• Environment NGOs

• Oil companies

• The Hybrid Car project

Using this procedure, we can create the list of stakeholders and beneficiaries for the Hybrid Car. Note that we could also have included other car companies in the analysis, either to reflect market share questions, or because we believe they play a positive role in growing the market or boosting consumer comfort with hybrid systems. However, in this analysis we have ­omitted other car companies. We have also included the Hybrid Car project itself as the reference, because we will want to illustrate the interactions between the stakeholders and the project.

Beneficiaries and stakeholders have needs. Needs are a product/system attribute in that you build a system to meet needs. Therefore, an important part of the first step of our stakeholder analysis (Figure 11.1) is identifying the needs of our beneficiaries and stakeholders.

Box 11.2 defines needs. Needs can be expressed—you know you want something—or ­unexpressed or even unrecognized.

In many cases, the identification of requirements is levied from the customer-specified technical requirements or past technical systems, without examining where needs arise. Furthermore, there is often a selection bias that tends to highlight technical needs because they can be more easily quantified as requirements. Requirements analysis has not always mated well with stakeholder analysis in the past, because there are difficulties translating between the outputs of stakeholder analysis and the inputs for requirements analysis. For example, the NASA Systems Engineering Handbook of 1995 makes no reference to stakeholders. A recent version of the “NASA Systems Engineering Processes and Requirements” document (2006) now requires stakeholder analysis as the first step in the procedure for defining requirements, in order to “elicit and define use cases, scenarios, operational concepts, and stakeholder expectations.”

There is no structure to the way that people talk about needs. It is part of the role of the architect, sometimes aided by business development or marketing functions, to understand the needs of the beneficiary.

When setting out to identify needs, consider each stakeholder and beneficiary, and ask what needs the stakeholder has that might be met by the system under consideration.

The most important guidance we can offer is to start with the primary beneficiary and the primary need of that beneficiary, whose needs are satisfied by changes in the principal value-related operand, as discussed in Chapter 7. The test is that if the primary needs of the primary beneficiary are not met, the system will never be a success. In the Hybrid Car example, the driver derives the primary benefit, transportation. The operator may have needs as well, and the stakeholder may play an important role in interpreting the needs of the beneficiary and the operator. We will treat the Hybrid Car’s beneficiary, stakeholders, and operator as the same individual, the driver/owner, even though we recognize that they could be separate. Therefore, the driver/owner is our primary beneficiary.

The driver/owner wants transportation, specifically fuel-efficient transportation. Figure 11.3 illustrates the needs of the stakeholders and beneficiaries we identify for the Hybrid Car. Notice that these needs are not complete at this stage; that is in order to keep Figure 11.3 manageable. Notice also that not all of the needs of the driver/owner are satisfied by the actual Hybrid Car. For example, the need for financial incentives, such as Hybrid Car federal tax deductions, cannot be met by the car-producing firm.

We identified three challenges for stakeholder analysis of complex systems in the introduction:

1. Complex systems, particularly new architectures, often provide new value propositions or address latent needs.

2. Complex systems serve many stakeholders, often with differing needs. It is often ­difficult to prioritize among these stakeholders.

3. Complex products (goods and services) often deliver value indirectly, which may make it difficult to identify all the needs in the system.

Our discussion of beneficiaries and stakeholders has touched on serving many stakeholders and on indirect value delivery, but we have not discussed latent needs. Although listing two or three needs for each beneficiary might be easy, the difficulty does not lie in identifying which needs existing products serve. The difficulty arises in identifying latent needs—those needs that are not yet served by current products. This is a challenge in synthesis of architectures. How did Whirlpool know customers “needed” an ice dispenser on the exterior of the refrigerator before this feature was on the market? How did GM know that customers who already had cell phones would “need” the OnStar™ system to call a central service in the event of an emergency?

The term “latent needs” is used to convey the idea that the needs are fundamental to the beneficiary, before the product that meets those needs comes into being. Needs are not chosen by the firm. We deliberately stay away from the idea that the firm shapes the needs of the market. The idea that advertising changes the customer’s value function is common in marketing. But in our experience, this idea is dangerously overused in an engineering context. The history of product development is rife with products that contained engineered features not valued by the market.

How, then, does one identify latent needs? One of the great breakthroughs in product needs was the idea of observing beneficiaries and the user using the product. Ernest Dichter pioneered in-depth interviews with consumers in the 1950s, searching for the underlying qualities that users perceived in the product. The design firm IDEO uses what is termed empathic design to observe potential customers in context, on occasion spending hours following shoppers through grocery stores. By definition, there is no set practice for identifying latent needs; a procedure that identified needs with accuracy through analysis would contravene the idea of latency. The only answers are deep scrutiny of users, including customer feedback on previous products, iteration on product concepts, and hard work.

As a caution against the hubris of asserting the latent needs of the customer, consider the litany of failed architectural predictions. Thomas Edison said in 1922, “The radio craze will die out in time.” Ken Olson, the founder of Digital Equipment Corp, said in 1977, “There is no reason anyone would want a computer in their home.” Imagine all the predictions made by overconfident architects whose product did not outlive their failed understanding of latent needs!

A central tenet of stakeholder theory is that stakeholder value results from an exchange. We are identifying the needs of the beneficiary so that we can architect our system to satisfy these needs. This is the first half of the exchange; our outputs or outcomes satisfy the beneficiary’s needs. The other half of this exchange is that stakeholders have outputs or outcomes that meet our input needs, as shown in Figure 11.4. This exchange is at the heart of stakeholder analysis. This observation will help us identify other potential stakeholders and their needs.

When we were identifying beneficiaries, we asked, “Who benefits from the outputs of this project?” Now we can see that the root of that question has two parts: the outputs or outcomes of the project, and the needs of the beneficiary. It is often worthwhile to explicitly list the outputs of the project and identify whether all of the project’s outputs are received by a beneficiary. For example, if the project produces regulatory approval for a new hybrid technology, might other projects within the enterprise benefit or have a stake? Might suppliers benefit? This question may lead to the identification of additional needs.

The complementary question we asked in identifying stakeholders was “Who provides inputs that are required to make this project successful?” We can now see that this question has the same exchange quality. We have already listed the needs from the perspective of the ­project, but we could similarly list the outputs of the stakeholders and beneficiaries and determine whether any of these outputs might be important to the project. In essence, we are changing the frame of reference between stakeholders, asking about the inputs and outputs of each. This can be helpful in stimulating creativity about needs.

For example, the driver/owner will produce driving behavior—she or he will operate the car. Is the driving behavior important to the project? It could be very helpful to understand the needs of drivers. An electric vehicle with a gasoline engine charging the battery might cause range ­anxiety with a range of only 80 km, and if we collected data on a prototype to show that a segment of buyers take trips of greater than 80 km only 5% of the time, it might impact our ­perspective on the importance of range. Therefore, there might be classes of hybrid ­vehicles where returning driving behavior is an important component of the exchange, such as with BMW’s MiniE and ActiveE demonstrator programs.

This fundamental exchange nature of beneficial stakeholder relationships acts as a completeness criterion to enumerate stakeholders and beneficiaries. The crux of this method is that the input needs of each stakeholder and beneficiary are listed (traditionally, it is easiest to argue what you need and hardest to indicate to whom you provide valued inputs), then the method works to identify which stakeholders provide those inputs. After iterating around a network, this method provides a complete list of stakeholders and their outputs at a given level of detail. This is shown as the check outputs match inputs step in Figure 11.1.

This is the critical link that will enable us to compare the needs we identify for each beneficiary with the outputs or outcomes produced by our architecture. Therefore, we can restate “stakeholders who must be considered and satisfied” as stakeholders whose outputs or outcomes are important to fulfilling our needs. This is the core principle by which we will later prioritize stakeholders according to what needs the project has.

This is fundamentally different from the consumer context. In consumer product markets, the only traditional output of the consumer is money, given in exchange for purchasing ­products. For complex systems, we will argue that there are important differences. The business-to-­business markets and nonmarket environments that prevail for many complex systems cannot be treated with the logic of consumer markets, which typically assumes that beneficiaries are static entities whose only feedback is acceptance or rejection in the market. Stakeholders and beneficiaries are often more actively engaged in product definition. These stakeholders and beneficiaries can and must be deeply engaged in project definition and criteria setting.

Having listed the potential needs that the Hybrid Car could satisfy, we proceed to the final task of Step 1 in Figure 11.1: taking a first pass at prioritizing stakeholders and beneficiaries by grouping them.

In Figure 11.5, we have classified our stakeholders according to whether we believe they are charitable beneficiaries, beneficial stakeholders, or problem stakeholders. For example, we receive regulatory approval from the regulator, but it is not clear that we provide anything of value to the regulator. By contrast, we need the parts the supplier produces, and the supplier needs our volume in order to fill its capacity. Similarly, we need gas from oil companies, but an aim of our project is to consume less gas by producing a Hybrid Car, so we have classified them as problem stakeholders. This classification might change if, for example, we partnered with the retail arm of an oil company to install fast charging stations at their gas stations. In that context, the oil company would need our cars to earn revenue on the electricity sold, and we would need its network of charging stations to create a use case for consumers. In this situation, we might reclassify our oil company partner as a beneficial stakeholder.

It would seem logical to prioritize problem stakeholders above charitable beneficiaries, but at this stage it is unclear which beneficial or problem stakeholders should take first priority. Similarly, we haven’t discussed how to prioritize within each group. Which of the problem stakeholders is most important?

Having made a distinction between beneficiaries and stakeholders, and having identified beneficial stakeholders, we will now condense to using the more traditional term “stakeholder” for brevity unless otherwise noted.

There are many other frameworks for grouping stakeholders. Another useful approach is to group stakeholders on the basis of how involved we want them to be in decision making: ­stakeholders who have veto power over decisions, stakeholders who have a vote in decisions, stakeholders whose opinions are important but who do not receive a vote, stakeholders who should be consulted about decisions, and (finally) stakeholders who should be informed of decisions.

The simplest method we have found is to group stakeholders in three buckets:

• Stakeholders who must be considered and satisfied

• Stakeholders who must be considered and should be satisfied

• Stakeholders who should be considered and might be satisfied

We’ve applied this taxonomy to the stakeholders in Figure 11.6, but we do so at this point without an explicit method. This is our first guess. Our experience suggests that writing down the expectations of stakeholder importance before conducting an in-depth analysis is a useful way to compare expectations against analysis. In Step 2 of Figure 11.1, we will prioritize the needs, and we will begin to consider our stakeholders in a system, both of which procedures will inform our prioritization of stakeholders.

In summary:

• Beneficiaries have needs; you are important to them.

• Stakeholders produce outputs that you need; they are important to you.

• Value delivery occurs in an exchange, when your outputs meet the needs of beneficial stakeholders, and their outputs meet your needs.

• Think carefully about which stakeholders and beneficiaries are included in the early stages of product definition, because they will have an outsized impact on the architecture.