Product Owners are supposed to be the informed leader who is able to provide direction to the development team on the expectations of the product. As more organisations look to adopt an adaptive/agile approach to project delivery, one of the big issues faced lies with the Product Owner. Unfortunately, in increasingly common cases, the criteria for a suitable Product Owner seems to be resource availability, followed by resource availability. This places more responsibility on the development team, especially the Business Analyst, to work with the Product Owner to ensure what is about to be built, is of value.
Product owners can be assisted by a number of analytical techniques. The one which will be explored in this blog is Impact Mapping.
Impact Mapping is a technique used to drive value and prevent over-engineered solutions. It places the overall Goal of the initiative as the main focal point (why are we doing this?), and then delves into the people we are doing this for, who can help it be done, or who can stand in its way (Actors), how the actors can help, change behaviours to help, or impede the goal being achieved (Impact), and plausible deliverables that can be created to address that impact (Deliverables).
This creates greater insight for the Product Owner and delivery team, which assists in maintaining focus during story definition, decomposition, prioritization, and delivery. Impact Mapping works both ways. Like forwards and backwards traceability, Impact Mapping can be used to maintain control of scope (forwards), and as also be used to question the logic of identified deliverables against the overall goal (backwards).
There are multiple points in an initiative that you can use Impact Mapping. And the results can be used throughout. At the start of project definition Impact Mapping can be used to identify features that would be suitable to achieving the project goal. From here you can move towards story definition and mapping to identify dependencies and conduct release planning. You can use Impact Mapping throughout the initiative as a way of checking when the original goal has been achieved. This is the part of Impact Mapping that mitigates against over-engineered solutions. Additionally throughout iterations the results of Impact Mapping can be used to maintain focus for delivery teams – why are we doing this again, who are we doing this for, what impact is this feature supposed to have – bingo!
Like all business analysis activities good preparation aids good performance. So make sure that you choose a suitable space for collaboration. Have all the necessary workshop aids (whiteboard, butchers paper, or better yet, a device to model and present). Start the session by setting the business goal (be SMART). Then work through the process by identifying the people, Actors, who we are doing this for, the expected Impacts the initiative will have, and then of course, identify the Deliverables. This works like a brainstorming session. You can do the backwards traceability at the end to de-scope (or deprioritize) deliverables that don’t directly align to the overall goal. Remember to document your assumptions. They will be key when questioning the logic.
Business Analysts have always had a broad role, and we remain cross-functional. Part of adaptive/agile is about measuring success through the delivery of valuable software. Without clearly distinguishing this value early, any project is destined to fail (the speed of failure becomes the variable). Impact Mapping is a simple tool to help Product Owners and Development Teams set off in the right direction and maintain focus throughout.
To find out more about what’s happening in the world of Business Analysis follow us on LinkedIn