A NOSTRUM of the late '90s was to dump internally developed, custom applications in favor of packaged applications. But the hidden costs of those packaged apps are coming back to haunt many companies that implemented them too hastily.
The motivation behind that lurching, tectonic shift was the horror generated by over-budget attempts to build systems internally. An entire generation of in-house programmers was pulled from projects and thrown at ERP and CRM systems -- or out the door -- because executives believed that packaged apps would fix the problem of hidden costs.
"Companies that had been building their own software for 40 years started thinking maybe they didn't need all those people, and that was a sign of something bigger: a crisis of confidence," says Tom DeMarco, a Camden, Maine-based principal at Atlantic Systems Guild and co-author of Peopleware.
DeMarco thinks the rush to packaged software was accelerated by organizations losing confidence in their ability to invest wisely in IT and the creeping belief that original works of code were merely a cost, not an investment. But the hidden-costs problem didn't go away with the adoption of packaged apps, which can hide even more expenses.
Tackling the hidden costs of packaged software can also drag down projects and hopes of simple adoption strategies.
"If companies were feeling defeated by custom software, then packaged software has proven an even greater defeat. The fiasco with Oracle last year indicates that even upgrading a package isn't affordable," DeMarco adds, referring to the snarled application-migration problems last August that purportedly cost Agilent more than $100 million.
Uncovering layers of hidden costs
Why do hidden costs seep into every significant software project, custom or packaged? To understand, you have to apply what I like to call the OUCH (Overwhelming Unforeseen Cost Headaches) five-layer model of potential hidden costs to your packaged software deployment project.
Layer I is the set of costs that appears on any vendor's or SI's checklist, including staff, the packaged application, and dedicated hardware.
Layer II, the "absolutely should have known" layer, contains costs that any competent project manager would have accounted for in scheduling -- items such as package customization and post-deployment, dedicated tech support.
Layer III includes the costs tangential to the project's mission and specifics: efforts the organization wouldn't have required without the project, but ones that lie outside the way normal organizations scope deployment projects. Tangential costs include post-deployment training, integration, and the repurposing, firing, and hiring of personnel associated with the application.
Layer IV includes costs that the deployment creates external to the project itself but become an expense to the departments touched by the software package. External costs include changes required to other systems (electronic and manual) and loss of effectiveness during the early part of the learning curve.
Layer V is the organization structure and superstructure layer. It includes project-generated distortions of effective behaviors throughout the organization for political or emotional reasons, and opportunity costs of putting one project ahead of another.
