Depending on the scale of your project and the size of your organization, the implementation of a cloud computing solution may take anything between an hour and a year, or even longer. Assuming the project is significantly large you will need a plan and a management strategy for it, and when the solution is fully implemented it will need measuring and monitoring.
If you completed the evaluation step described above you will know what you hope to achieve with your project and who the stakeholders are, but it is advisable to write it all down. Any project that is not open-ended needs welldefined objectives, so the implementation plan for the project should include:
- Project definition – key business drivers, guiding principles and clear business objectives;
- Governance – named executive sponsors and project management team members;
- Project delivery team – named IT staff and business users who will implement, test, develop and use the system;
- Scope – deliverables specified in the requirements checklist and constrained by internal information governance;
- Implementation schedule – phases, activities, milestones and timescales;
- Work breakdown structure – details of scheduled activities and who will perform them;
- Resource requirements – budget plan for internal IT and staff costs and external cloud computing services;
- Risk management – ongoing assessment of risks;
- Stakeholder engagement – consultations and communications with business users;
- Quality assurance – key success metrics and service level monitoring.
Regarding project scope and resource requirements in the preceding list, if your business is small then you may decide to roll out the cloud computing service as soon as possible, but if you are responsible for a large organization then a pilot project may be more appropriate. In either case you may need answers to the following questions:
- Will this project be a pilot, and will it be rolled out to one site or multiple sites?
- How many users will be affected?
- If the project is a success are staffing levels likely to be affected?
- Does the product require any customization or integration?
- Is any additional infrastructure or connectivity required to support a cloud service?
- Are any mobile devices or thin client terminal devices required for testing purposes?
- What level of availability and performance is required of the service ?
And if a new system is to be introduced then the following points need to be included in the work breakdown part of the implementation plan:
- user training;
- data migration;
- parallel running of old and new systems;
- integration with other systems;
- performance testing;
- user testing and documentation;
- security testing;
- ROLLBACK (exit) plan;
Use whatever project management methods you are comfortable with, but keep business objectives and the project’s ‘guiding principles’ in mind. Depending on the project, whether it is Infrastructure, Platform or Software as a
Service, you could either adhere rigidly to a functional specification and ensure there is no ‘feature creep’ or take a more agile approach to the project, involving key members of the project team at key stages and finding the best solution rather than the solution you originally envisaged. In any case you should communicate regularly with stakeholders; and it is always good practice to ask your technical staff to document what they do and let end users document the user experience as it develops. This will make training other users much easier.
Monitoring and measuring
If you are using Infrastructure as a Service (IaaS) then you can monitor the performance of your systems in great detail
at a low level. As for Platform as a Service and Software as a Service, or applications running on IaaS, the user experience can be monitored by timing and recording common web transactions on a regular basis, using automated tools or manually (see Chapter 5). Besides performance, it is important to monitor user adoption of any new systems you introduce. It is no good having a new Customer Relationship Management system, for example, if your sales team are not using it; but if you involve users at the development stage of a new system then they are more likely to adopt it.
Not all projects are completed successfully and some systems turn out to be less useful than you expect, so if your use of a particular cloud technology is to be long term (Enterprise Resource Planning, for example) rather than temporary (data crunching, for example), it is in your interest to ensure your business has a way back and a way out. Often businesses choose to use a new system in parallel with the old one for a fixed period of time so that data in the old system is kept up-to-date, just in case the business needs to revert to the old system, but you may be able to keep the two systems synchronized automatically without double entry. That is a way back, but what about a way out? Well, if you read the checklist at the end of Step 3 you will see that the final question is ‘Can you extract all your data from the system in a structured form that preserves its meaning whenever you need to?’ With web services this should be possible, but be sure to put your system to the test because it is your data after all.