This was in the context of trying to sell a new software solution for risk management, but I think there are suggestions in here that apply more broadly.
Inevitably, every business fad (or should that be FAD?) is boiled into a TLA. Unless you want to look really serious (4 letters) or so serious as to be military (multi-letter concatenations sometimes with numbers in them).
A classic was Enterprise Resource Planning. In the sixties we started trying to coordinate manufacturing to reduce waste and maximise capital asset utilisation. We called this MRP, then MRPII (nowadays of course we would write MRP 2.0). And eventually this became Enterprise Resource Planning.
The theory was that we could move to finely coordinated processes that demanded precisely the correct inputs for a given output. And all you had to do was buy some software. SAP were very good at convincing large organisations that they could make huge gains by following the extremely logical processes offered.
In my current field the equivalent is GRC: Governance, Risk & Compliance. As with ERP, the theory is solid: having a surveillance and workflow layer sitting above the operational business means firms can get an overview of their risk. The challenge is how to deploy in a way that will actually drive some value.
I’ve rolled out SAP a couple of times. In the nineties the NZ Apple & Pear Board (now known as ENZA) paid about NZ$30 million for the deployment of SAP and some ancillary systems (such as a Jade warehouse management solution). The programme was managed by Deloitte*. I think the technical term for the result might be ‘sub-optimal’.
I joined the new Executive team charged with taking the business through deregulation. As a newly minted CIO, after a few months I surprised many people (including myself) by deciding to re-implement SAP (and drop a bunch of ancillary solutions).
So I started reading, and found some common themes of successful deployments:
-
They did it to themselves. By which I mean firms used their own people to run the deployment (with some supporting technical expertise). In some instances, they seconded their staff out in advance of the project, then brought them back.
-
Consulting firms were in the background, not as a prime supplier. And the vendor was not involved to any significant extent. This avoids conflict: a vendor on a governance committee is naturally going to defend their product, a consulting firm will look for growth.
-
They got on with it, with project teams sitting alongside the people who do the real work understanding precisely what the new world will look like.
This resonated with me. I believe the person who leads the project must have a very clear loyalty to the sponsor: I like hiring people directly into projects (even if it takes a bit of time). The analysis and specification is ideally by employees, not contractors.
In my case the reporting was very clear. I had the best PM I know, and was able to spend my time as sponsor working making sure the critical stakeholders were comfortable. Frankly this project kind of ruined me for all the subsequent ones, because it went so well. I’m not saying we didn’t have a few exciting moments, (and I hurt the feelings of a couple of vendors).
But we redeployed for about 10% of the original cost, and that included a bit more licence (to cover the stuff decommissioned). If you look at the accounts from that period, you can see that the opex more than halved in the subsequent year (a six month payback on the project).
But most importantly the people who used it on a day to day basis were happy.