Yesterday I was meeting with IT leaders from a very large company with a global footprint. When we talked about their lessons learned in a recent CRM implementation, they shared that after purchasing the software and spending one year and $12 million on implementation, they canceled the project due to a timeline and cost that was no longer feasible. They sited the root cause as customization ‘requirements’ that had become too complex. Oddly though, after canceling the project the company adopted a Software as a Service solution that allowed zero customization and forced the company to change all its processes and policies to fit what the software would do. These leaders reported that their company has been using a global implementation of this software across all divisions for the past 18 months and it is a huge success. In fact their top salesperson is the largest user of the software.
I find it interesting that the failed first implementation was caused by trying to customize the software to fit the processes rather than fitting the processes to the software and that this company was later able to put their ‘requirements’ aside and find a way to fit all their processes to an inflexible solution when there was no other option.
What does this story teach us about IT enabled projects? Should we be spending less time gathering requirements and more time learning how to use the standard application? What would we ultimately lose if we did? How much time would we save? How much money would we save? Would our processes become more effective or less effective? Where did today’s processes come from? Are they the result of an engineered solution for the best way to accomplish a task, or are they the result of ad-hoc decisions over a number of years that incorporate work arounds to limitations in tools and information?
What do you think about this story and these questions? What can we learn?
