Impact mapping in practice

When I read Impact Mapping for the first time, I had a desire to drop it in the middle. Everything written there is too obvious. I found strength in myself and read it, since the book is short and with large pictures. As it turned out later, all the salt was that I did not apply all these obvious and simple practices from the book in my work.

Sometimes customers wrote their goals in the official documents for the project. Sometimes it seemed to me that I already understand the goals of the customer - they are absolutely obvious. Why clarify the obvious? I felt the difference when I started applying Impact Mapping to work.

Impact Mapping History

Previously, at the start of the project, we had technical specifications, system operation schemes, and, in a good version, interface prototypes. These documents lacked an understanding of the dynamics of the development of the project and priorities in the work.

We started writing User Story and doing Story Mapping . These practices added an understanding of how the project will develop, what are the priorities now, and gave us the opportunity to communicate more effectively with the customer. What was missing? Products do not exist in a vacuum, you need to see more global tasks that lie somewhere above the history of the use of the system. There wasn’t enough simple game practice for setting goals for the project, from which later Story Mapping and the User Story list will appear.

Mijo Balic and Ingrid Ottersten in 2007 wrote an article called Effect Managing IT (more about Agile product management using Effect Maps ). After 4 years in 2011, Gojko Adzic released the book Specification by Example , where in the chapter “Deriving scope from goals” he mentions a technique called Effect mapping. This technique is designed to help teams focus on business goals, identify stakeholders and their needs .

Gojko Adzic over time adds several improvements to Effect mapping, such as: prioritization of goals and effects, the ability to move away from technical details at the What level, the cyclical nature of assumptions and experiments, etc. Personally, it seems to me that these are important changes, they add usefulness in real life. After that, the technique began to be called in a new way - Impact Mapping.

How much is a kilogram of code?

Imagine a situation. A customer comes to you. He already has a set of features to buy, he knows what he wants. He takes a shopping basket, like in a store. Adds to it a list of technologies, a dozen interface prototypes, integration with social services. networks, etc. He approaches the checkout counter and asks to weigh everything, realize it and bill him.



It turns out that the customer came to you with ready-made solutions to some of his problems. In such a situation, only the hands of the developer will work, but not the head. The developer will not be able to critically look at all the decisions that we will make.

Will such a project be successful? If the client has a live business and the project is not done “on the table”, then success can only be assessed by the effect that has been exerted on the business. Not by the number of features delivered, not by meeting deadlines, not by budgeting, but only by changes in the business.

Frankly, it is difficult to guarantee that the project will be successful. But in our power to increase the chances of success due to the fact that everyone in the team will understand and share the goals of the business. Then any decision - from naming a variable in the code to choosing an architecture - will be made based on the real needs of the business.

The question remains, how to get the real business goals that we want to achieve from the customer? How to make the team hear them, accept and start working with them?

Composing Impact Mapping

Impact Mapping is a mind map for the goals of the project with a map of influences that should push the customer’s business to achieve the goals.



Why?
The central element of our map that answers the key question: Why are we doing this? This is the goal that the business is trying to achieve.

Who?
At the first level, we answer the questions: Who can help achieve the desired result? Who can interfere? Who are the users of our product? This will include all interested parties that may affect the goals of the business.

How?
At the second level, we must describe the impact that stakeholders must have in order for the business to achieve its goals. We are looking for the answer to the questions:How will they help businesses achieve their goals? How can they hinder the success of the project?

What?
After answering the basic questions, specific tasks can be discussed. The third level answers the questions: What can we do as an organization or development team to create the necessary impacts? The final result of our work will be described here.

Organization of the process

1. Invite no more than 10-15 people to this event, otherwise it will be difficult to conduct. It is optimal to call 3-4 people from the customer and the same from the team.
2. On the part of the customer, it is imperative to take representatives of business, and not just technical specialists, who already have an opinion on specific implementations of all goals.
3. You will build a map on a board or wall, prepare them in advance. Impact Mapping for a task lasting 6-8 months fits on a standard-sized board.
   I have not tried the online version of this technique yet, but I think any interactive tool will do. Communication will not be the same, but it can save you if you personally know the customer or are an excellent facilitator / moderator.
4. Mapping will take from one hour to two days. This figure is highly dependent on the composition of participants and your conducting skills.
5. Each block of the map can be drawn with a marker or made with stickers. I prefer stickers because they are more mobile, and the impact map will often sort and change as you dive into the project.
6. Before you start, be sure to talk about the rules and goals of mapping. If you have time, then send everyone material on the topic for preparation
7. If possible and circumstances allow, then make a few Icebreakers.
8. And most importantly, the process itself should be easy and fun. Do not add bureaucracy to it!

Case study

Let us examine an example very close to the real project, for which we did Impact Mapping at the beginning. Let us dwell on the key points in compiling Impact Mapping and on errors that can ruin the whole idea.

Why?

The root element of our map will be a list of business goals. For example, this could be a 2-fold increase in user satisfaction . It’s important that user satisfaction is an index, i.e. a specific figure that can be taken from CRM, and not the opinion / feeling of the customer. After delivery of features, we want to measure the achievement of the goal and understand in which direction we are going or not. If user satisfaction was not a number, how would we know that we have achieved a goal? It is also important that we wrote exactly 2 times , and not just an increase . Good goals should be SMART :



The first stage is rather complicated, it should give an impulse for drawing up the rest of the map and create trust between the participants. What can I advise based on my practice:

1. Take your time to propose solutions at this point. Listen to the customer, truly listen. In the course of further discussion, you will have time to correct and comb everything, but for now write down what he has in his head.
2. The most common problem is imposing solutions (What? Step) before the goals become clear. An engineering idea flies at the speed of light - the customer just opened his mouth, just started talking about his goals, and we already created databases with all the tables in our heads, came up with the architecture and threw pieces of code. Why listen further if we have already come up with everything? It will be a mistake to begin to interrupt the customer and propose solutions. Remember the joke on this subject and try to avoid the problem: “Dima said“ Hello, ”and Dasha mentally played a wedding and gave birth to three children.”
3. Do not reassure the customer at this point. At the very beginning you do not know his business in all its subtleties. Customers can trust you as IT professionals, and because of this, quickly agree to your corrections. You yourself will not notice how only those goals that you imposed on the board, and not those with which the customer lived all this time, appear on the board.
4. Even if the goal is difficult to measure, then try to come up with a criterion for its achievement. Mentally transfer to the final of the project and think about how you will find out if the goal has been achieved or not.
5. The process of developing goals is iterative, it is not necessary to squeeze out all the goals from the customer on the first round.
6. No need to stretch artificial targets. There are projects that simply exist, because investors want to play software creators. You need to put up with this and curtail the work of compiling Impact Mapping.

At HappyDev 2014, I conducted a master class on composing Impact Mapping and Story Mapping. The project manager for the processing of construction applications agreed to play the role of the customer. Everyone who came to the training was very active and immediately got involved in the process. Over time, we realized that it’s quite difficult to just listen to the customer and understand his problem. Colleagues vied to offer their solutions. At some point, I had to interrupt the work of the group, to remind us that we should listen more. Several times due to the tense atmosphere and pressure of the participants, the customer made our decisions, abandoning his own. I think that all participants felt an important balance between when to listen to the customer and when to offer solutions.

Who?

At this stage, we must identify all who will help influence the goal, who will contribute to its achievement or interfere. In our example, these will be the Marketing Department and the Forum Moderator . According to the customer, it is they who can change user satisfaction:



Here we can indicate specific people, department names, market segments, etc. Choose any level of abstraction if only it is adequate to your project.

How?

Now we need to determine the impacts that will be made to achieve the goal. For example, a forum moderator may try to answer questions within 1 minute. Do you think this will increase user satisfaction? We have an assumption that it will increase, so we write this “impact”. We do the same for the remaining roles:



A few recommendations:

1. Optionally, but it is desirable that the impacts are also measurable. We wrote not just Answer the forum , but Reply to the forum for 1 minute .
2. Do not record all the possible effects of each role. We need only those activities that lead to the achievement of the goal.

What?

We have reached the most insignificant in Impact Mapping. In the last node of our map is the very shopping basket with which work on the project usually begins. The difference is that now we understand the value of each feature, why this feature is here and what its implementation will lead to:



Some comments and recommendations:

1. At the end nodes of the map, you can write User Story or the names of modules / subsystems.
2. You can’t paint this part of the map in detail, you can even not fill it out at all, but just say its main points. You will be able to create a complete list of all User Stories on Story Mappging.
3. It is not necessary to describe IT tasks here. Instead, you can write some kind of organizational transformation and generally any action to implement the impact on the goal.
4. Understanding goals enables us to create cheaper and faster solutions to achieve these goals. Due to the card, we begin to use not only the hands of developers, but also the head - each team member can make informed decisions.

Impact Mapping Results

So our Impact Mapping is ready. It remains to prioritize each column. Not all goals are equally important, the same can be said about the rest of the map nodes. There are different ways to prioritize. Because we follow the path of simplicity and visualization, I can recommend putting stars. Give each participant 5 stars and he can put them wherever he wants. Thus, it is possible to identify the highest priority nodes.

The result of the work must be hung in full view. If the team is distributed, then you need to put Impact Mapping into a common knowledge base or hang it in front of the screen that all development participants see. The main goal is to ensure the visibility and reachability of this information, because we rely on it when working on a project.

When I talked about Impact Mapping on AgileClub , colleagues noticed that there are other ways to understand strategic goals. For example, you can use Lean Canvas or collect requirements in project documentation describing goals and stakeholders. In fact, Impact Mapping does not contradict other approaches and can be used with them. Personally, I like him more, because:

• This is a simple technique that promotes communication and interaction; it does not have bureaucracy.
• For customers who are not versed in IT and software production, this approach is very easy to explain, it takes a couple of minutes.
• Mind map visualization

Inbound Filter

Even when everyone agreed with the goals of the project and how to achieve them, the customer can add a feature to his project that he really likes - the pet feature. We can filter it through goals, show that this feature in no way leads us to achieve goals.

Similarly, we will filter ideas for architecture and system design that come from the development team. Does remaking architecture lead to faster and cheaper goal achievement? If not, then why should we do this?

Kanban board upgrade

Which column is the last on your Kanban board? I bet it's Release, Deploy, Done, or something like that. The last column on the board should be - checking the achievement of the goal. It’s not enough just to upload the feature to the server, we need to check if we have reached the goal, as expected or not.

FAQ

• How to sell the creation of Impact Mapping to the customer before the start of the project?
  It’s best to go from the problem. Ask the customer to recall cases when a lot of features were made, and the business only suffered from this. Why did it happen? Maybe you need to clearly describe the goals?
• Should this work be paid?
  Yes, definitely. Compilation of Impact Mapping can take several days and is of value to the business, I do not recommend doing it for free.
• What if the customer does not want to do this?
  You, as a professional, must provide the customer with a forecast for the future. Tell us about possible problems, describe the risks and their dangers. After that, let the customer choose. If you conveyed a possible troubled future and the client accepted it, abandoned Impact Mapping with full clarity of consequences, now this is not your problem, just make it a feature.

Impact Mapping is one of the activities that will make both customers and developers happier and more efficient. Set the right goals right!

---

Links:

How to get the most out of impact mapping , Gojko Adzic

How I Learned to Stop Worrying and Love Flexible Scope , Gojko Adzic

Impact Mapping - how can a dev team stop doing what they need and start doing what it needs? , Dmitry Petrashev