Houston Neil, of Manufacturing Software Advice, just wrote a nice article about different ERP implementation approaches. He did an informal study with 45 participants and came up with some interesting summaries. The three primary implementation strategies are:
- Big Bang: cutover all at once from the legacy system
- Phased: cutover areas over the system a portion of the time
- Parallel: Process in both systems at the same time until comfortable
His findings show that few, if any, organizations parallel process.
I generally start with a Phased approach when the project’s scope and complexity are high. If the project is small enough, I go with the Big Bang approach.
Several years ago, I led an implementation for a major Talent Agency where we planned a Big Bang approach. We built a custom trust accounting application that plugged into Microsoft Dynamics NAV. We were going with native Accounts Payable and General Ledger features. The risk was in the software stability of our new application and the data migration. Big Bang made sense because we were going to retire the “Tiny Term” legacy system before the client’s contract renewal term came due at the end of the year. Right after we started the implementation, our key sponsor and project champion left the agency, and we were forced to start working with a new CFO.
The new CFO was reasonably nervous. He was new in the position, had not had the opportunity to develop a relationship with me and my team, and had never gone through a new financial system implementation. He was very concerned that the new system was not going to work and that he would end up having a significant issue processing disbursements to his high-profile celebrity clients. That would be a major failure under his leadership. I was calm because I had done so many implementations; I understood where the risks were, and I knew how to manage them. The CFO wanted an “insurance option” in our contract to ensure costs would not get out of control if the software did not deliver on our promise.
The CFO wanted to go Parallel. Naturally, I did not challenge him on this, but I did advise him about his organization’s extra costs and demands. Most people who are risk-averse conceptually like the parallel option as it eases their mind that they can abandon the strategy should it not work. I offered that before we start the parallel processing phase of the project, we should perform good data conversion tests, ensure the team is well-trained and perform an Acceptance Test. We proceeded with that plan and had approximately 4 weeks of parallel processing in the mix.
What is great about working with a CFO is their concern for ROI. As we were in the implementation and performing our Acceptance Test, he began get comfortable that the system functioned as promised. Instead of using the 4 weeks for parallel processing, he used that time to perform more training and planning for the cut-over. He basically picked Big-Bang but he never knew nor admitted it. He elected to not exercise his insurance option. This was a good decision on his part.
In almost all cases, the cost of parallel processing is simply too great to get a return. It’s logistically difficult to pull it off — and invariably, you run into exceptions that must be reconciled, driving up costs. In my mind, the question gets down to weighing the cost of uncovering issues before cutting over versus the costs of discovering and dealing with them in the heat of the cut-over. I think the concerns about breaking customer trust if we experience system failures should be factored into the decision-making. Many times, customers are shielded from the back-office operation, so this is usually not a heavy factor. After 20-plus years doing this kind of work, I have witnessed and admired clients who “go for it” by going live with basic testing and training and who are committed to handling issues as they come up. This approach generally keeps costs down, forcing real concerns to come forth that need attention. Recently, I heard another client discuss the desire to go Parallel. I kept quiet, staying sensitive to his concerns but speculating that it was “all talk.”
If you found this article relevant, feel free to sign up for notifications to new articles as I post them. If you would like to discuss your GoLive implementation options, let’s have a conversation.
2 thoughts on “All-Talk: Parallel Processing before Going Live!”