Cutover Planning is Essential

In this blog post, I will be discussing what I believe to be one of the most important aspects of an ERP implementation project. However, for some reason, this subject does not seem to get the attention and careful planning in deserves. The subject is CUT-OVER PLANNING. Some may call this go-live planning, data migration planning, etc. but since I focus on the minute details in the planning and the physical activities involved, I prefer to use the above term.

CUT-OVER PHASES

Many people assume that cut-over planning should be done toward the end of the project – I strongly disagree.

Prepare

The first step to a successful cut-over is to start planning early. From the first project meeting, the team constantly needs to consider how any decision may affect the cut-over activities. For example, if a decision is made to re-factor the location sequence in the warehouse, the cut-over plan must reflect all the logistical challenges relating to this decision. If this is not identified and planned for early in the project, the warehouse team may not have the time required to prepare and test. As part of the planning phase, the project must also make the BIG decisions:

• Do we need to renumber master data keys?
• What do we do with historical transactions?
• Will a phased approach be used?

In many cases, I would question how a project can be planned in the first place, without having at least an outline sketch of the cut-over plan.

Transition

Obviously, during the Development and Deployment phases, the teams will develop data migration scripts, test scripts etc. and execute all the necessary testing to make sure all this works. However, often the test scripts do not allow for the transition that needs to take place during cut-over. In my view it is equally important to test all the activities that need to happen during cut-over. For instance, if a stock-take with reconciliation needs to take place before we post the goods-received-not-invoiced balances to the general ledger, it would probably be a good idea to test this before the actual cut-over.

Also, in many plans that I have seen, cut-over is a one or two-day activity (often during weekends or holidays). In my view, cut-over starts and takes place over the weeks leading up to the actual cut-over point. During this transition period, master data can be migrated and locked down in the live system (with parallel update in both systems), preparatory stock takes can be performed, labels can be printed, the order backlog reduced etc. By viewing cut-over as a transition phase, we are able to avoid back-loading the activities and therefore significantly reduce the cut-over workload and risks.

Stabilise

Often I have seen projects go live without the faintest idea of how they measure, not only success, but more importantly point-of-stability. The main project objective must always be to reach a stability point where the project can be handed over to operations and support. If the cut-over plan (or operations plan) does not clearly outline the KPIs that need to be met to proclaim the system stable, I would think that there is a significant risk of the implementation team being stuck with project for a long while without the option to move on to new projects or rollout activities. Every project needs a set objective!

GETTING DATA INTO SHAPE

Going back to the transition phase, obviously data cleansing and consolidation play a major part of most projects. Often we are in a situation where we need to migrate data from 20 year olds systems with a very low degree of quality and consistency. That in itself is not a problem and today we have tools to deal with the technical side of the issue. However, I often see projects underestimating the actual workload and calendar time require to do this. Very often analysing data and taking decisions on how the data should be cleansed or consolidated can only be done by a select group of key users. Interestingly, this key group of users also seem to be the people, who take part in the functional workshops, train the end users, produce training materials etc. So here we have a classical bottleneck scenario that is often not allowed for in the project plan.

One way of mitigating this issue is to produce a CLEAR AND CONCISE data policy framework. This framework describes how data should look in a future system and rules of engagement when it comes to consolidating and cleansing customer, product and vendor data. With this policy in place, less experienced staff (or even temps) can be assigned to the job allowing the key resources to focus on the exceptions.

THE FINAL FURLONG

Once you get to the stage where you are ready to go-live, you are getting into the final phase of the cut-over transition. A lot of people in customer service will hate me for this, but I think it is often a good idea to key in open sales orders manually. Obviously, for some businesses this is not doable due to the sheer volume of orders, but in other cases it is. Why do I think this is a good idea? Firstly, it is brilliant training! The end users get to know the system in a thorough way and are able to iron out small mishaps early on. Also, it allows them to hit the ground running once you are live with the system. Secondly, many businesses have forward orders with a ship date after the cut-over date. These orders can often be put on the system early, distributing the data entry workload across one or more weekes leading up to the cut-over point.

When you get to the actual cut-over point, it is pivotal to have a DETAILED cut-over crib sheet. If possible, make this crib sheet as public as possible so people can follow progress step-by-step. The crib sheet must, in minute detail, describe what needs to happen and, who is responsible for making it happen. The project manager acts as a the central control-point, so activity must be reported back to him or her to keep the cut-over plan updated.

Clearly, we all expect things to go smoothly, so hand-on-heart; how many of you have always had fallback plans in place when going live? In my view, it is essential to have a detailed fallback plan that outlines exactly how you can go back to a stable point without disrupting business operations. Essentially, the plan should allow for going all the way back to the original system. Also, it is very important to have agreement on, who makes the decision to stop the cut-over process and fall back? Who has the authority to do this on a Sunday afternoon? A simple problem, yes, but not a simple decision, if a plan is not in place.

SURE STEP AND CUTOVER PLANNING

As much as I favour Sure Step as an implementation framework, I also have to admit that this is a weak point in the methodology. Yes, there is a go-live check list and a go-live plan template, but they both seem to miss the point of external and physical activities. This is not the end of the world as long as the project manager is aware that this is a simplified template, which is in need of some additions and refinements.

PLANNING PLANNING PLANNING

To sum up my above text, the key to a successful cut-over lies with detailed planning. In my experience it takes time to produce such a detailed plan, so start early in the project life-cycle and make sure you get all stakeholders involved. It is all too easy to overlook a small detail that may cause mayhem when you cut-over. Good luck…