Any big software project is vulnerable to the evils of scope creep. Project estimates are wrong, new requirements are added, and the next big bang release falls farther off schedule and out of budget. What are the specific tactics that can lower the impact of scope creep in CRM systems?
CRM systems are different from most other enterprise applications. While some requirements are non-negotiable, there is far more room for redefining requirements and deploying functionality in an incremental way. This means CRM systems can use a "by-the-drink model" of investment, rather than the "bet-the-farm model" characteristic of traditional enterprise software.
SaaS based CRM systems give you even more flexibility, as there are no hardware or heavyweight operational issues to deal with-scaling up or turning modules on is just a phone call away. CRM systems with solid web-services APIs such as Salesforce.com's make for even more flexibility in development and deployment cycles.
Here are tactics that fight scope-creep, borrowed from several disciplines.
Deliver small units of value to the business
Working incrementally isn't a bug-it's a huge feature of modern CRM systems. Thanks to the loose coupling of web services, there is every reason to keep functional deliveries small, simple, and separable. Sometimes highly desired feature enhancements take only a few man-hours to develop and test, so deployments can happen twice a quarter or even more frequently.
Taking this idea further, it is sometimes desirable to deploy only a portion of functionality even if an entire feature set is ready. Keeping features in reserve can ease learning curves, acclimate the organization to smaller and more frequent deliveries, and provide IT with "dry powder" for the next deployment cycle. (The ultimate weapon against scope creep is delivering something!)
Push back hard on requirements
Since the first line of defense against scope creep is avoiding spurious requirements, use the philosophy of Agile projects (even if you don't use the specific techniques). The user may not really know how important a requirement is. And even if they're adamant about a feature, they can rarely quantify the business value of having it. So get a core system-essential functionality onlyup quickly and add to it as the business case for "the next feature" becomes crystal clear.
Where this tactic runs into trouble is when your new CRM system is replacing an existing one. User expectations will have been set by the previous system, and they'll insist that they can't live unless the previous functionality and all data from the previous system is available on day one. This sets the stage for a "big bang" release and practically guarantees scope creep. It may take some hard arguments at long meetings, but you have to get across:
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.