Impact Mapping: Making a big impact with software products and projects

by Gojko Adzic

Impact mapping is a strategic planning technique.

If a product milestone or project succeeds in delivering the expected business goal, it is a success from a business perspective, even if the delivered scope ends up being different from what was originally envisaged.

To use impact mapping for strategic planning, you need: strategic goals – impact mapping is not applicable to maintenance mode projects the participation of senior decision-makers and senior technical people

The role of testing becomes to prove that deliverables support desired actor behaviours, instead of comparing software features to technical expectations. If a deliverable does not support an impact, even if it works correctly from a technical perspective, it is a failure and should be treated as a problem, enhanced or removed.

This is not a problem only in IT. Studies of military commanders and tank platoon leaders in the US Army show that giving answers to ‘what’ and ‘how’ does not prepare individual teams for reacting to unforeseen problems.

We visualise assumptions, which allows us to change direction once these assumptions are proven or discarded.

information is valuable if it reduces uncertainty about decisions, and that the “value of measuring a variable is often inversely proportional to the attention it gets”.

projects with strong outside metrics can fail when people involved focus on reaching quotas even when this damages the overall objectives, but achieves their private agenda.

plans driven by metrics need a counter-balance: adaptive planning.

Variation: seek out new ideas and try new things Survivability: try new things out at a scale where failure is survivable Selection: seek out feedback and learn from your mistakes as you go along

Water-Scrum-Fall, with a huge business decision-making part up front, an iterative technical delivery part in the middle, and a long business approval process at the end.

Impact maps help to keep user stories honest – each story needs to fit somewhere on the map.

Gibb-Drexler-Weisbord team-building process. Jack Gibb, Marvin Weisbord and Alan Drexler formulated a team-building process in the 1960s, based on research into group processes and organisational development. They structured an engagement model around four key questions: ‘Why are we here?’, ‘Who are you?’, ‘What are we doing?’ and ‘How are we going to do it?’.

When the business goals are not communicated clearly, technology experts cannot suggest a better solution if it exists.

If you can't find any objectives, start with suggested features and ask whose behaviour will this change and in what way. Then ask why those behaviour changes are important.

Tom Gilb has good advice on how to establish precise measurements for goals in his book Competitive Engineering. A simplified version of his list that worked well for me has the following five items: what we'll measure (Gilb calls it ‘scale’) how we'll measure it (‘meter’) what the situation is like now (‘benchmark’) the minimum acceptable value, the break-even point for investment (‘constraint’) the desired value (‘target’)

If it would take too long or would be too risky to wait for a 700K increase in the number of users before reducing IT costs, renegotiate targets. The first milestone could be to increase the number of users by 100K, then the second could be to reduce IT costs, then you could return to targeting a further increase in the number of players.

Reverse-engineering a bit of the shopping list has a positive psychological effect even if the original list has no good ideas. The people who provided the list probably have a lot of emotional attachment to their ideas, and by putting them into the map skeleton we show that we're valuing their opinions.

Diverge and merge. Get groups to work independently and review results every 20 minutes. The goal of this step is to try to find a better or a cheaper solution, a shorter journey to the key objectives. Don't criticise any ideas, just throw them on there.

Look at possible obstructions: what are the crucial things that can stop us before we even start? Is there a high-value low-hanging-fruit impact somewhere? What are the key assumptions to test?

To identify key priorities

Ask the following questions to start a useful discussion on deliverables: What is the simplest way to support this activity? What else could we do? If we're unsure about the assumption, what is the simplest way to test it? Could we test it without software? Could we start earning with a partly manual process?

When there are only one or two key measurements for a node, we can rephrase the node name to reflect the key measurements. So instead of ‘more players’, we can say ‘between 800K and 1M players over 6 months’.

use impact maps for iterative medium-term plans:

Once you reach your milestone, regardless of what was actually delivered in the software, you're done. It's time to move on to the next milestone, and do another mapping session with senior actors.

Criticising too early can kill the discussion before people have come up with good alternatives. Even a seemingly silly idea might inspire someone else to think of a good realistic alternative.

If the team is working on a map that does not have any actors or impacts that could prevent delivery, ask them to think about this – they will then often identify constraints on key deliverables.