Almost half of all cloud computing projects are rated as being at least partially unsuccessful by internal or external auditors after launch. In two-thirds of all cases, benefits promised by the cloud migration were deemed real but not realized by the cloud project. To secure your own cloud benefits, establish explicit target benefits and link each target benefit to a specific step in the process, then audit benefit realization status at each project milestone and take prompt steps to record what you've promised.
There will, however, be hurdles along the way.
Establishing target benefits
The biggest problem with benefit loss is lack of any organized benefit set. You can't chase benefits you never really had under control, and control starts in the
The biggest problem with benefit loss is lack of any organized benefit set.
First calculate total ownership costs for a current application in-house and for that app in the cloud. Address the capital cost of hardware and software, maintenance charges, facilities costs, network costs and support in both of your analyses. The second step, perhaps most critical, is to record the assumptions associated with each source of savings projected for the cloud. Under what range of conditions will these savings be available? The goal of your benefit managing process is to ensure that these assumptions will be met. Your cloud project must manage the variables associated with each assumption and take prompt action if something changes.
Users report that operational costs most often expand to blow a project's benefit case. Running something in the cloud doesn't cede all operations' responsibility to the cloud provider; the user must still create and maintain a machine image, support the applications' end users and maintain the cloud computing environment. Companies report that often, management can modify a cloud project without considering the operational impact of such a change. This can increase support costs unexpectedly, shaving percentages off thin cloud savings.
You also need to be aware of cost items that show up during the project but were not in the matrix of benefit assumptions. One company's recent cloud project planning neglected to consider the access cost for data movement into and out of the cloud. This cost showed up in the first testing bill, and nobody mentioned it to project management -- probably because they'd not been conditioned to alert management of any unexpected costs. As a result, the higher cost wasn't detected until pilot testing, and the project couldn't be completed at the adjusted (and correct) return on investment.
Network costs are an overall issue in the challenge of preserving cloud computing benefits. While cloud costs have typically fallen, network costs can actually rise when cloud computing is adopted if application performance needs can be met only with faster or more reliable connections. Some cloud applications, because they are easy to use and accessible, are used more often and drive up network use. When planning a cloud project, identify network services that are usage priced or where current capacity/utilization is close to price-imposed limits. Where there's any chance of expanding network needs, price the new services into the cloud project assumptions, negotiate better terms or find another provider.
Auditing and recording benefit realization
Every one of the benefit assumptions in a cloud project must be tested at each point, just as much as application features or network access. Any sign of a problem should be brought to management attention quickly. Often, if problems that impact cloud benefits can be addressed, it's often possible to keep the project approvals intact and even get approval to complete the project with lesser benefits than expected. However, a surprise failure to deliver expected benefits is very likely to result in loss of management confidence in the project. In the same way, keep track of target benefits that are realized in the cloud project.
Problems in targeting cloud benefits
Some cloud planners endorse the idea of "banking benefits," which identify only the benefits needed to secure approval for the project and that keep additional savings available to cover unexpected costs or issues. Some CFOs will endorse this notion, but others consider it to be circumventing financial oversight, so find the appropriate people before considering this approach. A better strategy is to build a "benefits buffer" that sets a higher target for approval for the project than the CFO would require, which gives latitude to cover overruns and missed costs. This can be made an explicit part of the project, justified by the fact that cloud experience levels are still low and so errors in project planning are more likely.
Obviously, inexperience generates benefit problems, but so will vendor over-promotion. More than half of cloud computing projects audited showed indications of cloud providers' errors in stating pricing policies or details of performance and features that materially impacted cost/benefit. In most cases these happened because the user didn't demand a formal quote, so be sure to get one so your project costs are correctly assessed. That's a big step in protecting your benefits and business case.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
This was first published in November 2013