What Your Cloud Consultant is Trying To Tell You
Consultants have been a mainstay of IT departments forever. But in the cloud the commercial language is filled with a new set of euphemisms you need to understand. Here are some to look out for.
Wed, October 26, 2011
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.
In cloud projects, we strongly recommend moving your projects to small phases that match the Agile methodology. Each task may be fixed price, but the overall project will not be. Why? Because you don't really know the business value of certain requirements when you start. Since you don't know the benefits yet, there can't be a real ROI calculation. Instead of mandating a laundry list of tasks whose value isn't known, just spend incrementally on the things that are immediately obvious, with overwhelming value. Spend only to the point where you start seeing the business value of the next task diminish, and then stop.
