What’s Gone Wrong with CIPS Systems? Part 2 – Advice to Help Avoid Similar Issues!

In part 1 of this discussion, we talked about the issues CIPS (the Chartered Institute of Procurement and Supply) has faced in implementing its new systems. Moving away from the CIPS specifics now, here are some lessons related to this field, based on both personal experience and wider research.

1. Nothing wrong with Oracle software, but small clients (and CIPS are small in the greater scheme of things for a firm like Oracle) sometimes struggle to get the attention that a Unilever, Barclays or Toyota might receive as customers of any software giant. In many sectors, including procurement software (which is not what CIPS has bought, I should say), I’ve always felt there is a lot to be said for smaller organisations choosing smaller suppliers.  
2. Optimism bias is often an issue too. Suppliers are almost always likely to tell you that “yes, our product can do this” and “yes, it can be up and running in six months, no problem”. They might not be lying – but they omit to mention the conditionality. “Yes our product can do this as long as the data is in this format…” Or “yes, six months is feasible – as long as a, b, c, and d all apply…”  
3. My understanding is that CIPS went for the “big bang” approach with the Oracle software. An alternative might have been to look at different aspects of the requirement – the student and exam booking element, core membership management, conferences and events, etc – and perhaps gone for a staged approach, with a more “best of breed with good inter-operability” approach to the software products chosen too. Whilst this might have looked somewhat more expensive and less rapid in theory, incremental approaches do tend to de-risk programmes like this.  
4. The US example in Bad Buying mentioned in part 1 was undoubtedly made more complex by the involvement of several parties. I do understand why Oracle “don’t do implementation”, but immediately you have potential for dilution of responsibility when another party or parties are involved. Most senior buy-side people tell me they would always prefer “one backside to kick”, if you pardon the language. It’s not always possible, but having real clarity about who is responsible and accountable for what on the vendor side is vital. That’s true not just in technology, I should say, but in many other areas including construction, outsourcing projects, etc.  
5. The Enigen statement (see part 1) is interesting in its mention of “evolving and additional requirements”. The very first chapter of Bad Buying is all about getting the specifications right. It’s the first chapter because it is the most fundamental cause of failure – if you get the spec wrong, nothing else matters. For complex technology projects, and that includes something like the Army’s disastrous Ajax armoured car programme as well as digital tech, changing specifications once work is underway will almost always cause problems. In terms of a software project, a client that starts saying, “oh, could we have that functionality as well please, sorry, forgot to mention it earlier…” is asking for trouble. Suppliers like to say “yes” of course, but not only can it lead to delays, it muddies the water in terms of accountability.  
6. Software implementation that involves a systems transition – rather than a totally new system / functionality – is often difficult because problems with (for instance) transferring data don’t always come to light until you’re well into the project. It is easy to say that thorough due diligence before choosing a supplier or starting the programme is the answer, and of course that is important. But sometimes issues do emerge from the woodwork (or from the silicon, we should say) only once you are actually pressing that “go live” button!  is It is often a sensible move to look at cleansing data, perhaps using a real specialist in this area, as part of the pre-contract award market engagement process and planning.  
7. On the client side, effective programme management is absolutely key. One would hope CIPS recognised that, but there might be questions now about factors such as the programme manager, governance, reporting, stakeholder and risk management. Now you can have a brilliant programme manager and still end up with a failed programme, but I’d hope the CIPS Board would be insisting on a detailed review of what has happened (if they haven’t done that already).  
8. Expanding on that point, clients MUST understand they are reputationally, contractually and commercially on the hook for leading the implementation. You can’t just hand this off to software providers, SIs (systems integrators) or consultants. Programmes must have the right level of senior people involved and fully engaged from programme inception, and involved in governance of the project throughout. A lack of appropriate senior input is the root cause of many implementation disasters – leaders must ensure early decisions are made and do not get missed. Small issues can fester into multi-million pound disputes  requiring un-picking, and causing cost, delays and disruption.  

In November 2021, CIPS net assets (excluding the defined benefit pension fund notional surplus) were about £6 million. The accounts up to November 2022 should be out in the next couple of months – it will be interesting to see if the systems issues have visibly affected the financial position. For the sake of next year’s membership fee inflation, I hope not!