How to manage return on technology spend – a layman's guide

MyCustomer.com
2

Much of the cut and thrust debates about poor returns from CRM projects, have been levelled at technology implementations – in particular massive spend on Contact Management Systems and Data Warehouses – and their failure to deliver. One of the most intractable problems in demonstrating effective business cases for technology spending has been the tendency of large implementations to be so long delayed that the original rationale for their existence has long since vanished (or been conveniently forgotten). Yet, if the role of technology is to enable a stream of business benefits over time, it should be susceptible to an ROI calculation which reflects delay and changing plans. This should be especially relevant for CRM, where both delay and change are so much in evidence.

In case my regular readers think I have finally lost my marbles, and such an application for ROI disciplines is totally impractical, I can re-assure them that I have made this approach work for very large technology spends in a very large organisation – British Gas, a major UK utility – whilst I was still a partner at McKinsey.

BG had an urgent need to solve a complex problem in the technology architecture which enabled their front line processes. Divisionalisation of the business had lead to 12 separate regions, 12 separate massive IT systems, and 12 sets of processes. Changes in the industry competitive environment made process reengineering a must, but doing it once would be hard enough – doing it 12 times would be impossible. We therefore had to evaluate, which of the 12 existing architectures to standardise on, or whether it was worth throwing them all away and starting again. The time dimension was critical to the business case, as changing such massive amounts of technology had to be a multi-year process, and the industry regulator was huffing and puffing about "re-structuring", if BG did not get their act together.

The problem for the joint BG/McKinsey team I lead was that each of the twelve existing architectures were being defended to the death by their own IT support group, plus there was a 150 man team building everything from scratch, who knew they were right. The approach we came up with to decide on the best solution and silence the warring factions was based around ROI. Every architecture was evaluated against the stream of reengineering benefits that were delivered at a specific cost over time. To estimate the cost of process change, we (credit here to Nick Brown, my McKinsey collaborator) developed a technique we called "Decision Engineering". This technique estimated the impact of a process change, then related it to the new types of decisions to be made in the process itself, and the data needed to support them. Decisions and data could then be related to the time and cost of their delivery by any one of our 13 IT architectural contenders. Decision Engineering gave us a tool to quickly map benefits against IT functionality over time - even better it provided a way of assessing the impact of any delays and re-prioritising IT delivery against best ROI.

My apologies for spending so long on this case, but it has only recently occurred to me that if we are to get run-away IT spending on CRM under control, we need a similar ROI based discipline to the one developed with BG. Experimenting with this thought, I identified the challenge as understanding both the likely stream of CRM process changes enabled by new technology, then the type of IT architectural migration which would support them. The process change area is fairly clear. I have been over the types of ROI opportunities driven by CRM in several recent Newsletters, and my experience grows daily due to participation in a fascinating research project carried out by MIT and sponsored by HP/Compaq. The architectural migration is a bigger headache. Holy wars about best solutions rage with a fierceness that even dwarfs the battles at BG, and the stakes are high for the vendor and consultancy community who have pinned their future to one option or the other.

The wrong technology migration path has the potential to not only create no value, but suffocate a corporation’s customer moves with inflexibility. We must have a permanent mechanism to plan and re-plan how to avoid such traps, by closely linking revenue from process reengineering to the technology which enables it. We must also have a flexible IT architecture that can react to new opportunities, without marooning us up blind alleys. Ian and my contention is that we now know enough about CRM, its process enablers and its technology, to manage the optimal path for both using ROI.

From my perspective, my old lessons so hardly gained at British Gas are more relevant than ever. Maybe, I should even dust off the "Decision Engineering Guide", Nick and I wrote then but never published. As they say " a good idea will always have its day".

Richard Heygate and Ian Woods

A fuller version of this article is available in the Library.

Share this content

Replies

Please login or register to join the discussion.

avatar
21st Jun 2003 13:06

A great article.

My personal interest is specifically backed up by the fact that a couple of years ago when faced a task to help a retail chain choose the technology architecture we also have to resort to analysing ROI of the proposed solutions. My grief now is that there is nothing new in the world, but I am glad that we are moving in right direction.

One thing that was significantly different from the described in article that the key point of our analysis was business and technical risk analysis for tha candidate architectures.

Thanks (0)
avatar
21st Jun 2003 13:06

A great article.

My personal interest is specifically backed up by the fact that a couple of years ago when faced a task to help a retail chain choose the technology architecture we also have to resort to analysing ROI of the proposed solutions. My grief now is that there is nothing new in the world, but I am glad that we are moving in right direction.

One thing that was significantly different from the described in article that the key point of our analysis was business and technical risk analysis for tha candidate architectures.

Thanks (0)