Identifying and Working With Stakeholders

A stakeholder is any person, group, or organization that can influence, contribute to it, or be impacted by your initiative. Your stakeholders bring different knowledge and priorities to the work, and they rarely, if ever, want the same things from it. Some understand how the work happens today. Some control funding or make key decisions. Others have to live with the changes you introduce. Partnering with each of them helps you understand their various perspectives and make better decisions about what to build and ultimately how to implement it.

Engaging them early can help you understand needs and constraints you might otherwise miss, identify potential impacts and/or unintended consequences, and surface differences before they become even harder to resolve.

In this chapter we look at how to identify your stakeholders, map their influence and relationships, understand what they are trying to achieve, and plan engagement that keeps them involved through the rest of the lifecycle.

Who Counts as a Stakeholder?

Identifying your stakeholders helps you find the people and organizations who can inform and shape the solution, as well as those who will be affected by it. Understanding their relationship to the work, what they know, and how they may influence or be affected by your initiative then helps you decide how and when to involve them.

Additionally, it's very important to remember that not every stakeholder will interact with the system in the same way. For example, your users may use it every day and be directly impacted by the way it works whereas senior managers may control funding and provide input on why the system should be implemented without ever actually using it. Others may be directly affected by changes the system introduces to their work or responsibilities. Some people, like IT support staff, may only get involved when something goes wrong.

Understanding these differences is important, because different stakeholders contribute different things, and knowing what those differences are helps you figure out whose input you need, what input you need from them, and how to involve them. For instance, senior stakeholders focus on how an initiative aligns with the organization's strategy and how much it will cost. Users help you understand day-to-day needs and work practices so you can design the system accordingly. Operational teams help you understand the technical options and constraints the solution must meet.

A useful way to think about, identify and categorize the groups you need to consider is:

• Key decision-makers that have significant authority over the initiative, such as executives and senior managers who control staffing, resources or strategic direction.
• Primary stakeholders who are directly affected by the solution or its outcomes. They often include end users, customers, service recipients, and others who will use or be directly affected by the solution.
• Secondary stakeholders who are affected more indirectly by the solution or the organizational changes it creates, such as people in adjacent departments, partner organizations, and downstream teams.
• External stakeholders who sit outside the organization but may influence the initiative or be affected by it. These can include regulators, suppliers, standards bodies, policymakers, and community groups.
• Subject matter experts (SMEs) who have specialized knowledge about needs, risks, and constraints. They may include people from legal, compliance, finance, enterprise architecture, privacy, accessibility, or security.

Be mindful that these categories often overlap, and the same person may fit into more than one. For example, you might work closely with a department manager, who is a primary stakeholder, a decision-maker, and the subject matter expert for a process you are replacing.

Identifying Stakeholders

Start by working with your team to brainstorm everyone who might be affected by the initiative, contribute to it, or influence its direction.

To help identify these groups, use the previous list and also explore:

• Who benefits from this work?
• Who will be directly or indirectly affected by the changes?
• Who could be disadvantaged or negatively affected?
• Who influences key decisions or controls resources?
• Who might oppose, resist, or raise concerns about the work?
• Who has knowledge, responsibilities, or dependencies the team needs to understand?
• Whose perspective might be easy to overlook because they have less influence or are less visible to the project team?

Reviewing organizational charts can also help you understand reporting lines, decision-making authority, and relationships between teams, while examining current process flows helps identify who participates in the work.

When identifying the stakeholders to engage you should pay particular attention to roles that deal with compliance, legal, procurement, finance, HR, infrastructure and security as they usually provide invaluable insight into important requirements, constraints, risks, and dependencies your solution almost certainly must address.

Stakeholder Mapping

A stakeholder map is a way of visualizing the people, groups, and organizations that may matter to your initiative. Early in discovery this map can help you organize what you already know, identify relationships between stakeholders, and spot people or groups you may have missed (Stickdorn et al., 2018).

You can create a stakeholder map by placing stakeholders relative to how closely they are connected to the system or initiative, distinguishing between people who interact with it directly, those who are involved through related processes or decisions, and those who are affected more indirectly. You can also organize stakeholders according to what matters for the problem you are exploring. For example, you might group them by their level of involvement, influence, relationship to users or customers, or the part of the organization they represent.

Stakeholder mapping is also useful for capturing and illustrating your understanding of your stakeholders over time. As you conduct interviews, observe work, review documents, and talk with stakeholders, you can add new people, relationships, goals, dependencies and areas of influence to the map as you discover them.

Clarifying Stakeholder Roles and Responsibilities with RACI

Confusion about who owns what can create delays, duplicated effort, and frustration. A RACI matrix is especially helpful when work crosses several teams, roles and/or responsibilities are unclear, or important activities and decisions require several stakeholder groups to be involved. It maps tasks, deliverables, and decisions to the people involved so everyone has a clearer understanding of their role.

RACI uses four categories to clarify people's role in the work:

• Responsible (R): The person or people needed to complete the task or deliverable.
• Accountable (A): The person who is ultimately answerable for the outcome, approves the work where necessary, and ensures it is completed.
• Consulted (C): The people who provide input, expertise, or feedback before or during the work. Communication with them is two-way.
• Informed (I): The people who need updates on progress, outcomes, or decisions. Communication with them is primarily one-way.

You'll want to develop your RACI matrix after you've identified the main stakeholders and have a reasonable understanding of the major activities involved. Then, review the draft with the people whose roles it describes as working through the responsibilities together surfaces different assumptions, clarifies expectations, and helps everyone agree on who's responsible, accountable, consulted, and informed.

Revisit the RACI as the work moves into development, deployment, and operations as roles can and often do change. Also be sure to update it when an effort's scope changes, the team is restructured, or people move into different roles.

Understanding Stakeholder Goals and Concerns

Introducing a new system can affect processes, roles, responsibilities, policies, training, and everyday ways of working, so these changes need to be understood early rather than left until deployment. Wherever possible, you should involve the people affected in shaping the solution, since they understand how the work happens today, what already supports it, where the problems are, and what may need to change.

You start by understanding what stakeholders want the solution to achieve and how they'll judge success, covering their own needs, their team's, and the wider organization's, then move on to understanding their requirements in more detail during ongoing discovery and development.

As you talk with stakeholders, try to understand:

• Vision and desired outcomes. What they think the product or system should achieve.
• Organizational drivers. If and how they think the initiative matters and what strategic outcomes it should support.
• Viability, budget, and timing. What the resource, schedule, or budget constraints are as this will guide what you can realistically achieve.
• Technical feasibility. What existing systems, data, integrations, skills, or emerging technologies your solution would need to support and work with.
• Assumptions. What stakeholders believe about the problems or opportunities you're trying to address, and about what users and other stakeholders need.
• Risks. The risks stakeholders see you need to address, such as compliance obligations or operational, financial, and reputational risks.

How to Explore Stakeholder Goals

You'll usually need more than one approach to understanding your stakeholder goals and needs. For example, interviews can help you identify individual stakeholder goals, priorities and concerns, contextual inquiry can give you insight into how people are currently doing work and where they're experiencing issues, and workshops can help you and your stakeholders explore potential ways to address the opportunity.

A good starting point is often with interviews, since these can help you get candid perspectives or work through sensitive topics. Workshops are useful when you want people to compare perspectives, explore ideas, or work through a decision together. Remember, be mindful of organizational power dynamics and make sure everyone has an opportunity to contribute.

A Guide to Conducting Interviews

Interviews are often a good place to start when you need to understand what matters to someone as you can follow up when they say something unexpected, ask for an example, or dig into a concern you had not considered.

As the interviewer, you can collect rich, detailed, comprehensive information around the topic you are exploring, whether it is interviewing subject matter experts to understand a particular organizational process or talking to customers to understand their needs and goals better.

During early discovery, interviews can help you understand stakeholder goals and needs, problems with current processes or systems, and what people think the solution needs to achieve. They are also useful when you need to understand why something is happening, uncover informal practices or workarounds, or follow up on patterns you have found in other data.

Interviews also help you build relationships with the people involved and when you approach people with curiosity and respect for their time and expertise, they are more likely to talk openly about what matters to them, what concerns them, and what a successful outcome would look like for them. Building those relationships is vitally important because as the work progresses, you'll need to keep working with your stakeholders. This is especially true for your end users, as you'll need to clarify what you have learned and describe their needs in enough detail to guide design and development, and for senior stakeholders, you'll need to demonstrate that your solution meets their and the organization's goals.

How to Interview Your Participants

Before you start interviewing, think about who you need to talk to, what you need to learn, and how you want to structure the conversation. To help you prepare, review relevant organizational documents, such as strategies, policies, governance materials, and existing plans, as they give you the wider organizational context for your stakeholders and any commitments your solution would need to support.

Interviews can be structured, semi-structured, or open-ended. Semi-structured interviews are a useful starting point because you can prepare the main topics you want to cover while still following up on unexpected or interesting responses. If you are new to interviewing then having a detailed interview guide can help keep you on track.

Regardless of the approach you use, keep the following in mind:

• Identify the people you need to interview. Include people with different roles, perspectives, and levels of influence, including those who may be affected by the change but have less organizational power.
• Prepare the topics you want to explore. Use open-ended questions about goals, current work, concerns, constraints, dependencies, and what a successful outcome would look like.
• Plan enough interviews to answer your important questions. Start with the main stakeholder groups and continue where important questions, differences, or risks remain unresolved.
• Get Permissions. Ask for permission before recording an interview, taking photographs, or making copies of documents, screenshots, or other materials the person shares with you, and explain how you'll use the recording or materials and who will have access to them.
• Build rapport first. Explain the purpose of your interview, how the information will be used, and that you are there to learn from the participant's experience rather than look for right or wrong answers.
• Ask open-ended questions. Questions that begin with "how," "what," or "tell me about" encourage more detailed responses and are less likely to lead people toward the answer you expect.
• Follow up and ask for examples. When someone says something interesting, ask them to explain further or to describe a specific example. Questions like "What happened the last time?" or "Can you show me how you do that?" can help you identify the details of issues, needs, tasks and goals.
• Avoid jumping to solutions. Focus first on understanding goals, experiences, challenges, and constraints rather than asking what features people want. People are often experts in their work and experiences, but not necessarily in designing the solution. Understanding the underlying need is usually more valuable than collecting feature requests.
• Capture what you learn. Take notes during the interview, focusing on quotes, themes, and anything that surprises you. If a second team member is available, have one person lead while the other takes notes. Record the interview as this can be an effective way to ensure you can focus the conversation, while not missing anything. Always obtain participants' permission before recording.
• Debrief soon afterwards. Review your interview notes while it is still fresh and capture your main takeaways, surprises, and any questions you want to explore in later interviews.

A Guide to Conducting Contextual Inquiry

Contextual inquiry helps you understand how work actually happens in its normal setting by combining observation and questions asked while someone is carrying out or explaining their work, identifying tacit knowledge, workarounds, and environmental constraints that might not come up during interviews. Contextual inquiry can help you identify both detailed user needs and broader opportunities for improvement.

For example, a manual workaround you observe may point to a specific user need or a missing feature, but it can also reveal a larger problem with how work is organized or how decisions are made. Looking across several observations can help you identify the immediate requirements the team needs to address as well as wider issues that may shape the goals and direction of the solution.

How to Conduct Contextual Inquiry

During contextual inquiry, your role is to learn from the participant while they work, observe what they do, ask questions when something is unclear or interesting, and capture enough detail to understand both the immediate task and the bigger issues it may show.

During your observation sessions, position yourself as a learner and the participant as the expert, asking them to show you how they do their work as if they were teaching a new colleague. This can help put your participants at ease and encourages them to explain steps they might otherwise skip as "obvious" (Holtzblatt & Beyer, 2017).

Make sure to get approval, access, scheduling or privacy requirements before the session and ask participants for their permission to observe and record. You should also let them know they can pause the session or decline to share information they consider sensitive.

When conducting the session:

• Decide what you need to observe. Choose tasks, workflow, or activity and the people who can show you how their work happens.
• Observe the work. Ask your participant to walk you through a particular task or workflow. Remember to ask them to treat you as a novice so that they don't skip steps.
• Note what people do. Record the sequence of steps, the tools they use, the information they reference, the people they consult, and the interruptions they handle. Pay particular attention to workarounds as these often indicate where current systems or processes fail to support real user needs.
• Ask questions. As the participant works, ask clarifying questions like "Why did you switch to that screen?", "What are you checking for here?", or "What happens if this step fails?" Time these carefully so you don't interrupt the flow of the work. If needed, write yourself a note and return to the question at the next natural pause, such as when they finish a task and move to the next one.
• Document the environment. Capture details about the physical and digital workspace as environmental factors shape how people work and what the system needs to support.
• Capture your observations. Write and/or record enough detail to reconstruct what you observed during your observation, so you do not need to rely solely on memory. You can do this by taking notes, sketching workflows, and taking photos of the environment and artifacts (or taking copies, especially of key documents) that people use and recording audio, if permitted.

A Guide to Conducting Workshops and Co-Design Sessions

Workshops are a great way to bring your team and stakeholders together to align on goals, generate ideas, and make decisions. Having people in the same room makes it easier to hear different perspectives, identify potential roadblocks, and work through priorities and trade-offs as a group.

Workshops are useful at several points during discovery. Early on, they can help you explore the problem, get everyone in the same room to get a picture of what people (especially senior stakeholders) think is important as well as hear different perspectives. Later, as you, your team and your stakeholders learn more they can be used to design potential solutions and explore certain aspects of the potential solution in detail such as co-design sessions, user experience workshops, system architecture workshops etc.

Some common workshops include:

• Kick-off and goal-alignment workshops help you bring key stakeholders together to clarify what the initiative is trying to achieve, agree on priorities, and define how success will be measured.
• Discovery workshops help you build a shared understanding of the problem or opportunity. You can use them to map current processes, identify pain points, surface assumptions, and decide what needs further investigation.
• Co-design sessions help you involve users and other stakeholders directly in developing and evaluating possible solutions. You can use them to map experiences, generate ideas, review prototypes, and compare alternatives.
• Prioritization workshops help you work with stakeholders to compare and rank goals, capabilities, features, or requirements so the team can focus on what matters most.

Planning and Facilitating Workshops

It's a good idea to bring your initial research findings into a workshop so participants have something concrete to react to. This can include common themes you identified from interviews, documents, summaries of data such as the number of people impacted by what you're exploring, or the result of any market research you've done to identify current trends. Review this during the workshop, asking stakeholders for feedback and identify anything that may be missing.

When planning and facilitating a workshop:

• Set clear objectives. Be clear about what you need the workshop to achieve and what decisions, ideas, or other outputs you want to leave with. Without a clear purpose, workshops can easily drift into unfocused discussion.
• Select the right participants. Include the people whose knowledge, decisions, or support you need. Depending on the workshop, this might include sponsors, representatives from key user groups and operational teams, supporting roles such as risk, compliance, or finance, and people who may have concerns about the proposed change.
• Prepare the activities and materials. Build an agenda around a small number of purposeful, time-boxed activities. Prepare any prompts, templates, sticky notes, whiteboards, or digital tools in advance, and make sure each activity contributes to what you need to achieve.
• Plan how you will capture what happens. Where possible, have someone other than the facilitator take notes and record important outputs, decisions, questions, and areas of disagreement.
• Set expectations at the start. Explain how the session will work and agree on basic expectations for participation, listening, timing, and disagreement. Simple ground rules such as "one conversation at a time" and "disagree with ideas, not people" can help.
• Make space for different voices. Senior or more confident participants can unintentionally dominate the discussion. Techniques such as individual brainstorming before group discussion, anonymous voting, or round-robin sharing (where everyone takes a turn) can help everyone contribute. As facilitator, your role is to guide the discussion rather than advocate for a particular answer.
• Keep the workshop moving. Time-box activities and avoid letting one discussion consume the session. If an issue cannot be resolved in the time available, capture it and decide when and how it will be followed up.
• Make the work visible. Use whiteboards, walls, or shared digital tools so participants can see ideas, decisions, and emerging patterns as they develop. This makes it easier for people to build on one another's thinking and correct misunderstandings as they happen.
• Close with clear next steps. Review what was decided, what remains unresolved, who is responsible for follow-up actions, and how the workshop outputs will be shared and used.

Capturing Stakeholder Goals and Needs

As you conduct interviews, observations, workshops, and other discovery activities, start building a picture of what different stakeholders want the initiative to achieve, what they need from the solution, and what concerns or constraints they have.

Stakeholders won't always share the same goals and this will lead to different and competing priorities. For example, the Finance team may be focused on reducing cost, Legal or Risk Management on meeting compliance obligations, HR on how the change will affect staff, and operational teams on whether the solution will work in practice.

You need to understand where stakeholders agree, where their goals conflict, what trade-offs may be required, as these will impact the design of your solution and what gets implemented when. A conflict between speed and control, for example, may affect the design of an approval process. A conflict between reducing cost and improving service may shape what is included in the first release.

The following techniques can help you capture stakeholder goals, needs, and concerns, that will inform the goals, priorities and design of your solution. They also make it easier to see where stakeholders agree, where priorities conflict, and where you need to make trade-offs.

Stakeholder Needs Statements

A simple stakeholder needs statement gives you an easy way to record what matters to each stakeholder and check that you understood them correctly. A useful format for this is:

• Stakeholder: Who the stakeholder or stakeholder group is.
• Needs and goals: What they need and want to achieve.
• Concerns and constraints: Risks, problems, or limitations that must be addressed.
• Success measures: How they will determine whether the solution is successful.

Stakeholder Needs example.

• Stakeholder: Executive sponsor
• Needs and goals: Confidence that the initiative supports organizational priorities and will deliver sufficient value to justify the investment.
• Concerns and constraints: Cost overruns, implementation delays, disruption to operations, regulatory exposure, and benefits that cannot be demonstrated.
• Success measures: Delivery within the approved budget and timeframe, measurable progress toward organizational goals, acceptable risk levels, and evidence that the expected benefits have been achieved.

Develop an Initial Backlog

Once you've captured individual stakeholder goals, you can organize what you've found into an initial backlog. The initial backlog helps you capture the high-level needs, opportunities, risks, and questions identified during your research with stakeholders. You can use it to organize what you've discovered, identify priorities, and plan further discovery work.

As the vision, goals, and requirements become clearer, these can be refined into epics, user stories, technical tasks, and other items, while others you might remove as you learn more.

How to Create an Initial Backlog

• Review your findings. Examine what you learned through interviews, observations, workshops, and affinity mapping.
• Identify possible backlog items. Create an initial item for each significant need, goal, capability or feature idea, or unresolved question.
• Prioritize at a high level. Consider stakeholder impact, organizational goals, risk, urgency, and potential value. A simple high, medium, or low rating is usually sufficient at this stage.
• Identify items requiring further research. Mark these as discovery or research activities that must be investigated before a decision can be made.
• Review and update the backlog. Validate with the team that it reflects your current understanding of the problem or opportunity, and revise it as new information emerges.

Ongoing Engagement and Communication with Stakeholders

Different stakeholders need different information and different levels of involvement. A sponsor may need a short, decision-focused update, while a team affected by a new workflow may need much more detail and regular opportunities to ask questions (Schmitz et al., 2019).

Aim for regular engagement where your stakeholders have opportunities to influence the work as it develops, check that it continues to align with their needs, see how the solution is developing, and provide feedback.

Ongoing engagement can also identify concerns about new processes, responsibilities, or ways of working early enough to address them, and help you adjust priorities and plans as you learn more. Depending on your delivery approach and the stakeholders involved, this might happen through sprint reviews, demonstrations, workshops, milestone reviews, user testing, or regular conversations.

Communicating with Stakeholders

Good communication helps your stakeholders understand what is happening, why it's important and what's expected of them. This helps you reduce confusion and surprises, supports timely decisions, surfaces concerns earlier, and helps maintain engagement as the work progresses.

When developing your communications plan define:

• Who needs to know. Identify the stakeholders who need information and to be kept informed.
• What they need. Decide what information they need.
• How and when will you communicate. Choose the channels you'll use and the frequency you need to communicate and make sure these align with your stakeholder's preferences.
• Define who is responsible. Make sure someone owns each communication and keeps the message consistent across channels.
• Ways to get feedback. Give stakeholders a way to ask questions, raise concerns, or push back, and make clear where that feedback goes.

It's a good idea to structure your communications so that people can scan it quickly, using clear headings, short summaries, and supporting detail only where it is needed.

Communicating with Senior Stakeholders

Senior stakeholders play a critical role in project success but often have limited time and attention. When communicating with them, be brief and lead with the key points, recommendations, or decisions you need, focusing on cost, risk, timing and competing priorities they need to consider.

Be explicit about where you need their input or a decision and provide the most important relevant information they need to make decisions without assuming they have, or need, detailed technical knowledge or knowledge of day-to-day activities.

Managing Change with Stakeholders

Introducing a new system often changes how people work as they follow different processes, take on new responsibilities, learn new skills, or give up familiar ways of working.

Identify these changes early, because if people are not prepared or supported, the result can be confusion, resistance, disrupted work, low adoption, and a solution that fails to deliver its intended benefits (Armenakis & Bedeian, 1999; Dikert et al., 2016).

Work with the people impacted to understand how the change affects their day-to-day work, what they think will become easier or harder, what they will need to learn, and what concerns they have.

Partner with managers, champions, and others who can help people through the transition, using what you learn to plan the people and process changes alongside the system itself. This might include communicating the nature, importance, and benefits of the change, providing training and job aids, changing processes, running pilots, and providing ongoing support.

References