What if we had a method we could use with clients to better understand their stakeholder landscape and that would help us do more effective UX work? What if it was more like a consulting method instead of a design deliverable? Could that help us choose research, design and evaluation methods more effectively so we could have more impact on our projects?
1. MAPPINGMARCH 30, 2014 â IA SUMMIT
STAKEHOLDER
My name is Gene Smith. This is my seventh or eighth presentation at the IA Summit in the
last 10 years. Iâm really grateful and humbled to be part of this yearâs program. Thereâs just
so much great content being shared this weekend.
This talk is about Stakeholder mapping.
2. #stakeholdermapping
#shmap
@gsmith
If you want to tweet about this talk, I will follow the hashtag #stakeholdermapping and look at
your comments and feedback later.
If you want to tweet to me directly, my handle is @gsmith
3. I think itâll be helpful if I share a couple of details about my company before I get started just
to give you the context our business.
nForm is a UX design ïŹrm. Weâre located in Edmonton Canada. And we work exclusively
with enterprise clients on large websites and intranets and complex business applications.
We donât really do things like ecommerce, micro-sites, or consumer facing web apps. Thatâs
partly a reïŹection of our location and customer base, as well as some of the choices weâve
made.
One of the features of our projects is that there are lots of people at the table with competing
and sometimes divergent interests.
And there are usually a few important people who aren't at the table, but who are invested in
whatever product we happen to be working on.
A couple of years a ago I had a moment of clarity.
The realization was that if we better understood the stakeholders on our projects, the
relationships between them, the role they play, their interests, and that sort of thing, we
would have a powerful advantage when it comes to planning and doing our work. A
methodical and comprehensive map of our stakeholders concerns would help us be more
savvy consultants *and* most importantly do better research, design and evaluation work.
4. This moment of clarity was the result of a simple question. It was a cool June afternoon. I
was sitting in a boardroom in Victoria, Canada, with seven othersâdevelopers, architects,
account managers, project managers. I was the only UX person.
We were doing a retrospective on an application development project that had just failed. We
had been part of that project, and thankfully we weren't the reason it failed. We were asked
to pull together with a new team to start over.
So as we surveyed the wreckage of this failed project, we started to talk about all the different
people who should've been involved, all the different people who had to approve different
facets of this system, and generally, all the different people who had some kind stake in the
project.
And one guy, a senior guy with a lot of corporate knowledge, asks "so who is the client?"
Photo: https://www.ïŹickr.com/photos/yasminsimpson/11287682726/
5. âWho is the client?â
We all paused.
It's not like we didn't know who signed the contract and the cheques. We all knew that. The
problem was there was a long list of other people who had a material interest in what we were
doing. They weren't the economic or contractual client, but they were clients.
Within two minutes of that question being asked we collectively came up with a list of eight
clients. It was the usual acronym soup.
All of them were the client. And by that I mean all of them were important enough to have
approvalâto say yea or nayâto some or all of what we were building.
And some of them had different points of view on what the application needed to be.
We couldn't just walk into this project with the mindset that we were there to advocate for and
design for the end user. That would be naive.
6. We had this whole constellation of stakeholders we needed to accommodate⊠with our
process, with our deliverables.
This was where the lightbulb started to ïŹicker on for me. Maybe the reason we aren't having
the impact we want on this project is because we haven't adequately surveyed the
stakeholder landscape.
And if you donât mind me mixing metaphors, we only had a rudimentary map of that
landcape. We didnât even have a âThere be dragonsâ on it.
Maybe if we had a methodical and comprehensive understanding of that landscape, our
design work would be more effective.
7. What if we had a method we could use with clients
to better understand their stakeholder landscape
and that would help us do more eïŹective UX work?
What if it was more like a consulting method
instead of a design deliverable? Repeatable,
teachable, measurable, provide reliable and unique
insights, oïŹer guidance on strategies.
Could that help us choose research, design and
evaluation methods more eïŹectively so we could
have more impact on our projects?
So I started to ask myself some questions:
What if we had a method we could use with clients to better understand their stakeholder
landscape and that would help us do more effective UX work?
What if it was more like a consulting method instead of a design deliverable? Repeatable,
teachable, measurable, provide reliable and unique insights, offer guidance on strategies.
Could that help us choose research, design and evaluation methods more effectively so we
could have more impact on our projects?
8. As I was asking myself these questions, there were some tools in the UX space that were an
inspiration to me:
XPLANEâs empathy map, which Iâve used dozens of times, and does a great job of getting
clients to put themselves in the shoes of different users.
9. Text
TUGâs performance continuumsâIâve used these a few times as wellâand they are really
effective at spurring discussion about the nature of the product weâre working on.
So I starting working through ideasâcould we develop something simple like empathy maps
or performance continuums, but that would help us and clients decide what to do with
stakeholders early in a project?
10. 1. Whatâs already been done in the ïŹeld of
stakeholder mapping
2. What Iâve been thinking about: stakeholder
mapping for complex design projects
3. A method weâve been testing internally and those
results.
What Iâm going to walk you through today is
1. Whatâs already been done in the ïŹeld of stakeholder mapping
2. What Iâve been thinking about: stakeholder mapping can be used on complex design
projects
3. A method weâve been testing internally and those results.
So by no means is this a complete method or set of tools, but this is our ïŹrst thrust at
creating stakeholder mapping tools speciïŹcally for complex design projects.
11. Whatâs a stakeholder?
But ïŹrst, let's start with the most important question: what is a stakeholder?
The term has different meanings depending on the context. In business, stakeholders are
typically investors, analysts, customers, board members, perhaps various kinds of advocacy
groups depending on the industry.
In public engagement, stakeholder can mean any kind of individual or community group. In
our UX work we sometimes distinguish between users and stakeholdersâthough perhaps that
distinction is unnecessary.
12. A party that has an interest in an enterprise or
project
âAny person group or organization that can place a
claim on the organization's attention, resources, or
output, or is aïŹected by that output.â - Bryson, 1995
âThose individuals or groups who depend on the
organization to fulïŹll their own goals and on whom,
in turn, the organization depends" - Johnson &
Scholes, 2002
Here are three deïŹnitions:
A party that has an interest in an enterprise or project
âAny person group or organization that can place a claim on the organization's attention,
resources, or output, or is affected by that outputâ (Bryson, 1995)
âThose individuals or groups who depend on the organization to fulïŹll their own goals and on
whom, in turn, the organization depends" (Johnson & Scholes, 2002)
I really like the third deïŹnition, since it encompasses the users we usually fret over. But for
the purposes of this talk any of these will doâwe are talking about people or groups who
have an interest in what we're doing.
13. Whatâs Already Been Done
Stakeholder mapping is not a new activity. It's widely used in management consulting, urban
planning, resource management, and public participation activities.
I want to walk you through some of prior work in this area, because I think it's instructive.
14. INTEREST
INFLUENCE
Keep Informed
Manage Closely
Keep Informed
+
Two-way
Communication
Keep SatisïŹed
One of the ïŹrst stakeholder analysis tools, developed by Gardner in the 1980s, is called a
power/interest matrix. With this tool you rank stakeholders based on their level of interest
and their level of inïŹuence.
One thing I like about this tool is it provides strategic guidance. For example, stakeholders
that are high inïŹuence and high interest are to be managed closely.
15. Crowd
PlayerSubjects
INTEREST
INFLUENCE
Context Setter
In a later version of this tool, developed by Eden and Ackermann in the late 1990s, we can see
these groups named. If youâre in the upper right, youâre a âplayerâ
If youâre in the lower right, a âcontext setterâ
One of the challenges for this tool, and any of the others that examine power/inïŹuence, is
that power is a hard thing to discuss honestly.
On one project we were involved in, the project manager created a power/interest matrix as a
planning tool. It was included some of the official project documentation and it just so
happened that one executive member was placed in the low inïŹuence.
Midway through the project, the project sponsor sees this matrix and objects. She says âhe
canât be listed low inïŹuence, what if he sees this?â So he was moved to high inïŹuence, and
the effectiveness of the tool was diminished.
16. Another for technique for stakeholder analysis looks at power, legitimacy and urgency.
Stakeholders are classiïŹed based on whether they have the power to inïŹuence the project or
organization, legitimacy in they eyes of the organization, and the degree to which their claims
or issues call for immediate attention.
Salience is deïŹned as the degree to which the organization prioritizes competing
stakeholders.
This model is also prescriptive; it tells us how to prioritize once we ïŹgured out where our
stakeholders fall it tells us how to deal with them.
In that red zone, we have deïŹnitive stakeholders.
In those orange petals we have dominant, dependent and dangerous stakeholders.
This tool give us guidance on how to handle each one, and balance their interests and needs.
17. Another technique from the natural resource management world is called a conïŹict analysis
matrix. Iâve seen this extended to look at interactions between different stakeholders.
This example shows the departments of a hospital and the matrix tells us how close or far
they should be from one another, and the reason.
For example,
* Wards and Intensive care = Undesirable because of noise levels
* Pharmacy and Outpatient Clinics = Very important because of convenience
Again, itâs a bit prescriptive.
In some cases, these methods were developed decades ago. While I think they are still
relevant in many ways, I also think the kind of work we do might require something different.
Obviously, as soon as weâre talking about digital products and services are very different from
natural resources.
18. Scarcity: no scarcity of digital assets
Scale: global audiences mean sheer numbers of
stakeholders can be huge
UX Role: we actively advocate for stakeholders
groups.
Letâs talk about some of the differences Iâve obversed.
Scarcity - when we talk about digital products and services, we arenât faced with the issue of
scarcity that we are in the physical world. Think of a ïŹshery. It can only support so many
ïŹshermen, and feed so many people. Thereâs no reason a website couldnât serve every single
stakeholder group, no matter how obscure or remote, simple because thereâs never going to
be a shortage of web. Or code.
With digital products we deal with scarcity of time, resources and attention.
Scale: many digital products and services are accessible to a global audience. The sheer
numbers of potential stakeholders can be huge.
These two things, sheer numbers and no scarcity, are kind of interesting when you put them
together.
Role of UX Practitioners. We are not outside the organization, we are in the middle. In many
ways our job is to represent less-known stakeholders and more powerful.
E.g. in the salience model we could think of our role as making the concerns of marginalized
stakeholders more legitimate and urgent in the eyes of the organization.
In any case, all of this is to say that perhaps the old methods of stakeholder analysis are not
enough and we need to look for something new.
19. PETER CHECKLAND
The place I chose to look was called soft systems methodology, and itâs a branch of systems
thinking that looks focuses on designing systems that learn.
Interestingly the guy who came up with Soft Systems methodology, Peter Checkland, is a peer
of Eden and Ackerman who wrote about the power/interest matrix. Checkland and Jim
Scholes wrote a book about soft systems methodology (Soft Systems Methodology in Action),
and if you remember Scholes is one of the authors of the third stakeholder deïŹnition I gave
earlier.
Thereâs a symbiotic relationship between some of the people thinking about stakeholder
mapping and the thinking behind soft systems methodology. Thatâs all Iâm going to say
about that.
One characteristic of these thinkers is that they tend to look broadly and inclusively at
systems and stakeholders. Thatâs what Iâm going to do too.
Photo: https://www.ïŹickr.com/photos/naughton/6960122636/
20. C
A
T
W
O
E
Customers
Actors
Transformation
Worldview
Owners
Environment
The particular method Iâm going to talk about is loosely based on an idea from soft systems
methodology called CATWOE.
CATWOE is an acronym that stands for customers, actors, transformation, worldview, owners
and environment. The idea is that interactions between these six elements can be used to
create a rich picture of complex systems.
21. Stakeholder Elicitation & ClassiïŹcation
Stakeholder Mapping
Pattern Analysis
Developing Design Strategies
As I started to think about how we could apply CATWOE to stakeholder analysis, I started
imagine a four step process that answered some of the questions Iâd been asking myself.
Step 1: Stakeholder Elicitation & ClassiïŹcation - How do we identify many of the stakeholders
speciïŹcally?
Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful ïŹdelity?
Step 3: Pattern Analysis - What insights can we glean from these maps?
Step 4: Design Strategies - How can our stakeholder maps guide strategy?
Iâm going to show you how we are working through this four-step process. As I said before,
this is not complete method. At this stage, we are just probing this space to see whatâs
interesting.
22. Stakeholder Elicitation
One thing Iâve noticed over the years is that people tend to talk about stakeholder groups
quite generally. There are citizens and advocacy groups and industry. There are off-hand
categories like internal and external. Years ago when I worked in communications we would
often call our stakeholders just âstakeholdersâ â one big catch-all bucket for everyone who
had an interest. In hindsight that was probably both lazy and risky.
But in our consulting work Iâve noticed that these groups are so large and homogenized and
frankly poorly deïŹned that important or even just interesting details are missed. They are
laced with unspoken assumptions.
Sometimes when weâre planning user research weâll talk with a client about who we should be
interviewing, and theyâll toss out these generic groups. And you really have to work to get
them to be speciïŹc, and inclusive. And if we arenât familiar with the domain, itâs easy to miss
an important stakeholder, which comes back to bite us later.
This was the easiest one to solve. We designed a workshop activity around eliciting a large
number of stakeholders.
23. Stakeholder Elicitation & ClassiïŹcation
Stakeholder Mapping
Pattern Analysis
Developing Design Strategies
As I started to think about how we could apply CATWOE to stakeholder analysis, I started
imagine a four step process that answered some of the questions Iâd been asking myself.
Step 1: Stakeholder Elicitation & ClassiïŹcation - How do we identify many of the stakeholders
speciïŹcally?
Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful ïŹdelity?
Step 3: Pattern Analysis - What insights can we glean from these maps?
Step 4: Design Strategies - How can our stakeholder maps guide strategy?
Iâm going to show you how we are working through this four-step process. As I said before,
this is not complete method. At this stage, we are just probing this space to see whatâs
interesting.
24. Held a workshop with six people from the client
organization.
Working alone, participants were asked to list
speciïŹc stakeholders for 10 - 15 minutes.
Team of six generated 140 stakeholder names.
We assembled a knowledgeable group of employees from across the organization. These are
people who were working close to the coalface, so they could take a front-line perspective
and a management perspective.
The instructions were simple:
âą
Working alone for 10 â 15 minutes write down one stakeholder per post-it note
âą
If itâs an individual, write their title or role
âą
Instead of generic group names give you must give speciïŹc examples.
An example of a generic group name might be âindustryâ or âlobby groups.â So instead of
just industry you might get âlarge manufacturersâ and âmanufacturers associationsâ, and from
there you might get individual company names or association names.
The facilitation technique I used is to read each post-it note before I place it on the wall, ask
if every understands what it means and if itâs speciïŹc enough, and if not I send it back to the
table to be broken down further.
I ran one of these workshops a few weeks ago. We had six people over two hours come up
with about 140 speciïŹc stakeholders--with very little duplication. Now this is a large public-
sector organization with a challenging business, so they may have more stakeholders than
most.
The next step was to divide them into customers, actors and owners. If you remember, these
are the three roles from our CATWOE model I shared earlier.
25. Customers use the product or receive the results
of the project; the end users, direct and indirect.
Actors work to create and maintain the project
and product.
Owners own the system or product or own
processes impacted by the project, and can
inhibit/enhance the success of the project.
For the purposes of this exercise, hereâs how we deïŹned customers, actors and owners.
-
Customers use the system; the end users, direct and indirect.
-
Actors work to create and maintain the system.
-
Owners own the system or product or own processes impacted by the system, and can
inhibit/enhance the success of the project.
This step generated even more names. We ended with about 180 in total.
As youâd expect, once we divided our stakeholders up we had a lot of customers, and fewer
actors and owners.
Then we could start to group our customers. This was challenging, we were battling the
groupâs natural inclination to use their historic stakeholder groupings OR their organizational
structure.
Working together, we subdivided the customers group into ïŹve: users, internal and external
service providers, and internal and external overseers. From there we were able to identify
four interesting (but rough) sub-groups of users. And then we ran out of time.
But we got great feedback from the participants, who had a chance to experience the breadth
and complexity of the stakeholder landscape. And that apprecitation came from seeing it in
detail.
In the future I would allow two days for this kind of workshop.
So, we have 180 stakeholder names. What do we do with them?
26. Stakeholder Mapping
Hereâs what we think is next.
Continuing with the CATWOE framework, I thought it would be interesting to look at the
environment and worldview of each stakeholder.
27. Customers
Actors
Transformation
Worldview
Owners
Environment
Just a side note, the term worldview has some baggage for me. So Iâm going to substitute
âexpectationsâ for âworldview.â I think âexpectationsâ is a bit more expansive in its meaning,
and that suits my purposes here.
In particular, I thought it might be interesting to see if we could map the expectations and
environment of various stakeholder groups.
To do this I asked my senior team members to retrospectively look at projects they worked on
over the past year. Collectively we did 5 projects.
They were instructed to divide their stakeholders into three groups: customers, actors and
owners.
They were asked to list the objectives of their project.
And they were given instructions on how to assess expectations and environment for each
stakeholder. This was strictly a gut-feel exercise.
28. Is their environment more ready or less ready for
the project to be a success?
Are their expectations about the project higher
or lower than what's outlined in the project
objectives?
There were two questions they had to answer:
-
Is their environment more ready or less ready than what is required for the project to be a
success?
-
Are their expectations about the project higher or lower than what's outlined in the
project objectives?
29. Environment
Physical
Financial
Technological
Legal
Organizational
Expectations
Project
Team
Sponsor
World at Large
Zeitgeist
And I asked them to use VERY broad deïŹnitions for environment and expectations.
âą
Environment encompasses physical, ïŹnancial, technological, organizational and legal
constraints. Basically everything but the âinner lifeâ of that stakeholder.
âą
Expectations covered the stakeholders beliefs about the project, the team, the project
sponsor, the world at large, the zeitgeist.
You might you think that's funny, but if youâre working on an Intranet and people believe that
"social networking will change our industry" then that's going to have a substantial impact on
your project.
30. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Actors
Customers
Owners
They were asked to place each stakeholder on a matrix with Expectations on the horizontal
axis (like so) and environment on the vertical axis (like this).
âą
On the right we have higher expectations, and on the left we have lower expectations.
âą
At the top we have more ready environment, and at the bottom we have less ready
environment.
And ïŹnally they were asked to colour-code their stakeholder groups: green for customers,
blue for actors, red for owners.
As you can imagine, this was a challenging and problematic exercise, Iâll summarize the
challenges in a minute. First I want to walk you through the maps
36. Here are al 5. What do we see?
I wasnât expecting such a variety of patterns. For all the projects, stakeholders cluster in
different areas.
So I said there were challenges.
First, everyone struggled with the broad deïŹnitions of these two categories. In particular,
environment is a big tent and some people felt it was important to distinguish between
organizational readinessâwillingness to change, leadership, psychological readiness--and
other factors like physical location or resources. Let's face it: organizational issues are much
harder to overcome than technological ones.
Second, in some cases we only had second-hand information about stakeholder groups. So
we were projecting on their behalf.
Third, sometimes it's hard to designate people as only customers, actors and owners.
Finally, some people weren't sure this could be done early in the projectâat least not on our
own. Most of these maps capture a year or more of hard-won knowledge. And if you recall,
one of the goals was to do this kind of mapping early we could make our projects more
effective. So it's really not useful at the end of the project.
I added a new symbol to clarify some of differences between stakeholder groups: an open
circle for stakeholders inside the client organization, a closed circle for those outside the
client organization.
43. Pattern Analysis
Let's continue to explore that hunch a bit. If we could do this early, is it possible that we could
develop differentâideally, more effective--design strategies based on the patterns we see?
How do we make sense of these patterns?
One question we asked is could this tool be used to identify stakeholders that might be a risk
to our success?
45. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
We think owners with high expectations and low environmental readiness may pose a risk.
And in particular, this risk is greater when those owners are struggling with organizational
challenges. Why?
May not be able to change their environment to enable success.
Or they may not be aware thereâs a problem.
So do any of our projects have owners clustered in this area?
47. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
Next we might look at customers with low expectations and high readiness. Why are these
people a risk? Couple of possible scenarios.
In the case of consumer-facing product maybe these are people in danger of switching to a
competitor.
For enterprise software, these may be critics who undermine your efforts, but they may also
be defectors. The groups who âgo rogueâ and develop their own system.
49. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Areas of
Risk
Third, we thought there would be a problem when we simultaneously see owners with low
expectations/low environmental readiness, and customers with high expectations/high
readiness.
In this case the owners act like anchor, keeping customers from achieveing their goals. And if
the situation is not addressed, we can imagine a deep rift as the project fails to address either
of these groups effectively.
50. EXPECTATIONS
ENVIRONMENT
MOREREADYLESSREADY
HIGHERLOWER
Project
#3
We have a project that ïŹts this pattern too.
In this case, some customers wanted to move forward quickly with a solution (and were
ready).
The owners couldnât move as quickly, that was the reality of their environment. That was
partly technical and partly attitude.
The next question is, how do we move people from their positions? This question is the
essence of step 4 - design strategies.
51. Design Strategies
As I had this conversation with my team, the picture that emerged was that the design
artifacts themselves were incidental. What was important was the way the stakeholders were
engaged in the design process.
This could mean participating in user research, service modeling or co-design workshops or
something like that. Having them involved in some activities that reveal the gap between
where they are and where they need to be.
Those are hard things. Not the design activities themselves, but to get the right people into
the room with the right mindset.
So my hunch that we would be able to use this stakeholder mapping method to help us
choose design methods hasnât really played out.
But what emerged was maybe a bit more interesting.
52. Positioning our work with owners
Advocating for access to important stakeholders
Empowering designers to ask challenging questions
Choreographing design reviews
Enabling stakeholder participation in design & research
We think that stakeholder mapping may be able to help us do more strategic things:
-
positioning our work with owners
-
advocating for access to stakeholders
-
empowering designers to ask challenging questions
-
choreographing design reviews to engage the right people
-
enabling for stakeholder participation in design and research
These arenât strictly UX design activities, but they set the stage for success later.
Thereâs a term for these kinds of activities:
53. Groundwork
Groundwork, something that is done early that makes success possible later.
When I think back to that boardroom in Victoria I realize that we ended up doing a lot of
groundwork, even though it wasnât part of our formal process.
Our formal design process revolved around Iterative prototyping
But behind the scenes we were advocating for regular design reviews with stakeholders, and
unfettered access to people with critical knowledge of business process, and multiple rounds
of usability testing.
SO maybe the biggest win for this method is that it enables more effective groundwork. And
seeing the stakeholder landscape early can help us pick the right battles.
54. Descriptive Prescriptive
Personas
Experience
M
aps
W
irefram
es
Pow
er/InterestM
atrix
Salience
M
odel
I want to make a larger point here about UX practice.
When it comes to UX deliverables we can imagine a continuum from descriptive to
prescriptive.
So many of our deliverables are focused on understanding and explaining users or systems
and, I think, fall to the left end of that continuum. Things like personas or experience maps
or wireframes.
We don't have many deliverables that impose a predeïŹned framework or rules on our clients.
But youâll notice that a lot of the examples of stakeholder mapping I showed at the beginning
of the talk fall to the right end of the continuum. After youâve mapped your stakeholders,
these frameworks tell you how to approach them. They recommend speciïŹc strategies for
dealing with them.
And this is where Iâm trying to land with our stakeholder mapping method.
I know I sometimes resist these methods because theyâre reductive--they seem to
oversimplify things. As IAs and UX designers, we love the details.
I remember talking with a colleague, attending poster night at her ïŹrst IA Summit, and she
noted that the elaborate diagrams with a baroque level of detail... these are like catnip for IAs.
They were drawn to them and really absorbed in the details, almost getting high off the little
boxes and arrows.
And maybe thatâs why we abhor these 2x2 matrices. They seem so coarse and
unsophisticated.
55. Prescriptive methods make
for good groundwork.
These prescriptive methods make for good groundwork, because they tell the organization
how to behave. Remember our challenge is not about whether wireframes or a prototype are
better, itâs about access and empowerment of the design team.
So a method that a) analyzes stakeholder relationships, and b) says to the client âto address
this particular stakeholder arrangement you must do Xâ could help us be more effective
designers.
56. Whatâs Next?
So whatâs next for this method?
Connecting the stakeholder elicitation workshop directly into the mapping exercise, probably
using a survey tool of some kind. That would allow for greater participation in this method.
More work on pattern analysis, probably done through more project retrospectives.
More work on identifying groundwork approaches to address particular risks.
TO SUM UP
Stakeholder mapping itâs a real thing.
We looked at some things that have been done. We thought there might be room for
something new.
We tried something.
It kind of worked, we learned a few things.
We will continue to apply it, with more rigour, to give us a strategic advantage on projects.
We would love your feedback, positive or negative.
If you want to try this, I have 20 print outs of the worksheet and instructions we used here at
the front.