After months of planning you’ve finally targeted an ICT as a candidate for Cloud. This blog covers how to make that transition to Cloud for a single service.
To a large extent this process is project management of which the sole aim is to move (or introduce) a service that is largely managed by a third-party, while ensuring that the ICT organisation can absorb the management of the end-to-end service from the day that it goes live (handover to production).
As a caveat, this is a long and complex process, what I’ve written here covers it at a very high level.
You’re going to need:
- A sponsor
- A project
- Process re-engineering
- Service levels
- Pilot deployment
- Handover to Production
- A go live date
- A warranty period
Without a sponsor, someone who sits on the senior management team in your organisation (preferably reporting to the Chief Executive), you will fail. That sponsor has a series of required characteristics. They need to be emotionally and mentally engaged in the project. They need to want the project to succeed. They need to be ultimately accountable for the success of the project. They need to make time to be the sponsor. I often see sponsors who assume they can come to a two-hour meeting once a fortnight and then wonder why the project is failing. Depending on the size of the project or programme, your sponsor should be dedicated 20% – 100% of their time to it.
Find a project manager that has done Cloud before, or at the very least, has worked on a transition project of some kind. I.e. Outsourcing a service from an internal ICT organisation to a provider.
Decide what you need in terms of support for the project and bind them together as tightly as you can. Once again, don’t expect your resource to do their day job and the project. It won’t work. You’re going to need various technical resources from within your organisation and the provider. As mandatory, for a mid-size organisation, I would consider the following to be required; Architecture from your organisation and the provider’s, business analyst(s), existing Systems Admin, Service Desk representation from both parties, application development / support resources, your IT Manager (or person who is going to sign the handover to production document at the end of the project certifying it is able to be supported).
Depending on the nature of the service, you may need more or less resource.
Publicise your project. A good communications plan will solve a raft of barriers for you as you start to implement.
There are several processes that need to be re-engineered end to end. These processes will stretch from the provider of the Cloud service, through your ICT organisation, to your end customers in the business. The best way to think about what needs to change is to run “what if” scenarios. Get a group of people in a room and think about all the different types of requests that you get today for the service that you are moving to Cloud. For example, email; what if I want to recover an email? What if email is down? What if I want to change settings in email? What if I want to increase the capacity of a user’s mailbox? What if I want to shut down the network for maintenance? What if I want to add a new user? What if I want to delete a user?
Most of that information should already be in your Service Desk system. As a rough guide, the following processes need to be examined and re-written while staff using them re-educated:
- Event management.
- Incident management.
- Crisis management.
- Business continuity processes (including Disaster Recovery).
- Problem management.
- Request fulfilment.
- Planning and support.
- Change management.
- Service asset and configuration management.
- Release and deployment management.
- Service validation and testing.
- Knowledge management.
Make sure that as part of the transition you map the Cloud service provider’s service levels to your own. At the very best, they will match you one for one. Hopefully they will at least loosely match, and the provider’s SLA’s will be a little better than yours. At worst, you may have to change your SLA’s with the business to align with the provider’s. This isn’t optimal, but if you don’t have clear SLA’s then you may end up in that position.
Remember that the Cloud provider is not going to change their SLA’s for you. Ever. Their delivery and entire business model will be built around standardised SLA’s.
As an aside, any provider who is willing to change their SLA’s to suit you should signal a red flag. This is very unusual behaviour and might say something about the maturity of the provider and their desire to win business.
This section goes without saying really. Many a programme and project has come unstuck due to undercooking this piece of the puzzle.
It is always a good idea to pilot your Cloud service. This will drive a number of issues out into the light in a small, controlled, friendly environment as opposed to your entire customer base in a “big bang” deployment.
There is a massive risk that surrounds pilot deployment of Cloud services that needs to be highlighted. There is a tendency, by lesser mature projects and inexperienced programme boards, to assume that the pilot can be “switched on” into a full production service. I.e. I deploy the pilot service, it looks ok, then I just let every business customer at it.
This is a path of destruction. The idea of a pilot is to test in a safe environment that your service is going to operate as you expect before you commit yourself to the full service. A pilot will not likely contain all the elements that you need in full production. For example, security and disaster recovery.
Operationalising a pilot always ends up in rework and additional scope that needs to be added and managed.
Ideally you should close the pilot down and move the users who participated back to status quo. At the very least you should isolate the pilot users and when the full Cloud service is available, migrate them to it.
Handover to Production
I’m going to cover this in detail in the next blog, however needless to say, it is critical that when your Cloud service transition project or programme is complete, there exists a list of handover deliverables that will allow it to be operated by the provider and your own ICT organisation.
This is an important step in the process. Obviously.
Ensure that you build in an adequate warranty period with your transition project and your service provider.
During warranty, the majority of the project will still exist in order to deal with issues rapidly as they arise, at no additional cost. Once you complete handover at the end of the warranty period, it is business as usual and all the standard SLA’s and charges will be in effect.
- Find an enthusiastic, well-connected sponsor who has authority.
- Pick an experienced transition or Cloud project manager or programme manager.
- Reorganise your processes.
- Test, test, test, pilot, and test some more.
- Don’t forget handover to production.