Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Anatomy of a cloud project cost overrun

David Taber | Feb. 7, 2017
A handful of areas in cloud integration projects produce cost ‘surprises’ with alarming regularity. Recognizing the pattern is the first step in solving the problem.

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.

2. Custom code

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 (SFDC) platform makes it tempting for both user interface and business logic. 


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.