The first time I read Impact Mapping, I wanted to leave it in the middle. Everything that's written there is too obvious. I found the strength to read it out, but it was a short book with big pictures. As it later turned out, the whole point was that I didn't use all these obvious and simple practices from the book in my work.
Sometimes customers wrote their goals in official documents for the project. Sometimes it seemed to me that I already understood the goals of the customer - they are absolutely obvious. Why specify the obvious? I felt the difference when I started using Impact Mapping in my work.
The history of Impact Mapping
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 project development dynamics and work priorities.
We started writing User Story and making Story Mapping. These practices have added understanding of how the project will develop, what are the priorities now, gave us an opportunity to communicate more productively with the customer. What was missing? The products do not exist in a vacuum, you need to see more global tasks that lie somewhere above the system usage stories. What we lacked was a simple game practice of setting project goals, from which Story Mapping and User Story will appear.
Mijo Balic and Ingrid Ottersten wrote the article Effect Managing IT (more on Agile product management using Effect Maps) in 2007. Four years later, in 2011, Gojko Adzic published a book called Specification by Example, in which it mentions a technique called Effect mapping in the chapter "Deriving scope from goals". This technique is designed to help teams focus on business goals, identify stakeholders and their needs.
Gojko Adzic adds several improvements to the Effect mapping over time, such as: prioritizing targets and impacts, the ability to move away from technical details at the level of What, the cyclicality in assumptions and experiments, etc. Personally, it seems to me that these are important changes, they add value in real life. After that the technique was renamed Impact Mapping.
How much is a kilo of code worth?
Imagine the situation. The customer comes to you. They already have a set of features to buy, they know what they want. He takes a shopping cart, just like in a shop. It includes a list of technologies, a dozen interface prototypes, integration with social networks, etc. Approaches the cash register and asks to weigh everything, implement and bill him.
It turns out that the customer came to you with ready-made solutions to some of their problems. In such a situation in work there will be only hands of the developer, but not a head. The developer will not be able to take a critical look at all the solutions we will be making.
Will such a project be successful? If the client's business and project is not "in the table", the success can only be evaluated by the effect that has been made on the business. Not by the number of set features, not by the deadlines, not by the budget, but only by changes in business.
Let's be honest, it is difficult to guarantee that the project will be successful. On the other hand, we can increase the chances of success by means of the fact that everyone in the team will understand and share the business goals. Then any decision - from naming a variable in the code to choosing an architecture - will be made based on real business needs.
The question remains: how do we get the real business goals we want to achieve out of the customer? How can we make sure that the team hears them, accepts them and starts working with them?
Composing Impact Mapping
Impact Mapping is a mind map of project goals with an impact map that should encourage the customer's business to achieve its goals.
Why? The central element of our map, which answers the key question: Why are we doing this? This is the goal that business is trying to achieve.
Who? At the first level, we answer questions: Who can help us achieve the desired result? Who can interfere? Who are the users of our product? This will include all stakeholders who can influence the business goals.
How? At the second level, we need to describe the impacts that stakeholders must have in order for the business to achieve its goals. We are looking for answers to questions: How will they help businesses achieve their goals? How can they hinder the success of the project?
What? After answering the key questions, you can discuss specific objectives. The third level answers the questions: What can we do as an organization or development team to create the necessary impact? This will describe the end result of our work.
To be continued on the next part