o Do you really want the new system to have all the data quality and functionality problems of the old one from the outset? Isn't the whole point to do better?
o Users and customers have become used to screens, reports, and functionality of the existing system, and the transition needs to be as smooth as possible. A "slash cut" from one system to the other is likely to be disruptive, while a staged, incremental switchover will be less jarring.
o The data in the system-transactions and evolving customer relationships-must not be put at risk. The core data and functionality must be stabilized in the new system before it can be the foundation of the higher-level system functions. Some period of either "parallel play" (redundant system operation) or diminished functionality is inevitable and should be built into the plan.
o The impact of a CRM system depends upon users actively leveraging the system to collaborate around the customer relationship. If the users aren't there, it doesn't matter if you add more functionality-there won't be more business impact. Furthermore, adding more (complex) features to the system may actually work against usability and adoption. This user adoption argument can become a gating factor in controlling scope.
Call their bluff
Some requests for user features are simple and straightforward to implement. Other "simple things" can involve expensive data rework and external system integration. When you suspect a big "nice to have" in the feature list, use budgets to call the requester's bluff. Create a good cost estimate for that unit of functionality, and tell the requester that work will start on that element as soon as they provide the budget. Don't start work until they provide a specific charge number or inter-departmental budget transfer.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.