How To Create Early Alignment On the Project's Definition of Success

When kicking off a new Agile project, it is important that the team has a shared understanding of how the product will deliver value for the business and the customer. The IRACIS mapping activity assists in identifying what the success measures and the accompanying target metrics will be. I’ve always found this an excellent activity to ensure that before we plunge into designing a solution, we have a good collective understanding (as a group) of why we’re really doing this project.

How To Facilitate an IRACIS Mapping Workshop

1. Ask your team (business SMEs, core team members, and other stakeholders) to ponder this question (first individually and silently), and write the answers on post-it notes, one answer per post-it: “If you had to define the product we want to build with three major benefits it delivers for the business and the customer, what would they be”?. An alternative question “what is the business impact we want to have with this product?” (for example, answers to this question could include things such as reduce customer churn, grow the customer base, sales retention, avoid regulatory fines, reduce manual effort (and cost), reduce maintenance and onboarding cost, reduce licensing fees for legacy systems, improve customer experience (measured through NPS & CES), improve eNPS, etc.)

2. Ask the team to put their post-it’s on the board when they’re done, then group similar post-its together. Each post-it/group of similar post-its represents a business driver

3. The next step is to map the primary impact of each of the business drivers identified: is the driver going to help us Increase Revenue (IR)? Avoid Cost (AC)? or Improve Service(IS)? And by how much?

1. Draw a grid that looks like the picture below: 
2. Ask the team to split into small groups (3~4 groups). Each group should be as cross-functional as possible, representing different specialties. Make sure that each group has at least 1 business representative (someone who could actually map drivers) as well as at least 1 member of the development team. I prefer to ask the team to self-organize rather than dictate who should be in which sub-group
3. Each sub-group then chooses a roughly equal number of drivers to analyze (e.g. if we had 20 drivers and 4 sub-groups, each sub-group focuses on 5 drivers). For each business driver, the sub-group tries to:
   • Decide whether this driver is going to help us Increase Revenue, Avoid Cost or Improve Service?
   • Decide whether to classify the impact of this driver as Primary (it is unlikely that the objective of Increasing Revenue, Reducing Cost or Improving Service will be met without this driver), Secondary (it is possible, though perhaps difficult, to achieve the IRACIS objective without this driver) or Tertiary (it is likely that the IRACIS objective could be achieved without the need for this driver). 
   • Example: In a workshop I facilitated recently, one of the business drivers identified was to reduce manual effort. The sub-group that chose this driver decided that it would help us Avoid Cost. They assessed this driver to have a Primary impact on the objective of avoiding cost (i.e. it is unlikely that we’ll be able to avoid cost if we don’t reduce manual effort since the cost of manual effort was a big part of the cost the division was incurring)
   • This is what the IRACIS matrix would look like at this point: business drivers mapped as to Increase Revenue (IR), Avoid Cost (AC) or Improve Service (IS); and each business driver is also assessed to have a High, Medium or Low impact on the objective to which it was mapped.
   • The focus then shifts to defining business drivers in more precise terms. For example, if we take the "reduce manual effort" driver mentioned above, what does reduce mean exactly? Reduce by how much? 5%? 99%? Each would require a radically different strategy than the other
   • Sub-groups take another look at the business drivers they’ve been working on, and for each driver:
     1. Decide on how the impact of this driver will be measured – e.g. if we take the reduce manual effort driver, a metric to measure it could be FTE hours. For the improve user experience business driver, a metric could be NPS, etc.
     2. Provide an estimate of the current baseline of the metric (what is our current NPS? What is our current FTE? Etc.) – a ballpark figure is accepted at this point. If the sub-group can’t provide even a high-level estimate of the current baseline, the issue can be taken up later with the entire team. If there’s no data available, it should then be a task for the team to find out
     3. Now that we have a baseline for the metric, the sub-group then discusses what the target is. By how much do we want to improve this metric? What is our goal vis-à-vis this business driver? Why? Again, the value here is in the conversation/debate this question engenders 
     4. Each sub-group should ensure that the metric, current value and future value information are captured on the same business driver post-it
     5. Now that each sub-group were able to specify how each business driver will be measured, what the current reading of that measurement is, and what the goal/target value for that metric is (as a result of the improvements brought about by our product), each sub-group is ready to share what they’ve accomplished with the rest of the team
4. Sub-groups then take turns presenting their work to the rest of the team. The business drivers and the rationale behind the mapping (Primary, Secondary or Tertiary) are explained, the metrics chosen to measure business drivers are presented, and current and future values for those metrics are discussed with the wider team. If the sub-group didn’t have the data to baseline one or more metrics, other sub-groups may have the information or are aware of where to find it
5. All the canvases that the sub-groups have been working on are merged into one Business Drivers canvas that contains all the business drivers and relevant information.

This exercise is most valuable when the thorough and probing questions of the wider team help create a shared understanding of the value we hope to create and the hidden assumptions that we make. The more we explore (and challenge) that understanding and those assumptions as a team, the more we learn. The learning we acquire from this activity takes many shapes: new ideas to experiment with, potential risks we haven’t considered, powerful questions and ‘what if’ scenarios we need to explore further, assumptions some in the team are making that others do not share, deep insights that should influence how we approach the project, etc.