Somebody once said that cloud apps are just like enterprise software, only more so. OK, nobody ever said that. Actually, most everyone says they're much easier and faster than traditional software projects. And done right, cloud projects can be. Because done right, they are smaller, simpler, and more separable than tightly-coupled software projects were.
But done wrong, they have all the pitfalls of large software projects...plus some new ones you never had in the client/server world. Because in cloud projects, you are typically trying to leverage existing services (in mashups, RESTful calls, or SOAP interactions) that you don't control. The more of those existing, external services you use, the higher the likelihood of surprises that are rarely pleasant.
In recent weeks, I've come across cloud projects that have been burdened with executive mandates that practically guarantee failure. Watch out for decisions or statements that follow these patterns, as they increase the risk of cost, schedule, or quality problems:
1. "We can't give you guidance on the priority of deliverable items: they're all hard requirements!" As an executive, it's easy to fall into this kind of thinking...particularly if you've already sold your customers and constituencies on the benefits of the project. But the reality is that tradeoffs will be made during the development, test, and deployment of any project — the only question is whether they will be hidden/political/random or open/rational/economic. There are no two requirements that are of exactly equal cost or equal value/benefit to the business. So to pretend that they are of equal importance (or worse, of infinite/non-negotiable importance) leads to distorted business decisions, at best. At worst, this kind of dictate leads to teams that cannot make decisions and will not communicate bad — but real — news up the chain of command. The end result is an "everything's fine until the last minute" syndrome, which classically leads to nasty surprises at the end of the project.
In cloud projects, the real opportunity is to have quick, low-cost work-arounds that provide a bare-bones feature in early iterations, and to gradually expand the feature coverage in later project cycles. The all-or-nothing mandate makes you miss this opportunity, costing the project time, money, and risk. If Agile projects teach us anything, it's that requirements should be treated as malleable and adaptable to user feedback. This goes double for CRM projects, where the usability of a feature can be more important than the underlying function (because without user adoption, the feature will never take root).
2. "We need to have all parts of this project on a common tool, library, or infrastructure element." Of course you want to keep the number of moving parts to a minimum, and it's important to have as few learning curves as possible. But cloud projects need to be flexible — because things move fast out there. You may discover that one version of a PHP library works really well with one cloud service, but is not supported by another cloud service. One payment gateway's API may have a detail that is not supported by the gateway your firm has standardized on. You may need to use SOAP, REST, and naked XML interchanges in tandem.
A key advantage of the cloud approach is it provides a lot of insulation from the underlying implementation details. So don't overdo it with the "one size has to fit all" directives.