Organization of the process
Invite no more than 10-15 people to this event, otherwise it will be difficult to conduct. It is optimal to invite 3-4 people from the side of the customer and the same number of people from the side of the team.
On the part of the customer it is necessary to take representatives of business, not only technical specialists, who have already formed an opinion about the specific implementation of all goals.
The map will be built on a board or wall, prepare them in advance. Impact Mapping for the 6-8 month task fits on a standard size board.
I haven't tried the online version of this technique yet, but I think any interactive tool will do. Communication will not be the same, but you can be saved if you know the customer personally or are an excellent facilitator/moderator.
Mapping will take from one hour to two days. This number depends greatly on the membership and your skills.
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.
Before you start, be sure to talk about the rules and objectives of the map. If you have time, send out the material on the topic to everyone to prepare
If the opportunity and circumstances allow, then make a few Icebreakers.
And the most important thing is that the process itself should be easy and fun. Do not add bureaucracy to it!
Example from practice
Let's look at an example very close to a real project, for which we made Impact Mapping in the beginning. Let's focus on the key points of Impact Mapping and on the mistakes 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 doubling of user satisfaction. It is important that user satisfaction is an index, i.e. a specific number that can be taken from the CRM, rather than a customer's opinion/feeling. We want to measure the achievement of the goal after the delivery of the feedback and understand whether we are going in that direction or not. If user satisfaction were not a number, how would we know that we have achieved the goal? It is also important that we have written exactly 2 times, not just an increase. Good goals should be SMART:
The first stage is quite a complex one, it should give impetus to the rest of the map and build trust between the participants. What can I advise based on my practice:
Do not rush to propose solutions at this stage. Listen to the customer, really listen. In the course of further discussion, you will have time to correct and comb everything, but in the meantime, write down what is in his head.
The most common problem is to impose solutions (What?) before the goals become clear. The engineering idea comes from the speed of light - the customer just opened his mouth, just started talking about his goals, and we have already created a database with all the tables in his head, invented the architecture and threw pieces of code. Why listen further if we already came up with everything? It will be a mistake to start interrupting the customer and offering solutions. Remember the joke on the subject and try to avoid the problem: "Dima said "Hello" and Dasha mentally played the wedding and gave birth to three children.
Do not dissuade the customer at this stage. In the beginning you don't know his business in all its subtleties. Customers can trust you as an IT professional and therefore quickly agree to your adjustments. You won't notice how only the goals you have imposed will be on the board, not those with which the customer has lived all this time.
Even if the goal is difficult to measure, try to come up with a criterion to achieve it. Move to the final of the project and think about how you will know if the goal has been achieved or not?
The process of developing the goals is iterative, and you don't have to squeeze all the goals on the first circle out of the customer.
There is no need to stretch out the artificial goals. There are projects that simply exist, because investors want to play software creators. You have to accept this and stop working on Impact Mapping.
At HappyDev 2014 I conducted a master class on Impact Mapping and Story Mapping. The project manager of the construction application processing project agreed to play the role of a customer. Everyone who came to the training was very active and immediately involved in the process. Over time we realized that it was difficult to just listen to the customer and understand his problem. Colleagues were in a hurry to offer their solutions. At some point we had to interrupt the work of the group and remind them that we had to listen more. Several times, because of the intense atmosphere and the pressure of the participants, the customer made our decisions by opening himself up to his own. I think that all the participants felt an important balance between listening to the customer and proposing solutions.
To be continued on the next part