Impact Mapping

Impact Mapping

Impact Mapping

A website connecting audiologists, manufacturers of hearing technologies and users of hearing devices. A sales lead marketplace and call centre management system. Property image processing and a presentation tool.

A publishing and e-learning platform. All of the aforementioned projects are the results of different ideas having however at least one thing in common: an idea was born in order to create, increase or protect the revenue. Yet between conceiving the idea and going live with the project, there are many steps, preparations, phases, levels, complexities and middlemen in the software development process. As a result, we end up with a situation where the developer who is turning on his machine, is unable to answer the ultimate question: “Why am I doing this?”, in a sense, “how the feature I am implementing now, gets the project closer to achieving a business goal?”. Moreover, the problem not only occurs on that endpoint of the software development process, but even at the very beginning, when the business goals are communicated by stakeholders. Business idea might “get lost in the process of translation” if there is no agreement upon words, terms or concepts that are used by stakeholders to describe business goals to the IT people. Also, if projects start with business sponsors asking for features which you can easily compare to a shopping list. At a first glance, coming up with features as solutions may seem a right thing to do, but should we give it more thought, we will discover a shopping list being suboptimal because:

  • senior business sponsors are usually not technology experts and solutions they propose might not necessarily be the best out there
  • the solutions might be valid for the successful outcome of the project, but nothing is known about underlying assumptions that led to these solutions. With the technology landscape changing rapidly and the underlying assumptions being unknown you cannot be Agile and respond to change because you are not aware of business objectives.

Therefore the problem concerns wrapping business goals properly and turning them into deliverables. Hence, software projects need to use techniques of collaborative planning that help with getting a clear focus on meeting stakeholder goals, eradicating miscommunication and reducing the cost of development. The techniques which help to ensure alignment of business and delivery, facilitate creating better plans and roadmaps, elicit the true business goals and values standing behind features, from the “shopping list”.

Impact Mapping.

One of the techniques the purpose of which is solving the problems I mentioned before, is a technique called “Impact Mapping”, created by Gojko Adzic. As the author of the technique describes it, “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 and the measurability and iterative delivery ideas by Tom Gilb”. Gojko Adzic states in his book “Impact Mapping” that he just linked these ideas together and put them into perspective of modern software delivery practices, which resulted in an emergence of a tool that facilitates:

  • Strategic planning. Impact Mapping prevents organisations from getting lost while building and delivering products. Key elements are:
  • Assumptions underneath features are clearly communicated
  • Enhancing collaboration by creating a shared big-picture view for technical and business people
  • Defining quality. Impact Map is a visualisation which defines the expected quality of software at a holistic level as well as defining activities related to improving or assuring quality. When everyone involved shares the same understanding of what has to be delivered, it is easier to maintain strong focus during delivery. Respectively, Impact Mapping enhances the role of testing. Testing is no longer confronting software features with technical expectations. Testing role is to prove that deliverables support desired actor behaviours.
  • Roadmap management helps to reduce waste by preventing scope creep and over-engineered solutions. It provides focus for delivery by putting deliverables in the context of impacts they are supposed to achieve, with ways of achieving the actual change. Hence, it is easy to potentially re-evaluate the strategy and decide whether to continue with pursuing the initial goal or change the objective and move on to something else.

It is important to note that Impact Mapping technique is not intended for the maintenance mode projects. However, it works best when used by non governmental organisations or existing businesses as it is easier to “get to the money”. Naturally, for start-ups the impact would be getting above zero, as this is the level they usually start from.

Let’s learn Impact Mapping technique by example. So far we have learnt about the importance of strategic planning techniques and their impact on software development process. I have highlighted one of such techniques called Impact Mapping. Yet in order to make this article really useful it seems to be a good idea to make it more accessible for someone who intends to adapt Impact Mapping technique described in this article, for his own (organisation) purposes. Hence, this is what I attempt to do now. And since I am a supporter of learning things through examples, I will use Impact Mapping itself as a topic for generating an exemplary impact map for studying purposes. Setting up a measurable goal is the key element of an impact map and usually answers the most important question: “What are we doing this for?”. Let us come up with a following goal: “Make it happen that more organisations turn to using Impact Mapping technique for strategic planning”. In order to answer this question properly we should try to find and identify in what way is our goal connected with money. In connection with that, let us ask that question again: “why are we doing this?” The answer is: “we are doing this because we want to save our clients money”. A cause defined like this is always the appropriate one for a company, but still one might say: “okay, but that is your customers’ money, not yours, so why are you doing this?”. Then we can explain that we want to do this, because we believe that our customers will appreciate the sheer fact, we’ve saved their money, thus they will want to sustain relationships with Selleo. This goal will obviously help us with protecting our revenue that actually comes from our existing customers. The same goal may also help us earn more, if a happy client recommends us to other customers. Having our goal specified, we can move to the next step of our preparations, which is defining good measurements. As one may have already noticed, the goal defined by us can and should be refined, because it contains a rather vague sounding term, i.e.”more”. At this point we don’t know what is the actual meaning of “more” so we will not be able to determine, if we finally achieve that “more”. Next, there is no information regarding when to expect a desired change. Thus, after a moment of brainstorming we come up with: “Make it happen that by the end of year 2013, the number of organisations using Impact Mapping technique for strategic planning will have doubled”. It sounds better now, but a goal defined like this still causes certain difficulties. How can we measure this? We would need some data concerning organisations using Impact Mapping in 2012 but also gather the same information with reference to the year 2013. This could be very difficult. Also, is “all organisations out there” our target, our actor, for whom we want to change its behaviour or just make an impact? Of course not. We focus on organisations which are our customers in the first place. Although it would be great if all organisations would adopt the techniques facilitating strategic planning, we are most interested in changing behaviour of those for which we deliver solutions. To limit the scope to our own customers exclusively makes a more realistic goal, as it would be easier for us to influence organisations which are our clients. So let us try to refine this goal once again: “Make it that by the end of year 2013, more than 50% new projects started by Selleo will have had their Impact Map prepared, before any development is commenced”. This way, we know:

  • what we intend to measure (number of Selleo new projects leveraging Impact Mapping technique)
  • how we intend to measure (compare number of projects using Impact Mapping in 2012 and 2013 respectively)
  • what is the situation like now
  • the minimum acceptable value (50%)
  • the desired value (more than 50%)

The key objective for our milestone is contained in the goal we have defined. This is an easy scenario in our circumstances as there is only one goal. In another situation there would most probably be several key objectives. The key element of milestone planning would be to choose only one goal and focus on it, as “five consecutive milestones where each fulfils one business objective are generally much better than one milestone that fulfils five partially”.

Mapping step 1: draw the map skeleton.

We can now move to the next step and draw the map skeleton. Let us assume that in order to do so, I asked my colleagues: a business consultant Greg, a technology leader Michael and a technology consultant Arek to gather with me in one room and help me to create an impact map.

Mapping step 2: find alternatives.

What we have above on the diagram is our rough idea of what needs to happen in order to make our goal become reality. Now that the key objectives are established, it is time to research some alternatives. Gojko suggests to leverage the design thinking technique here; specifically the divergent phase. Groups should work independently in 20 minutes sprint sessions and review results at the end of each sprint. Key points of step 2:

  • the goal of this step is to try to find better, cheaper and more quickly implemented alternatives
  • Don’t criticize any ideas… just yet. Throw them in into a skeleton map. Other group members may find them inspiring and come up with different / better ideas.
  • You may leverage various Agile techniques used for creating User stories. It will help the group with brainstorming ideas.

After some time spent on brainstorming with Greg, Michael and Arek, we came up with the following:We have noticed that the more precise and concrete the goal is, there are less possible (valid) impacts out there to potentially support the goal. Thus, coming up with a precise and concrete goal helps with identifying impacts which will contribute most to established goals. If you have defined your goal, say, “get 1 million of customers in a year” then you could have identified a several actors helping or obstructing the achievement of your goal with many possible impacts you would have to prioritize, before even starting looking for deliverables supporting these impacts.

Mapping step 3: Identify key priorities

We began mapping step 3 by asking ourselves the following questions:

  • “What are the crucial things that can stop us before we even start?”
  • “Is there a high-value low-hanging-fruit impact somewhere?”
  • “What are the key assumptions to test?”

Following some discussion we concluded that it would be, in many ways better, to teach about benefits of strategic planning techniques like Impact Mapping, than demanding compliance upfront, from our customers. An incentive in the form of a discount is a tempting idea, but we decided to try to explore more cost-effective options instead. Hence, we could start growing the third level of the map: deliverables.

Mapping step 4: earn or learn.

Gojko recommends to establish with the group first, what is the learning budget, i.e., the maximum cost or length of tasks aimed at learning. Sometimes we have no way to tell how things will turn out before we actually try them. The group should grow the deliverables, so each item is either justified by a validated assumption or it fits into the learning budget. Gojko suggest to operate with the following set of questions while discussing deliverables:

  • “What is the simplest way to support this activity? What else could we do?”
  • “If we are unsure about the assumption, what is the simplest way to test it?”
  • “Could we test it without software?”
  • “Could we start earning with a partly manual process?”

Certainly, sponsoring training courses organized by Gojko Adzic would be the best way to explain Impact Mapping and its key benefits to our customers, but it would also be the most expensive option. Therefore it does not fit into our learning budget. We have to come up with something else:Therefore, following a brainstorming session, our team came up with two additional ideas: The first one would be to organize such training workshops by ourselves. We would not have to pay for plane tickets and training course attendance fees, but again this option wouldn’t be necessarily much cheaper. Since we need to consider the alternative cost of some Selleo’s employees spending their time for running workshops instead of doing some other work. That is why we quickly moved to another idea, which is, to write an article, which would:

  • highlight the importance of strategic planning,
  • explain how to turn business goals into deliverables,
  • capture the process of working on the Impact Map, by example.

By now, it should be clearly visible where I am heading to, i.e. what you are reading right now can be considered as a deliverable of an Impact Mapping technique.


If you can’t define small experiments to test key assumptions, Gojko suggests that we try user story mapping technique by Jeff Patton or the hamburger method to identify iterative delivery slices that could help you earn or learn sooner. The Impact Mapping fits here perfectly as creating User Stories is naturally the next step in the software development process. Impact map ensures that your requirements are properly validated before the implementation process starts. If you would like to delve deeper into the topics of fitting measurements into the map, typical organisational, facilitation and mapping mistakes as well as when to call it a day, or return to the whiteboard for strategy rethink, then you can find some more resources here. If your organisation’s projects are often plagued by:

  • scope creep,
  • wrong solutions,
  • pet features,
  • wrong assumptions
  • ad-hoc prioritization

then definitely you should consider giving Impact Mapping a try.