The Micro-Tech London (MTL) Knowledge Corner is filled with resources aimed at keeping you in compliance and in the know. From helpful articles and links to downloadable tools, we’re putting our expertise at your fingertips. If you need information and training that’s more tailored to your needs, we can do that too. Visit our Facebook page @MicroTechLondon
Written by – Abhijat Mittal (SAP/Prince2/GDPR Certified Program Manager)
Spring is round the corner and as I was cleaning my drawers I stumbled upon some old project documents, notes and scratch pads. Memories started creeping in about what we did, what we did not do and what we should have done during CUTOVER. Based on some real-life experience with world-class businesses, I wanted to share my key learnings of CUTOVER. Although I am brave enough to put everything under 6 points, they are by no means carved in stone. Change is the only constant and so these points would keep changing with time.
Cutover Plan is very critical. It should have a set of tasks listed out with clearly defined interdependencies, duration required to perform that task and person responsible to execute it. Once finalised, this plan should read as a storyboard and should be able to highlight a total elapsed time for cutover – from start to finish. Let us now try and do this step-by-step:
FIRST: Create buckets of information in the plan – put them under heads like Preparation Tasks, Technology Tasks, Business Tasks, Data Tasks, Communication Tasks, Governance Tasks & Post Go-Live Support (PGLS) Tasks.
SECOND: Further categorize them as Prep, Ramp-Down, Ramp-Up, Continuous, Governance, Reversal or Support tasks.
Prep task example – “discuss with vendor to agree on a system backup window before data load”.
Ramp-Down task example – “close open sales orders as much as possible to reduce open-items data load”.
Ramp-Up task example – “activate interfaces once go-live has been declared and unlock users”
Continuous task example – “agree with hardware vendor on 24/7 system monitoring during cutover and provide system performance report every 6 hours”
Governance task example – “approval stage gate after every key milestone on plan – gatekeeper to approve if ok to proceed”
Reversal task example – “Finance data not reconciling therefore gatekeeper has approved reversal to early state position”
Support task example – “Review Order to Cash support tickets related to order entry”
THIRD: Ensure that start and end date, time, duration, person responsible and predecessor or successor definition is updated for all tasks. Try to keep all time to one standard time zone (like GMT) and avoid any confusions.
FOURTH: Take a copy of the plan prepared till now and put it aside somewhere safe
FIFTH: Now Sort the whole plan based on Start Date progressively and as an output we should get a START-TO-FINISH plan with a clear elapsed time. Flow of the plan should then look like:
Preparation à Technology Ramp-Down à Business Ramp-Down à Data Load & Validation à Technology Ramp-Up à Business Ramp-Up à GO-LIVE à Support
[Reversal tasks are used only if there is a need to revert to earlier state]
SIXTH: If you are overshooting your cutover window, find “rogue” tasks and correct them (normally the duration is too long or dependencies are not defined correctly). If all ok – you have your cutover plan. If not – create a copy from the earlier saved backup and keep re-planning till you achieve your goal.
SmartTip – All stakeholders may not have MS Project licenses so create both versions of plan (.msp and .xls) for everybody to access.
Step 2 – Find our (CRITICAL) path and follow it – till we are out of woods
Once we have our plan, we have to review and clearly identify our critical path. This would become our ROAD-TO-SUCCESS for cutover. Standard reporting is done about overall progress of cutover plan and managed accordingly but there is always a special focus on critical path. This critical path is what differentiates success from failure. Tasks may keep getting added or deleted from critical path and it may be an evolving road but overall the base route still remains the same as per our original cutover plan.
Example = “Lock Users and make system unavailable for use” may be one of the initial tasks on critical path because that task happening on time would decide whether the whole plan is on track or delayed. Similarly, under Data section, critical path would flow through 2 tasks – “load customers” and then successor task “load accounts receivable”. Without loading customers, we cannot load Accounts Receivable and therefore they are lined up one after the other on critical path.
SmartTip – If our critical path elapsed time is more than 90% of overall cutover plan elapsed time then our cutover plan needs expert review to see if any tasks can be done early or in parallel – in order to get benefit of, as we say, “low-hanging-fruits”.
Step 3 – Technology – A Friend and an Enemy
Technology, even when it is not human, can be extremely moody and erratic. Best of the plans can go wrong and your boat can be blown out of water. I have seen networking issue affect system copy delaying task by 12 hours, in turn pushing go-live by 6 weeks. I have also seen a Production Server hanging continuously and whole of data load in progress being terminated – losing key 9 hours of cutover window.
We should do a couple of “warm-ups” or dress rehearsals before going into Live Cutover. Assuming that technology would become our enemy when we need it the most, we should also plan for failure during cutover. If 24% of our linked technology tasks take just 1% extra time, it means we are delayed by almost 6 hours (lots of assumptions !!). Imagine telling users sitting in Singapore that instead of doing a task at 8PM their time, they would now have to do it at 2AM their local time. Cutover Managers start racking up enemies faster than they can count.
So long and short of it – if you want Technology to say “I Do”, before popping the question first time as “Live Cutover”, try it out couple of times before as Dress Rehearsal or Dry Run.
You can never be ready for EVERYTHING but at least practise SOMETHING.
Step 4 – Business – The Be-All End-All
Everything that we do as Project Team is with one objective – make a fit-for-purpose system ready for business to transact on. They are the final recipients of all our success (and failure!). During Cutover, a lot of key business tasks are also to be performed, which are intertwined with technical tasks. It is important that key stakeholders from business are engaged properly, well in advance and with clear objectives. We have to walk them through the detailed plan, clearly articulating what is expected from them and when. It is also important for them to get in perspective what would be the domino effect if their tasks get delayed.
As we keep hearing “We are in it together” – it cannot be more true in case of cutover. Responsibility of business tasks should be clearly defined and names updated on the plan. For the purpose of cutover, business team becomes an important part of project team.
Step 5 – Keep Talking – even when nobody is listening
“If everybody in this world just listened, there would be complete silence” – Anonymous
Communication is one of the important pillars on which success of cutover planning rests. Cutover Manager should engage with all stakeholders and walk through the plan at length. Any questions, queries, clarifications, doubts should be addressed and it is ensured that everybody is on same page (of same book!). Recently I have seen projects where Cutover Manager develop videos and podcasts to be socialised on organization’s portal so that cutover strategy & methodology can be made clear to all involved. Escalation mechanism and query resolution matrix are communicated, task sheet created to give visibility of questions asked and how they would be resolved.
Some of the organizations where I worked were very conservative and therefore miserly with words. I cannot stress enough that overdoing communication would do no harm but under-communication would definitely give rise to confusion, which can be our tripping point during cutover execution.
Step 6 – Celebrate, Enjoy, Document (in the same order)
Once system is live, it is party-time. Whole team has worked hard so there should be celebrations and enjoyment. Everybody should get an opportunity in rotation to take some important time off and recharge their batteries.
BUT (and there is always a but…) we should not forget to document our learnings and putting it in shared drive. Cutover Manager’s job is not complete till the time all learnings are comprehensively documented and stored properly for future use. This task is important from governance principle perspective and also linked to more critical activities like acting as supporting documentation during any system or project audit.
And yes, documenting our cutover execution learning is also important because sometime later when we open an old drawer we should find old notes and then memories should start creeping in about what we did, what we did not do and what we should have done during CUTOVER.
