Unprepared for hidden costs

Packaged applications' ugly surprises include training time, integration woes

The higher up the stack you go, the more difficult it is to account for the hidden costs. Although internally developed custom software shares the same potential for these costs, most of these unforeseen costs are more controllable in a custom software deployment. Internal critics also have more power to affect an internal project's design than that of a packaged one. The luster, self-confidence, and branding of packaged application vendors help to mute corporate Cassandras.

The fact that these large-scale systems work most coherently when accepted in their entirety, without customization, creates an all-or-nothing proposition that's polarizing, increasing both politics and human engineering stress.

Layers I and II: the obvious

There are obvious costs that should never have been hidden from an experienced observer: upgrades to hardware and operating systems to accommodate new, "more robust" (translation: blubbery) program code, and consultants to tweak and modify the packaged code to match the enterprise's requirements, for example.

"It seems like it's always a surprise to the client how much it costs to customize the package when they find out it doesn't have something they want," says Doug Zeffer, vice president of production at Enlighten, an Ann Arbor, Mich.-based Internet professional services company.

"Buyers take for granted a lot of things, don't ask the right questions, and discover after they bought it the features they requested aren't included," says George Brown, president of Database Solutions in King of Prussia, Pa. "And their sense of the complexity of these solutions, because they're packaged, is too low."

Another issue that can torpedo estimators' plans involves underestimating the amount of effort that it takes even great systems programmers to tweak, customize, and continually upgrade a packaged application. A high-performance coder such as Nik Malenovic, managing director at ThoughtSpring Consulting in Chicago, may spend 10 minutes trying to do a task in a new system it would have taken him 30 seconds to do in a system he already knows.

For Malenovic, the coding skills are so ingrained in his psyche that he has to "translate" when presented with another format, and in that case, "familiarity becomes a liability," he says. That liability sneaks into projects when managers, knowing high-performance coders' usual productivity rates, assume the same high rates on new packaged app tasks. Phillip Gordon, a consultant at Neon Consulting Group in San Francisco, points out an expensive hidden cost in Layer II that involves people rather than technology: critical staff being off-line during training.

"Yes, the vendor told you," Gordon says, "and you even paid for the training and set aside the time in the project plan, but when that time comes, their managers scream because they haven't planned for having their staff out of pocket for three days, not doing scheduled work."

Layers III and IV: revenge of the subtle

An even bigger people cost skulks in Layer III: ongoing training and technical support. "The cost of training -- and it's a significant one -- is an ongoing responsibility, and the cost isn't being tracked," according to AMR Research Vice President Bill Swanton. "There's the training you need long after deployment for new people or those who change positions."