By Jon Reynolds | Mar 30 2018
Like me haven’t you at times been frustrated by software that has been delivered late and not made the business impact you expected. A lot of time and money had been wasted due to assumptions being made with inadequate requirements; poor communication of team objectives and an overall lack of understanding, focus and misalignment with the overall business goals. As a developer I use interative delivery and this places emphasis on integrating learning from delivery and refining the scope and requirements. However iterative delivery often loses focus on the overarching business goal and instead addresses just the business scope important at that moment of time.
Impact mapping is a strategic, planning technique that communicates assumptions and creates a visual map to plan and align stakeholders for iterative software delivery. This approach produces better roadmap paths and decisions by preventing businesses from losing focus on their goals and helping teams to align their activities with the business objectives. The impact map is created from discussions with all the relevant parties in answering the following four questions:
What are the overriding business goals? WHY is the business doing this? Goals are often poorly defined and very few people working on delivery know the actual expected business objectives. It is imperative that the business knows the purpose of its goal in order to make the correct decisions about cost, scope and timelines. If a product milestone or project delivers 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. Conversely, if it delivers exactly the requested scope but misses the business goal, it should be classed a failure. Knowing the “Why” ensures everyone involved understands why they are doing what they do. This would then allow delivery teams to co-ordinate their responsibilities better. In order to deem the delivery of a goal as a success good goals should be defined as SMART:
- Realistic and
Who are the decision makers, user and customers associated with these goals? Who can produce and be impacted by the desired effect? In order to deliver high-quality goals we need to understand who these people are, and what kind of value they are looking for from our products or project outcomes. People have their own needs, goals and preferences, which all come into play if we truly care about achieving a business goal instead of just delivering software. Unfortunately however the software requirements set have often ignored the actors who will benefit from it and who will be worse off when it is delivered.
We can classify the actors into 3 groups:
- Primary actors - the fulfilled end-parties who will hopefully be impacted postively by the delivered goals
- Secondary actors - the people who provide the services
- Off-stage actors - these are the business stakeholders who are interested in the behaviours and outcomes being provided e.g. regulators or senior decision-makers.
How should the our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent the goals from providing benefit? At this point we need to focus on what jobs customers want to get done instead of their ideas about a product or service. This should grant delivery teams the freedom to investigate and design different technical approaches and solutions in order to fulfil the goals. By listing the impacts we consider the desired changes in the behaviour of actors. This leads to better plans and helps with prioritisation.
At this point we define what are the deliverables? By providing context on the above questions we can now build priority-led requirements and shape delivery plans in accordance with the businesses explanations of why such things are important. A clear mapping of deliverables to business objectives, accompanied with a supported justification of that mapping creates a coherent investment in building business goals understood across by all.
Creating impact maps
Impact maps combine strategic planning and roadmap delivery by creating a big-picture view focused on key business objectives. The map defines all the deliverables within the context of the impact to the actors. As a result it helps build requirements with clear business value that are easy to evolve, prioritise, develop and shrink as necessary in aligment with the changing markets and opportunities to the business. Business stakeholders will be able to communicate their ideas better through visual representation. Senior product owners will learn how to communicate the impacts more effectively to delivery teams. Impact maps visualise assumptions and therefore facilitate effective meetings between all parties of the process helping businesses to clarify any assumptions being made and co-ordinate and align the big-picture thinking. Technical delivery teams will be able to draw on impact maps to make better strategic technical decisions by focusing on the deliverables. This helps them to better align their workflow; prevent scope-creep and developing over-engineered technical implementations.
So in summary
Impact mapping is a great facility to engage senior business and technical experts at the start of work on a product deliverable 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. Impact map promote effective discussions helping the entire group to benefit from each others wisdom. This can lead to discovering quick wins or defining alternative goals that are more effective and building software that is ultimately cheaper and faster to ship.