How your ERP PMO can help you avoid... excessive Innovation Risk

This article is #3 in a series addressing the top 5 root causes of ERP cost and time overruns. You can find the overview of all 5 and links to the whole series here.

Let’s talk about getting better at managing ERP Innovation Risk!

The degree of innovation is the third biggest root cause factor in cost and time overruns. Whether we are talking about choosing a new bleeding edge ERP product, or about an organisation that is trying to bend an established product into new and "interesting" shapes, innovation means risks and risks do not always pan out.

Unfortunately, “Do Not Innovate!” is not a useful countermeasure. Indeed, modern ERPs market themselves as catalysts for innovation. Therefore, a better aim might be “how do we balance ERP innovation with risk?”

Here are five things we can do to arrive at an appropriate mix:

1. Break delivery into phases

If you can, consider breaking your ERP delivery into a cumulative set of individually less ambitious but collectively innovative phases. The innovation capabilities of modern ERPs are intended to be long-term. It might be wise to deliver a less innovative, less risky first iteration and build on it with more innovative features once it has bedded in.

Do not confuse this with the cynical “MVP, then run away” approach that some partners might have in mind! A well-considered iterative approach will deliver tranches of functionality and - hopefully - beneficial outcomes, with an upgraded interim solution in place after each successive tranche. It is important to validate that each interim state is sustainable in its own right - what would happen if funding disappeared after only 2 of an intended 3 phases are delivered?

Do also take into account that alongside an ERP solution you need to deliver the capability for ongoing innovation - "Digital Kaizen" - as part of your "to be" state. This continuous improvement approach can often support innovation better than the initial ERP roll-out itself. However, it requires different skills and processes. You will need to add the relevant talent acquisition and/or in-house skills development to your People delivery scope.

2. Consider pilots & foundational sprints

ERP programmes are expensive and disruptive. Businesses often insist on a commensurately high return on investment in terms of features and functionality. No business manager is capable of walking into a busy ERP programme office and not mentally counting up the resources that are NOT being spent on immediate business opportunities.

However, focusing only on business features can increase the riskiness of the project unhelpfully. It may feel like a focus on "bang per buck", but it brings a higher risk of failure - a plan where "every chicken has to lay an egg, and every egg has to hatch into a chicken".

Consider instead a more balanced approach with development iterations that include a mix of: User Stories to deliver business features per se; Enabler Stories to keep IT foundations up to spec and aligned with expected growth, speed and other non-functional requirements; and Exploration Stories or experiments to prove out the riskier or more speculative innovation scenarios in a controlled manner.

Consider running pilots before committing the whole business to an innovative solution that may still have a lot of residual risk. If you can afford it, the combination of paper-based conference room pilots, testable innovations in a Sandbox, system-based conference room pilots and Production pilots can greatly limit the final risk exposure of the operational business.

3. Pursue “fit to standard” where possible

Look for opportunities to reduce innovation risk by adopting a “fit to standard” approach unless there is a very good reason not to. Engage a good Solution Architect to ensure we're not overlooking more sustainable options.

• “I can demonstrate a clear market advantage” is a good reason, so long as the folks making the assertion bring their data along with them;
• “We’ve always done it this way” is not.

Develop a decision tree to nudge people away from customisations in the first place and put any proposed customisations through rigorous governance at both commercial and technology level.

• Commercial: treat the customisation as an investment in its own right - is this really a good use of money? Consider the ongoing support costs can balloon over just a few years
• Technology: even if the change makes commercial sense, is customisation the best available answer? (This is an area where solutions architects and enterprise architects can have a useful dialogue)

4. Beef up your uncertainty handling capabilities

As the degree of innovation increases, so does the amount of uncertainty. Set up a RAID log of these uncertainties – Risks, Assumptions, Issues and Dependencies. Help the team to understand why capturing, describing and managing them is important. RAID management is often considered "a thing that gets in the way of work" rather than "a thing that protects our work" and this can become a self-fulfilling prophecy.

• Risks: you will need to capture and describe them, size them using a standard rating, assign to an owner and develop actions that measurable reduce the likelihood and/or impact of the risk. Watch out for water-cooler conversations along the lines of "I can't believe we are still intending to use approach X" or "why on Earth are they still promising a March Go-Live?" These are conversations about risks, but there is often a blind spot in recognising them as such, or some nervousness that we are acknowledging the unacknowledgable, so they never come under risk management.
• Assumptions: you will need to capture and describe them, and as a minimum seek to validate them. But some assumptions need more work than a simple fact check. Watch out for assumptions built into contracts, assumptions about technology capabilities, and assumptions about user take-up.
• Issues: you will need to capture and describe them, size them using a standard rating, assign to an owner and develop actions to mitigate them, contain them, work around them and finally resolve them. Speed is of the essence and a root cause analysis is highly recommended.
• Dependencies: you will need to capture and describe them, and as a minimum seek to validate them with the "giving" and "receiving" projects or departments. Even well-managed dependencies can be disruptive. In that respect, a lot of internal cross-team dependencies may indicate an opportunity to revise your teams' make-up or topology.

A good Solution Architect will again be a useful addition here.

5. Adopt a robust Change Management approach

Change Management covers many things. My own "mental toolkit" considers Communication, Organisation Design, Job Design, Stakeholder Management, Training & Familiarisation and post-Go Live Support to embed and sustain the new ways of working. Two that are particularly useful in managing the degree of innovation are:

• Stakeholder Management: a lot of people will need to be kept in synch in an innovative ERP programme. Be clear on the difference between the few decision-makers and the many people whose advice, input and support you need. A well-structured set of stakeholder engagement and (separate) decision-making bodies at both steering and working levels will pay dividends on an innovative programme;
• Business readiness: I use this term to mean a combination of communication, training and practical support that ensures teams are “ready, willing and able” for the new ways of working. The best advice I can give here is to explain the "why" of the change, explain "what" is changing, then look people in the eye, ask them what they need in order to succeed, and give it to them. Just be aware that they will ask for it in their words; you will need to do the translation into whatever change framework makes sense for you and they won't thank you for a lecture on ADKAR or the Kubler-Ross curve. Those are your tools, not theirs.

Sources and Resources

Break delivery into phases: I like Managing Successful Programmes for its use of tranches to give something more usable to ERP programmes than the standard project/programme dichotomy. There is also a useful practice standard from the PMI as well as their heavyweight PgMP qualification. Highly-experienced ERP Programme Managers like Mark Askew or Mark Adams can add huge value in designing a coherent programme.

Pilots & foundational sprints: you will find guidance on balanced programme delivery in the SAFe framework as part of PI planning. It is also covered from a portfolio viewpoint in the very accessible Henny Portman book "Agile Portfolio Management"

Pursue “fit to standard” where possible: just about every ERP vendor repeats this message. Solution Architects like MATTHEW CULVER and Shaun Balding can help you manage the risk when you inevitably find that one thing that justifies an exception.

Beef up your uncertainty handling capabilities: classical risk and issues guidance is available from Management of Risk, the PMI Standard for Risk and (free!) the UK Government Orange Book. Henny Portman's book mentioned above includes the tip of using exploratory stories to test assumptions that cannot simply be validated by fact-checking.

Adopt a robust Change Management approach: I refer to APMG Change Management - PROSCI is an alternative - but this is one area where over-reliance on theory can hurt you a lot. Engage skilled advisers and practitioners like Lisa Forrest or Paul Lee-Maynard to beef up your internal change agent network.

#ERPPMO #UsefulPMO