After you’ve discovered your transition requirements, assessed the organization’s readiness, and addressed motivation and competency in your business analysis, you’re ready to choose the approach you want to use to roll out your strategy and actually implement the solution.
Note that this phase of the project includes the entire team; it’s not just you and the users of the new solution. You can choose from three different approaches: parallel processing, piloting, and single cutover.
If you’re dealing with a large project, your upfront strategy may be to create solutions in phases, in which case each one of the phases would be released in one of these manners.
Parallel processing as the business analysis strategy roll out plan
In parallel processing, users continue to use the current process and software while also using the new processes and software. Consider this approach a real-world test with a safety net provided by the current system.
Parallel processing works best when your project involves automating a manual process. You should use this approach for a set amount of time to verify that the new system is working as anticipated. Then you can compare the results of both and make sure the new automated solution is working as anticipated.
If an issue pops up with the new system, you have the results of the manual process as a backup.
Additional advantages of this approach include the following:
It provides an easy rollback strategy if the system doesn’t work as anticipated.
Any issues discovered with the new system don’t negatively impact the business because the old system is still being used.
However, parallel processing has its disadvantages:
Users have to use both systems, which adds time to operations. The additional time can be costly and reduce productivity.
The system administrators need to support both systems during the parallel processing.
You don’t have to use parallel processing with all users of the new solution; you can do it with a subset of the users. After the subset is satisfied with the new system, you can make full transition to the new system
Piloting as the business analysis strategy roll out plan
Piloting the solution means that you’re implementing the new solution for only a small group of people. For a period of time, they use the new system while others use the current system to evaluate whether the solution is working as anticipated.
If it does work as anticipated, the team can decide to roll it out to the rest of the community or pick another pilot group and continue until all groups are on the new solution.
You’ve most likely seen some examples of piloting, such as when restaurant chains offer a new menu item in certain stores to test interest from customers or when retail chains implement system updates in stores close to the home office to ensure they work as anticipated before they roll it out to all stores nationwide.
The pilot approach works best when a company is trying to roll out a new product, particularly when the team suspects that users will find the change difficult. The team can use a test market for the new product to determine what’s effective.
Advantages of this approach include the following:
It comes with a low risk for the initial run of the new product. Only a small group is impacted if issues arise.
Fewer users need training at one time.
Because the team is working with small groups, each group gets more attention, which helps stakeholders accept the change.
Here are some disadvantages of piloting:
The rollout takes longer than with other approaches, which keeps resources from working on other solutions.
The system administrators need to support both systems during the pilot phase(s).
Single cutover as the business analysis strategy roll out plan
Using the single cutover approach means that you stop the current process and go right to the new solution that’s replacing it. This method is like ripping off a bandage in one quick motion. Users are using the current system one day and the new system the next.
A single cutover approach works well for small enhancement projects. These projects usually don’t involve many changes, so the abrupt switch to the new system is fairly easy for the users to handle. In addition, this approach comes in handy for large initiatives where parallel processing is too difficult or costly, such as the transition of a customer relationship management system for a sales team.
Having a sales team manage the customer base in two systems may be too cumbersome, and it may even result in inaccurate data and poor customer service. In this scenario, sticking with single cutover (perhaps after piloting it on a small group first) is a better bet.
Often, this approach includes everyone on the team being ready as soon as the new system is turned on. Single cutovers usually occur during a slow time, such as in the middle of the night or weekends, to help minimize business disruption. We’ve been involved in many cutovers on Saturday or Sunday. Having coffee, donuts, and pizza helps (at least in terms of morale)!
The single cutover approach offers advantages such as the following:
It provides a clean transition for system administrators. They don’t have to support multiple systems.
The user community doesn’t have to work in multiple systems like it does in the parallel process approach.
Everyone cuts over at one time, so the project team doesn’t have to manage multiple rollouts as it does in the pilot approach.
Disadvantages of this approach include
Any problems with the solution mean a high risk of severe customer/business impact.
The business may experience a reduction in productivity during the learning curve for users.
Single cutover requires more planning and coordination of all resources impacted than other approaches do.