An impact map is a visulation of scope and underlying assumptions, created collaboratively by senior technical and business people. Ot is a mind map grown during a discussion facillitated by answering the following four questions: Why? Who? How? What?
What are we trying to achieve? Usually defined in vague terms. Knowing why allows you to make good decisions around cost, scope & timelines, both at the start and when things change.
People (example in military) need to know the objective of any activity to react correctly to unforseen problems (which are a fact of life).
You can deliver to a biz goal without achieving the same scope (WIN). You can deliver the scope while missing the biz goal (FAIL). We usually blame customers for not knowing what they want.
Why goes at the centre of the mind map. Allows aligning activities better, identifies true requirements & design better solutions.
Goals shouldn't be about scope or products, why should explain why that would be useful in SMART terms. Goals should present the problem to be solved, avoid design constraints in the goal definition.
Chris Matts says don't worry about getting a single number, define goals as increments of biz value, explaining how the situation should change in the future. This works when you have KPIs for the product.
For commercial products/orgs try to define goals as an obvious link to money.
Examples: Start to trade in Brazil by March next year. Increased user conversion by 20% in 3 months.
Next level on map. "Whose behaviour do we want to impact? Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it?" The answers are the actors who can influence the outcome.
Wienberg 'Quality is value delivered to some person'. To deliver high quality you need to know who these people are & what value they want from product/outcome. As well as the direct link, we have to consider the other people involved in influencing the creation. People have their own needs, goals and preferences which come into play when meeting the biz goal.
Most requirements models ignore this - they focus on what the product should do and not who benefits or will not when it's delivered. Usually this actor appears mid-flow and changes things fundamentally, or someone with influence just stops the project in it't tracks.
The map makes you consider these actors (decision makers, user groups, customer segments) and how to prioritize better. Satisfy the most important actors first.
Important actors are the ones who can significantly influence the success of a project milestone including end-users & internal/external decsion makers.
Cockburn says look for three types of actors: Primary actors who goals are fulfilled. Secondary actors who provide services. Off-stage acotors who do not directly benefit or providing a service (refulators, senior decision makers).
Avoid terms like 'users', diff users have diff categories of needs, not all users are important for specific projects. Define actors in this order: Specific Individual, user persona, role/jobtitle, group/department.
Examples: Mike Smith from the Marketing Dept. Under 18 users with a mobile device at a consert. Apple ITunes store approvers.
Second Level of map sets the actors in the perspective of the biz goal. Answering the questions: "How should the actors behaviour change? How can they help us achieve the goal? How can they obstruct or prevent us from succeeding?" These are the impacts we're trying to create.
Ulwick says key to succesful delivery is to understand the jobs (or changes to jobs) the customer want to get done instead of ideas about product or service. Allows technical exploring. Focuses on helping users get stuff done, rather than delivering features.
We are considering the desired change in the behaviour in the actors. Gives you better plans and helps with prioritization. Many actors can help or hinder towards the biz objectives. Some impacts will compete, some conflict, some compliment. You don't have to support all of them, but without considering scope in this context it's hard to prioritize deliverables.
The map should show you who creates an impact and how that contributes to the goal. This helps see what contributes to the gaol and identify risks.
Don't list all things an actor wants, only the ones that help you move towards the central goal.
Impacts != Product Features. Focus on biz activities.
Ideally show the behaviour change, not just the behaviour. Don't say "selling tickets" say "selling tickets 5 times faster".
Consider negative impacts as well as postive.
Important actors can help or hinder in different ways. Once you discover the first impact of an actor, think what else they could do.
Examples: Inviting more friends. Purchasing tickets without calling the call centre. Selling tickets faster.
Now we talk about scope. "What can we do as an org or team to support the following required impacts?" These are deliverables, software features and organisational activities.
Delivery plans and requirements docs are often shopping lists of features, without context that explains why they are important. Without the mapping to biz objectives it's very hard to argue about making or not an investment in certain items. I large orgs with many stakeholders/sponsors this leads to scope creep as pet features are added. This usually fails.
Impact Maps put all deliverables in the context of the impact that they are supposed to support. This helps you break down the work into chunks that provide clear biz value sooner. The hierarhcy allows you to group similar deliverables and avoid over investing in unimportant actors/impacts. Also allows you to throw out that don't really help with an important impact. Knowing the path allows you to scruntinize the assumptions later when things change.
This is the least important level of an impact map. Don't make it complete, refine and iterate as you deliver.
Deliverables are options, don't assume that everything will be delivered.
Don't go into great detail early on, there will be time for that later. List only high level delverables. You can break these down into low level scope items like user stories/spine stories/use cases later. These items can become 4th/5th/6th level map branches.
There are often ways to achieve biz activity without building software. Somtiems it's cheaper to advertise/market than rebuild a system.
Examples: On-line ticket sales. Mobile home page with purchase form. Optimise call centre sales scripts. Sign re-selling contracts.
Never aim to implement the whole map. Instead, find the shorteset path through the map to the goal!
Online Gaming - Reach 1M Players Actors: Players, Internal, Advertisers Branches: Players - Inviting friends, recommendations, posting about game Internal: PR Event, Engage network Advertisers: Bulk invites, Banner ads
Financial Transation Processing - Reduce transaction cost by 90% Actors: German Settlement Team, Traders, IT Ops Branches: GST: Process exceptions faster, Process fewer manually Traders: Cause fewer exceptions, Reduce non-standard orders IT OPs: Run system cheaper