How cloud computing is changing project management

Many organizations have started their cloud transition, but cloud computing is still new enough that project management practices have yet to catch up.

There aren’t a lot of resources available about managing cloud (transformation) projects, which is rather strange, because the way cloud computing works has a major impact on the skills a project manager needs to be successful in delivering such projects.

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 and doing business. I am not a big fan of bullshit bingo, but this you really can call a paradigm shift.

Some projects configure cloud services as a private cloud, while others use pre-defined public SaaS (Software as a Service), PaaS (Platform as a Service) or IaaS (Infrastructure as a Service) offerings. Of course, you can combine these in what are known as hybrid clouds, or join forces with other organizations in creating a community cloud.

Examples of typical cloud projects include:

• Converting to an external hosted business application, such as Salesforce;
• 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.

This article will describe what are, in my opinion, the 10 most important things you need to be aware of when managing cloud projects compared to on-premises projects.

Security & Compliance

You need to understand that a migration to the cloud will often completely disrupt an organization's existing security and governance strategy. Governance methods that worked for traditional on-premises systems probably won't work for the cloud.

As organizations move data to the public cloud, their control decreases and more responsibility falls on the shoulders of the cloud providers. Therefore, organizations must shape their security governance strategies to rely less on internal security and control, and more on their cloud provider's offerings.

Since security is never 100 percent perfect, it's important for you to plan ahead for potential breaches, failover and disaster recovery.

And of course, these additional security tools and services will increase overall project and operational costs.

Data Privacy & Residency

You need to be aware that there are laws in specific states, countries, or governmental associations such as the European Union (EU) that dictate that sensitive or private information may not leave the physical boundaries of the country or region (residency), and that the information should not be exposed to unauthorized parties (privacy).

Example legislation includes:

• The United Kingdom Data Protection Law
• The Swiss Federal Act on Data Protection
• Russian Data Privacy Law
• The Canadian Personal Information Protection and Electronic Documents Act (PIPEDA)

The EU Data Protection Directive is also an important piece of data privacy legislation that regulates how data on EU citizens needs to be secured and protected. With the European Court of Justice’s ruling in 2015 that the Safe Harbor framework is inadequate to protect the privacy rights of EU citizens when their data is processed in the United States, data privacy professionals expect to see additional data privacy legislation and restrictions appear across Europe.

Besides these general data protection laws, there are also industry-specific compliance requirements that can affect your project. Examples of such requirements include:

• The Health Information Portability and Accountability Act (HIPAA)
• Swiss Banking Secrecy
• The Health Information Technology for Economic and Clinical Health (HITECH) Act
• The Payment Card Industry Data Security Standards (PCI DSS)

And then there are third-party obligations: Agreements among business partners that outline how a party such as a contractor or vendor will handle and treat private or sensitive data belonging to another organization.

Such agreements often hold the external party accountable for securing the data in the same fashion as the owner of the data, including adherence to all residency, privacy, and compliance requirements.

For example, a contracted agency performing billing for a hospital in the U.S. must observe all the data protection requirements mandated by HIPAA and HIT.

Vendor Relationships & Contract Negotiation

While project managers have always needed to have contract negotiation skills, the move to cloud requires you to employ vendor relationship and contract negotiation skills much more often.

There is an aspect of additional overhead to this because the development of even a small application would necessitate working with the vendor to iron things out.

Cloud and SaaS vendors need to stay in business, and are not likely to cut customers slack in many areas. Buyers need to be prepared to assert their organizations' best interests on the questions of service interruptions, service-level agreements, data availability and physical location, and intellectual-property rights.

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 project managers may not have had much prior experience with this type of agreement. You will when you are involved in a cloud computing project.

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 service agreements between departments or with a cloud broker; and

> Internal Provider/External Provider – an SLA between the organization and a cloud service provider.

Team Size & Skills

The size of local project teams has greatly reduced and the skillsets of those who need to stay onsite have changed. This means effective coordination and communication between location- and organization-dispersed teams becomes even more important than it was the last few years.

There are no internal team members involved in the design and architecture piece. You only interact with designers and architects from the vendor side remotely, with them coming onsite for meetings as needed.

The coordination overhead increases as you still have to take care of oversight responsibilities ranging from estimation through testing, but with external vendor personnel.

Financial Literacy

You will be required to deal with environments that are going to be a mix of applications hosted on onsite servers and those hosted at cloud sites. When a new application is to be developed, you need to perform cost and ROI analysis for both options. This requires knowledge of cost for cloud-based environments and expertise at creating both a detailed project budget and an operational budget.

This can be challenging, because a disadvantage of running things in the cloud is that costs can be wildly unpredictable. Public cloud providers, with the exception of most SaaS providers, are not known for using simple billing models. Typically, you are billed based on the resources you consume. This includes storage resources, but also CPUs, memory, and storage I/O. Resource consumption may be billed differently at different times of the day, and not all activity is treated equally.

Technical Proficiency

You don’t have to be an engineer or solutions architect to run a cloud-based project. That said, the more technical knowledge you have, the better. At the very least, it helps to know the differences between VMware, Azure, Google Cloud Platform and AWS, and how your company or vendor deals with these differences. After all, as the unified cloud becomes more of a reality, knowledge of gaps and bridges will only enhance your project skills and contribution to the project.

Due to the fact that the architectural landscape for applications gets more complicated after the move to the cloud, a deeper knowledge of the organization’s enterprise architecture comes in handy in order to ensure that newer applications get developed with the correct business and technical requirements in a manner that they work seamlessly with the existing applications hosted in the cloud and onsite.

Risk Management

The use of external providers, or a hybrid of internal and external services, can lead to additional business, technical, and project risks. Reputation and breaches of providers impact you more than ever. 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; you as a project manager will spend a lot of time allaying fears, proving the solution, and generally providing answers to stakeholder questions.

Exit Strategies

Exit strategies need to be carefully thought out before committing to a cloud engagement. Vendor lock-in typically results from long-term initial contracts. Some providers want early termination fees (which may be huge) if organizations terminate a fixed-term contract earlier for convenience.

Often, contracts require "notice of non-renewal within a set period before expiry,” causing users to miss the window to exit the arrangement. Such automatic renewal provisions can be negotiated out up front.

Another way to avoid lock-in is to actually use several providers, to avoid over-reliance on one provider’s service and its (possibly proprietary) application programming interfaces.

Cloud-to-Cloud Migrations

Cloud migrations aren't just a transition from on-premises technology to the cloud; you can also migrate data from one cloud to another. These cloud-to-cloud migrations include moves from one provider to another, as well as migrations between private and public clouds. However, the migration process from private clouds to public clouds can be difficult.

While third-party tools are available to help, there is no comprehensive tool to handle the entire migration process. Cloud-to-cloud migrations involve considerable manual labor. To prepare for migration from one provider to another, organizations need to test their applications and make all necessary configurations for virtual machines, networks, operating systems and more.

Conclusion

For most project managers, managing cloud computing projects means entering unfamiliar territory. As you can see, the things a project manager needs to be aware of in order to be effective are different for cloud computing projects than for traditional on-prem projects. When considering a move to the cloud, you will need to skill up and learn about contracts, SLAs, laws, technology, and more.