Project Management Institute

Cloud first! Managing cloud computing challenges with a program management office

Abstract

The drive to implement Cloud Computing as a solution may be outpacing the project management disciplines in place to manage the transition. From the start of the hype cycle, the move to the Cloud has promised better, faster, and cheaper capabilities. Anticipating this transition requires thoughtful methodical management. However, we are starting to see ad hoc adoption that is completely out of synch with the best practices of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fourth Edition (Project Management Institute [PMI], 2008). Other Cloud implementations that were previously thought safe are experiencing outages because of failures to implement failovers. A strong program management office (PMO) can serve as a counterweight to the clamor to adopt in spite of the risks.

Cloud First! Managing Cloud Computing Challenges With a Program Management Office

Cloud First! derives from former U.S. government CIO Vivek Kundra’s government Cloud Computing Strategy: “To harness the benefits of cloud computing, we have instituted a Cloud First policy. This policy is intended to the pace at which the government will realize the value of cloud computing by requiring agencies to evaluate safe, secure cloud computing options before making any new investments” (Kundra, 2011, p. 6) Kundra also required all agencies to identify three services that they will move to Cloud over the next 18 months. One service must convert by the end of 2011 and the remaining two by mid-2012. Even with Kundra’s recent departure to Harvard, these transitions are already in play and not likely to subside. However, can they fail?

Causes of Project Failure

Based on recent research on project failure by PM Solutions, Inc. (2011), there is a 37 percent chance of project failure in the portfolios studied. The causes listed are the who’s who of the PMBOK® Guide—Fourth Edition (PMI, 2008): failure to communicate, failure to engage stakeholders, failure to identify, quantify or mitigate risks and a personal favorite, failure to manage the scope (Krigsman, 2011).

The program management office (PMO) can serve various purposes according to our needs. It can serve as an umbrella for reporting. It can present standards to an otherwise unruly project or program management group. It can also lead.

The Cloud First initiative may not be what is driving private sector forays into the Cloud. Maybe it is a mandate from the board of directors, the CEO, or CFO to adopt what they are hearing is the take off ramp to $USD0.70 to $US0.95 cents on the dollar savings on IT investments. This sort of money is real money in days where every penny must be justified and economic bust has not been so quickly followed by economic boom times.

Cloud Defined

When I published Above the Clouds, Managing Risk in the World of Cloud Computing (McDonald, 2010), one of the tenets that I subscribe to is that the hype cycle will do more for adoption than perhaps the underlying value to the organization. What I mean by this, is that sometimes what drives decision makers is not the rational view, it is the herd mentality. With a common barrage of great value, easy to implement, faster than internal IT, it would be quite likely that the executive suite would adopt Cloud Computing eventually. Accordingly, the IT governance process should be involved, but it might not be involved until it is too late to do anything about selection criteria, risk management, or even consideration of the effects on legacy systems.

Into this void, the PMO can step in and perhaps if not save the day, provide at least a framework and a rationale process for adopting Cloud centric policies and procedures across the enterprise. The definition I used in Above the Clouds is Cloud Computing is the elastic provisioning of metered, Shared Managed IT Services (McDonald, 2010). This should hit most of the buttons of outsourcing. The U.S. government’s, public-private partnership derived definition of Cloud Computing and published by the National Institute of Standards Technology has a very granular definition as well, and I encourage everyone to view their definition for reference (Mell & Grance, 2011). Some of the commercial providers insist that Cloud Computing is not really Cloud unless is purchased or rented from… of course, the commercial providers. My view is a bit less demanding.

Virtualization, Key to Cloud Enablement

A cloud environment is at its core a virtual environment. Virtualization is the key technology enabler of Cloud Computing. By virtualization, I mean the provisioning a working virtual image of a physical compute or storage entity. You could be accessible via a network, but it is possible using tools such as the Oracle virtual desktop, Xenworks, Citrix, Microsoft Virtual PC, and VMware to create a virtual world on a desktop or server with no network access. The value is that the virtual environment could crash or become corrupted and a simple reboot resets the environment to the pristine copy stored offline.

Another advantage of this technology is that the starting point of all security nowadays is the baseline image or baseline configuration. By using virtual systems, a startup image or bootstrap image can be used to deliver a fine-grained hardened, secure system that incorporates all of the best security settings deemed important by the information assurance folks. This baseline or gold copy, platinum copy, steps up the security game and in the interest of time, I will not discuss cyber in detail during this presentation, but just note that as long as there are malleable computer images in use, there are vulnerabilities that will need to be vigilantly guarded against.

Consolidation Trends

Virtualization is a precursor to application consolidation. Once applications in the portfolio are consolidated into a virtual environment, also called virtualization in place, the servers running consolidated workloads can be consolidated.

Consolidation also lends itself to higher utilization, fewer pipes to watch, and higher utilization usually translates into lower cost and more efficient operations. This can be a revenue sharing model if the organization is focusing on green technology and can save the vendor money.

Monitoring the Cloud

The challenges around Cloud are many. From the standpoint of IT, there are grumblings that this will either eliminate or certainly radically alter the traditional IT workforce. Similar to an outsourcing craze a few years ago, this is outsourcing writ large. The infrastructure, the commodity applications, e-mail, web hosting, all the cool tools, all the bells and whistles, gone, and replaced with a Web page showing how much CPU and how many processors and memory you are renting this minute!

It is a challenge for auditors trying to make sense of SAS 70 reports and whether data is really backed up continuously. And where is the data stored anyway (Gilbert, 2011)? Is it within the 48 continental 48 states? All the time? This may be difficult to pin this down with some providers.

IT is a challenge for managers to determine whether the application is going to run as well as it does inhouse. Will the availability exceed internal benchmarks? Will the all of the enterprise embrace this solution, if we jump first, will anyone follow? Is this a fad? Business early adopters have some reason to fear all of these types of results have already plagued other cloud projects.

Developers may like the Cloud because they are 10 minutes away from the cool tools and an inexhaustible supply of servers. No longer will they have to wait on IT to install the servers; they can go push whatever they want to EC2 with a Web service and credit card. Along with all the organization’s data, they can push. Test data? Right?

The Role of the Program Management Office

How can a PMO help with this cluster of blessings? Well for one, it can provide a center for answering these issues with an Enterprise approach. Without an Enterprise approach, we may be facing the same sort of issues you see with other deployments, SharePoint sites everywhere, not one in synch with corporate. Failure to scale, failure to monitor, because if IT doesn’t know it is there, neither does corporate security.

PMOs can serve as centers of excellence. Helping to consolidate the Cloud effort can result in economies of scale even within Cloud vendors there are frequent flyer discounts. By using or standardizing on a platform, they can roll all of the management eggs into one basket to reduce the administrative overhead. This can reduce the angst of the management types on whether the dev/prod environments are actively scanned and reduce the number of spots to extend Kerberos or Active Directory to let the good people in and keep out the bad people.

The other more important role of a PMO is portfolio management of risk. By pushing all of the Cloud wants through a single management silo, the value of various projects can be assessed. This assessment can also look for synergies, between collaboration, e-mail, and web hosting for example, there are services that support these particular services within one umbrella. If the email group and the SharePoint group aren’t talking with one another, this can fragment these acquisitions and wind up costing more than is necessary.

Critical Success Factors for the Cloud PMO

Consolidated Portfolio view of all IT services is a great place to start. What we refer to most succinctly is assessment. By assessing and setting the baseline of the current portfolio of Cloud Services, the IT governance organization will have the basic information required to determine the best fit for Cloud-based service models. Generally, this takes the form of a data call from an Enterprise Architecture office or department of the CIO. Asking questions on what is the application, what is the value to the organization, and what is the maximum tolerable downtime will provide information on what sorts of risk that the organization would face if the Cloud based version was down for some reason. In addition, this plays a role in the application resiliency design (ARD) with the focus of worst-case scenario evaluations.

Once this inventory or services catalog has been compiled, the other critical piece is enrolling all of the appropriate stakeholders in the evaluation of the architecture. The Cloud Services portfolio can be managed by an integrated project team (IPT) approach. The IPT serves as an advisory and voting body. Without the explicit approval of the IPT, the service migration cannot take place.

The other role of the Cloud PMO is to serve as a focal point and communications conduit for lessons learned and services consolidation. If every department turns up their own Cloud service, the possibility of multiple external connections and multiple providers raises the risk of duplication of services and deployment that is more chaotic and diffusion of management oversight. The savings from economies of scale will likely be lost in the increased overhead of managing multiple providers.

This is not a call for a single provider model. It is simply that the provider be the clear and deserved winner of the acquisition cycle. In other words, if a related set of applications are going to move to the Cloud, it would likely make the most sense to deploy them on a single platform. If there were specialized capabilities such as providing Geographic Information Services that are not available from a particular vendor, then perhaps the GIS suite would be broken off as a separate solicitation.

The other possible outcome is reigning in through policy pronouncements that ‘development clouds’ will only be provided through this list of vendors using this common security framework.’ The use of ad hoc clouds by developers is increasing. This is often only detected after the fact by reviewing expense reports.

Development occurring outside the organizational network also increases the risk that code might be tampered with while residing on the Cloud provider’s network. Such Cloud-based malware insertions are not a commonly catalogued as a security risk. Development is usually thought of as being somewhere lower on the risk matrix.

However, if it is common practice and knowledge that developers are using a particular cloud platform, there may be some value to the hacker community from attacking via this less intuitive method.

Another corollary risk is the HR component of the Cloud service provider. Because a third-party assertion is at the core of the HR staffing for service providers, this may not be verifiable that no foreign national (NFN) access to cloud storage data is allowed. If an organization falls on financial difficulties, these assertions might be relaxed and without transparency into the service providers hiring process, this may be difficult or impossible to verify. By clearly providing a beacon for cloud services, the how to procedurals of acquiring and deploying, the risk that a given organization will go rogue and start acquiring services on their own can be somewhat reduced.

Integrated Project Teams (IPT)

The role of the IPT cannot be understood without determining the clear roles and responsibilities of all of the stakeholders. Once the stakeholders are identified, the authoritative representatives should be brought together with a formal charter. Formal charters and genuine stakeholder engagement is key to management buy in to the Cloud PMO. The PMO has the responsibility of organizing, gauging, and measuring progress and then moving the pieces around on the board until they begin to perform.

The IPT role is to gather requirements, sometimes called “shall statements.” Develop a list of the requirements and put them to a vote either by the body as a whole or if the charter is focusing power on a smaller group, by the steering committee, governing board, or IPT voting committee. Just having a seat at the IPT does not nor should it guarantee everyone a vote. Only a voice in the proceedings can be granted. Too many on the steering committee and the group will not get anything done or will water down the requirements to suit everyone’s wants if not needs. The administrative burden for the IPT is to produce meeting agendas in advance of the meetings. The charter should mandate at a minimum that the IPT contains both the technical representatives and the business representatives and if deemed appropriate and helpful, perhaps the consumer representatives as well.

The general progress is noted by (a) production of the required documentation; (b) the actual record of attendance and support by the stakeholders; and (c) most importantly, actual planned deliverables along with the schedule of delivery as best can be determined. This focus of the IPT, the voting on scope and timing of delivery of deliverables, is a critical piece of PMO governance. The secondary considerations of most projects today are the triumvirate of cost, scope, and time.

Given that cost and time are mostly locked down, cost is subject to preordained budgets, time is usually something about “we want a deliverable” every three weeks, or three months or six months. That leaves scope as the main variable. If scope is allowed to float, the time and cost are unrestricted. Better to lock the other two and force the issue of scope to be decided clearly and methodically by a determined, accountable group.

Conclusion

Cloud Computing PMOs represent a way for management to establish clear lines of communication on what is a rapidly evolving technology. By concentrating the lessons learned, the management best practices and economies of scale can be concentrated, refined, and then defused to the rest of the Enterprise. The formation of IPTs within the Enterprise ensures that all of the stakeholders are properly represented and engaged. Finally, starting small with pilots and prototypes, reduces the risk of massive retreats synonymous with excessive initial scope and executive overreach.

By concentrating on the Cloud, it is more likely that the pace of adoption can increase as the organization develops more capacity to manage the hybrid legacy/private cloud environment. The fastest path to the clouds may be the narrowest.

References

Gilbert, F. (2011). Server location: A significant factor in cloud computing services. Retrieved from http://www.francoisegilbert.com/2011/04/cloud-computing-legal-issues-data-location/

Krigsman, M. (2011). CIO analysis: Why 37 percent of projects fail | ZDNet. Retrieved from http://www.zdnet.com/blog/projectfailures/cio-analysis-why-37-percent-of-projects-fail/12565?tag=mantle_skin;content

Kundra, V. (2010). 25-point-implementation-plan-to-reform-federal IT.pdf (application/pdf object). Retrieved from http://www.cio.gov/documents/25-Point-Implementation-Plan-to-Reform-FederalIT.pdf

McDonald, K. (2010). Above the clouds: Managing risk in the world of cloud computing. Retrieved from http://www.itgovernanceusa.com/product/2014.aspx

Mell, P., & Grance, T. (2011). Draft-SP-800-145_cloud-definition.pdf (application/pdf object). Retrieved from http://csrc.nist.gov/publications/drafts/800-145/Draft-SP-800-145_cloud-definition.pdf

Project Management Solutions, Inc. (2011). Strategies for Project Recovery. Retrieved 08 16, 2011, from www.pmisolutions.com: http://www.pmsolutions.com/collateral/research/Strategies%20for%20Project%20Recovery%202011.pdf

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2011, Kevin T. McDonald
Originally published as a part of 2011 PMI Global Congress Proceedings – Dallas, TX

Advertisement

Advertisement

Related Content

Advertisement