Over the course of too many years, I've said that you can't make a user interface that's too easy for users. But cloud-based software vendors have \n\nessentially done just that. System setup is now deceptively simple, and too many sales pitches tell stories of how users can set up a cloud-based system \n\nthemselves.The problem is, users (and junior consultants) will feel empowered to set up cloud-based systems up without a plan or even a model for proper system \n\nexecution. The cloud system's GUI will let them do so. A few months later, the system will be mired in bad data (that was too sloppily imported), a silly \n\nobject model (that was too easily created), and a cacophony of business rules (that were never vetted). Here are some important steps you can take in order to avoid pain later on.Agile != Ready, Fire, AimToo many sins of omission have been committed in the name of Agile. Agile projects may be light on documentation, but they're supposed to be heavy \n\non domain expertise, user feedback, and \u2014 most critically \u2014 technical excellence. So don't let anyone make the excuse that because the \n\nproject is Agile there isn't time to think through classic IT issues.In cloud CRM systems, some of the messiest novice errors come from a misunderstanding of the object model. Leads are confused with \n\nopportunities. Assets are confused with products. Entitlements are confused with contracts. By using these terms interchangeably, undisciplined users will \n\nend up asking for extra fields to be added in the wrong places. Consequently, imports and ongoing data feeds will be scrambled. Because the data is in the wrong place, the users will soon ask for triggers to \n\ndenormalize fields or replicate entire objects. Later, they will ask for functions and triggers that are essentially reinventing the wheel of standard CRM \n\nfunctionality. This isn't just cloud CRM systems: nearly any cloud DBMS can be easily misconfigured with data models and entity relationships that won't serve the \n\nbusiness need.Not Just SemanticsThe next trap for novice users of cloud CRM systems stems from imprecise definitions of the state and meaning of data. The UI will not challenge \n\nblurred or even contradictory definitions. While this issue is starkly obvious with pick lists (in the choice and number of values), it also comes up in the \n\ndefinition of record types and the setup of account hierarchies. Classic examples of blurred meanings include:\n\n\u2022 What does it mean to be a lead? How many lead statuses are there (e.g., open, contact attempted, contacted, qualified, unqualified, dead)?\n\u2022 What does it mean to convert a lead? What are the qualification criteria required before conversion?\n\u2022 When is an opportunity created? What does it mean to have an opportunity of $0 value?\n\u2022 What are the sales stages for an opportunity? What are the entry and exit criteria for each of the stages, and how long is each stage expected to \n\nlast?\n\u2022 What's the difference between a no-action opportunity (there isn't a deal here for any competitor), an unqualified one (there's a deal, but not one that \n\nmatches us), and a lost opportunity (where we were in full competitive status, but were not selected)?\n\u2022 What are the criteria for a Severity-1 vs a Priority-1 case? What are the SLA thresholds and ramifications for each of the severity and priority \n\nlevels?\n\u2022 What's the difference between a "strategic customer" and a "mid-market customer"? If a strategic account has only a small departmental deal, does \n\nthat make it a mid-market opportunity?Some of the ambiguity and imprecision surrounding these status and criteria come from the political consequences of their definitions. If it's too clear \n\nwhat's in and what's out of the sales pipeline, this can make sales or marketing look bad. The problem, of course, is that a CRM system is going to enforce \n\nlogic and consistency \u2014 and the ambiguity around meaning can cause ridiculous misrepresentations in reports, alerts, and dashboards. The \n\ntemptation among novices is to try to blur the clear logic of the CRM system, rather than tighten up the definitions of their own terms.Shoot the MessengerIn both marketing and sales, there's a real aversion to lost deals and weak leads. The temptation is to simply delete all the losers from the system, so \n\nthat all that's left are winners and hopefuls. Unfortunately, as Bill Gates wrote, "success is a lousy teacher." By erasing data \u2014 even clearly bogus or corrupted records \u2014 we're \n\nerasing the possibility of learning anything. Instead, leaving the "bad" and "loser" data in the system leaves open the possibility of troubleshooting and \n\nrectifying the business process that created them. Too many bad leads? Maybe that marketing vendor we use isn't careful enough. Conversion rates too \n\nlow? Maybe we should stop buying leads from a list broker.This last issue can be often solved by simply removing the Delete privileges from most users. But the general problem remains: just because clouds \n\nmake it look easy doesn't mean that users can forget about IT and system design issues.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. \n\nSalesLogistix 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 \n\nlevel or above.Follow everything from CIO.com on Twitter @CIOonline.