Somebody once said that cloud apps are just like enterprise software, only more so. OK, nobody ever said that. Actually, most everyone says \n\nthey'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 \n\nwere.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 \n\ncloud projects, you are typically trying to leverage existing services (in mashups, RESTful calls, or SOAP interactions) that you don't control. The more \n\nof 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 \n\nfor 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 \n\nthis kind of thinking...particularly if you've already sold your customers and constituencies on the benefits of the project. But the reality is that \n\ntradeoffs will be made during the development, test, and deployment of any project \u2014 the only question is whether they will be \n\nhidden\/political\/random or open\/rational\/economic. There are no two requirements that are of exactly equal cost or equal value\/benefit to the \n\nbusiness. So to pretend that they are of equal importance (or worse, of infinite\/non-negotiable importance) leads to distorted business decisions, at \n\nbest. At worst, this kind of dictate leads to teams that cannot make decisions and will not communicate bad \u2014 but real \u2014 news up the \n\nchain 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 \n\nproject.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 \n\ngradually expand the feature coverage in later project cycles. The all-or-nothing mandate makes you miss this opportunity, costing the project time, \n\nmoney, and risk. If Agile projects teach us anything, it's that requirements should be treated as malleable and adaptable to user feedback. This goes \n\ndouble for CRM projects, where the usability of a feature can be more important than the underlying function (because without user adoption, the \n\nfeature 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 \n\nnumber 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 \u2014 \n\nbecause 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 \n\nsupported by another cloud service. One payment gateway's API may have a detail that is not supported by the gateway your firm has standardized \n\non. 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 \n\n"one size has to fit all" directives.3. "We don't have time to do user testing along the way. Leave that till the very end." This is a classic for people with a waterfall, \n\ncommand-and-control project management style, because it satisfies their thirst for certainty. But that comfort is illusory. You don't have to be a \n\nDemming devotee to know that product cost, schedule, and risk are reduced by driving quality into every stage of your development (manufacturing) \n\nprocess, not tacking it on at the end. To postpone user testing is to fall into traps described in the literature over decades (from the The \n\nMythical Man Month to The Agile Manifesto).In cloud projects, this issue is amplified by the fact you are leveraging services that you neither built nor control. The cloud services may do \n\nexactly what your users want...or they may not. Until you actually do a trial deployment of your cloud functionality and all the elements you're \n\nintegrating from outside, you won't know that the project meets user needs. For example, a simple map mash-up may work fine with a single icon, \n\nbut be hopelessly slow or visually messy when trying to paint "my closeby customers."When leveraging public cloud services, you may not discover reliability or performance issues until you've run things under a representative load \n\nfor a couple of weeks. During unit testing by developers, everything may look fine \u2014 but that's because they're doing their tests at 2 in the \n\nmorning. Try the public clouds during busy hours, and you may discover that you need to switch to a different service. This can be a costly discovery \n\nif it's late in the project.This goes double for CRM projects, as the value of the system comes as much from the data in the system as from the software functionality. \n\nAny user test that's done with faked data is almost pointless \u2014 and will give a false sense of security. I strongly advise that the user tests be \n\ndone with a big chunk of real data from the very beginning, and that final acceptance testing not start until the entire data set is in the system. Too \n\noften, you won't see the bugs and shortfalls until users are working with the real thing.David Taber is the author of the new Prentice Hall book, "Salesforce.com Secrets of \n\nSuccess" and is the CEO of SalesLogistix, a certified Salesforce.com consultancy \n\nfocused on business process improvement through use of CRM systems. SalesLogistix clients are in North America, Europe, Israel, and India, and \n\nDavid 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.