Unless you are doing all your system configuration and implementation work internally, you’ll be depending on consultants to get your cloud projects done. When consultants start doing dumb things, your project will be at risk. Even if they get your project done right, if they can’t make a profit they’ll eventually have to bail on you.
Full disclaimer here: I’m a consultant, and this article is written entirely from the perspective of the consultant/system integrator. I’m not defending anybody’s practices, but trying to wave a red flag for those of you in contract negotiations right now.
With that out of the way, let’s start at the beginning—markets. We all operate in competitive markets, and we all depend on proper operation of those markets. If a market is unhealthy, most participants will not do well. You’ll see it first in the vendors (who start acting more and more desperate), but it will show up on the client side as well (in the form of project failures). I’m here to tell you that the market for cloud consulting services is not healthy, even though it is growing like mad. This means you must do your homework and take your time.
Here’s what has made the cloud consulting market treacherous:
- Lots of wanna-be vendors from around the world are trying to compete, blowing the bottom out of the market. Unfortunately, with most low-end vendors the client does not get value without an inordinate amount of monitoring and management. But even if you never consider the wanna-be’s for your project, they are sucking the margins out of the business for everyone.
- The technology platforms have gotten way more complicated, as cloud vendors innovate like crazy. It is not unusual to have to learn an entirely new toolkit or language every year, which means a lower percentage of the consultants are actually competent with all the latest stuff.
- Clients are not doing their homework (if it’s waterfall) or dedicating the quality of resources to the project (if it’s agile), so they don’t really know what they need. Even though they don’t know the requirements, they are demanding (and, unfortunately getting) fixed-price bids before discovery has even started. I’ve covered this silliness in a half-dozen articles, but the situation is not improving…and it leads to lawsuits.
- Clients are not treating their cloud computing software as a long-run corporate asset. Ladies and gentlemen, just because you don’t control the hardware and operating environment doesn’t mean it isn’t IT. This is a fatal error, because it means clients are not taking their projects seriously enough (see above).
- Somebody has created an urban legend that consulting projects for cloud IT should cost “about 1x the annual license revenue.” Salespeople will tell you this, but I have seen no data to support it. Indeed, if you look at the annual license revenues of most cloud vendors in comparison to on-premises software, you’d expect the multiple to be many times larger. Magical thinking aside, this is still IT. Given the number of engagements I have as an expert witness, I think this price expectation is dangerous.
If you didn’t know better, you’d think this was all great: lots of competitors lowering the price bar and fighting to improve themselves while the invisible hand of the market does its thing. The problem is, economists know that invisible hands cannot protect against stupidity if everyone is acting stupid. That’s what causes a “race to the bottom,” where nobody wins.
Here’s what I’ve been seeing in cloud consulting projects over the last couple of years:
- Clients are shopping for project price, not business value. There is too little emphasis on trust and too much emphasis on micromanagement. This is bad for everyone, no matter how much you believe in bean-counting.
- The win rates on project bids have gone down. This means all the vendors are scrambling to churn out more proposals without time for due diligence. As the selling cost of each project has risen, the opportunities for real innovation during the project have gone down. This means more cookie-cutter solutions that result in lower user satisfaction.
- Consultants’ sales reps are way too eager to say, “yes we can,” even when the client doesn’t really know what they need and the technology is not known for certain to be capable of the task. The sales rep makes the sale, and only as the project gets underway (typically around the end of discovery) do the impossibilities surface. I am aware of several multi-million dollar projects whose budgets were less than a third of what was required once the discovery scoping was done. There are a few other projects where “discovery” was still underway after UAT. Consequently, project managers on both sides of the table will go through some very painful negotiations, with huge change orders (or cancellations, or law suits) forthcoming.
- Clients are too willing to use overseas resources without the needed oversight. As I wrote here, one of the critical enemies of projects is distance … and overseas resources are not just physically far away: They can also be distant in time-zone, language and business culture. The assumptions they make about how your business works, what your users value and how you manage projects can lead to enormous problems that don’t become obvious until late in the project. Even if your consultant manages all this, you should still be on alert.
Emptor has been caveated. Now what?
If there’s one common thread through all these issues, it’s time. Take your time in the pre-project homework and be thorough in vendor selection.
If you’re going waterfall, write a real spec and expect to spend some money on consultants’ discovery and analysis before the project begins. If you’re going agile, make sure that you really are. Executives need to sign off in blood that the project team has full authority to reset scope and priorities with each sprint. With either waterfall or agile, check references thoroughly and use questions like these to screen consultants.
The final use of time is to build trust. This is the backbone of a successful project. If either you or the consultant can only trust the other party to take shortcuts and make beggar-thy-neighbor decisions, you’ve got the wrong relationship and should cut it off as early in the project as possible.