Why phasing is essential for ERP backbone projects

máj. 18, 2016
When you migrate to a new ERP backbone software system for your business, you don’t want a simple replacement. Instead, aim for long-term benefits that are in line with your strategic goals. This makes the presale phase especially challenging: normal features are expected to work, and candidate suppliers are compared based on long-term expectations. The danger, however, is that certain ‘special features’ will be immediately taken over into the implementation phase — hence the importance of phasing when undertaking any ERP backbone project. But how do you know which features that you, as a decision maker, should take into phase 1 of the implementation? And when should your (first) go-live take place?

The classic project phases are preparation, blueprint, realization, preparation go-live and go-live. Typically, details about the software system are not yet clear during the blueprint phase. One of the risks of this approach is that the high-level long-term expectations are repeated again during the different blueprint meetings, resulting in a huge blueprint.

System-guided blueprint

That’s why, as part of the Delaware Consulting Fast Approach, we introduced a “system-guided blueprint” phase. Basic flows are already shown during the blueprint phase itself. This approach reduces the risk of having a high-expectation blueprint before the realization phase and makes the blueprint more concrete and agile. In smaller projects, the blueprint phase can be reduced to almost nothing and only consists of some very small sessions for critical topics.

A “car” for everyone

Software suppliers as well as customers often compare ERP backbone software features to car options. The first refer to it if the customer wants an additional, unexpected feature that is not within the scope of the project. The latter uses the comparison to make it clear that the car should drive well in the first place.

I think that it’s a lot more difficult to compare the product “ERP backbone software delivery” to a car. It begins with the fact that the “car” can mean different things to different people within the company. The car could drive well for sales and finance people but be a hindrance for the production department, for example. In fact, you should deliver a multi-purpose car that satisfies everybody in the end. From my personal perspective, that’s the difference between an ERP backbone software implementation (delivery), and a well-defined single product.

Defining the MVP

Concepts like Minimum Viable Product (MVP) and Minimum Marketable Product (MMP) are familiar. Two things are important here. First of all, with each of the car drivers (business owners responsible for a particular domain), it’s indeed a good idea to define the MVP together in order to respect the lead-time of the project (go-live phase 1). Secondly, we cannot stress enough that the business owners should be involved intensively during the development of this definition. A software supplier could never define this alone! And minimum does mean “in as short a lead time as possible”, not necessarily “minimum functionality” in ALL areas.

Why an ERP backbone project is (not) like a car

One thing is certain: if the go-live risk is mitigated by reduced scope and through truly necessary but thorough testing before go-live, the best extensive testing will automatically happen when people are forced to go live with the product. In that sense, the learning after go-live could contain crucial information about what optimizations to take on first.

But even if I totally agree with the general approach above, I would like to make some remarks to illustrate why the car analogy falls short:

  • Sticking to a minimum lead-time while keeping enough features has its limitations. As minimum does not mean minimum functionality for all areas, strategic areas like sales and finance will typically be given priority over internal domains like warehousing or production. This can cause business owners in those latter areas to be dissatisfied with the “multi-purpose car”, as it will not fit their specific needs.
  • Some features can’t be defined; for example, “user-friendly screens with a limited number of clicks necessary”. Even if you defined what you need in advance, there can be discussion or confusion about the final result, which is only apparent at the end. It’s simply impossible to define everything up front down to the smallest detail.
  • In an effort to sell the project, all the possibilities of the ERP will already be mentioned in the presales phase. It’s human to keep comparing this with the result of phase 1. After all, the car with all the next-level options that you had your eye on wasn’t yet brought to market before you bought it. That’s why it’s important in this phase, to manage expectations – Rome wasn’t built in a day, and neither will the ERP backbone of your dreams.
  • You will always compare the result of phase 1 with the overall result (all phases) of the legacy system currently in place. As mentioned before, it’s not that easy to accept that, in phase 1, only part of the expectations are fulfilled. It’s normal to fear the postponing of phases that follow.

All of this is to show why I’m absolutely pro phasing in projects. I truly believe that, through phasing, it’s feasible — and beneficial — to keep lead time before going live with the first version surprisingly (and reasonably) short.

Author: Wouter Dessein
. You can follow Wouter Dessein on Twitter (@DesseinWouter) or connect with him on LinkedIn