Impact mapping is a variant of the InUse effect mapping method, introduced by Mijo Balic and Ingrid Domingues (Ottersten), combined with impact maps for training organisations invented by Robert O. Brinkerhoff, the feature injection ideas of Chris Matts, the measurability and iterative delivery ideas of Tom Gilb. It draws heavily on their work – enough to say that all key good ideas are theirs, I’ve just linked them together and put them into the perspective of modern software delivery practices. You will find references to the original ideas at the end of this booklet. Most of the glue between these ideas comes from inspiring, insightful and challenging conversations I’ve had with Craig Larman, Tom and Mary Poppendieck, Dan North, Gordon Weir, Jeff Patton and Matthias Edinger (in no particular order).
By combining these ideas, impact mapping brings usability and speed to proven product and project management strategies, helping them fit better into modern software delivery constraints, and at the same time applying some great ideas from other industries to software delivery.
This book describes the way I use impact maps. In my previous work, I referred to the method described here as “effect mapping”, as the structure closely resembles InUse effect maps. However, the way I use the maps is significantly different from the InUse method. I follow an approach much closer to what Brinkerhoff describes in his HET (highly-effective training) method, as roadmaps and iteratively refined milestone plans. In addition, I found that a slightly modified set of questions fits better the kinds of projects that I am involved in. InUse effect maps aim to facilitate innovative product design and user experience design. As a consultant, I work with ambitious organisations to help them improve delivery practices, and they often suffer from scope creep, lack of big picture, lack of alignment of delivery teams with business objectives; they waste a lot of time and effort building the wrong software. Impact mapping is a fantastic way to reduce all that suffering.
Using the same name for both InUse effect maps and the maps as I use them caused confusion, to the point that a well-known consultant said to one of my clients, “Gojko got effect maps completely wrong, but he’s on to something”. After several conference presentations in Sweden, the home of InUse, attendees came to complain that I was presenting effect mapping wrongly. This is why in this book, and from now on, I will use the name impact maps instead of effect maps for my method. By using a different name, I hope to prevent further confusion.
Craig Larman suggested the name “impact maps”, which is similar enough to effect maps but different enough not to cause confusion. Brinkerhoff calls his planning visualisation impact maps, which justifies the use of that name. His maps are used for managing training plans for organisations, so I hope that there is not much danger of confusion.
Disconnecting the maps I describe here from InUse effect mapping by name also allows me to focus completely on managing scope for software delivery, and use names for map elements that are more appropriate for that context.