Author: Richard Clayton, Higher Education Lead, Namos Solutions
Let’s face it, planning and executing a project cutover can be daunting. I am a Prince 2 and Oracle qualified PM, ITIL Expert and Certified Scrum Master, all of which is theory that counts for nought when you’re in a ‘Go/No Go’ meeting asking for the trust of those accountable to purposefully interrupt their critical business processes (that may have been decades in the making).
This article is drawn from years of successful go lives and some (hard) lessons learned!
1. Plan Cutover from Day 1
Cutover planning is not the result of quiet planning in a darkened room the month before go live, it is the result of months of listening, capturing ‘As Is’ processes, understanding dependencies and lessons learned from each build that came before.
Add the cutover section to your project plans and notes from the beginning and add to them as you go. This will mean that when you start assessing cutover readiness in earnest, you’re not clambering to remember key points from months before.
2. Communicate, Communicate, Communicate
I could have doubled the word count of this article by including wider change management principles in terms of business transformation and still not scratched the surface. The key principle is that your communication plan and your cutover plan go hand in hand.
Knowing which stakeholders need to know what progress when, is the difference of a quiet cutover that no one notices (sorry, there is never fanfare!) and a noisy cutover full of worried stakeholders who know too much and key stakeholders who are in the dark.
Little and often is invariably the best approach. Ensure they are targeted, prewritten, triggered by checkpoints and milestones and backed by facts.
3. It is Dependency Driven – Not Time Driven
I know, I know, it’s basic project management, however for those rolling their eyes that all project management is driven by dependencies, bear with me! If you’re a PM, this may be second nature, but for the Workstream Leads and Business Owners at the helm of cutover, I cannot stress this enough, the number one thing you ought to concern yourself with is the path on the cutover plan not the dates. The dates need to have some flex and fluidity, they ought to be brought forward and pushed back dictated by checkpoints and opportunity. The path should not be changed unless you are certain of the dependencies.
4. Visualise it
Cutover plans come in all shapes and sizes. I have worked with Cutover plans on 3000 lines of Excel, Ms Project plans and several other online PPM tools, Kanban boards (both physical and virtual) and I have worked with A0 sized Process Maps.
Bearing in mind my point above on dependencies, the Business Analyst in me can’t help but love a process map. Gannt and Kanban have their place, however, if you are looking to ‘drill’ a team, process maps are really impactful. Cutover planning is invariably a complex critical path with tasks running in serial and parallel. A process map shows that ‘at-a-glance’.
Finally, a real-time cutover dashboard (automatically driven by progress) is the best way to keep a team on track and communicate progress to those who need it. Be creative with your KPIs and make them look pretty, overall progress percentage is great, however, task slippage as a proportion of outstanding, late delivered tasks, phase completion percentages etc. these are the KPIs that make for a meaningful dashboard that people will engage with and act upon.
5. It comes in Waves
In my experience there are three basic Cutover Phases:
- Pre-Cutover – The activity that lays the foundations for Cutover, consisting of broadcasted communication, final build and initial data migration, ceasing BAU and culminating in the ‘Go/No Go’ decision.
- Cutover – The actual act of switching across, consisting of stopping BAU processes (e.g. stopping feeds to legacy systems, revoking access etc.), the final extracts and loads, granting access, catch up data entry, sanity checks and targeted communications.
- Post Cutover – The HyperCare tasks that need careful marshalling before you meet the acceptance criteria of ‘live’. Typically consisting of; wholesale access granting, broadcasted communication, floorwalking by champions, scheduling processes and integrations, decommissioning legacy etc.
6. CheckPoints and Go/No Go
The perfect cutover plan is punctuated by Go/No Go project boards, sanity checks, reconciliation and critical business activity milestones. Having these throughout your plan will pull project tasks through and push communications. For instance, the cutover ‘Readiness Assessment’ is the trigger for the Go/No Go project board, which pushes communications to the project team and pulls forward the next task of data migration which in turn pulls forward the reconciliation, which in turn… etc.
If you are lean minded, you want to create an inertia where tasks are logically pulled through teams without a burden on the project team to constantly push tasks.
7. Plan for Backout not Blackout
Supposedly the way to tell a liar is to ask them to repeat their story in reverse! The notion being that you only ever really know something if you can play it back in reverse. This is true of Cutover.
I was ‘Head of Cutover’ when a previous implementation hit a ‘No Go’ decision and we backed out a month’s worth of changes over a dozen systems in two days… it’s not fun!
It is key to have a prewritten plan that has been interrogated (I can thank a great PM who worked with me at the time), aligned to business continuity plans and change boards, and is timed for Go/No Go decisions. The completion of this plan should be fundamental to your ‘Readiness Assessment’.
Don’t be fooled into thinking Backout is the Cutover Plan in reverse, there are steps that cannot be undone, there are processes that do not need to return to how they were, there are continuity plans that will not last… do you really want to be finding that out in the heat of the moment?
Every build and testing cycle is an opportunity to rehearse your cutover tasks. Carry them out in the correct order and have those who are ‘back-up’ task owners to carry out the tasks (led by those will actually carry out the task).
If your plan allows, do a dry run!
9. Cutover is Just the First Step
At Namos we have a track record of delivering HR and Finance solution implementations in under a year, however, as a customer I was once attached to an implementation that spanned a number of years. Do not underestimate the fatigue that can set in. Be prepared to stand-down the implementation team ready for the operational team to step-up with renewed energy.
10. Trust the Team
I have designed ‘major incident management’ processes in the past, and the number one success factor is to entrust the team ‘on the ground’ with the autonomy to deliver. If you don’t, micromanagement will take hold and the team will do nothing but communicate reassuring messages, whilst not focussing on the task at hand.
Finally, if you would like to talk more about Cutover or how Namos could be part of that trusted team, please get in touch.
About Namos Solutions
Namos Solutions are an award-winning Oracle OPN Modernised Partner specialising in the implementation and support of ERP, EPM and HCM business solutions, both in the Cloud and on-premise.
With global experience together with an impeccable track record, our business is built on our passion for delivering successful business transformation. Passion underpins everything we do at Namos – passionate about delivering beyond expectations, earning trust and building long-lasting relationships with our clients.
Although based in central London, we work wherever our clients need us to be. Many leading organisations located all over the world trust and rely on our expertise to deliver industry-leading business solutions. Namos customers can currently be found in the UK, Europe, Middle East, Asia Pacific, North America and Africa.