How finance leaders can deliver successful change projects

Major solution change projects, as typified by the classic ERP programme that most CFOs will be expected to sponsor at some point, have the potential to be career defining moments.

Tales of major change projects that got out of hand, and significantly impacted the recipient  organisation, are hardly rare, but a good deal more are never made public, for obvious reasons. Unsuccessfully delivered ERP solutions remain a major threat to unwary organisations, but the good news is that the application of a few key principles can minimise the unavoidable risks in making major changes to enterprise management solutions.

The most important principle is that of putting the project on the right footing in that golden period, the first 90 days after inception. As with much else in modern business, it is vital that ERP projects be established with everything required – resources in particular – in place from the start.

Don’t believe consultancies who try to tell you that the project can be constructed ‘in flight’ as a means of reducing the size of their quotation – structuring and resourcing the project to minimise risk may appear more expensive than the alternative, but ‘cheap’ ERP projects tend in reality to be hugely more expensive in terms of capital, reputation and business outcomes than planning for success. So, what are the big rules for a lower risk ERP project?

Buy-in from the top

First things first. If you don’t have a clear line of committed sponsorship to the very top of the business, you might want to ask yourself whether the project is viable. CEOs and GMs who trust their CFOs, and who will leave the field clear for you to sponsor your project with their authority, are sometimes good enough, but there’s no message to beat the most senior person in the organisation looking the board in the eye and demanding their commitment.

And to make that stick, insist that everyone involved – including all C level participants – have part of their incentive packages directly linked to your measures of success (we’ll get to those later). Why? Because senior managers put their main focus on what pays their bonus, and all senior managers must be totally committed to project success.

The first and most important manifestation of that sponsorship has to be the quality of the people who are diverted to work on the project on a full time basis – part-time membership being a major risk that needs to be prevented at all costs, because it hardly ever works. The people you need – full time, for the length of the project –  are the future generation of leaders, ideally with at least ten years’ experience in your own or a related organisation.

Why? Because the people you put into process defining roles will design a solution that the business has to use for the next ten years. If you want a poor quality solution, put anyone but your best and brightest into these positions. Tell them it’s a career move of the highest quality (and mean it), and that it will give them unparalled business vision in their understanding of the enterprise. In return, they will deliver a solution you can trust at go-live, and an organisation that is more inclined to accept it through their referent leadership.

With the right people in place, the next thing you need is a methodology – a recipe for success that details every component of the ERP delivery and applies quality standards by both deliverable and project phase, with formal stage approval gates.

Why? Because the plan that the project will follow depends on that level of detail to call out dependencies, and because without some measure of quality achieved you won’t know if you’re building each successive level of the project on rock or sand. Or at least not until it’s too late, and costs start to multiply.

It will also provide project and business with a mutual language in which to discuss progress, risks and issues, and make the major governance decisions. If a potential  implementation partner can’t show you a quality assured method that operates to commonly accepted PRINCE2 guidelines, they’re not the right people to guide you through the risks involved in this major undertaking.

Speaking of governance, there’s a fine balance to be achieved in terms of the frequency and formality of your steering activities. This is the factor that will make or break a programme more efficiently than almost any other factor.

Why? Because too little governance will result in a project that is distant from the main sponsor, and risks a poorly integrated team working in silos. Whereas too much will stifle activity and decision making, and reduce programme management to ‘reporting for a decision’ – which will effectively make the sponsor the programme manager. Insist on strong governance, with the right C level participants (anyone whose business will be impacted) all demonstrating their commitment while allowing their chosen business team members to run the project.

And while we’re discussing project management, there’s a major risk in waiting for the sponsor who tries to treat an ERP project like part of the business. Why? Because while successful organisations tend to thrive on pragmatism and compromise, successful projects require formality and the avoidance of compromise. Insist on a strict routine centred around the project meeting cycle, discussing plan progress, risks, issues and actions in language that the governance audience can understand and use to inform major decisions. And be clear with your steering committee colleagues that fudge isn’t usually a successful flavour come go-live time.

Critically, you’ll also need your senior colleagues to help control project scope. ‘Vanilla’ solutions (changing as little as possible in the out of the box solution you almost certainly purchased) are very much the way to go, especially as cloud services mean that upgrades now arrive on a monthly, not a yearly basis.

Why? Because allowing the project team to change the solution to look like your current process – even just changing field names to be familiar – is a recipe for support expense that will continue to cost long after the project has been closed. The fundamental question to ask is ‘what do we lose if we don’t make that change?’ If the answer is ‘nothing, but we’ll have to manage the resulting process change’ you just asked the right question.

Understanding change

Speaking of which, change management is one of the two great ‘invisible’ causes of project failure. It’s not about communications – although they are important – it’s about being assiduous from the earliest days of the project in making clear to the business how their jobs will change after go-live. Understand change impacts and then communicate continuously to the people who will be most impacted by them, inside and outside the organisation.

Why? Because the attitude that ‘they’ll work it out for themselves’ just won’t cut it given the potential risks posed by a disaffected workforce operating a process they don’t understand or even care about. And make sure that a full suite of business performance KPIs is in place and understood before go-live, so that you can gauge where the solution issues are quickly, and without ambiguity, after go-live. It’ll be a great measure of whether the project succeeded (remember those incentive bonuses), and you’ll avoid the risk of only finding out – for example – that your accounts payable process doesn’t work when suppliers cut you off for non-payment.

There’s another invisible source of project failure, data. This is often the most overlooked item in ERP projects, and yet it’s one of the most fundamental aspects. Why? Because systems which operate perfectly at go-live often appear to be ‘degrading’ in the weeks and months that follow, and the usual diagnosis in this situation is that the data they use – think of it as being akin to engine oil – is either missing or has been allowed to become corrupted, or was never even cleansed in the first place.

Be clear with your governance colleagues that the data belongs to them, not to the project, and help them to ensure that their teams play their part in making their data ready for use by the new solution. Critically, ensure that they put the right roles and responsibilities in place to govern it, and keep it clean and fit for purpose in the longer term.

Follow these simple rules – all of them, it’s a recipe, not a buffet – and you’re more than likely to weather the inevitable ups and downs of major projects. And consider these parting words of advice. Firstly, buy the best possible project manager – it’s the fundamental role in the project, and a person you will lean on harder than you could ever predict.

He or she might cost more than you really want to pay, but, when you consider how much choosing the wrong person might cost in costly delays and business performance issues, it’s easy to see that saving money on this key role is the ultimate false economy.

And if you want to know whether you’re really winning or not, find an assurance partner who’s been there, and done that, to take an unbiased view and point out the bits you’ve missed. It might just end up saving you more than just money.

Comments are closed.