The Myth Of Off-The-Shelf KM Software 

By Scott Ryser

Even though commercial off-the-shelf software (COTS) is often considered less risky and less expensive than custom code, that's not the case when it comes to large-scale knowledge management (KM). KM deployments are plagued by security issues, budget overruns and early obsolescence for one reason: software modifications never go smoothly. 

It's COTS in name only 

KM software packages are about as close to plug-and-play as flour and sugar are to a birthday cake. Extensive customization is always necessary, and the final price tag for fully configured COTS is easily four to ten times the original software license fee. But there's a lingering belief (hammered into us since the '80s when packaged applications were introduced), that any off-the-shelf software is categorically more cost-effective and 'safer' than any custom application. This may be a comforting notion, but it's simply not true. 

Acquisition and customization aside, the real cost of software comes from supporting and maintaining it. About 80% of a system's lifetime cost is incurred after deployment,1 which sheds a different light on the initial purchase decision. If your criteria are cost, performance and schedule, you must project the total price of ownership in each category to compare systems accurately. 

What you get—and what you don't 

By definition, COTS vendors maintain complete control over their development and their source code. Customers willingly forego access to those in exchange for lower R&D and manufacturing costs (spread across the installed base) and the very real benefits of a broad user community. This is a good deal for both sides— until market forces prompt your COTS vendor to sunset the package you're using. If you're several releases behind due to budget constraints and they're discontinuing support for your version in 90 days, you've got a serious operational problem. 

Playing out the scenario, your next move (at least until a new budget is approved) would likely be to contract out maintenance and support. At current rates, that option would cost 5 to 7 times your total software and maintenance expense for the past three years.  This isn't an expenditure that anybody anticipated back at the budgeting stage—but it's certainly a factor in the total lifetime cost of this particular system. 

COTS TECHNOLOGY IS MARKET-DRIVEN. IT'S ALWAYS CHANGING, SO YOU'RE PERPETUALLY LOCKED INTO CONTRACTORS WHO MAINTAIN CODE THE VENDOR NO LONGER SUPPORTS. 

Upgrading COTS Security 

Security is another area where COTS modifications can actually exceed the cost of custom software. There's no way to verify how any COTS package handles security at the code level, so it's logical to assume that developers who work for major software vendors are capable and conscientious. But that's all it is: an assumption. Conversely, custom software is built from the inside out for specific content, processes and infrastructure. 

Network security is layered and holistic, and dozens of factors—hardware, software, physical surroundings, corporate policy, the technology infrastructure and more—affect system vulnerability. When developers know, all the way down to the code level, precisely how an application is protected, changes in the target environment don't turn into cross-your-fingers-and-hope-for-the-best scenarios. 

Again, COTS is built to generic standards. It cannot be considered secure until it has been configured specifically for your environment. Right out of the box, COTS applications do not meet all security mandates for government, financial services, health care and other regulated environments without extensive modification. The development team must shore up the software's limitations since modifying the core is not an option. As mentioned earlier, the cost to do this can meet or exceed what you'd spend on a system tailored to your environment. 

Failed projects have one thing in common 

There's no 'typical' COTS project, but those that fail all have one thing in common. They allow technology to trump the business problem. 

Let's say, for example, that you need to work with another division or agency to allocate assets, track an issue, or collaborate on a new project. One day Joe comes back from a trade show and says, 'Hey! Let's do it with CRM!' 

So the focus shifts from business problem to technology bake-off. Which system has most features? Latest innovations? Best quarter-end pricing? 

PROJECTS THAT FAIL ALL HAVE ONE THING IN COMMON. THEY ALLOW TECHNOLOGY TO TRUMP THE BUSINESS PROBLEM. 

Now vendor slicks, not business objectives, drive the requirements. Meanwhile, the user community doesn't know or care about CRM, and they're digging in to 'slow roll' what they view as an imposition—one more so-called productivity tool that won't make work any easier or better. 

They forge ahead anyway 

So the project kicks off with a big delivery of 'best in class' plumbing from BEA, Oracle, Vignette. The lead contractor generates a steady stream of design documents, specs and Gantt charts. As soon as the stakeholders sign off the development team steps in. 

Dozens (sometimes hundreds) of person-years and much custom code later, the initial version of the system is ready to deploy. But business priorities have shifted unexpectedly and the contractor won't rework the Interface Control Document without more funding. Whenever something breaks down, goes wrong or fails to deliver as promised, the integrator points to vendor A, who blames vendor B. Vendor B claims the system works perfectly—the problem must be the user community. By now the project is so far over budget and behind schedule that stakeholders decide to re-bid the contract. ('Low cost' is shaping up to be relative term after all.) Finally somebody says: 'Maybe we should just bite the bullet and start over.' 

You do the math 

Before you spend a dime on COTS, custom software, or any combination of the two, calculate the cost of intangibles. Nasty surprises in these 'soft' areas sink a staggering 80% of KM deployments (that's CIO Magazine's number; the more optimistic put failure rates at 45% to 70%) and nobody sees them coming. 

Usability: How quickly did reference accounts reach critical mass? What do the usage trends look like? 

Scalability: Can the system expand from dozens of users to thousands without replacing the software and any connecting systems? What happens to response and performance as capacity grows? 

Security: Does the system comply specifically with the data security standards and mandates governing your industry? If not, how long will it take and how much will it cost to bring it into compliance? 

Reliability: How do vendor SLAs compare? What are your options for on-site, online and phone support? 

Capacity: Must you buy more system than you need right now to accommodate future growth? What's the true cost of that unused capacity, including the cost of capital? 

Opportunity costs: Will owning and using this system take time away from your core business? What's that time worth? Can you reduce or eliminate that cost with a more efficient system? 

 

1 Glass, Robert L. Facts and Fallacies of Software Engineering. Boston, MA: Addison-Wesley, 2003