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