With the majority of UK organisation either migrated to the Cloud (part or full) or planning for their migration to the Cloud. The transition project is a vital step for any business as the migration can be a high-risk event. The execution of the project needs to be done correctly otherwise your organisations operation could be put in serious jeopardy.
The inception of a programme is an exciting time for any Project Manager. However, most projects fail due to wrong decisions being made in the infancy stage of a programme. Prior to joining the Clover index, I spent many years performing Cloud programmes for mid to large scale financial services organisations in the UK and picked up many ‘scars’ from these projects. I’m hoping that my top five cloud transition lessons learnt will put you in good stead for your upcoming Cloud projects:
Lesson 01: Order comms links as soon as possible
I used to have a ‘thousand-yard stare’ through the amount of times I would have to chair a Steering Committee meeting and state to the clients CXO Team that their project is delayed as a Telco has failed to deliver on time or a critical circuit is stuck in the wayleave process
Many CSPs will advertise that your service can be turned up on demand or almost straight away after contract signature. However, comms links could take between 8 to 12 weeks for a wayleave to be approved by your Landlord then another 8 to 12 weeks to deliver the circuit. Therefore, you could be looking at up to six months for your circuits or longer (there are some horror stories out there).
This is my advice to give you the best chance to keep your programme dates on track:
- If you are serious about a project and have the ‘A’ and ‘B’ locations of where you need comms provisioned to and from – place the order! Even if you are not in contract with the CSP, it’s imperative to start the process as early as possible. The cost of good quality links has dropped over the years and your commercial exposure is very low. Furthermore, most Telco’s allow you to cancel an order in mid-flight and will only charge a small cancellation fee
- Over order on your comms links. if you need to connect two resilient comms links between your office and a CSP location. Order three links from three different Telco’s. Why? One Telco is likely to fail through a wayleave not being agreed or an incorrect survey being undertaken and them realising there is not enough capacity in the street to ‘light’ your building. As per above, if your three links do look likely to be delivered, you can always cancel one ‘mid-flight’
Lesson 02: Speed is not everything
There is generally a temptation to get a project completed as fast as possible once you have your platform to migrate to. Typically, this is due to the resource costs as having a multi month or even year project can be a ‘fair chunk’ of the total cost of ownership of the solution you will be deploying (good project staff are not cheap).
There will be some instances where you will need to be aggressive with your migration approach (e.g. you’re moving office locations in X months and your data centre is ‘on prem’, or your contract with your current CSP expires on a certain date).
However, if you’re programme does not have a business impacting time dependency date, my recommendation is always to have a gradual service migration path (less critical systems first) for one reason, new things fail!
The bath tub curve depicted below is an engineering term that demonstrates that the probability of failure in the infancy of new infrastructure is very high, once the infrastructure is ‘bedded in’ the probability of failure drops. As you reach the end of life phase where the probability of failure then increases again.
Go at a steady pace as no one wants ‘Captain Hindsight’ flying into a room, where you are explaining an outage to your Stakeholders, stating ““You should have taken your time and not been so aggressive with the transition”.
Fianlly, use the opportunity to purge or upgrade systems either prior to the migration or as a migration activity. There’s no point migrating Windows 2012 servers when support expires in the next year. A transition project is an excellent opportunity to get ‘the house in order’ for the next three to five years.
Lesson 03: Be prepared for BAU staff angst about the upcoming change
If your organisation has historically managed their own IT environment and you have committed to outsourcing this moving forward to a CSP. There will be natural anxiety within the Technology BAU Team as they will feel threatened that their jobs will be at risk once the project is completed. A move to the Cloud allows time for the BAU Teams to focus on the important items that were generally ignored due to dealing with break fix issues, etc. As such, their jobs will typically be safe but their job description will differ once the project is complete.
A good lessons learnt for your transition project is to engage with the BAU Team at the early stages of the project to communicate the objective and the steps to reach the goal. Ensure that their management is sending the right message to them about what happens after the project has finished to provide them with certainty on the future.
Once there is certainty on where they fit into the organisation post Project completion, you typically will find that the BAU Team will be engaged and committed to the objective of the Project.
Undertaking a Project without the BAU Team ‘buy-in’ will make it a very difficult project to deliver and can increase the risk of the project failing as their ingrained knowledge of how systems ‘piece together’ will be needed for the transition.
Lesson 04: Actively manage your BCP / DR plans and risk during transition
Many organisations have wordy DR and BCP plans which generally sit upon a shelve with layers of dust upon them, only dusted off when the auditors are in so they can ‘tick the boxes’ for having these documents.
BCP and DR is a complex thing to manage in normal operations at the best of times. However, managing BCP and DR throughout a transition project when there is a split of the ‘old world’ and ‘new world’ is extremely complex. Should an event occur where DR needs to be invoked during a transition project, not having a plan showing the current state could mean the recovery time objective (RTO) for DR not being met or recovery in general not being possible.
My lesson learnt here is for the Project Team to take ownership of the BCP and DR plans throughout the transition period. These documents should be treated as transient plans being updated as the environment changes and / or systems are migrated (in some cases this could be weekly updates). Once the project is complete, it’s a deliverable for the project to handover the end state BCP / DR documents to the BAU.
Lesson 05: Don’t be scared to re-plan and always look for opportunities to gain efficiencies
Eisenhower had a famous quote from World War 2 “planning is everything; plans are nothing”. For me this quote sums up a good project manager. The best project managers I’ve worked with don’t have to rely on a ‘1000 line’ project plan to tell them where the project is, they know instinctively. I’m not saying project plans shouldn’t be used but these need to be a secondary reference / validation point on where the project is.
The project plan will always need to be re-baselined throughout the project as issues will occur or there are opportunities to re-plan to bring efficiencies. One of the best pieces of advice I received as a young project manager was to always look at opportunities to gain efficiencies (resource / timeline). Don’t be scared to change the plan, it does not mean you’re a bad project manager if you need to reshuffle work to gain timelines or lighten resource demands.
My lesson learnt is to always look for where efficiencies can be gained and to not be scared to re-plan mid-flight. A project plan should not be static as it needs to be dynamic from the start through to the end of the project.
