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.
I know this style of project drives the accountants crazy, but it should be music to the CFO's ears. Because you'll be building less, and spending only where you can really see the business value.
• The consultant resigned the account. Smart consultants know they have to trim the bottom 10% of their clients every year. The consultant may introduce another firm in, or simply decline to bid the next phase. One way or the other, leaving money on the table is a pretty significant statement.
What does it mean when a vendor walks away? Look at your side of the project for signs of too-rapid changes in requirements, personnel, or priorities. See if there are problems with too-many-cooks, excessive politics, unachievable expectations, or impossible deadlines. Also look for issues of staff competence, internal resistance to change, or clinging to worst-practices.
• The consultant wants to rip and replace. This may be couched in terminology like "rearchitecting" or "new technology foundation." But it amounts to "start over," with all the attendant risks and benefits. Of course, this may be exactly the right prescription...but what else could it mean?
All too often, it means "we aren't familiar with this technology" or "our engineers don't like working with it." Obviously, you don't want to stick with antiques and odd-ball technology, but almost any product has a newer version that leverages new interfaces and languages. Whenever you hear the R&R recommendation, ask about what is fundamentally un-achievable with the technology path you're on. If you get good answers, proceed. If not, keep questioning. See if the real problem is "my vendor doesn't have the right subcontractors yet."
• They raise their hourly rates. Depending on who and where they are, this communicates different things. As I wrote over a year ago, in the big metro areas there is a severe shortage of real talent, with a resulting bidding war. Big cloud consultancies have $4,000 bounties on the right talent, and in the Bay Area Google, Facebook, Zynga, and LinkedIn are vacuuming up all the Java and Ruby developers.
That bidding war means a rising internal cost for the consultancy's supply...and they can get pickier about the demand they choose as well. The key issue for you: with this price increase, is the consultancy actually delivering you more value (by upgrading the depth and breadth of their staff), or are they willing to commit to tighter project and quality parameters? If not, you may need to look for alternatives.
David Taber is the author of the new Prentice Hall book, " Salesforce.com Secrets of Success" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy focused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and David has over 25 years experience in high tech, including 10 years at the VP level or above.
Follow everything from CIO.com on Twitter @CIOonline.
Read more about cloud computing in CIO's Cloud Computing Drilldown.