• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Stakeholder Mapping: IA Summit 2014
 

Stakeholder Mapping: IA Summit 2014

on

  • 815 views

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 ...

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?

Statistics

Views

Total Views
815
Views on SlideShare
742
Embed Views
73

Actions

Likes
3
Downloads
30
Comments
0

2 Embeds 73

http://nform.com 52
https://twitter.com 21

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Stakeholder Mapping: IA Summit 2014 Stakeholder Mapping: IA Summit 2014 Document Transcript

    • 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.
    • #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
    • 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 firm. 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 reflection 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.
    • 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.flickr.com/photos/yasminsimpson/11287682726/
    • “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.
    • We had this whole constellation of stakeholders we needed to accommodate… with our process, with our deliverables. This was where the lightbulb started to flicker 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.
    • 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? 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?
    • 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.
    • 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?
    • 1. What’s already been done in the field 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 field 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 first thrust at creating stakeholder mapping tools specifically for complex design projects.
    • What’s a stakeholder? But first, 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.
    • 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 fulfill their own goals and on whom, in turn, the organization depends" - Johnson & Scholes, 2002 Here are three definitions: 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 fulfill their own goals and on whom, in turn, the organization depends" (Johnson & Scholes, 2002) I really like the third definition, 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.
    • 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.
    • INTEREST INFLUENCE Keep Informed Manage Closely Keep Informed + Two-way Communication Keep Satisfied One of the first 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 influence. One thing I like about this tool is it provides strategic guidance. For example, stakeholders that are high influence and high interest are to be managed closely.
    • 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/influence, 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 influence. Midway through the project, the project sponsor sees this matrix and objects. She says “he can’t be listed low influence, what if he sees this?” So he was moved to high influence, and the effectiveness of the tool was diminished.
    • Another for technique for stakeholder analysis looks at power, legitimacy and urgency. Stakeholders are classified based on whether they have the power to influence 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 defined as the degree to which the organization prioritizes competing stakeholders. This model is also prescriptive; it tells us how to prioritize once we figured out where our stakeholders fall it tells us how to deal with them. In that red zone, we have definitive 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.
    • Another technique from the natural resource management world is called a conflict 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.
    • 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 fishery. It can only support so many fishermen, 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.
    • 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 definition 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.flickr.com/photos/naughton/6960122636/
    • 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.
    • Stakeholder Elicitation & Classification 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 & Classification - How do we identify many of the stakeholders specifically? Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful fidelity? 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.
    • 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 defined 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 specific, 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.
    • Stakeholder Elicitation & Classification 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 & Classification - How do we identify many of the stakeholders specifically? Step 2: Mapping - How do we map the stakeholder landscape quickly but with useful fidelity? 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.
    • Held a workshop with six people from the client organization. Working alone, participants were asked to list specific 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 specific 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 specific 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 specific 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.
    • 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 defined 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 five: 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?
    • 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.
    • 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.
    • 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?
    • Environment Physical Financial Technological Legal Organizational Expectations Project Team Sponsor World at Large Zeitgeist And I asked them to use VERY broad definitions for environment and expectations. • Environment encompasses physical, financial, 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.
    • 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 finally 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
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #1
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #2
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #3
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #4
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #5
    • 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 definitions 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.
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #1
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #2
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #3
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #4
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #5
    • 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?
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Areas of Risk Let’s focus on a couple of areas of our matrix. In particular, the corners. The corners are places where we might find risk.
    • 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?
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #1 Sure--it’s project #1. The designer who’s working on this told me that in the context of this project “it’s possible for us to do good work and still utterly fail.”
    • 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.
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #1 As it turned out that same project, #1, also fits this pattern. So at this point we’re getting scared.
    • 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.
    • EXPECTATIONS ENVIRONMENT MOREREADYLESSREADY HIGHERLOWER Project #3 We have a project that fits 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.
    • 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.
    • 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:
    • 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.
    • 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 predefined 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 specific 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 first 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.
    • 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.
    • 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.
    • @gsmith @nform
    • THANKS!