What Your Cloud Consultant is Trying To Tell You

CIO - Cloud consultants aren't that much different from the consulting and contracting firms that IT has used over the years. But the economics of cloud consulting are a whole bunch different from what the Big 5 firms were doing with SAP and Siebel. Thanks to the price points of cloud solutions (typically, a monthly fee) and the expectation of Web open systems (all I do is point and click, right?), behemoth consulting gigs are few and far between.

To a large degree, the Agile method means not just quicker cycle time -- it means smaller project chunks. And your consultant has to achieve some level of profitability on each of those chunks.

Since the development and deployment projects tend to be smaller for the cloud, the commercial language is filled with a new set of euphemisms you need to understand. Here are some to look out for:

"Your project will leverage offshore resources." Many firms are able to effectively use development, test, and data scrubbing personnel offshore, keeping your costs low while maintaining the margins the integrator really needs. While two shifts a day can make for a quicker cycle time, it also opens the door for subtle miscommunication between your staff, the onshore team, and the offshore team. The early warning signs of trouble: a consultant's inability to say "no' to a questionable requirement, and a denial that there is a feasibility, quality, or schedule problem brewing.

There's another issue: do you really want your data going offshore? For many financial institutions, this is a bad plan even if not strictly verboten. Think about how you're going to pass your next PCI or process compliance audit before you agree to offshoring data.

What your vendor is telling you here is, "there are a lot of low-value hours in this project...which we're staffing with low-cost people." Think about whether this vendor is really being a consultant...or just a contractor.

They've made a fixed price bid, but it seems awfully high. As I wrote in the price isn't right, CRM projects have a larger proportion of integration and data crunching than most other enterprise software. Integration and data cleansing/reconciliation are inherently uncertain in scope and cost. Worse, CRM projects are often over-specified with requirements whose business value hasn't been thought through. And even if they have, the likelihood is that the requirements will change in 18 months.

By putting out a high fixed price bid, the vendor is saying either (1) they don't really want this project, or (2) the project requirements are too vague or overblown, so there's a lot of risk in it. Often, issue #1 is a result of issue #2.