The most expensive software requirements aren't the ones that cost a lot to implement. They're not even the ones with the biggest over-runs. No, the most expensive requirements are the ones that should never have been started, the ones with marginal or even fictional business value — and in CRM, like no other class of enterprise software, the parade of bogus requirements seems never-ending.
The root cause of excessive CRM customization requirements is typically one of the following:
- CRM has been oversold by the vendor with dazzling demos and dodgy statements that let your team mislead itself into over-optimism.
- Your internal champion has overreached in order to overcome internal opposition and get the project approved.
- Users have worked with a "similar" CRM at other companies that over-customized their systems.
- The executives just assume that "any CRM does this."
- Users have overly optimistic assumptions about ease of use.
By now, everybody knows I'm an agile zealot, if not a waterfall bigot. The magic of agile comes from incrementalism: Building only what's inescapably required now and adding features over time so that the system can evolve with changing business requirements and political necessity. This lets IT escape the tyranny of "slash cut" programs and the inevitable issues of large, monolithic projects.
Agile remains vulnerable to bogus requirements and sloppy thinking, though. Let's face it: Using squeaky wheels to prioritize can only take you so far. The shrillest voices are seldom the most rational.
Remember, Money Makes the World Go 'Round
Your friends in finance stand as the first powerful line of defense. There's nothing like a budgetary requirement to calm things down. The trick is making the requesting department pay for the improvements out of its own bucket. If there's one part of economics that always works, its the pricing mechanism. Make sure nobody gets a free ride on somebody else's budget line.
Incremental project dollars are only part of the story; there are other "invisible impacts" of all new functionality. Organizations can't just assume these other ramifications away:
- Most new features involve some new data. Who's really going to do all that data entry? If the data comes from another system, who's going to validate the data that comes over? Whose job will that be, and how much of his/her day will be consumed by this new task?
- Most new features mean some new user interaction and automation. Who's going to validate that the new feature automates the right thing the right way? Who's going to handle the inevitable debate about the way the business process should work and guide the testing of that automation when questions arise?
- Automation requires some training and hand-holding, particularly during the break-in period where users will point to things they don't like and call them bugs, even when they're required features and controls. Who's going to do that training and user support?
- Almost always, reports and data extracts will be required. Who's going to specify what those reports do and validate the semantics of the underlying data and the information products? As I mentioned recently, unchecked CRM reporting is often its own Tower of Babel.