Management of Cloud Projects

cloud-computing-datatrendThe 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 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., 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 (; 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;

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.


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:

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.


Project Management of Mobile Applications

mobiledevicesAs most are fully aware, our world is rapidly being transformed by the increasing prevalence of ‘smart’ devices that are carried around on our persons. Mobile phones, tablets and now wearable tech like Google Glasses or SmartWatches are providing consumers with new products to explore and new ancillary applications to utilize.

The wave of new devices has produced a veritable plethora of new utilities that users can leverage, whether they be mapping applications, social network widgets or simple games. There is not much of a limit on the type and nature of usable software on the myriad of smart phones and tablets that are available nowadays.

From the standpoint of producing an actual mobile application that is then made available to the consumer, the process to follow from a project management perspective is somewhat akin to other development activities, but with a few key differences. This post will attempt to cover some of the dos and don’t of effective project management in the mobile space.

A Word on Mobile & Tablet Technologies

There are various companies that produce various software packages for use on mobile devices along with many vendors who produce the hardware that these varied software applications utilize. In many cases, the vendors of the hardware also produce software for their own units, as might be expected. To provide a brief pre-amble to the discussion, here is a list of the various companies involved in the mobile space:

1. Apple – Produces the iOS operating system for use exclusively on iPhones and iPads. Also responsible for the creation and distribution of the hardware inherent to these devices. (Through third party contracts) The primary development language in use is Objective C.

2. Google – Produces the Android operating system and makes the OS available to everyone. Also owns the former Motorola Mobile Hardware division and uses that to produce its own hardware leveraging its own operating system. The primary development language in use is Java, an open source programming language now maintained by Oracle.

3. Microsoft – Produces Windows Mobile operating system, a derivative of the common Windows OS in use on many desktop computers. Has partnerships with Nokia on the creation of hardware to distribute Windows phones and also creates hardware of its own, primarily in the tablet space, such as the Surface product line. The primary development language in use is .NET, with most developers opting to use C#, an exclusive proprietary derivative of C++.

4. Blackberry (formerly RIMM) – Produces the Blackberry operating system for exclusive use on its Blackberry devices. Also produces its own hardware, mostly nowadays just relegated to mobile phones. The Blackberry platform supports a variety of different programming languages that one can leverage, including C/C++, JavaScript, ActionScript and Java.

Additional note: there are numerous vendors that also produce hardware leveraging some of the technologies listed above. The most prominent operating system being used is Android, and that is being leveraged by companies such as Samsung, HTC, LG, Kyocera, and Casio.

Application Development for Mobile Devices

Development for mobile devices in an of itself is not entirely different from development in other spaces. As indicated above, many of the technologies that are used in both application or web development are portable for use on mobile devices. There are however, some key differences that need to be noted in regards to producing applications for use on mobile devices:

Generic Platform Development – While many individuals working on mobile development may opt to use the standard toolkits as they are individually for mobile devices, there are options that exist that will allow one to potentially write generic code that can be built and distributed across a variety of different device types. Several mechanisms exist that provide a singular way to write and publish code that can function on Apple, Android, Windows and other platform types without the need to have to write separate pieces of code for each device. Technologies such as PhoneGap, Titanium and Unity are but a few development toolskits and IDEs that can allow one to keep all code generic enough that it will be easily implemented from one platform to the next.

  • Pros – Keeps coding simple and allows for easy distribution and maintenance of applications
  • Cons – Performance can generally suffer due to abstraction layer of generic engine adding additional ‘weight’ to overall app

Distribution & Development Caveats

One major point to be aware of as it pertains to how one develops and distributes their applications is an understanding of how apps are marketed and downloaded by users. As most are likely aware, depending on your smartphone of choice, one will need to go through the ‘store’ that is made available by the main vendor in order to acquire an application. For Apple, it is the AppStore, for Google, it is GooglePlay and for Microsoft it is Windows Store.

With that being said, development and distribution of mobile applications must go through a vendor review and ratification process before an application is sanctioned for broad-based availability. This means that the development process itself needs to be mindful of the regulations and rules that an app vendor might have as it pertains to what can be distributed in their network. Additionally, as part of overall development, most vendors will have a sandbox area where apps can be uploaded and tested. Utilizing this sandbox is also part of the overall process of getting a particular mobile application ratified.

As the project manager, you will need to be cognizant of all these factors when performing your scheduling activities. Care must be taken to ensure that all policies as dictated by the vendor are followed. It is also advantageous to add flexibility and potentially some padding to the schedule to ensure that adequate time is provided for approval and potential rejection and re-factoring of the application as needed.

Application Maintenance for Mobile Devices

As most owners of Smartphones will already know, the applications you have on your device will generally have an update feature built into them. This can be either automatic or manual. The system is akin to updates of resident applications on personal computers; i.e. as new features and/or fixes are performed to the application, the changes are ‘pushed’ to devices currently leveraging the application.

From the standpoint of your own technology application, you need to be cognizant of these main factors:

  1. Fixes/Updates Need to be Continuous – As changes are made, especially bug fixes, those modifications should be pushed out studiously. Note that to avoid inundating the user with updates, ensure you ‘bulk’ push changes and updates, except in those corner cases where a critical fix is being rolled out.
  2. Keep your App Store Application Up to Date – As changes are being made to your already deployed app, ensure you have a policy in place to make sure the latest version of your application is available on the main download sites. Otherwise, your users will be forced to perform immediate updates to a recently downloaded application, which can be frustrating and gives the impression of a poor release methodology being in place.
  3. Monitor User Sentiment – While this is somewhat in the realm of product management, nonetheless, it is imperative you get a gauge of how your application is being perceived. Most app stores have rating and feedback systems built into their platform and it is important that those channels are monitored. There is actually software available that can track sentiment and feedback put out by users in app store spaces or in other social networking circles such as Facebook or Twitter. Utilizing some of this type of software can help stream effective feedback into actionable items that can be reviewed and acted upon by the team.
  4. Stay Up to Date on New Versions of Mobile Operating Systems – This is probably one of the more overlooked concepts, but it can be exceptionally hazardous if not monitored. Just as you and your team are updating your own application(s), Google, Apple, Microsoft and others are also making changes to their underlying platforms. In some cases, these updates are small, but in other cases, a new operating system is rolled out and like anything, it can be a bumpy ride for app developers. Changes to the underlying platform can cause your application to behave erratically or not function outright. In any case, from the team perspective, it is important to stay abreast of these types of changes and allocate adequate testing as part of the overall application timeline. From the project manager perspective, keeping track of these and other dependencies is of utmost importance.


In most cases, development of mobile applications is not too dissimilar from other software packages created by engineers and developers around the globe. However, there are distinctions as mentioned above that need to be considered an evaluated as part of the overall life-cycle of the application. Being knowledgeable of how things operate in the mobile arena and understanding the differences will allow one to more readily handle the issues that arise with mobile app development and be able to mitigate problems that might manifest.