Ideas for an Agile Business Case

Posted by Alastair on November 11, 2016

We often talk about ‘agile’ in terms of technology delivery and many organisations set themselves the goal of becoming more agile in their customer and service delivery.  However, the business cases which are required for investment needed to achieve this are very often completed in a ‘waterfall’ manner. So often, I see clients having to develop a long-term business case for a technology implementation based on a 2-5 year payback, so they can ask for a large sum of cash when the benefits won’t be seen until well after the project has completed, or in lumps during the project.

This maybe made some sense in the old world where a licence was perpetual and purchased upfront (although we still see many instances where the ROI hasn’t come close to what the vendor sold).  The implementation itself then required considerable investment and the projects went live in a big bang approach 9-12 months afterwards. Today, particularly when investments are so heavily scrutinised, businesses need to think differently and start considering a more agile or iterative approach to making investment decisions.

With Cloud/SaaS solutions there is no large CAPEX requirement for the licences but there may be a requirement for implementation effort, although this should be considerably smaller with a cloud solution requiring less or zero customisation. Businesses often learn that it is cheaper to re-engineer processes to meet the technology, rather than the other way around.

This is the polar opposite to the mantra that I was brought up with. I always believed, and passed on to clients, that technology should not drive your business processes. Today, I see the processes that are available in many solutions as being far more mature, proven, sophisticated and optimised, meaning that it makes sense to match processes to technology in many cases.

Configuring those processes iteratively and deploying them into the business in waves allows you to become familiar with the toolsets and the possibilities for improvement over time.  Trying to define every last little requirement before the tool is fully understood leads to long, complex, costly and ultimately disappointing projects.  I now believe the opposite works better, take a simple starting point, reap benefits early and evolve into something more sophisticated.

So, if upfront costs are much reduced in this model, why are so many companies still attempting to justify the whole project from day 1 through a long and complex business case?  Instead, why not implement a simple solution and get the benefits to start rolling early to pay for more sophistication later?

In this way, you consider business cases with a truly agile mindset. In my mind, looking at the transformation in this way not only speeds up the business case process, but most importantly, helps manage the implications of business change, building credibility and buy-in very, very quickly.