This project was a software implementation for two divisions of a listed company. They needed to replace their current ERP (Enterprise Resource Planning) system, as the current version was no longer going to be supported by the service provider. So why not upgrade to a newer version? The IT team had made so many modifications to the source code, that an upgrade would be the equivalent to implementing the software from scratch.
How can I say the project was a success?
The reason this project was a success, is that the entire process – from selecting the new ERP system solution to the successful go-live – took 18 months. The project came in within budget, mostly. It was, however, not a perfect implementation.
So how was success achieved?
Let’s start at the beginning
Success was achieved by following a very methodical approach. The first step was to pick the best-fit solution for the business. This was done by reviewing available ERP solutions. This in-depth investigation included looking at the costs, not only to implement, but also to maintain each option. Of course, the benefits were also identified, and other businesses who had implemented the various ERP systems were interviewed about their implementation and user experience.
The key to success in this phase was that this process was not limited to a couple of IT and finance staff. Each employee was aware of the process, the reason for the project, and could contribute towards the decision. The business understood that, in this case, all employees were stakeholders and, as such, were involved from the beginning.
Proper governance
The project was governed by the CIO and managing directors of both divisions, in addition to the steering committee established by the holding company. Together they hired an external Project Manager, who was working directly for the holding company, giving her both independence and authority. Her first act of business was to put all other projects on hold. For more on why this was important, see this article.
She also ensured that there were weekly feedback sessions with the cross-functional teams, as well as weekly meetings to discuss risks, issues, and concerns. She also held monthly sessions with the steering committee, so they were well aware of progress and any potential stumbling blocks. She chaired each and every one of these sessions and made sure no time was wasted – here is more on how she hosted good project meetings.
The devil is in the details
With the appointment of the project manager, the detailed project planning could start. Due to the nature of the rollout, a big bang approach was needed. This article spells out why. Next, the project streams were established. Instead of these being structured around business departments, such as manufacturing, finance, or IT, the streams where based on functional processes. Thus, we had teams like “Forecast to Supply” and “Procure to Pay” etc.
Each of these streams consisted of at least the following members:
- An executive responsible for the process
- A business analyst
- A senior ERP system consultant, who was a subject matter expert in that stream
- An internal IT staff member, who would become the super user and first line of support
- Team members from within the business, who were identified as champions and change drivers
Stepping carefully
The required outputs for each stream were the same:
- Detailed processes
- Interfaces to other systems
- User specifications
- Functional specifications
- Test scripts
Each output was documented. The documents were reviewed both within the stream, and by the other streams, and then finally reviewed and signed off by the broader business.
The secret sauce
While all of the above factors definitely contributed, there were three things that really ensured the success of the project.
The first was ensuring that only good quality master data was uploaded into the new ERP system. This included exporting the current master data from the old ERP system, cleaning it up, and migrating it to the new system. This article explains the importance of having good master data.
The second has been alluded to a couple of times already: documenting everything. The final ingredient was testing. Test scenarios were created for each process and, in some cases, for each step. The test scenarios included expected results and, if the test was failed, the changes were retested.
Lessons learnt
As mentioned in the beginning, this project was a success, but it was not perfect. Two important lessons have stuck with me:
- Print out training materials. While there was detailed, in-depth training held for each person at every site, people like to have a paper manual, so that they can make notes during their training.
- The Business Intelligence tool was not successfully implemented. This was most likely because this was a brand new tool, which had not yet been rolled out anywhere in the world. So I have learned to be wary of shiny new objects.