Understanding Organizational Stakeholders for Design Success

Who stakeholders are and why they matter

Stakeholders are defined as “individuals or organizations who stand to gain or lose from the success or failure of a system” (“Nuseibeh and Easterbrook, 2000”:http://www.doc.ic.ac.uk/~ban/pubs/sotar.re.pdf). For a software system, this can include managers, designers, and users of a system. Since, by definition, stakeholders are those who are impacted by (or have an impact on) the project, their perspectives need to be taken into account in order for a project to be successful. Stakeholders can have positive or negative views regarding a given project, and often don’t agree with one another, making it a challenge to reconcile their varied viewpoints.

A design must meet the business needs of the company, and must be supported by disparate members of the management team, in order to be actually implemented.

User-centered design professionals pay special emphasis to one type of stakeholder–the users of the system–arguing that user experience needs to be carefully crafted to satisfy user needs. While understanding user needs and goals is certainly necessary, it is often not sufficient for producing a successful design. Apart from an understanding of user needs and perspective, design needs to incorporate the goals and perspective of other stakeholders in order to get their buy-in and be considered a success in the corporate workplace.

Stakeholders are often in conflict with one another. For example, consider the design of a system for use in a manufacturing plant. Factory workers might value a high degree of autonomy and personal control over their work practice, while management might value efficiency and standardization of the factory’s workflow (Spinuzzi, 2002). The goals of various organizational stakeholders might differ as well. For example, the factory manager might want to maximize the output of the factory, while the CFO might want to have a real-time view of the factory’s inventory, even if implementing such a system will decrease factory output.

Design occurs in this complex environment, and needs to fit into it. Stakeholder analysis is the designer’s tool for synthesizing these disparate worldviews, to insure that her recommendations also fit the business requirements and thus will actually be implemented.

It is worth considering the history and lineage of the term “stakeholder analysis.” The term was introduced in a seminal book by R. Edward Freeman called Strategic Management (1984). The word stakeholder was used to stand in contrast to the neoclassical view of the firm as catering to stockholders. Freeman used the term stakeholder analysis to remind management that it was in the long-term interests of the company to pay attention to the interests of those who have an impact on or are impacted by the activities of the company. The present article uses the “stakeholder analysis” concept to extend the focus of user experience practitioners beyond the end user, to the organizational context of the project.

Stakeholders as users
User experience professionals can benefit from the ideas about stakeholder analysis that have been developed in the field of Requirements Engineering. Requirements Engineering for software systems starts with the basic assumption that there will be multiple stakeholders with differing requirements, and that some requirements will be in conflict with other requirements (Nuseibeh and Easterbrook, 2000). This is because different stakeholders have different goals (in the previous example, the goal of the CFO was to track the assets of the company as accurately and efficiently as possible; the goal of the factory manager was to maximize factory output). Systematically exploring this problem space (of differing requirements) can lead to the discovery of design solutions that meet the goals of the stakeholders while removing (some) requirements conflicts. The goal is to reduce requirements conflicts while maintaining as high a level of stakeholder satisfaction with the design as possible.

This way of thinking should be natural to user experience professionals, who are used to thinking systematically about user goals and resolving conflicts between those goals. In fact, it is easier than a typical design problem because:

• It is easier to reach organizational stakeholders, since they are members of the organization that you are working with. There is no “elastic user” (Cooper, 1999); each stakeholder is a flesh-and-blood person you can talk to.
• Stakeholder goals are typically concrete, and explicitly tied to particular business or performance metrics for the purposes of compensation. As a result, stakeholders will often be quite explicit about what their goals and what their objections to a given project might be.

Focusing on business stakeholders and their goals is important for creating successful designs. However, an exclusive focus on business stakeholders could lead to problems–producing a design that does not meet user needs, or is not technically feasible. A design must meet the business needs of the company, and must be supported by disparate members of the management team, in order to be actually implemented. Not paying attention to the strategic needs of the company and the particular goals of individual stakeholders often dooms a design to rejection by management, regardless of how well it might meet the needs of end users.

Many recent articles have discussed the need for user experience professionals to understand business requirements and context into their work (McMullin, 2003, Lash, 2002). In our own work, we have made an effort to incorporate stakeholder analysis as a core process, done early in the design research phase of a project. This article presents the “how” of understanding business goals and requirements.

Goals of stakeholder analysis
Stakeholder analysis serves a dual purpose. Information gleaned from stakeholder analysis is helpful in creating design solutions that are appropriate to the business context. This is important for making sure that user experience design moves in concert with the rest of the company. Secondly, stakeholder analysis helps gain greater acceptance of design solutions. This goal is fulfilled even when it is not possible to fulfill the first goal. For example, consider a redesign of an ecommerce site that has a risk of causing an immediate revenue reduction. Even if there is no way to eliminate the risk of revenue reduction, stakeholder analysis will help the user experience practitioner anticipate what the objections to this project could be and build a business case to show why the redesign is necessary for the long-term growth of revenue. Forewarned is forearmed.

One of the goals of stakeholder analysis is to anticipate reactions to the project, and build into one’s plans the actions that will help win support for the project. User experience projects have often had a difficult time winning support from management and development teams. This issue often arises later in the project cycle, by which point stakeholders already have had a chance to stake out their positions.

Our experience is that conducting stakeholder analysis early in the project gives us a chance to anticipate potential objections and take care of them upfront. Stakeholders, when shown the results of a project, are not surprised, and recognize their own input into the project. This personal investment makes them more likely to accept the results.

Steps in stakeholder analysis

1. Identify organizational stakeholders.
The first step in stakeholder analysis is to identify who your stakeholders are. Think of all the people within the organization who are impacted by your work, who have influence over it, or have a stake in its successful completion. For example, imagine a project to redesign the item page for a large ecommerce vendor such as Amazon. Amazon has a crowded page for each item, with many components visible within a given page. If each of these page components represents a business unit that wants a presence on that page, then multiple product managers will be impacted by any changes to the page.

Projects will succeed or fail primarily based on the actions of people who care enough to defend or oppose them.

Asking what the organizational challenges are to a particular project is an excellent way to identify key stakeholders. Organizational charts can be of some help, but are often not fully representative of patterns of influence within an organization (Marshall, 1999). Initial stakeholder meetings can help you identify other stakeholders: in each of your initial meetings, ask about who else might be affected by your project, or might have a strong opinion about it, and try to meet with those people.

Sometimes it is difficult to get meetings with influential stakeholders. In this case, the best substitute for a face-to-face meeting is to schedule interviews with a subordinate of the stakeholder. If your project is truly of interest to the stakeholder, the subordinate will be familiar with the stakeholder’s position on the issue and will, in effect, be representing the stakeholder on that issue, much as a lawyer represents a client. Meeting with the subordinate will get you the information you need, and the stakeholder will feel that they have had input into your project.

In our experience, an outsider perspective is often invaluable for conducting stakeholder analysis. It makes it possible to start with a clean slate for every conversation. People inside the company are themselves stakeholders, and may be too deeply entrenched to be able to analyze the perspective of other stakeholders in an unbiased manner; outsiders will not have these issues. If using someone from outside your own organization is not an option, be sure to pick someone who will be perceived as a “neutral party” for the role of stakeholder analyst. They will be more effective than someone who is deeply entrenched in the project.

2. Prioritize stakeholders.
When meeting with stakeholders, we recommend keeping notes in a table that estimates the stakeholders’ influence and their interest in the project, and specifies their overall goals, and their objections to the project.

A sample table is below.

Table 1: Stakeholder Perspectives
Stakeholder	Position	Influence	Interest in Project	Goals	Objections to Project
Andre Agassi	CEO	10	High	Exceed quarterly estimates for next 4 quarters	Seems like it won’t pay off in the time frame he’s most concerned about
Chris Evert	Product Manager	6	Medium	Increase % of company revenue generated by his product Get noticed by Andre	Will it reduce number of sales?

Note: this document is the opposite of a deliverable (an undeliverable?). It is “for your eyes only”. In the interest of workplace harmony, never misplace such a worksheet or leave it in a place where a client might see it.

Once you have organized information about stakeholders in this manner, you easily identify stakeholders on the basis of their power and interest in the project. Broadly speaking, stakeholders can be organized into four groups:

• High Influence, High Interest: Some stakeholders might have a lot of influence over the project, and also be very interested in the project. It is vital to understand the viewpoints of such stakeholders–specifically what potential objections they might raise. Spend most time on these stakeholders.
• Low Influence, High Interest: Other stakeholders might have a lot of interest, but little real influence. Such stakeholders (if they are in favor of your project) can be valuable sources of information: they can get you access to documents relevant to your project, fill you in on the institutional history of past efforts in your project domain, and help you identify what the organizational challenges to the project will be. These are good stakeholders to meet with first, since each interaction is relatively low-risk.
• High Influence, Low Interest: Stakeholders with high power, but low interest need to be broadly satisfied. They won’t pay attention to the fine print of your project, since they perceive the project as not affecting them. However, they have influence on whether the project will be a success: for example, they may have a vote during the approval process of a project. The goal of your interactions with this type of stakeholder should be to give them enough information about the project that they will not create obstacles for your project.
• Low Influence, Low Interest: You should spend less time with stakeholders who have little influence and little interest in the project. They aren’t interested in what you are doing, and are not in a position to help you do it.

One interesting thing about the suggestions generated by this model is that interest matters more than influence in determining the value of interactions between yourself and stakeholders. High interest, low influence stakeholders give you the ammunition and contextual information needed to make your case with the high influence stakeholders. Low interest, high influence stakeholders, in contrast, simply need merely to be won over or neutralized in a fairly superficial way. Projects will succeed or fail primarily based on the actions of people who care enough to defend or oppose them.

You can visualize the stakeholders relative power and interest with a two-by-two grid, and color-code them by whether they are supporters or opponents of the project. In the below visualization, supporters are colored green, opponents are colored red, and neutral parties are colored black.

 

It is important to have an accurate understanding of the power and interest of various stakeholders. This kind of stakeholder analysis is best done in conjunction with someone who understands the organizational context well. Asking your project sponsor what the organizational challenges to your project are is a good way to start compiling your list of key stakeholders. Subtle cues (for example, someone’s position on an issue being described by others when they are not present) can also indicate the level of a given stakeholder’s influence to the careful observer.

3. Understand stakeholder perspectives.
A good way to understand stakeholders is to conduct semi-structured interviews. Broad, open-ended questions can be a good way of starting a conversation with stakeholders. Asking about ways that your project might go right, ways that it might go wrong, and what sources of data are available can be a good way of directing the conversation towards collaborative problem solving (DeBono, 1985). If a stakeholder has strong opinions about your project, it will come through during your conversation. Follow-up questions should focus on design alternatives or solutions to the problems raised by the stakeholder.

We have had particular success using free-listing techniques (Sinha, 2003) with stakeholders (Boutelle et al, 2004). Asking multiple stakeholders questions that yield answers in the form of lists (example: “What kind of things do you think users will be able to do on your site five years from now that they cannot do right now?”) can provide a rich data set that is amenable to statistical analysis, and can also serve as the input to card-sorting exercises with users.

Conduct stakeholder interviews until you start to experience diminishing returns. If you are learning less and less from each interview, and you believe that you have met with representatives from all the business units that are affected by your project, than it is probably time to call it quits. Also, it is a good idea not to conduct all the stakeholder interviews at once. While it is a good idea to meet representatives from all the groups early in the process, it is often very fruitful to have more meetings as your thinking about the problem evolves. It also provides a chance to explain design solutions that you are considering on a one-to-one basis, rather than present the solution to a group of people at once.

4. Incorporate stakeholder perspective into design.

Strong objections by powerful stakeholders will not go away just because you understand the reasoning behind the objections.

Part of the benefit of stakeholder interviews is accomplished simply by doing it well. It is not just that people like to be consulted, and that if you talk to them they will feel better about the process; a week of meetings with representatives of disparate business units will give you a much richer understanding of the corporate strategy, interdepartmental dynamics, and challenges a company faces than many of their employees have. This perspective will quite naturally seep into any designs you propose.

However, strong objections by powerful stakeholders will not go away just because you understand the reasoning behind the objections. If the objections are not addressed, they may jeopardize the success of the project. The preferable option is to design away the objections. Remember that the business units in a company represent the business concerns of a company. Try turning a negative on its head. For example, if the project is going to negatively impact the revenue of a particular business unit, try to imagine how the project could be redesigned so that that the business unit actually sees revenue increases. Not only will you be improving the odds of your project succeeding; you will also be providing a solution that better meets the strategic goals of the company.

Sometimes there will be objections that cannot be satisfied with design changes, because the changes required to satisfy the objections would eliminate the central benefit of the project. For example, a project to simplify a user interface may lead to a loss of training revenue, as users will need less training in order to be able to use the product effectively. This will certainly be of concern to the director of the training program. Decreasing the simplicity of the interface (thus lessening the objections of the training program director) will also decrease the benefit gained by providing a simpler, more intuitive interface (happier customers, better word-of-mouth for the product, increased sales). In such a case, you will have to win the argument about why your design serves the strategic interests of your client. Collect data that makes the business case for your proposed design. Verify that your design does in fact support the strategic goals of the company as a whole. Win over as many other stakeholders as you can to your case.

Costs of stakeholder analysis
Below are some of the costs of and potential problems with conducting stakeholder analysis.

• It takes time and adds to the amount of work for a project.
• Stakeholder interviews can sometimes have unintended repercussions! Projects are the domain of particular people, and have limited purview. Such limits and boundaries can often be invisible to outsiders or newcomers. It is important to understand exactly how to frame and portray the project you are working on during stakeholder interviews. You don’t want to step on people’s toes and cause people to view your project with alarm.

Benefits of stakeholder analysis
Below are some of the benefits of conducting stakeholder analysis.

• Acceptance of recommendations: The biggest benefit of stakeholder analysis is that design recommendations are more likely to gain acceptance. By conducting stakeholder analysis early in the process, and getting some feedback on the recommendations, the stage is set for the recommendations to gain acceptance within the organization.
• Design is more likely to serve business goals: By spending time understanding stakeholder perspectives, recommended solutions are more likely to be in tune with business requirements and goals.
• Stakeholders gain familiarity with design research methods: Take the opportunity of meeting with stakeholders as a way to familiarize stakeholders with your own goals and methods. For example, for a project where we were developing personas, we described what personas are, how we were going to create them in each interview. The result was that by the time stakeholders were introduced to the personas we created, they already understood why personas were important.

Stakeholder analysis is a very effective mechanism for bringing other perspectives into the design process. Over the years, the user experience field has seen a flowering of methods and techniques for understanding users. It is time to expand the focus and include the perspectives of others who are impacted by (or have an impact on) user experience work. Stakeholder analysis is an effective way of making that happen.

See also: Understanding the Business: How to Get Good, Usable Requirements

 

Additional Resources

Applegate, Lynda M. “Stakeholder Analysis Tool.” Harvard Business School Note 803-171.

Boutelle, J., Sinha, R. Swearingen, K., Cornett, L.,Dan, I. Rapid User Mental Modelling at eBay: a case study. IASummit, Feb 28, 2004.

Cooper, Alan. 1999. The Inmates are Running the Asylum. SAMS. New York.

De Bono, Edward. 1985. Six Thinking Hats. New York: Little, Brown, and Company.

Freeman, R.E. 1984. Strategic Management: a Stakeholder Approach. Boston: Pittman.

Lash, J. The myth of user-centered design. 2002. Digital Web magazine. Oct 2002.

Manketelow. Stakeholder Management-Winning Support for Your Projects.

Manketelow. Stakeholder Planning–Planning Stakeholder Communication.
Marshall. Surfing Office Politics.

McMullin, J. 2003. Searching for the center of design. Boxes and Arrows September 2003.

Nuseibeh and Easterbrook. 2000. Requirements Engineering: A Roadmap. ICSE–Future of SE Track.

Scholl, H. J. Applying stakeholder theory to E-Government. Benefits and Limits. Proceedings of the 1st IFIP conference on e-Commerce and e-Government, October 2001, Zurich, Switzerland.

Sinha, R. Beyond Card-Sorting: Free-Listing Methods to Explore User Categorizations. Boxes and Arrows, Feb. 24, 2003.

Spinuzzi. 2002. A Scandinavial Challenge, a US Response: Methodological Assumptions in US and Scandinavian Prototyping Approaches. 20th annual International Conference on Computer Documentation.

Jonathan Boutelle is a software engineer who has worked in the high-tech industry for the last decade, with experience spanning computer graphics, information visualization, and business-to-business ecommerce at such firms as AVS and Commerce One. He is currently principal at Uzanto Consulting where he specializes in integrating technology and business requirements into the practise of user experience design and analysis.

He posts an occasional rant at www.jonathanboutelle.com and can be reached at jon at uzanto.com.