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

by Gojko Adzic

An impact map is a visualisation of scope and underlying assumptions, created collaboratively by senior technical and business people. It is a mind-map grown during a discussion facilitated by answering the following four questions: Why? Who? How? What?

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.

By having the answer to ‘WHY?’ in the centre, impact maps ensure that everyone knows why they are doing something. That helps teams align their activities better, identify true requirements and design better solutions.

Goals should not be about building products or delivering project scope. They should explain why such a thing would be useful. Goals should present the problem to be solved, not the solution. Avoid design constraints in a goal definition.

Who? The first level 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.

Alistair Cockburn advises looking for three types of actors: Primary actors, whose goals are fulfilled, for example players of a gaming system Secondary actors, who provide services, for example the fraud prevention team Off-stage actors, who have an interest in the behaviours, but are not directly benefiting or providing a service, for example regulators or senior decision-makers

How? The second 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.

By listing impacts on the second level of a map, we consider the desired changes in the behaviour of actors. This leads to better plans and helps with prioritisation. Different actors could help us or obstruct us in many ways on our route to achieving the key business objectives. Some of the impacts will be competing, some conflicting, some complementary. We do not necessarily have to support all of them, but without considering delivery scope in the context of these activities it is very difficult to prioritise and compare deliverables. The hierarchical nature of the map clearly shows who creates an impact and how that contributes to the goal. This clear visualisation allows us to decide which impacts best contribute to the goal and identify the risks; this helps immensely with prioritisation.

Don't list everything an actor might want to achieve. List only the impacts that really help move you in the right direction towards the central goal.

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

Ideally show a change in actor behaviour, not just the behaviour. Show how the activity is different from what is currently possible. So instead of just ‘selling tick...

What? Once we have the first three questions answered, we can talk about scope. The third 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.

An impact map puts all the deliverables in the context of the impacts that they are supposed to support. This helps with breaking deliverables down into independent chunks that provide clear business value, and helps us launch something valuable sooner. A clear hierarchy allows us to group related deliverables, compare them and avoid over-investing in less important actors or impacts. It also helps us to throw out deliverables that do not really contribute to any important impact for a particular goal. Finally, by connecting deliverables to impacts and goals, a map shows the chain of reasoning that led to a feature suggestion, visualising the assumptions of stakeholders. This allows us to scrutinise those decisions better and re-evaluate them as new information becomes available through delivery.

This is the least important level of an impact map. Don't try to make it complete from the start. Refine it iteratively as you deliver. Treat deliverables as options, don't take it for granted that everything listed here will actually be delivered.

Don't go into a lot of detail early on, there will be time for that later. List only...

Impact mapping is a great way to communicate assumptions, create plans and align stakeholders for iterative software delivery. Impact maps also facilitate several popular product and project management practices.

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.

Impact maps bridge the two worlds: they facilitate strategic planning and thinking to create a big-picture view focused on key business objectives, but also facilitate learning through delivery and help us manage project roadmaps. They represent and organise delivery scope in a way that is easy to evolve, reprioritise, grow and shrink as necessary to react to changed market opportunities or new knowledge.

Strategic planning Impact mapping is a great way to engage senior business and technical experts at the start of work on a product module or project milestone to create a shared understanding of scope – not from a technical but from a business perspective. Visual meeting techniques and collaboration ensure that senior decision-makers share an understanding of key business assumptions. This helps to align everyone with the overall vision. The structure of an impact map facilitates a good discussion, helping the entire group benefit from the wisdom of crowds. This...

To use impact mapping for strategic planning, you need: strategic goals – impact mapping is not applicable to maintenance mode projects the participation of senio...

To use impact maps to define quality, you need: agreement that the purpose of deliverables is to support changes in actor behaviour agreement on metrics that express stakeholder expectations for those changes

To use impact maps for roadmap management, you need: agreement that your aim is to achieve a business goal, not deliver pre-set scope frequent, iterative releases to measure progress agreement on metrics that express stakeholder expectations for the central business goal

Impact maps solve common problems

Scope creep

An impact map demonstrates that no further impacts are needed to achieve our goal.

Wrong solutions

Because an impact map puts software deliverables in the context of business goals, it is trivially easy to spot solutions looking for a problem, or those that would contribute to a different business objective.

Pet features

Impact maps allow us to quickly spot suggested features that do not support any of the desired activities, or do not contribute to the overall goal.

Wrong assumptions

Impact maps clearly show assumptions so that we can track and validate them.

Ad-hoc prioritisation

Impact maps put features in the context of behaviour impacts, allowing stakeholders to relate better to benefits they would get from features and make much better prioritisation decisions.

In larger organisations, impact maps also help to communicate the big picture to many stakeholders that need to coordinate their decisions. This significantly helps align everyone's expectations, and make trade-offs between the priorities of different departments.

He got the stakeholders to agree on a limit on the number of business goals for a release. Then he eliminated superfluous scope by insisting that each feature references a requirement it fulfils, and that each requirement references the goal it supports. Berkun wrote that such mapping allowed his teams to decide which features should or should not be part of a delivery, which ones should be reprioritised when business goals changed and which were critical for success.

Instead of just connecting features to goals at the start of a product milestone or a project, impact maps allow us to maintain a dynamic roadmap that changes with our learning, keeping the goal in mind and making features and scope secondary to it. We visualise assumptions, which allows us to change direction once these assumptions are proven or discarded.

Once the feature is delivered, we can track if the assumption was true or not. If players invite friends, we can keep investing in that branch. If not, we should stop, analyse the situation, and try to do something else about invitations.

In How to Measure Anything, Douglas Hubbard warns about a common psychological tendency to track what is easy to measure instead of what can inform good decisions. 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”. Knowing that we need to decide whether or not to continue investing in an area of a map, we can design measurements that would inform this decision.

A common problem with measurements is that they can change from being the means to control the success of a project to an end in itself.

In Seeing like a state, James C. Scott warns about the conflict between two levels of metrics: the ones that provide understanding and control to people outside the process being measured, and the ones that are important for the people inside, affected by the process.

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

"real-world problems are more complex than we think", because of they have a human dimension and a local dimension, and are likely to change as circumstances change.

For example, if we decide to run an experiment on invitations, we're aiming to validate an assumption that semi-automated invites will support players inviting their friends. The metrics we establish for this impact define how many invitations we expect, over what period etc. We build the feature, measure the results, compare them to expectations and learn from this to decide on the next feature. We apply this to the larger picture as well: improve invitations, measure the rate at which invited friends are becoming new players, learn from this and decide where to invest next.

A recent report published by Forrester Research argues that most organisations apply agile ideas only to development, leaving business outside the loop and losing out on big benefits. 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 planning before forming a Scrum team” paints a bleak picture of agile adoption. Impact maps can help solve this problem as they make business and technical experts clarify business objectives, focus on achieving impacts and think about software scope ideas as assumptions that could be proven right or wrong.

Big picture A common cause for the disconnect between business and delivery is that teams iteratively deliver items that are too small to make a difference from a business perspective. Projects become endless streams of small items going through the pipeline, with no big picture or big benefits. Business sponsors simply don't care about small deliverables, and they wait for everything to be finished. Even worse, they often ask for scope and cost to be fixed at the beginning of a project, pretty much defeating the point of iterative delivery. By trading the big picture for the ability to change things quickly, many teams lead their projects very much as if they were making their way along a dark tunnel – we don't know exactly where we'll go but small steps ensure we do not fall down.

Impact maps provide the big picture for both business sponsors and technical delivery teams. They remove the need for major upfront analysis. Because the process of creating a map is qui...