Case Study: Customization Surprises
It was late fall, 2005, at the headquarters of a well-known company we’ll call Company W. The selection of the (fictitious) Really Great Warehouse Management System (RGWMS) for the company’s three manufacturing plants was a sound one, everyone felt, in part because it would cost about $1.3 million less than the industry-leading packaged applications. The company planned for implementation to begin after the first of the year. This would allow time for formal approval of the project’s $1.8 million budget.
I had come on to the project in February 2006. Much of the spring and summer of that year was spent running the software through hundreds of business scenarios to identify “gaps” between how the warehouse would process product movements in the warehouse, such as pallet put-away, picking, staging, and shipping, and what the software could perform in its current “out-of-the-box” state.
The project team began logging a significant number of gaps, which is normal for a packaged software application. But one area of missing functionality was particularly maddening: the limited ability of the software to process radio frequency scans of the bar-coded label placed on each pallet of product.
For each pallet, we had designed four to six scans as the product was received from the manufacturing side of the building. Each scan would tell RGWMS where the product was, where it moved from, and where it was supposed to go. This particular version of RGWMS, however, did not process scans the way we had expected a normal warehouse management application would. When one of the consultants explained how this version of the software processed scans, I had three words: You. Are. Joking.
It seems that for every movement of a pallet inside the warehouse, RGWMS expected that a Transfer Order, or TO, would be created, by, say, a warehouse supervisor using the system. Then, when a forklift operator scanned a pallet to move it from point A to point B, he was merely “confirming” the TO that had already been set up in the system by the supervisor. This meant that a facility producing 2,000 pallets per day, with each pallet being scanned four to six times before being shipped, would require someone to enter 8,000 to 12,000 TOs into the system each day, one at a time.
Maybe there was a warehouse out there, somewhere on the planet, that could use this type of scanning process, but for our project it was completely unacceptable (and maddening!). So we invested hundreds of thousands of dollars to automate the TO creation process, mainly by creating the TO “on the fly” whenever an operator scanned a pallet. When a pallet was scanned, a simultaneous transaction in the background would create the requisite TO.
The result: about four extra months to complete the changes to the software, pushing the three launch dates out and adding unplanned expenses for programming and extended engagements for the project’s consultants. The total cost came to $3.1 million, nearly exactly what it would have cost to implement either of the two other industry-leading applications the company had considered.
Development costs were under-estimated, due to insufficient exploration of the particular version of RGWMS the company had chosen. A conference room pilot (CRP) would have been a good way to more thoroughly identify the version’s functional gaps. In a CRP, the software is loaded on to a test server, configured the way the enterprise will use it, and loaded with some of the company’s real data. Once this is complete, users spend a few days performing the transactions they would use in the test system, and along the way gaps – missing functionality – are noted. Usually the vendor’s technical team is also present so as to explain how the software works in each step of the process.
Software does not respect rules of common sense; it only knows what the programmer wrote in its code. Just when you think you understand how an application works, it throws a monkey wrench into your carefully ordered world, nixing your plans and vacuuming up money you didn’t budget. In this case company W thought it knew enough about RGWMS to estimate implementation costs.
There is a tendency in cases like this to get the project moving, and so assumptions are made – almost subconsciously — about what the software will provide and how it will perform. These assumptions almost always lean to the optimistic side; that everything will somehow work out fine.