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

by Gojko Adzic

It helps you to find the right questions, which is much more difficult than finding good answers.

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.

Goals should present the problem to be solved, not the solution. Avoid design constraints in a goal definition.

Impacts are not product features. Avoid listing software ideas here, focus on business activities.

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.

This helps with breaking deliverables down into independent chunks that provide clear business value, and helps us launch something valuable sooner.

List only high-level deliverables. You can break down high-level features into lower-level scope items, such as user stories, spine stories, basic or extension use cases later. These items can become fourth, fifth or sixth level map branches.

Never aim to implement the whole map. Instead, find the shortest path through the map to the goal!

Iterative delivery methods and lean startup ideas place significant emphasis on integrating learning from delivery into refining scope, specifications and requirements. Upfront plans are inadequate because the landscape changes too frequently.

But iterative delivery plans often lack a big picture.

An impact map helps the delivery organisation maintain a strong focus during delivery, and helps to prioritise and define activities related to improving or assuring quality. 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.

Hubbard says that

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

suggesting the solution in the form of a checklist: 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

Impact maps can help to facilitate the application of the Palchinsky method. By focusing on business objectives and desired impacts, a map helps us think better about alternative ways of delivering, stimulating variation. While mapping impacts we break deliverables into small pieces, supporting survivability. Finally, by visualising assumptions and defining a clear path from deliverables to desired impacts and business goals, impact maps define good measurements for feedback, helping with the selection principle.

Lean startup is an innovative approach to designing and implementing products and managing companies, described by Eric Ries in his book Lean Startup. Two of the core ideas of lean startup are validated learning (intentionally testing assumptions) and the build-measure-learn cycle (small iterative deliveries to facilitate learning).

build-measure-learn

Iterative delivery became mainstream during the last decade, especially through the use of agile methods.

Many organisations adopt a process that Dave West called 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. West's

conclusion that “most firms do requirements and plann...

a Scrum...

they often ask for scope and cost to be fixed at the beginning of a project, pretty much defeating the point of iterative delivery.

Impact maps provide the big picture for both business sponsors and technical delivery teams.

User stories are de-facto standard for managing scope in agile methods today.

impact maps allow us to prioritise whole branches easily.

Another common problem with user stories, especially when they are created in bulk, is that they are often created to describe technical deliverables. The most popular story format lists the expected business benefit, a user group that will benefit from the story and the scope that will be delivered on a high level. The idea with this format is to ensure that we know why each story is important, so that we can plan better.

Impact maps help to keep user stories honest – each story needs to fit somewhere on the map. In order to fit it in,

the stakeholder and business benefit on the story card should relate to an actor and an impact on a map. This makes people think harder about what they really want to achieve with a user story, and formulate them better. If there is no suitable place for a story on the impact map, it probably doesn't belong in the current delivery cycle.

Brainstorming to generate new ideas: with the structured process of asking the four key questions and looking for alternatives (explained in the following part of this book), impact mapping facilitates brainstorming.

Change by Design [Brown09]

Visual facilitation makes meetings more effective, according to David Sibbet, because of three key factors: Participation significantly increases as people interact over the graphical presentation of ideas Big-picture thinking allows groups to compare ideas, discover patterns and find new ideas more easily Group memory improves because the meeting is recorded in pictures, and follow-through improves.

Sibbet claims that visualisations make groups smarter, writing ‘visualization is worth 80 IQ points’ because it releases energy, intelligence and creativity in the room.

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?’. Their model helps with alignment of teams, and directly corresponds to the discussions used to create an impact

map. In practice, this mea...

structure of an impact map facilitates a good discussion and brings separate roles together into a si...

Visual Meetings [...

With a clear focus on business goals and good metrics to tell us when we've delivered, we can respond to questions about costs and times by asking ‘How valuable is this? How much do you want to invest? And when do you want it?’.

Something in human psychology makes us come up with features as solutions.

Most of my past projects started with business sponsors asking for features, a kind of shopping list. Business objectives often exist only in the back of some senior sponsor's head, but they aren't clearly expressed or known to anyone else. This sets up software projects for failure from the start for two reasons:

Senior business sponsors are usually not technology experts, so the solutions they pr...

mission statement is by expressing the expected business goals.

‘why is the feature important’ or ‘how would it be useful’. Keep asking the questions until you get to the money.

Tom Gilb has good advice on how to establish precise measurements for goals in his book Competitive Engineering.

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’)

This is why it's good to plan for two meetings, with enough