Fortnightly Finances for Agile Organisations - Part 2, Tracking Benefits
In our last article we showed how it's possible to track project costs on a fortnightly basis by asking two simple questions and eliminating a whole lotta overhead across the board.
This article lays out how we tracked project benefits in the same project, to produce a graph of cost and benefit delivered, from day zero, on a multi-million dollar program.
Our client was looking to move from a traditional project environment to a more responsive, agile way of working. They'd made a big bet on a project and promised that the new agile methodology would deliver benefit during the project execution, rather than at the end of the 3 year program. So we devised a way to measure our costs in line with fortnightly software drops (iterations) and each time we dropped a package, we were able to tie it to a financial benefit for the company - here's how we did it.
1. Identify the measures - aim to solve the problems your stakeholders see first
The quickest way to demonstrate value to your customers is to speak their language - in this case we worked closely with stakeholders responsible for delivering the outcomes of the technology project to understand what was most important to them. Turns out they had a monthly business forum with 5 key measures that their leaders paid attention to, and they'd largely done the leg work in quantifying benefit - because their KPIs depended on it. It was critical that we demonstrated improvement in these terms, making their life easier, before we'd have any kind of trust to go looking for additional insight, or showing them what we thought was more important. If you're taking away their gantt charts, then what are you giving back in return? We gave them utter transparency on the dollars.
2. Write your dictionary - ensure everyone is on the same page
Over a 2 month period as we kicked off, one of our team members was solely responsible for getting the plan on paper. He worked tirelessly with our stakeholders to document each of their 5 key metrics in project terms - What it meant, a definition and a calculation of the monetary benefit associated with a change in each measure. Here's an example of what that looked like:
Cost per call - The average cost of a call across the entire organisation. The lower the better, achievable through fewer calls, less time spent on a call, lower cost of labour.
Cost per call = the monthly cost of the call centre operations business unit, divided by total calls received for that month
e.g. Cost per call = $ 130,000 to run the business / 5,000 calls in July = $26 per call
3. Support teams to translate their work into quantifiable benefits
With each deployment we made on the project, the team took time to review their results and then use the benefits dictionary to quantify their impact and add it to the graph. With 8-10 teams working simultaneously, this meant a constant flow of benefits every 2 weeks that then accumulated over time, so the graph steadily built.
Over the life of the project, our work changed both what and how the business measured - the cost of a call dropped for example - and so a new rhythm emerged: At monthly forums the business stakeholders would update their "cost per call" and we'd then feed that back to the team. This meant as our work had impact, we had a feedback loop to then shift our prioritisation of future work.
This simple shift meant that the team could respond to a changing business environment, rather than basing decisions of priority on the cost of a call that had been set at the start of the project (which could have been 3 year old data!).
4 Make it matter
With the support infrastructure in place, it's now our role as leaders to continue to show that this is important. Large visual displays and regular conversations reinforce for teams that it's worth the extra effort to quantify the benefits of their work. Here's a number of ways we can do this:
Print your cost / benefits graph and post it prominently on the wall, for everyone to see - Ours measured one metre by one metre square on the wall the first time we put it up. The secondary benefit of having it on a wall is that it's always accessible, anytime anyone wants to ask, with the information as we know it *right now*.
Build the same picture into your distributed reporting, so everyone sings from the same song sheet.
Planning and prioritising work should be a place for us to ask "how does this work impact our measures of success?".
Utilise the language of servant leadership: "how will we know? what data do we have to show improvement?" and with measures agreed, you're in a position to issue instructions with fewer constraints - because we're crystal clear on what good looks like.
So in summary,
Solve the problem your stakeholders see - because if you don't, they won't buy-in and you'll be pushing uphill on multiple fronts. Pick your battles, transparency of cost and benefit is a bigger win for the principles than getting perfect measures first time.
Ensure everyone's on the same page - Clarity of the measure, its definition, how it's calculated means a solid base for decisions and coherence through the whole team about how we will know we've been successful.
Reinforce the importance of demonstrating benefit with large, prominent visual displays and regular conversations that show your team not only that these measures are important, but also that their understanding of how their work impacts the measure is important.
In return, you'll build trust through hyper-transparency, shorten feedback loops between the work you do and impact on your business and customers, and you'll greatly simplify priority calls and communication between business and technology stakeholders because everyone understands what good looks like.