Stakeholder and User Analysis
I have heard it said, and have probably said it many times myself, that IT projects would be so much easier if people weren't involved.
That's not the case -- people are involved, and they are the most important aspect of the projects. The main purpose of IT projects is to change the work people do or the way in which they do it, so it makes sense to figure out how best to work with them.
I'd like to share some techniques that help you understand the people you are working with. The first two techniques help you understand the people whose needs you are trying to satisfy -- also known as stakeholder analysis. The other two techniques help you understand the people who are actually going to use the solution you deliver; let's call this user analysis.
What do I mean by "stakeholders"? For purposes of this article, I'll use the definition from PMBOK Guide 5th Edition: "An individual, group, or organization who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project."
That's a pretty broad definition that includes, well, just about everyone who has anything to do with a project. Here I want to focus on project sponsors, subject matter experts, users, regulators, and service providers. Keep in mind that these can be people from both business and IT areas. Technology people have needs, too, and can often provide a different perspective on possible solutions. For example, IT support often has different interactions with end users than the rest of IT and may have some very helpful insight with respect to problems that end users face.
Stakeholder analysis is the act of understanding those stakeholders better, usually with the goal of figuring out the best way to communicate, engage, and work with them. The two techniques I cover here are ways to guide the conversation about your stakeholders on the way to establishing a plan for working with them.
The stakeholder map is a technique commonly used for stakeholder analysis. Using the stakeholder map to guide conversations helps a team understand who the stakeholders for the project are, understand key characteristics about those stakeholders, and identify plans for engaging the stakeholders on an ongoing basis. Primary outcomes from a stakeholder map include:
- A comprehensive list of the stakeholders involved with the project
- An understanding of how to interact with those stakeholders
Stakeholder maps are appropriate in all situations; however, the extent to which you use one depends on whether the current initiative involves new stakeholders or a group the team has been working with for quite a while. New stakeholders will generally prompt more rigorous and intentional map creation.
The commitment scale guides a conversation about how much your stakeholders support your project. This discussion provides ideas on how to engage them and what type of change activities you need to conduct to get the stakeholder support you need.
The commitment scale is a stakeholder analysis technique. This technique gauges the current level of stakeholder commitment to a project, as well as what level of commitment is needed to ensure the project's success.
The commitment scale is most applicable when a team is starting a new project that does not have clear, unanimous support from all stakeholders or on projects that are introducing significant organizational change. It may also be helpful when a team is working with a set of stakeholders with whom they have not worked before. It's a good idea for the team to have a discussion surrounding the commitment scale when they are first getting started (during iteration zero, for example) so they can establish their plans for engaging with stakeholders early on.
A special subset of stakeholders is the people who are actually going to use the solution you deliver -- your users. User analysis helps you understand who uses your solution, what they can do, and the environment in which they use it. You can use that information to guide design decisions and structure permissions so that people can do what they are supposed to and can't do what they aren't supposed to. The two techniques I describe here help to structure conversations around those ideas and persist information going forward.
A user is anyone who receives value from a solution. Users include people who directly interact with the solution as well as those who do not directly interact with the solution but receive some value from it.
User modeling is a technique used to establish a commonly agreed-upon list of user roles for a solution. This list of user roles and their descriptions provides helpful context for user stories and other backlog items.
You can think of user modeling as one aspect of stakeholder analysis that is specifically focused on people interacting with a solution or receiving value from it.
User modeling is especially helpful when working on solutions with a significant amount of user interaction and where there are different types of users who are able to perform different activities or access different functionality. It's generally best to do user modeling when first starting work on a solution. The discussions that occur during user modeling help to establish the range of potential users and can provide needed context. User modeling discussions can also provide some very helpful information for establishing scope. If your team is using one of the familiar formats for user stories, the list generated by user modeling provides selections for the "as a . . ." portion of those stories.
User profiles define a typical user of a solution. They are helpful for understanding the context in which user roles use the solution to help guide design decisions. User profiles are loosely based on personas which originated from Alan Cooper's work on user-centered design.
User profiles are especially helpful when working on solutions with a significant amount of user interaction where the context in which those users work can greatly influence how they use the solution. User profiles are often a good technique to use in conjunction with user modeling as a way of further describing the key user roles you identified during user modeling.
It's important to remember that you don't need to use all of these techniques for every project. They are the most useful when you find yourself working with new stakeholders or new users. You can find more information about when and how to apply these techniques in Beyond Requirements: Analysis with an Agile Mindset.
Applying these techniques in the right time in the right way will certainly reduce your urge to get rid of all the people associated with your project.