Ian Alexander and Suzanne Robertson

All the projects that we work on seem to have one thing in common: developers are concerned about the difficulty of involving the right stakeholders to discover, specify, and test requirements.

We ran the Stakeholder Concerns Survey (see Table 1) to better understand what people mean when they say, "We have a problem with our stakeholders." We asked each participant to choose one stakeholder concern that causes the biggest problem in his or her environment. The objective was to discover which concerns are the most frequent and where we should focus our improvement efforts. Table 1 summarizes some specific problems:

Commitment. People with authority (business and technical managers) don’t commit enough time or budget for requirements.

Skill. The stakeholders (this includes all types of stakeholders, both business and technical) don’t have the skills necessary to participate in gathering requirements. They describe solutions rather than requirements, and they change their minds.

Discovery. We can’t discover the appropriate stakeholders. Finding all the people who must be involved in discovering, inventing, and specifying requirements is difficult.

Maintaining. We can’t keep the stakeholders interested and involved throughout the entire project.

Other. Of the 5 percent who answered "other," the most common reason was lack of communication between stakeholders and developers. On reflection, we realized that a formal understanding of what we mean by a stakeholder was the first step toward addressing the stakeholders’ concerns.

A project stakeholder is someone who gains or loses something (could be functionality, revenue, status, compliance with rules, and so on) as a result of that project. In other words, a stakeholder is much more than a product’s eventual "user." A stakeholder can be someone who finances the project; someone whose skill is needed to build a product, such as a network specialist or a usability expert; an organization whose rules developers must obey, such as a tax lawyer firm or a standards institute; or an external organization that can influence project success, such as an environmental group or a competitor. Given this wide and complex project sociology, it helps to have some way of modeling the stakeholders and their differing involvements.

We can view the containing system as a tool. For instance, if the product is a business information system, then the containing system might be an investment business. Shareholders might own this business and benefit financially from it, and a board and president might run the business and derive power from it (of course they are probably also financial beneficiaries). So, a chain of responsibility exists, and we use the simple metaphor of a straight dotted line of linked icons (left side of the diagram) to indicate this.

Incidentally, the onion model uses several more metaphors (not to mention the name onion itself and the title of a tutorial we recently ran, "Stakeholders without Tears," shown in Figure 2).

To use the onion model approach, you can start either with an empty set of circles or with typical slots already present. Either way, you ask stakeholders (in workshops or interviews) what their roles are, and you populate the model accordingly—down to the contact details of the people filling each role. Then you can investigate any slots that remain unfilled and ask if anyone knows who might fill roles in those areas. Finally, you can check for possible conflicts (which we describe further in the next section). Figure 3 shows part of a stakeholder analysis template (see www.volere. co.uk).

You can use this model, as you would an onion model, to help discover missing stakeholders. The template also approaches stakeholder discovery by asking an alternate question: "What sorts of knowledge are we looking for?" leading to, "Who is the source of that knowledge?" The two approaches are complementary because people who have been using one model might overlook a role that the other model immediately suggests. The template provides a formal tool for recording stakeholders’ names and responsibilities and is especially useful when you have several different stakeholders concerned with the same knowledge or multiple stakeholders occupying the same role.

One attractive result of modeling project stakeholders this way is that some simple and effective metrics immediately come to mind (see Table 2). The number of circles, slots, and roles in a model mostly indicates its size, although if fewer roles exist than slots, clearly some slots must be empty.

Once you find the appropriate stakeholders, you can do more detailed work. You model the context, partition the problem, define the requirements, and build the product according to whatever combination of cyclic, incremental, or agile approach you are using. But regardless of the approach, one thing is common: appropriate participation of the necessary stakeholders directly influences your work’s success. Suppose that you have thoroughly analyzed your project’s sociology and have identified the appropriate roles and the stakeholders to occupy them. And all the work you’re doing maps directly to your stakeholder models. All will be well as long as nothing changes—and there’s the rub. The world your stakeholder models reflect is guaranteed to change during your project’s lifetime, and these changes are likely to affect your stakeholder involvement. Certain indicators signal the need to do some work on stakeholder involvement.

Any reorganization in your contained system or anywhere in the wider environment might take stakeholders away from your project. Changes in job titles, department names, repartitioning of the organization, and new geographical locations all signal potential changes to your stakeholders. This might require you to add new roles.

When someone leaves the organization, gets promoted, or changes jobs, you’ll probably need to make some changes to your stakeholder roles. We have often seen this slip through the cracks because when an occupant leaves a role, he or she often forgets to inform the new role occupant of his or her stakeholder responsibilities.

If the context of your investigation changes, new or different knowledge boundaries will probably exist. This might happen because extra functionality is introduced to the project or a new external influence could exist, such as a new law. This often introduces new roles and hence new stakeholders. At the start of a project, we map the context of investigation to the stakeholder analysis and monitor the mapping to ensure that the world we are investigating is still in sync with our stakeholders and vice versa.

Finding the appropriate stakeholders is one thing; keeping them involved throughout the project is another. Everyone is increasingly busy—unless you can keep your project in the limelight, people lose interest and treat it with less urgency. You need to design feedback mechanisms so that the stakeholders know what’s going on and why it’s relevant to them. Part of our project planning involves building an agreedon project knowledge model with the stakeholders—specifically what we mean by each project deliverable and who is interested in and responsible for which deliverables. Then we design frequent feedback loops to make the agreed deliverables visible to the appropriate stakeholders.

Missing stakeholders result in missing requirements and escalating project costs. Once you’ve analyzed your project using a combination of onion models and stakeholder analysis templates, your project sociology models become a tool for monitoring the continuing involvement of the appropriate stakeholders.

Suzanne Robertson is a principal of The Atlantic Systems Guild and co-author of Managing the Requirements Process (Addison Wesley 1999), Complete Systems Analysis (Dorset House 1994)