National Grid case – business transformation has its merit

We have now again a case with a troubled project that finally landed in the court. In this particular case we can access public audit report with almost 300 pages evaluated by a business consultancy NorthStar Consulting Group. They are apparently not experts of IT projects, so it is about business and governance on customer’s side. Nevertheless, it nails many weaknesses around the project and brings up the main cause of the failure which is clearly:

instead transforming business to leverage new opportunities given by newest IT technology they recreated the obsolete legacy scenario.

Let me give you some quotes from the report showing it. They started quite bold with an aim to transform from old patchwork:

“These failures of internal controls led to the formation of a project team to address the gaps. It was believed that the problems arose from the fragile “patchwork” of disparate applications since the acquisition of KeySpan in August 2007.40 These included Oracle and PeopleSoft, Hyperion Planning and associated legacy planning, budgeting and allocation systems and the legacy fixed asset system PowerPlan (two instances). The USFP to implement SAP as a single financial system for all of National Grid was expected to resolve many of the internal control problems.”

but in vain as:

 “National Grid initiated the USFP and SAP go-live before solving existing significant deficiencies and material weaknesses, and did not address these in the USFP design plans.”

“National Grid’s design had a total of 636 RICEFWs. As Exhibit IV-5 illustrates, this was a large number for even a large power utility.”

“National Grid also addressed these control weaknesses by establishing FEPO in 2011. While this effort made some progress, it was ended prematurely in 2012, due to the implementation of and then the effort required to stabilize SAP.41 The conversion to SAP has not resolved the significant deficiencies and material weaknesses. The conversion to SAP has increased the internal control problems. There are several reasons for this including: assignment of staff and contractors to several areas in an effort to stabilize SAP and produce timely reports, rather than decreasing the number of accounts that must be reconciled when National Grid was operating two different systems. SAP has in fact increased the number of accounts that require reconciliation.”

“Even after SAP implementation, National Grid’s approach to management reporting relies heavily on complex Excel spreadsheets, an approach that is both labor-intensive and more subject to errors.”

We can see clearly here that after initially there was the intention to transform to new better solution they eventually have got mired in recreation of the old legacy solution.

Let me here use an example where this way was fortunately identified and in consequence the decision has been taken to get back to design desk – Lufthansa management admitted courageously about their project https://www.computerweekly.com/news/252438183/Lufthansa-goes-back-to-the-drawing-board-with-HR-IT-project:

“Instead of just thinking in a digital way, and thinking about software as a service, we wanted Employee Central to copy our existing HR system. We realised that was not going to happen”

The scope of the project is in this example different but that is exactly the same case here: instead of going a way to get a new solution bringing a lot of self-reconciliation, automation and integration what makes the work easier, they went and still maintain a wrong solution that indeed recreates all the legacy systems on the new SAP platform.

This kind of recreation of legacy within new technology does not only cost more (not only by all the RICEFW’s) but also works worse and needs much more labor and audience as causing many discrepancies, demands a lot of hard work to create workarounds (like mentioned above Excel spreadsheets) and patches. Reconstruction of an old semi-integrated solution within new platform is always a bad way and must be labeled as ”dirty” because leads to more complex business landscape thus bringing demand for higher labor to maintain and keep it alive.

The only one good solution is to get back and redesign (like in mentioned Lufthansa case) – without redesign they are doomed to still firefight at many places. This redesign may not necessary be disruptive – bet that majority of needed redesign can be done in a continuous way.

So, if you ever hear that after any SAP implementation they needed more people to make much more mechanical work and there were continues flows of issues at every piece of the business it would mean it was this kind of implementation: not any transformation just only reconstruction of the old one bringing more reconciliation, pain, uncertainty and costs…

And here we come to the fundamental question around Organizational Change Management – what is better:

• to face OCM with a bit of pain and issues during the project and then after it access all the benefits?

• or opposite try to simply follow “as is” state for the sake of “policy of smiles” during the project but then face all the troubles and realize that all this effort was in vain?

Of course, there were many other weaknesses on this project but the above is in my opinion a root cause making that this solution would never work properly and bringing up the benefits expected, even if all the remaining errors were fixed and all the people trained.