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.
Stakeholder 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.
Stakeholder Map
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.
Commitment Scale
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.
User Analysis
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
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 Profile
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.
Conclusion
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.
