Brace Yourself for the Shared Services Pit of Despair

{{article.creator.firstname}} {{article.creator.lastname}}
Editor Coda
Jul 23, 2013

When rolling out a new technology, most organizations follow the same process: you figure out your requirements, go through an RFP process, you see the glitzy case studies, a new system is chosen, and you prepare to go live with the project. You are as prepared as possible.

So why so often do companies see an almost instant dip in performance?

Earlier this month, at sharedserviceslink.com’s Accounts Payable Tech and e-Invoicing Summit, Phil Price gave an insightful presentation on the best practices for implementation projects to succeed. As the current Head of Finance Transformation and the former CFO of Readers Digest Europe, he is well placed to give advice.

A key takeaway from his session, I thought, was that the J-curve (a.k.a. “the pit of despair”) is an almost unavoidable, totally normal, and even, possibly, a necessary part of any change project:

J Curve

As you can see from the above graph, Phase 1 represents the situation under the old system: not optimal, but a steady state. Phase 3 represents where you’d like to get to, and Phase 2 shows how you get there. Clearly, there is a huge discrepancy between expectations and what actually does happen.

But why is there such a pronounced J-curve? And what can be done to mitigate it?

According to Phil, the secret is in the preparation for the project. “Too often an implementation team is created only to be abandoned at go-live”, he explained. After go-live, the business thinks the project is done and dusted, when suddenly members of staff find that they’ve forgotten the training and the new system and process doesn’t look anything like they expected it to. This leads to a backlog of unprocessed transactions and results in a distraction which adversely affects the business.

The best way to prepare for go-live and therefore avoid such sticky situations, beyond thoroughly researching requirements and current processes, is to have clear ownership and strong leadership from the very start. Supported by full training, this will improve discipline, encourage standardisation and ensure engagement. “The success of projects like this hinge on user involvement”, said Phil.

“The fun starts at go-live. This is when you need to be all over the project, make sure that you are getting real time feedback on how it’s working, expect surprises along the way, and have a SWAT team on standby”, he continued.

From listening to the delegate feedback from Phil’s session, it sounded as though it was rare for any change project to not have even a slight dip after go-live. It also should be noted, however, that this is no bad thing. The earlier you spot the flaws after go live, the earlier and quicker you can resolve them.

This essentially adds up to a more intense version of the continuous improvement tracks most of us are on. By using KPIs you can spot the areas that need attention, and also at this early stage you can determine whether they are bedding-in issues or design flaws.

“Don’t cut corners at the front end of the project, because it will be much more expensive down the line to resolve any problems”, warned Phil. “It will also make building on the platform much easier in the future”.

To read this article you have to be registered.

Become a member to access all content and / or download it

We value your privacy

We use cookies to enhance your browsing experience and analyze our traffic. By clicking 'Accept All' you consent to our use of cookies.