Impact Mapping
An impact map is a four-level tree that links a goal of the organisation to the deliverables meant to reach it, by way of the people able to act on that goal and the change of behaviour expected of them. Each level answers a question: why, who, how, what. The tree is built in a facilitated session, in that order, with the stakeholders and the team; the map then stays visible and is revised as results come in. The technique comes from Gojko Adzic, who published it under this name in 2012. The Agile Extension to the BABOK Guide files it under process analysis, among the techniques practised with stakeholders outside the delivery team.
Goal
Impact Mapping produces a four-level map: the goal of the organisation, the actors who can influence it, the impacts, meaning what those actors would do differently, then the deliverables that make that change possible. The four levels answer, in order, why, who, how and what. The map is built from the top down, in a facilitated workshop that brings together the team and the stakeholders concerned.
The problem it addresses is the jump straight from the goal to the list of features: the Agile Extension gives the technique the intent of keeping all stakeholders focused on value creation, the why, instead of feature development, the what. An organisation that wants to cut the number of visits to its counters opens a workshop and comes out with screens to build, without having said who has to behave differently or how that behaviour moves the number. The two middle levels are the assumptions that jump leaves implicit. Writing them down makes them arguable in the session and verifiable afterwards.
The deliverable is a one-page map, kept visible and revised as results come in. The guide credits it with one property: since the goal is quantified, the map says when the intended result is reached, so when to stop funding the next stage. It also strengthens the feedback loops between the Strategy, Initiative and Delivery horizons, by tying activities back to the goals of the organisation.
Usage
When to use it
- Framing an initiative with a quantified goal: settling the goal, the actors and the expected impacts before the backlog opens.
- A backlog drifting into a list of features: tying each item to the impact it is supposed to produce or dropping it.
- A decision shared with stakeholders outside the team: the map fits on one page and reads without project vocabulary.
- Funding by milestones: the quantified goal gives the stop signal once the result is in.
When not to use it
- A goal nobody knows how to measure: the map loses its stop signal; put the metrics and key performance indicators in place first.
- A solution already chosen and budgeted: the map would only supply an after-the-fact justification; hold the link between value and deliverable through backlog management.
Description
The technique comes from Gojko Adzic, who published it in 2012 under this name, placing it at the meeting point of goal-oriented requirements engineering, agile methods and the Lean Startup. The Agile Extension catalogues it and supplies its framing for the business analyst. The visual form is that of a mind map, read left to right or top to bottom.
The four levels
| Level | Question | What goes on it | What gives away an error |
|---|---|---|---|
| Goal | Why are we doing this? | The result the organisation wants to obtain, with a number and a deadline. | A wish with no number, of the "improve satisfaction" kind. |
| Actor | Who can influence the goal? | A person or a group whose behaviour influences the goal. Customers, staff, partners, the regulator. | An entity too broad to act, of the "the market" or "management" kind. |
| Impact | How will this actor influence the goal? | What the actor would do differently, stated as an observable behaviour. | A feature dressed up as a behaviour: "uses the new screen". |
| Deliverable | What do we produce to make that behaviour possible? | What the team builds or puts in place for the actor: a feature, a set of talking points, a short training course, an organisational change. | The product's full feature list, copied out under the map. |
The levels fan out: several actors under a goal, several impacts under each actor, several deliverables under each impact. That is what lets one page carry the context of a whole initiative. It is also what bounds the technique: a map with thirty branches is no longer readable at a glance.
The two reading directions
Downwards, the map reads as a deduction: for this goal, these actors; for this actor, these behaviours; for this behaviour, these deliverables. That is the direction it is built in.
Upwards, it reads as a test. Every deliverable is a bet on an impact, every impact a bet on the goal. A deliverable for which nobody can name a changed behaviour has no reason to be funded. An impact that nobody can size against the indicator is a hunch that has to be either quantified or tried on a reduced scope. Reading the map in that direction turns a list of work into a series of assumptions that can be ranked by cost and by expected gain.
Running the session
- Establish and quantify the goal before the session
The Open Practice Library reckons two to four hours of preparation. A goal still under discussion when the session opens eats the whole session and the map never reaches the deliverable level. - Bring the team and the stakeholders who decide into one space
Half a dozen people: the sponsor, the product owner, a facilitator, the person who knows the technical constraint and the person who talks to the customer every day. - Provide the surface
A wall, a whiteboard, sticky notes. The map has to be able to grow and be reorganised during the session. - Facilitate level by level, in order
Goals, then actors, then impacts, then deliverables. A participant who offers a deliverable during the round on actors is asked which behaviour it attaches to; the note waits until its level comes. - Keep the map visible and revise it
Posted in the team's space, updated when an impact is measured or a deliverable disappoints.
A session that stops at the finished tree has done half the work: the branch kept is the one promising the most effect on the goal for the least work, and the others are held as written options.
What makes the technique fail
The goal with no number
The guide counts the goal's being quantifiable among the strengths of the technique. "Reduce the number of visits to the counter" says neither by how much, nor by when, nor how it will be counted. Without a number no impact can be assessed, no branch can be compared with another and the map will never say that it is time to stop. The question to put in the session: which report, out of which system, shows today's baseline value?
The deliverable hung under the goal
This is the drift the order of the levels exists to prevent. The group names the goal, then moves on to features, and the two middle levels are filled in afterwards to justify what was already decided. The map is then complete and false: it gives an existing backlog the look of a value chain. A facilitator who lets a deliverable through out of turn loses the one constraint that makes the group work.
The impact written as a feature
"The customer uses the mobile app" describes the use of a deliverable. The impact level expects a behaviour, and the test fits in one question: would this sentence still be true if the team delivered something else? "The customer executes their own standing orders without going into the branch" leaves open how that is made possible, the only state in which the deliverable level has a choice.
The end-of-workshop map
The Agile Extension makes this a limitation: the map has to stay visual, accessible and open to revision. A map photographed and then filed away stops returning anything from the first decision taken without it. It is then a workshop record, which any document produces at lower cost.
Working at a distance
The guide states that the technique is best practised in person, without offering an adjustment. A distributed team pays that limitation twice: the shared board replaces the wall, but the map leaves the daily field of view as soon as the tab is closed. Where a room can be had at short notice, it beats a video call. Elsewhere, the shared board carries the construction; what costs afterwards is bringing the map back in front of the group.
AI considerations
On this technique a language model is useful before and after the session, never during. Before, it produces a list of candidate actors from the goal and the stakeholder list: what interests the facilitator is the names the model offers that the room had not mentioned. It also proposes impact wordings for a given actor, used as provocations when a branch stays empty. After, it spots the deliverables appearing under several impacts, a sign of a duplicate or a misplaced branch. It also rewrites the impacts drafted in feature language.
The choice of actors depends on who holds power in the organisation concerned, which no model knows; it will propose the generic actors of the sector, plausible and foreign to the balance of power at play there. Told to quantify a goal, it will produce a percentage and a deadline that look reasonable and come out of no in-house measurement system: the number that triggers the end of a funding is taken from an existing report. The session earns its keep through the disagreement among the people present about what the customer will do, and a map that arrives ready-made removes that disagreement instead of resolving it. Lastly, a map carries customer segments, volumes and sometimes amounts that have no business leaving the company: they are stripped out before anything is sent to a public model.
Examples
A cantonal bank in French-speaking Switzerland wants to reduce the routine transactions handled at the counter.
The goal states itself in one line: cut by 30% in twelve months the routine transactions handled at the counter, standing orders and address changes, measured on the retail network's monthly count. The first branch is funded to the tune of CHF 150'000, and that count says when the funding no longer has a reason to exist.
What the map makes visible and a feature list hides is read on the third branch: the behaviour expected of the counter staff, who steer a routine request to the self-service terminal instead of handling it themselves, has as its deliverable a set of talking points and a short training course, without a line of code. That deliverable would never have come out of a product framing workshop. It is also the cheapest of the three paths to the same number.
Visualisations
The technique produces a tree, so it is drawn: the map in the example shows the goal at the root, the actors on the first branch, the impacts under each actor and the deliverables as leaves, with the four questions why, who, how and what set against the levels. What has to be visible is the fanning out.
A second drawing serves the upward reading: the same four levels, with the construction arrow pointing down and the testing arrow pointing up, the latter carrying the two questions that decide a funding, which behaviour this deliverable changes and by how much that behaviour moves the indicator.
Cost
| Phase | Level | Rationale |
|---|---|---|
| Preparation | Medium | Two to four hours to establish and quantify the goal, plus obtaining half a day in common from stakeholders, some of them outside the team. |
| Execution | Medium | Half a day to a day of facilitation with half a dozen people. The guide notes that the map itself is created quickly; the cost is in the diaries. |
| Documentation | Low | One page. The spend that counts is the revision, when an impact is measured or a branch is abandoned. |
Tooling
The wall and sticky notes remain the reference setting, because the technique assumes facilitation in person and because the map has to stay in front of the team after the session. Moving a note from one branch to another is the most frequent operation of the session.
Collaborative whiteboards (Miro, Mural, FigJam and their equivalents) are the fallback for a distributed group. They supply the surface and the history, provided somebody brings the map back in front of the group.
Mind-mapping tools (XMind, Freeplane and their equivalents) fit the tree shape and reorganise a whole branch in one drag. They suit the fair copy and the revision, less the session, where a single laptop screen reduces the group to an audience.
Backlog management tools (Jira, Azure DevOps, GitLab and their equivalents) take in the leaves of the map: each deliverable kept becomes an item whose value field carries the impact aimed at. That connection stops the backlog resuming its drift in the next sprint.
That leaves the tool the stop signal depends on: the system that produces the measurement of the goal, a BI dashboard, a web analytics tool or an operational report. A quantified goal whose measurement nobody knows how to produce each month is decorative.
Sources
- IIBA, Agile Extension to the BABOK Guide, §7.3 Impact Mapping: the purpose of the technique, the four components and the question each of them answers, the order of construction and the four steps of the session, facilitation in person, the strengths stated, among them the quantifiable goal and the signal to stop a funding, the limitations and the filing of the technique under process analysis with stakeholders outside the team (Table 7.0.1).
- Gojko Adzic, Impact Mapping: Making a Big Impact with Software Products and Projects, Provoking Thoughts, 2012: the source of the technique, which places it at the meeting point of goal-oriented requirements engineering, agile methods and the Lean Startup.
- impactmapping.org, the technique's official site: the definition of the four elements and the visual form of the map.
- Open Practice Library, Impact Mapping: the logistics of the session, two to four hours of preparation to establish the goal and a facilitated workshop with a small group.