Impact mapping can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better road-map decisions.
I use this tool when ever the plan is not clear or there is no plan as it helps to align stakeholders with a clear understanding of the needs to be done to achieve the projects objective whether that be software delivery or business change.
How does it work:
An impact map is a visualisation of scope and underlying assumptions, created collaboratively with stakeholders. A map is grown during a discussion facilitated by answering the following four questions:
- Why are we doing this?
This will define the goal we are trying to achieve.
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.
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’ behavior 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.
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.
Project plans and requirements documents are often shopping lists of features or needs, without any context why such things are important. Without a clear map of the deliverables need to achieve the business objectives, and a justification of that mapping through impacts that need to be supported, it is incredibly difficult to argue why certain items should or shouldn’t be invested in. In larger organisations with many project stakeholders or product sponsors, this leads to huge scope-creep as everyone’s pet features and ideas are bundled in.
This is where an impact map puts all the deliverables in the context of the impacts that they are supposed to support. This will allow us to compare these deliverables and avoid investing time in less important areas of a projects. This will also help to weed out any delivereables that do not add to the end goal/objective.
For Business Analysts it also makes the requirement gathering easier as a User story can be pulled from the impact map. Even though the requirement will need to be fleshed out this is still a great starting point. Below you can see a diagram of how this can be achieved
If we take the time to connect the deliverables to impacts and goals, an impact map shows the chain of reasoning and thinking that leads to a feature or planning suggestion. This allows us to scrutinise those decisions better and re-evaluate them as new information becomes available through delivery.
Below is a infographic that has been put together that gives some great insight into Impact Mapping