Anatomy of a cloud project cost overrun | CIO – CIO

I recently conducted an informal survey of some cloud integration companies and found something deeply troubling. Aside from cookie-cutter or formulaic quick-start projects, more than 70 percent of cloud consulting engagements involving new customers resulted in either a 10 percent cost overrun or a change-order. The bigger the project, the more likely the overrun.

You can blame it on stupid consultants or bad estimation or nutty customers or sunspot activity, but blame does no good. Something is going wrong here, and its causing a lot of heartburn for customers and vendors alike.

In an earlier article on trends making the cloud consulting market treacherous, I mentioned that a root cause of any cloud overrun is mis-set expectations: customers believing that meeting their requirements will be simpler than it is and that it should cost less than it will. However significant that observation may be, its not particularly actionable. So lets take the next step to understand the driving specifics, and what steps we can take.

[ How to compare cloud costs between Amazon, Microsoft and Google ]

In most cloud projects, several areas are nicely contained and are unlikely to cause significant cost surprises. If setting up a function is merely a matter of system configuration, there cant be that many hours of mouse-driving involved.

We should be so lucky!

Here are the project areas where we see cost surprises on a regular basis:

This twin-headed beast can involve some very serious surprises, as its impossible to detect many of the issues until youre in the middle of draining the swamp. The cost issues scale both with the amount of data and the number of data sources.

Even if the data looks superficially clean, there may be non-printing characters, format problems, improper values, overloaded semantics and object-model ambiguities that make for a messy migration or integration. If an ongoing integration is needed, you may not realize early on that the point-to-point adaptor you originally bid needs to be replaced with a full-blown middleware system.

Solution strategy: Do a real cost-benefit analysis of the amount of data to be migrated and the number of sources to be integrated, and develop a cost model that reflects reality. Start on the migration/integration/validation tasks at the outset of the project, so the surprises come early. Expect that migration and integration can represent the single largest part of your project.

Clients often stipulate no code, out of the box functionality only as part of their project definition, and on day two of the project discover requirements that cannot be satisfied any other way. Unfortunately, too many consultants are code-happy, so they willingly nudge the client toward custom-code land. And the rich coding environment of the Salesforce.com (SFDC) platform makes it tempting for both user interface and business logic.

The problem, of course, will be developer productivity and code maintenance costs. Expect custom coding a feature to be at least an order of magnitude more expensive than configuring the standard functionality.

[ Essential CRM software features: A savvy buyer's guide ]

Solution strategy: To the degree possible, use standard system features and off-the-shelf plug-in products to meet requirements. Bend requirements to fit whats available. Push coding out of the initial delivery if possible, so coders are working on a stable platform. For items that must be built, push to streamline processes and business rules that can cause combinatorial explosions (e.g., the security model, order configurations, distribution/partner networks).

The original SFDC reporting engine strikes a nice balance between power and ease of use, but it gives spreadsheet-quality output. If you want really clever and beautiful reports, it wont take long before you run into a wall.

SFDCs Wave reporting system is both more powerful and prettier, but really leveraging its power means writing query code. For even fancier stuff with nice formatting, multi-page layouts, and automatic office-document generation third-party add-ons are needed.

But as I noted in a previous article on design work in CRM projects, if its got to be pretty, its going to be pretty expensive both to set up in the first place, and to evolve over time with your needs.

Solution strategy: Thoroughly understand and specify every variant including formats and user-specific tweaks of every single report you will need prior to putting the system out to bid. Its best to discover that you actually require 100+ reports, not the ten you thought. If you have a working report (e.g., from Access or Crystal) that you need the system to emulate, provide the vendor with a sample set of input data and the reports output, with annotations regarding format and exception conditions.

This means you, project leaders and executive champions! Things you do will contribute directly to overruns. As I discussed in an article on agile project management, distance and delay are the enemies of efficient and economical projects.

But I need to add some new Ds that are even more deadly: dithering and (unending) discovery. The first of these, dithering (a.k.a. indecisiveness) is bad enough, as it causes delay and erratic direction, which leads directly to rework. But the second, whose hallmarks are discovering that (1) the requirements werent really known up front, (2) your assumptions about how things need to work were wrong, and (3) your assumptions about how the new system features will work were wrong, is the root cause of scope creep. I cant tell you how many large projects discovered more than half of the costly requirements after formal discovery was completed.

Solution strategy: Make the discovery phase longer, and when its complete have a signoff sheet for a strict feature and data freeze. Make the project team as small and tight as it can be, and do not hire more than one consulting company (to reduce finger-pointing). Work to constantly improve trust among the team members. Kick people off the team who blame. Keep executives and bean counters as far away from the project as you can, and limit big review meetings. Focus everyones attention on business value rather than abstract or arbitrary metrics and project dashboards.

Im currently reading the book Being Wrong Adventures in the Margin of Error after having finished Wrong! Why Experts Keep Failing Us. So maybe Im a little jaded, but it sure looks to me like cost overruns are the result of bad assumptions, fragmentary information, incomplete requirements and low trust.

Interestingly, overruns are much less common for follow-on projects, where both sides have put the time in to develop good assumptions, a solid understanding of the real requirements and a trust relationship. So for initial projects, we clients and consultants have to stop the pretend-certainty about our projects.

The truth is we dont really know, and were not willing to spend the time and money to get sufficiently knowledgeable about, all the niggling details of a new project. We run off and get a budget without knowing what the project will really entail. And then we discover too many plot complications after weve reached the halfway mark in the project. For those hoping that hybrid agile techniques will solve the problem, I havent seen much help there.

In contrast, the real agile approach admits we dont know, and simply scopes the project deliverables dynamically to
fit within the budget and schedule. The team discovers as they go, prioritizes as they go and focuses on maximizing business value instead of fixed (and possibly random) criteria. When done right, agile makes the bean counters happy (they can claim on time, on budget) and gets the most important stuff out to the users as soon as its done.

>> Agile project management: A beginner's guide <<

Read more from the original source:
Anatomy of a cloud project cost overrun | CIO - CIO