First of all, credit to Mark Dalgarno who’s serendipitous tweet spawned this experiment.
I won’t go into explaining what Impact Mapping is because it would just be duplicating Mark’s excellent introduction on the topic that gave me all I needed to try it out.
I’m going to park some caveats at the end of this post because I’m not wholly convinced I’m using this method appropriately. But that’s what experiments are for right? Try something and see what worked and what didn’t.
Context
I’m working on something which entails a reasonably large change to an internal IT system. The change will be primarily driven by operational decisions that are owned by one or more teams roughly grouped by profession.
I’m in what might be considered the early scoping phase of the work. So broadly speaking, based on the intended goal, what are the questions we need to answer before we can understand what we actually need to do to deliver this outcome.
I’d started drafting a high level list of things to bring clarity to the work ahead. It included highlighting dependencies both between my tasks and other teams. I kept having this nagging feeling at the back of my brain that there was a disconnect between the goal and the specific tasks I had written.
Enter Impact Mapping.
Creating an Impact Map for an IT system change
I’m going to use a fictional example here, but it’ll broadly mirror my actual experiment in the ways that are important to articulate the learning, including some of the bumps in the road I hit.
I started off with writing my inteaded goal.
The centre of an impact map answers the most important question: Why are we doing this? This is the goal we are trying to achieve.
https://www.impactmapping.org/drawing.html
You might use something like SMART to make sure this doesn’t end up being too woolly. I found it helped in being clear about the outcome because as you go along, it will aid you in spotting if you’ve thought about all the things that the goal touches upon. I actually went back and re-wrote my goal at least twice because of the realisation that it was too imprecise.
Having talked about precision, I appreciate there’s some irony of me using a place holder for a policy decision in my example. Hopefully you get the gist.
Once I’d established my goal, I then thought about all the various people who would influence the delivery of that goal. In impact mapping these are referred to as actors.
The first branch of an impact map provides answers to the following questions: Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it? These are the actors who can influence the outcome.
https://www.impactmapping.org/drawing.html
These were mostly internal teams in my scenario, but I also thought about external actors that could influence the delivery of the goal.
For the purposes of this example, I’ve kept it relatively simple. In my real world experiement, I actually ended up with quite a long list, and certainly more than I had originally captured as dependencies. This encouraged me that regardless of whether I got any more value out of it, at least it had given me an improved perspective of who was actually involved in influencing the goal.
Next, I tried to think of the how these actors could contribute toward the goal. These are the impacts.
The second branch level of an impact map sets the actors in the perspective of our business goal. It answers the following questions: How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? These are the impacts that we’re trying to create.
https://www.impactmapping.org/drawing.html
I also thought about potential blockers and listed those too.
During the process, I occasionally mixed up the impact and the actions. Some of that might have been down to the fact that I was thinking in terms of how and what. When I reframed things as impact and actions, it was easier for me to connect an impact to an actor, especially around unintended consequences or blockers.
I found it helpful having the definitions of actor, impact and actions handy for at least your first run through. Next time around I’d add these as headings before I got started for ease of reference and clarity for others.
Having captured my impacts, I now tried to think about the deliverables that were connected to them.
Once we have the first three questions answered, we can talk about scope. The third branch level of an impact map answers the following question: What can we do, as an organisation or a delivery team, to support the required impacts? These are the deliverables, software features and organisational activities.
https://www.impactmapping.org/drawing.html
This was almost the easiest part of the process. Perhaps because I’d started at this level of detail previously. Perhaps I have a natural tendancy to focus on the detail?
As before, I picked up many more deliverables because I now had more of a clear through line between the goal, the groups of people involved and the impacts upon them.
Here’s my completed example with added headings for clarity.
Reflections
So, what are my thoughts after this initial stab at impact mapping? And I acknowledge that this will be largely unfluenced by the thing I’m using it to map, so should not be taken as a critique of the mapping method itself.
Because I’d created the map on my own, I thought it likely that it was subject to my own assumptions and blindspots. If I were to do this again, I think I’d do the map with some of the people who I knew would be involved to better validate it and generate a shared understanding of both the map and the work.
Also, given the size of the change I was trying to map, I don’t think I’d consider this as replacement for something better suited to structuring all the detail, dependencies, owners etc. but I think that’s okay. This would be the wrong tool for that purpose. Perhaps that would be the next natural step?
I do feel like this process helped draw a very literal through line between the goal and deliverables. It didn’t give me the whole picture, but it gave me enough to feel confident about the right direction of travel to gather more detail. So perhaps more of a compass point than a road map?
The beauty of impact mapping is that it’s a relatively easy thing to grasp and try out. And even if you end up doing it slightly wong (and please remember that all maps are imperfect) I do think there’s learning to be had from the process.
Caveats
- In scouting around for examples of impact mapping, I’ve seen this applied to mostly product features, not whole system changes so I’m a bit wary of stretching the intended scope of this approach.
- I’m apply this to something that is will most definitely not end up being an agile in terms of implementation, but perhaps being in a scoping phase lends itself to this? I think I can hear people screaming about “wagile”. In writing this post I did some digging around at the appropriate use of impact mapping in different contexts which is covered in detail; here: https://www.infoq.com/articles/most-impact-mapping/
- My example process makes everything seem far more sequential and orderly than in real life. In practice I bounced between the goal, the actors, the impacts and deliverables as my understanding grew. That’s probably a good thing.