Is cloud computing “business as usual” for the IT project manager (the PM)? Are cloud-based projects really any different from traditional projects?
Since cloud computing is now enterprise-class, we can no longer ignore cloud solutions for IT projects. For the PM, however, cloud computing is still relatively new and can be a significant challenge, at least it is here in Canada.
PMs are, or should soon be, deciding how cloud computing can affect the execution of their projects. Does it reduce delivery times? Does it simplify the technical tasks? Does it increase project risk? Does it radically change the infrastructure or application development processes? There can be many questions, and the answers aren’t always straightforward.
Many companies have started their cloud transition, but only a very few could be considered mature users. In fact, cloud computing is still new enough that project management best practices have yet to catch up. The PMI perspective is expressed in a cloud computing whitepaper, but most project management guides have not yet been revised.
Excellent references such as NIST, ISO, the Cloud Standards Customer Council, Amazon Web Services, and Microsoft Azure describe, in more detail, the capabilities, characteristics, benefits and architecture of cloud computing. However, there are relatively few references describing how to go about managing cloud transformation projects.
Different types of project
One of the first hurdles is recognizing that cloud computing is not a single technology, product or design – it really is a new approach to IT (a paradigm shift).
Three fundamental categories of cloud project would be:
- Projects that deploy cloud services for multiple applications or customers (provider projects) versus projects that make use of public cloud facilities (customer projects);
- Projects that are one-off, independent cloud applications (a cloud silo) versus a multi-application managed “Anything as a Service” project; and
- Projects based on a single cloud provider’s services (Salesforce, for example) versus multi-cloud, multi-vendor cloud configurations (e.g., a hybrid cloud).
Examples of typical cloud projects would include:
- Converting to an external packaged application, such as Google email (i.e., becoming a SaaS tenant);
- Implementing Microsoft Office 365 in the cloud;
- Creating a cloud-based server/storage infrastructure as a standard resource for corporate users;
- Establishing a standard program testing platform and deploying a set of development tools for cloud application development (i.e., creating a PaaS environment);
- Developing a new cloud-based enterprise application using an existing PaaS environment;
- Implementing a cloud-based data backup or disaster recovery system; and
- Acquiring a cloud-based security management system.
In summary, some projects configure cloud services for private enterprise use, while others use pre-defined public SaaS (Software as a Service), PaaS (Platform as a Service) or IaaS (Infrastructure as a Service) offerings.
Cloud project complexity
Cloud projects can be divided into low, medium and high complexity, using the following as a possible guideline:
- Lower complexity: deployment of a single SaaS cloud configuration from a single provider, with little or no service orchestration, integration or special security requirements;
- Medium complexity: development and deployment of a private business application using a pre-deployed cloud program execution platform; and
- Higher complexity: a hybrid cloud involving multiple service providers with public and private components, integrated with external partners and having specific compliance requirements.
Cloud computing emphasizes provider-owned IT systems and services shared by multiple clients (i.e., public clouds). One example is Google for Business.
Cloud computing can both simplify a project (since capabilities already exist and providers want to help) and make it more complex (since not all required features or qualities may be readily available). Each cloud project should be planned and organized to fit its user’s requirements and to ensure sufficient control is applied to the processes.
Here’s a few items to consider when planning any cloud-based project:
Project scope
How much of the cloud ecosystem has to be included in the project scope?
Is formal procurement required or have cloud Vendors of Record already been appointed?
Is a cloud-based business case needed or has a cloud first policy already been adopted?
Are there any unique integration, customization or specialization requirements for the application?
Are there potential compliance or other regulatory roadblocks?
The PM should also establish the organization’s cloud maturity level (initial, repeatable, systematic, measured, or optimized) prior to doing the detailed planning for the project.
Project constraints
Every project involves a balance of various constraints, preferably balanced in a way that is acceptable to all the stakeholders. Cloud projects may require different factors be taken into consideration.
Cloud project constraints can include:
- Scope – the organization may be an early adopter which would involve increased management oversight, additional training costs, and possibly organizational changes;
- Risk – the use of external providers, or a hybrid of internal and external services, can lead to additional business, technical and project risks;
- Quality – new quality issues include provider service quality, network quality of service, support services quality and the solution technical quality (i.e., the architecture and design);
- Reputation – sensationalized stories about data loss in the cloud, and publicized security breaches can make it difficult to gain support for cloud systems, especially public clouds; the PM will spend a lot of time allaying fears, proving the solution and generally providing answers to stakeholder questions;
- Schedule – since cloud computing is intended to be on-demand, self-service and agile, delay times in obtaining resources for development, testing and production can be shortened significantly (not counting procurement rules); this can be offset by the legal and contractual issues that need to be managed earlier in the project;
- Budget – there will be significant savings in capital costs, and operational savings may accrue over the long term, but there can also be increased costs for training, management, vendor relations and so on.
Service level agreements
Cloud computing involves a division of responsibilities between users and providers that needs to be based on well-defined agreements, usually called Service Level Agreements (SLAs).
Every cloud services provider has an SLA that specifies what is being provided, how well it should work, what remedies are available if it fails, and how much it costs. For example, Microsoft has its Azure SLA(s) and Amazon has its EC2 SLA.
Many PMs may not have had much prior experience with this type of agreement.
SLA concepts can be applied at three different interface points:
- End User/Solution Owner – an SLA between parties within the enterprise that specifies what the IT Department provides to its business customers;
- Solution Owner/Internal Provider (or a Broker) – an Operational Level Agreement (OLA) that codifies services agreements between departments or with a cloud broker; and
- Internal Provider/External Provider – a SLA between the IT Department and a Cloud Service Provider.
The on-demand availability of cloud resources can present interesting opportunities for the PM to move some activities forward, to eliminate some activities, and to apply more agile design, development and continuous improvement processes. For example, testing on a production platform, access to common security functions, pay-as-you-go billing are areas of focus in cloud computing projects that are either glossed over or taken for granted on traditional projects.
Five points to remember
The following five points should be kept in mind when you start down the road towards your corporate cloud:
- Cloud computing should not be a set of silos (independent, incompatible solutions) – clouds need to be designed and managed as an ecosystem and this touches on virtually all areas of the IT department;
- Cloud computing can be more complex technology and will have a different balance of project constraints than is traditional;
- Cloud computing, even though based on previous technologies, is not yet well understood and widely taught; there may be considerable FUD (fear, uncertainty and doubt) to be faced;
- Cloud computing is a partnership with one or more external vendors – well-defined performance requirements, service level agreements, and possibly multiple procurements will be required; and
- Operations staff have relatively little training or experience with managing cloud systems.