CRM in Manufacturing Doesn't Need to Be Perfect

Why IT deployments are better off flawed

Phil Mickelson became the first wire-to-wire winner in the 68-year history of the Pebble Beach Pro-Am tournament on February 13, 2005, missing the tournament scoring record by only one shot. However, his accomplishment didn't come without mistakes; he missed six birdie putts and had back-to-back bogeys.

Customer relationship management (CRM) implementations in manufacturing are a lot like golf. They don't have to be perfect to be hugely successful. Despite what many companies claim as near-perfection in IT projects, industry analyst firm Gartner says that 83 percent of IT projects fail to achieve their anticipated return on investment. The majority of companies struggle with IT projects and if Gartner is to be believed, eight out of 10 fail.

Don't Wait to Deploy

One major reason for this is the fact that IT departments wait too long to deploy the applications, hoping for perfection. This hesitancy to deploy until every bit of the functionality is included causes projects that might have only taken a few weeks to achieve value end up taking months or even years. If time was not a factor this approach would have merit and is certainly easier on the IT department who rarely gets credit for business success but always gets the blame when applications have flaws.

The dirty little secret is that software is never perfect, and time is always a factor. The paradox that causes these CRM initiatives to fail, or at least fail to meet expected results, is that in a development initiative where IT is building or modeling the application:

  • Functionality rises at a decreasing rate over time while
  • Expectations rise at an increasing rate over time.

The longer it takes to deploy, the more functionality and less flaws users expect or tolerate from the system. The sooner the deployment, the lower the expectations and the sooner the organization will receive value. Managing expectations is just the beginning.

Figure 1 illustrates the functionality vs. expectation over time and the ideal timeframe for deployment. Click here to view.

Measuring Value in an Organization

The value to any organization as measured in ROI and customer satisfaction is the ultimate measure of success. If the business anticipates a $10 million improvement over five years, each month of delay in deployment represents $167,000 in lost opportunity ($10,000,000/60 months). If a project can be deployed and achieve just half the functionality in three months versus all the functionality in 24 months, the value to the company would be $1,750,000 (half of $167,000 over 21 months after the three-month deployment). In other words, delaying the deployment to achieve full functionality costs more than just time, it threatens the success of the project.

In addition, these initiatives are usually competitive advantages for the company. Competitive advantages have a decreasing finite life, so the longer the delay, the smaller the advantage. The largest competitive advantage is early in the implementation. Time moves so fast for businesses today that this advantage cannot be regained and is gone forever.

How to Get the Most Value Out of Your Implementation

The most successful implementations share three factors:

1. They manage expectations. Managing expectations is critical in setting up the project plan. The promise of a fully functional application in record time is foolish.

2. They implement in phases. By breaking down the project into quarterly phases with tangible deliverables that bring value to the business, momentum is maintained, value is achieved and expectations remain in balance.

3. They put the application into the hands of the business users early in the process. By doing this, the project has a far greater chance of catching problems when the price of failure is much lower. If a boat is off course, the longer it continues off course, the more difficult it will be to reach the final destination. The sooner the course is corrected, the less wasted energy and money.

Case Study No. 1: A Successful Implementation

For example, in one very successful implementation, the project plan was mapped out so that each quarter, a piece of the project would be completed and provide value to the end users. At the end of each quarter, there was a mad rush to meet the deadline and the deliverable was achieved. The phases were completed as follows:

  • Phase one was an accurately priced professional proposal that could be generated in minutes.
  • Phase two provided integration with the customer's homegrown legacy systems that automatically generated performance curves. (This was essential for their customers and took the engineering department days to generate prior to this project.)
  • Phase three provided the electronic integration with the company's computer-aided design (CAD) system to allow certified drawings within seconds of configuration. This saved the customer nearly four weeks in production delay once the order was received.
  • Phase four involved dynamically generating a bill of material that integrated with the enterprise resource planning (ERP) system, eliminating order entry errors and reducing order entry time from a day to a minute.

One of the many benefits of this project was that sales and marketing received significant value from the application within 90 days. Their expectations were low and the functionality they received was significant. Sure, there were issues that needed to be worked out, but the users were able to voice their concerns early, which led to modifications to the project that were unforeseen and would have been expensive show-stoppers later in the project.

Had they waited for the complete functionality before deployment, the cost to fix the bugs would have put the project in jeopardy and severely reduced the return on investment. Instead, the changes were made and the project continued on schedule, eventually finishing on time and under budget.

Value is not gained until the application is deployed to real users, outside of the project team, who do not know all the intentions of the project but who ultimately will be expected to use the application in their daily job functions.

Case Study #2: Don't Wait for Perfection

One manufacturer put together a very comprehensive project plan, executed it flawlessly and even put on demonstrations to the sales team showing them how it worked and how much easier their job would be when they finally got the technology. The problem was that these demonstrations did not include the user actually physically working on the system. The engineer who did the demonstrations made it look so easy, everyone enthusiastically praised the project. When the application was finally deployed, the users found that the application was too difficult and time consuming to use and the project that was considered wildly successful turned out to be a disappointment. Even though the project team had kept the end user involved and included along the way, they never actually required them to test and use the application until IT felt it was "perfect."

Why does this happen? IT has no incentive to deploy a system until it is perfect because they are measured by the quality of the deliverable and they rarely get the credit for the value achieved once it's deployed. If the application helps the salesperson sell or helps upper management better control margins, the credit will likely go to the business users, but if problems arise IT usually gets blamed. So their goal is to make the application as perfect as possible before deployment in order to reduce the complaints. Unfortunately, the return on investment gets delayed and the software held responsible.

Case Study #3: The Importance of Rapid Implementation

Another example that emphasizes the importance of rapid deployment is the tale of two competitors. The first company embraced a CRM technology and began to develop their application with a goal of providing a perfect system that automated the quote-to-order process and required minimal engineering resources from quote-to-build. While this was an admirable goal and one that they ultimately achieved, the time involved in putting all this functionality into the system severely delayed their time to value. Since this was considered a strategic advantage for them, they did not want to tip their hand and deploy a portion of the application until it was completely functional. Two years later, they are finally deploying the application and the value is significant. The expectations however, are even more significant.

Their competitor, who was late to embrace the technology and who knew they were behind the power curve to streamline their processes, chose to deploy only part of the application for part of their product line. They chose their most popular product that represented half their sales volume and developed a no-frills quote-to-order system within three months. Even though they started over a year after their competitor, they deployed it to their channels first and received value six months earlier. Anticipation was low and the functionality deployed exceeded their dealer's expectations. While the application was not nearly as feature-rich and lacked much of the functionality, they achieved a higher return on their investment earlier than their rival.

Conclusion and Recommendations

Delays in application deployment cost companies dearly and dramatically reduce the anticipated return on investment. If projects get delayed beyond their expected date of deployment, senior management loses confidence and the project loses momentum. This can be very dangerous in an organization where there are multiple priorities and where strategies may shift due to economic or competitive pressures.

Management should require project plans that achieve ROI in a phased approach for the following reasons:

  • To maintain momentum over the project life cycle.
  • Phased implementations with partial functionality have a higher chance for success.
  • Roadblocks or delays are discovered earlier in the project, relieving upper management worries.
  • By requiring short term deliverables, the steering committee can provide better direction and take the necessary action to maintain the project momentum.

About the Author: Jim Hessin is a Cincom Manufacturing Business Solutions senior advisor in the Quote-to-Order practice. Prior to Cincom, Hessin was a manufacturer's representative for eight years, specializing in electrical and electro-mechanical motion control solutions for special machinery OEMs and end-users. For more information, you can contact him at [email protected].