Management of Cloud Projects

The concept of ‘The Cloud’ has become the newest phrase and buzz item within the technology space over the past several years. Many companies are now adopting some level of a cloud strategy either as part of their own service offerings or as part of a new way of handling their infrastructure needs. Gartner has indicated that this space will be one of the fastest growing segments in the tech industry for the next several years, as more and more organizations offer some or all of their product deliverables in some cloud form.

From the standpoint of a project that revolves around the concept of being cloud enabled or have a cloud deliverable associated with it, the project manager must be cognizant of the various constituent components that are part of the broader cloud strategy. Understanding the terminology, technology and key attributes of how a cloud deliverable looks and operates will go a long way to ensuring the project stays on track and achieves its goals.

With that being said, it is important for the project manager to become well versed with the concept of The Cloud, as well as understanding how a project that produces a cloud deliverable or deliverables differs from other projects in the technology space.

What is ‘The Cloud’?

Contrary to what many less tech savvy individuals think, The Cloud has very little to do with the sky or the weather. In simple terms, The Cloud (or Cloud Computing) is the utilization of computing resources (both hardware and software), existing in one or more remote locations, that provide a set services available over a network (usually the internet). While the term ‘The Cloud’ (Cloud Computing) is relatively new, the concept of delivering services over the internet in one form or another is not, and has been around for quite some time. One of the most common examples is internet mail, such as Gmail or the newly rebranded Outlook.com. Both of these services have been allowing people to access and monitor their email from any device, irrespective of that individual’s current location. All that was required was some mechanism that could access the internet and a browser to view a particular webpage. Nowadays, mobile applications are also allowing access to email from phones over the networks of various wireless carriers.

From the standpoint of the end-user, The Cloud is providing some service that they are consuming. The internet mail example would be one, but that has expanded greatly over the years to include full service applications over the internet (eg. Salesforce.com), as well as systems that allow storage and backup of files (eg. Google Docs) and now even the streaming of video on demand (eg. Netflix, Hulu). In summary, what The Cloud is essentially doing is reducing the dependency on clients and users to maintain their own applications and services and instead transferring that job to the service provider(s).

How is The Cloud Structured?

On a holistic level, cloud computing provides services and infrastructure to the end-user as well as allowing for some API (Application Programming Interface) access for further customization. The Cloud as it is commonly understood is actually broken down into three layers as follows:

• Application (or SAAS) Layer – This provides the end-user with a mobile or web enabled interface to an application (such as a Salesforce system) that the user can access from any device that is internet-enabled. Product offerings in the cloud space give the user the flexibility of leveraging a powerful application without the need to install or maintain that application on their own. Note that mobile devices do install clients on their operating systems, but these are generally what are referred to as ‘thin clients’ that install only the minimum in order to access the application through web services (explained next).
• Platform (or PAAS) Layer – This provides the user with the ability to interface with a server-side hosted system of some sort through the usage of web services (also known as APIs). The consumer of the PAAS will then leverage additional tools and libraries provided to them to create their own software offerings or augment the existing offering. Generally speaking, the most common mechanisms for this type of interface would be in the form of web services, usually either SOAP (Simple Object Access Protocol) or REST (Representational State Transfer) types. An example of a PAAS offering would be Google Analytics (http://www.google.com/analytics/); this system allows the user to leverage tools and APIs provided by Google to analyze the traffic to the user’s website(s). Google is providing the necessary processing power of their servers and their custom algorithms to give the user the means to do analysis that would otherwise be too cumbersome or difficult for the user to accomplish on their own.
• Infrastructure (or IAAS) Layer – This would be the low-level hardware and software necessary for providing the functionality of the preceding layers. (Note that the layers are stacked) Now while this may seem not too inventive from the standpoint of the user; after all, internet service providers have been leveraging servers and server space to the end-user for years. And that functionality still exists, but the one key difference can be summed up in one word: virtualization. Virtualization refers to the many techniques and systems that allow for the creation of virtual rather than physical instantiation of something, like an operating system or hardware platform. What virtualization has allowed is to create an abstraction between the physical systems and the operating systems. What this essentially means is that if a user is accessing a given server, they are not necessarily accessing a singular device or even the same device. A single physical computer could actually have multiple virtual images associated with it. Clustering, fault-tolerance and load balancing could also have the user accessing different images and devices without even knowing it. The primary benefit of virtualization is essentially making the infrastructure more fluid; new servers and storage can be added on the fly and systems can be offlined for maintenance or replacement without interruption in service if other images are available for pick up the slack.

In summary, the cloud is structured in a stacked fashion with the IAAS layer supporting the PAAS layer with both in turn supporting the SAAS layer. As an example, the diagram below shows the overall cloud architecture of Oracle’s primary solution offering stack:

**Source: Oracle Corporation; http://www.oracle.com

Some additional terminology to be aware of as it pertains to the cloud: cloud computing is often categorized into three types, defined below:

• Public Cloud – Applications, services and storage is made available to the general public
• Private Cloud – An infrastructure and its resident services operated solely for a single organization
• Hybrid Cloud – A combination of both private and public clouds with some bounding between them

Fundamentally, the main difference between public and private clouds is one of security. Corporations may operate their own private cloud infrastructure behind a firewall they control for added protection from cyber threats.

Dealing with Cloud Projects

Now that the terminology is out-of-the-way, we can address the key attributes of what is involved in managing a project that has components or deliverables as part of a broader cloud strategy.

When dealing with projects in the cloud space, the project manager has to contend with different types of deliverables, which can be both hardware and software based, or combinations thereof. These deliverables will interact with each other in various ways and changes to one core portion of the stack can affect other areas of the overall cloud offering. As such, it is important to ensure all these moving parts are handled smoothly to ensure a problem in one area does not derail efforts in another.

1. Tracking Dependencies

As one can already surmise, the nature of the cloud automatically denotes the fact that certain deliverables of the overall cloud offering will be dependent on others. As described above, the Platform Layer supports things in the SAAS or Application Layer. These dependencies are an extremely important component of the overall cloud project and as such, it is imperative that they are tracked effectively.

In most cases, the overall cloud project will likely be broken up into separate tracks, probably corresponding to the specific layers of the cloud architecture. Dealing with separate tracks is easier when viewing the project holistically and will allow teams to function semi-autonomously while the cloud project is moving forward. The project manager will be responsible for reconciling project track details with each other and calling out any issues that have arisen.

From the standpoint of the overall dependencies, it is highly recommended that the project manager perform a PERT (Project Evaluation and Review Technique) on the primary cloud project in order to itemize all the various parts and lay out the dependencies into a cohesive diagram. This will allow for a solid way to visually track all the dependencies as well as calculate the critical path for the cloud project. (For more information on PERT techniques, please review the following posts: The PERT Analysis – Part 1 and The PERT Analysis – Part 2) As noted, the dependencies of the cloud layer will heavily effect the overall progress of the project. Slippage in one area must immediately be reconciled with other deliverables that may be dependent on that area.

2. Communication Strategy

As mentioned above, a cloud project will have a large degree of dependency associated with it, as well several tracks for each of the specific cloud layers. Because there will need to be a certain level of autonomy for each of the project tracks and separate teams working on the various deliverables of the cloud offering, the project manager will need to set up a very efficient communication strategy in order to facilitate adequate dialog between teams, especially where dependencies exist while also ensuring that information overload does not occur. Usage of good software, such as requirements management, defect tracking and project management can assist tremendously in this regard. Most software suites will allow for effective compartmentalization between areas as well as ways to organize items to denote dependencies and their corresponding resources. By leveraging these software suites effectively (with assistance from the development and QA managers), the project manager should be able to set up proper communication streams to ensure important information finds its way to the right individuals while more routine team communication can be relegated within the email traffic of the specific teams themselves.

One exercise the project manager should do is to diagram the current layout of the various components of the project and their corresponding teams. That will provide a visual representation of the structure of how communication traffic should be handled and in what forms. The diagram below provides an example of such a diagram:

3. Stakeholder Management

Every project will have its stakeholders. Generally speaking, stakeholders can actually span multiple projects and thus have a vested interest in a variety of different initiatives throughout the corporation. When it comes to cloud projects, stakeholders can come from a variety of different divisions in the company, spanning areas such as IT, engineering, sales & marketing, etc. The main takeaway from this from the project manager’s perspective is that the knowledge areas and focus interests of these stakeholders will deviate and as such, the project manager must be cognizant of both their technical background and specific interest in the project as a whole.

As part of any communication plan (mentioned above), dialog with stakeholders is going to be an important component. What is imperative is formulating the status updates and dialog exchanges in a manner that will be palatable for all the stakeholders in question. Getting too technical or leveraging concepts or terminology that may be foreign to other stakeholders of the project will lead to confusion.

At inception of the cloud project, the project manager should perform the following exercise in cataloging the stakeholders to determine how best to approach the stakeholder management process:

1. Identify – Pretty self-explanatory. Itemize the stakeholders by name, contact details, department and physical location.
2. Categorize – Group your stakeholders based on certain common criteria, such as background, expertise, and common department. This will allow for better structure to the communication and status updates you perform.
3. Get to Know Them – This would be on a more personal level. Determine their degree of engagement and get an idea of how they generally prefer to communicate. Some stakeholders like face-to-face or live dialog while others are satisfied with weekly updates on their areas of interest.
4. Observe and Record – Get an idea of what is most valuable to the stakeholder as it pertains to the project. Determine if they have any issues with the current project strategy and execution and deal with issues as they arise.
5. Review – Keep tabs on the stakeholders and if changes arise in the organization that moves a particular stakeholder away from direct interest in your project, find a suitable replacement within their former area. This will ensure your stakeholder critical mass stays constant.

4. Handling Scope

Probably one of the more sacrosanct portions of a project (at least from the standpoint of the project manager), the project scope is essentially the blueprint of what key elements will be part of this iteration of the deliverable. Generally agreed upon at the inception of the project, what is ‘in scope’ and what is ‘out of scope’ is always itemized up front to ensure all stakeholders, team members and the project sponsor are on the same page. The nature of what is in scope can vary, but as most are aware, the Triple Constraint will dictate that changes to scope will require alterations to both the time and cost of the project. (For more information on the Triple Constraint, please view the following post: Managing the Triple Constraint)

From the standpoint of a cloud project, scope can be a little more difficult to discern due to the sheer number of components involved in the overall cloud model. Elements of the infrastructure will have hardware bases scope items while items in the platform and application layers will have software based scope items. An additional piece of complexity is the dependent nature of the cloud model (mentioned above) that can cause a ‘scope cascade’ to occur. What that means is that a reduction in scope for example at the lower levels of the cloud stack can cause higher level scope items to also change. A simple example would be a change to the platform layer in the cloud model. If one of the web services that was meant to yield specific functionality is altered or removed, than any scope items at the application layer that were dependent on that capability will also need to be re-scoped.

In order to ensure all these permutations are tracked, the project manager should create a scope map of the main feature items, showing all dependencies and relationships. This will provide a baseline guide that they can use to keep an eye on specific scope items and be aware immediately if a scope change will result in a scope cascade. Usually, the scope map can be derived through usage of a good tracking software system that is capable of relationships between features. Itemizing all those correctly will produce the scope dependencies and make it obvious if a scope change will have larger scale impact on the overall project. The scope map and requirements should also denote which particular enhancement or feature resides in which portion of the overall cloud stack. That will add additional information and allow the project manager to ‘tag’ certain scoped items as being more likely to cause a scope cascade if they reside at lower levels of the stack.

5. Schedule Management

A project’s schedule is essentially its timeline for success. More often that not, it will also be the most referenced aspect of any status update or general information sharing that occurs with the stakeholders. Invariably, those at the top of the food chain are most concerned with one question: are we on track?

With that being said, managing the schedule for any project is a baseline necessity. This becomes even more necessary as a project’s complexity expands, as in the case of a cloud project. As denoted earlier, because of the stacked nature of a cloud project in its entirety, being mindful of how a slippage in one area can affect another is of paramount importance. Additionally, as the project grows in complexity and scale, it becomes necessary to begin to segment up aspects of the project into cohesive parts that can function in and of themselves in a semi-autonomous fashion, but can still maintain inter-relationships.

Ideally, a cloud project should be broken down into separate tracks, which are linked as a whole, but can be tracked individually. (A cloud project should probably be a program anyway, so this should not be entirely unusual) These separate tracks can then be staffed with the resources who have the proper skill sets to operate in that area. The tracks themselves can function semi-autonomously, with the project manager and key team leads meeting regularly to share information and discuss any technical challenges that have arisen. To add some additional granularity to the project, it is also advantageous to break up the tracks into specific phases or set milestones that have some commonality across the tracks. The reason for this is the dependency between layers as alluded to earlier. By identifying the key tracks, itemizing the deliverables and then spacing out key milestones into phases, the overall program will be easier to monitor and team members will be able to more readily view things holistically. The graphic below denotes an example cloud project, across three tracks, broken down into three phases:

Final Thoughts

A cloud project in and of itself is not the most daunting of project types, but it is certainly not the most simple either. The skills that a project manager has in their arsenal (time & schedule management, resource allocation, scope definition, etc) are all applicable to a cloud project. What is paramount however is that the project manager understands the nature of how things operate in the cloud and how dependencies within items that are part of a cloud project affect other items. Knowing the terminology, understanding the concepts and having baseline knowledge of the technology space will go a long way towards ensuring that the project (or program) moves forward smoothly. And while a project manager does not have to be a uber technical expert as it pertains to the technology of the cloud, it still pays to have good familiarity with the overall premise and technology that makes cloud offerings what they are in the internet world.

**Addendum**

As a corollary to the above post, I have composed a slide deck outlining in further detail, a cloud enablement strategy from a project management perspective. The deck is available at the following SlideShare location for viewing:

http://www.slideshare.net/TomTsongasPMPCSM/cloud-enablement

The deck will walk you through the steps of how to properly categorize and outline a potential project (program) plan for your own efforts in moving from a traditional client-server based architecture, to a more robust cloud-based architecture.