In L. Frank Baum’s book The Wonderful Wizard of Oz (Project Gutenberg), the Tin Woodman was originally a human named Nick Chopper. In an effort to prevent his marrying his sweetheart, the Wicked Witch of the East cursed his axe so that it would cut off part of his body every time he tried to chop wood. Nick lost his limbs one by one, only to have them replaced with metal versions by a friendly tinsmith. Eventually he lost his head and trunk as well, and had them replaced with tin in the same way.

Buy or build?

Nick’s story might sound painfully familiar to anyone who has spent time working with IT in large enterprises or government. Big organizations will buy a huge, off-the-shelf software system in an attempt to save the cost and risk of building their own, only to replace one part after the other because of lack of scalability, bad performance, bugs, or missing features. They end up with a system that they’ve built almost entirely themselves (at perhaps double the cost of a from-scratch system) but still have to pay royalties to an outside vendor to use.

How to avoid building your own Tin Woodman

Why does this happen? In principle, buying instead of building is a great idea — it lets a company share development costs with many others while concentrating its limited IT resources on its core specialties. This approach works, however, only when a product does something that is well understood and widely implemented (i.e. it’s a commodity). When considering an OTS product instead of building a system from scratch, a company should ask itself two questions:

1. Do we have a choice of more than one comparable product (preferably following the same open standards)?
2. Is this particular product already in full-scale production use at at least two or three sites that do the same kind of business, at the same volume, as we do?

If the answer to either of these questions is no, then you’re looking at a potential Tin Woodman: you’ll probably end up chopping off one limb at a time and rebuilding the product yourself, piece by piece. That’s not always a bad idea — companies will often choose to outsource R&D by funding the initial development of a product at another (usually smaller) company and serving as the launch customer — but in those cases, both management and IT know what they’re getting into, and there’s no expectation of simply installing the software, doing a bit of configuration and testing, then going into production in six months.