A common dilemma presented to decision makers in the technology groups of many companies is whether to buy software off-the-shelf, or to build the software from scratch. As someone who has faced this decision, and faced the results from both sides, allow me to present my 2 cents.

There are certainly many situations when buying software makes sense. Buying pre-built software usually makes sense when the application has reached a level of maturity where change is minimal, such as standard accounting applications, database technologies, browsers, and the like. The age-old idiom, "why re-invent the wheel?" fits well here.

However, I would argue that some applications that seem to fit the buy criteria, such as contact management tools, often times have persuasive arguments pointing towards the opposite conclusion. For that matter, I would strongly argue that any application that must fit the unique requirements of a given organization, buying a solution from some vendor is a major blunder, and I've personally seen management careers take a major hit as the disastrous results of this ill-fated decision are eventually realized.

Here's my top reason why this is so:

Who's Process??
Why should a company or organization be forced to alter the way they are used to doing business in order to fit some new software into the process? Shouldn't it be the other way around? We see this all the time. The company has a standardized process.. albeit, typically, a flawed one. The employees are comfortable, and the work gets done. Then, some slick-tongued software salespeson comes along and convinces management that, if they would only buy their software, all your problems would magically go away. The software is purchased... often times, at an extremely high price. A few hundred thousand (or more) dollars are than spent on high-priced consultants to come in and integrate the software. Finally, a new application is launched that sort of works as advertised, as long as the company follows THEIR WAY of doing business. Employees are left scratching their heads and quietly berating the new software, and wishing they could have their old Excel spreadsheet back.

Who owns the kingdom??
Software purchased from a vendor does not usually come with the source code, and thus, getting "under the hood" is virtually impossible. This is always a shock to the decision maker not adept at technology. The software is launched, and tweaking it to fit a new model is very difficult or impossible to do. As the owner of the keys to the source code kingdom, the organization that chose to build their own version of the software can quickly react to changing requirements and control the change management process. The key word here is CONTROL.

How long is that line??
During the sales phase of the process the slick-tongued salesperson is quick to promise and always short to deliver when it comes to support. During the sale, your company is the center of the salesperson's universe... no one matters more to a good salesperson. Than, two years later, some issue comes along, and you quickly find out that the vendor's universe contains players far larger, and far more important to their bottom line than you could possibly offer. Thus, you find your problems sitting in their support queue along with everyone else. As the owner of the software, YOU control the support process. YOU decide the priorities. YOU determine how much you will spend on support. As a decision maker in a company, those are assets that make YOU look good.

Let's figure this out
My final reason why software should almost always be developed in-house is the most vital one to the success of the project. In a word... collaboration. When software is developed by your people, you can quickly and very early in the process involve the end-user community themselves, who will ultimately decide whether the software works FOR THEM. Thus, instead of layering another "new gadget" for them to fit into their already busy days, you've instead given them a personal stake in how the software will improve their jobs. This is no small thing, and I've found it makes ALL THE DIFFERENCE whether a project is ultimately successful or not.