How agile made me change my mind on business cases

By Mark an der Pas, CEO Uffective

Never thought I would say this, but the time has come to look beyond business cases for IT investments. As those of you who know me, I used to be a die hard fan of business cases as they were a main guidance in allocating IT ressources to the initiatives with the biggest impact. In this I was in good company as Nobel Laureat Harry Markowitz, the godfather of portfolio management, made clear that without the expected return of an investment modern portfolio management was impossible. Nevertheless I came to the conclusion that business cases are not usefull in specific cases.

So what made me change my mind?

It was not that it takes a lot of time to create a business case

Of course I heard the disadvantages of business cases and of course I know that it takes time to create one. But I was never impressed by this argument and I am still not impressed by it as I still think that spending a couple of hours or even a day or two thinking about the financial consequences is a good thing. It is a good thing as it enables you to compare and select the most impactfull investments. On top the process of creating a business case turned out to be a great place for the discussion on how to reduce project cost as well as how to increase  expected benefits. In discussing this properly the creation of a business case turned out to be an activity that generates value as such.

It was also not that business cases are ‘full of lies’

The accuracy of business cases has been discussed several times. The cost estimations are inaccurate and the benefits are even more inaccurate or can not be quantified at all. The argument of not being able to quantify some aspects was properly mitigated by Douglas Hubbard, the author of “how to measure everything”. Together with a colleague from the University of Windsor, Canada, I studied the inaccuracy with hundreds of post calculations and found that e.g. 69% of the cost saving projects deliver more than 80% of the expected value. Accepting that there are inaccuracies in business cases the question is what is a better way to help rational colleagues to decide on which activity to work on? Donald Reinertsen asked colleagues working on the same project to estimate the financial impact of delivering their one day earlier. Reinertsen found differences of colleagues guestimating the impact of a factor 50 meaning that where one colleague would expect that speeding up the project would bring 1.000 Euros a day another would think it would be 50.000 Euros a day. So it turns out that the gutfeeling of participants on the value to be created can be far worse than a business case. So you can lie in business cases but you do not need to lie in business cases.

It was the actual creation of value that changed my mind

In praxis we have seen that discussing a business case after the project was finished was an impactful and easy instrument to generate value. The assets were already present and in several cases the discussion generated the insight that they were not yet used optimally. Better usage of available instruments generated value without any new investments. This was powerful in praxis but unfortunately I only saw this effect only after projects were finished and only for a few very enhanced organisations. I have been wrestling with the question ‘Can we not generate this effect during the project, especially when working agile?’. The answer is yes with, agile performance management we can link agile deliverables like tasks, user stories, features and epics to the organisational KPIs. So you link them directly to KPIs like average first call resolution at customer care, revenue from a new product, A&R efficiency and NPS.

How this works in praxis? Agile value streams and teams are assigned to improve a set of organisational KPIs and they can prioritise their work based on their experience and insights of the biggest impact starting from the already known current performance of those KPIs. And as these KPIS are already regularly measured the agile value streams and teams can monitor using the Uffective Boost Platform the impact on those KPIs of the improvements they implement. As normal sprints drop every second or third week new software the feedback cycle on their impact is in IT terms very fast and that enables unprecendented fast learning and efficient searching for the biggest improvement levers. So Agile Performance Management trumps business cases because of more impact and faster feedback and that for no additional cost as the KPIs are already available.

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment