Asia's Source for Enterprise Network Knowledge

Monday, February 20th, 2017


Anatomy of a cloud project cost overrun

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 it’s 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, it’s not particularly actionable.  So let’s take the next step to understand the driving specifics, and what steps we can take.

The four horsemen of the cost overrun

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 can’t 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:

1. Data integration/migration

This twin-headed beast can involve some very serious surprises, as it’s impossible to detect many of the issues until you’re 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.