Build or Buy

You manage a successful small business using 'manual' or 'old technology' and it has grown to the point where you feel that upgrading your information technology systems would accelerate your growth. Now you face a tough decision. You have few choices. Most of your choices are expensive to implement. You feel uncertain, out of your element. What happens if you choose wrong? Unfortunately, nothing, which is not what you want. What are your common choices?

1. Buy a prepackaged system and change your business to match the systems requirements.
2. Hire technical staff and have them build a custom solution to make the system match your needs.

Buying a prepackaged system often feels like buying a car, you know the salesperson knows way more on the subject than you do and never tells you what their system can't do. Persuasive sales representatives from software providers can tell you in an evocative full color presentation how their product is absolutely the best solution for your business needs.

At it's best, when buying a prepackaged solution you get a solution that is cost efficient in the long run. The software vendor makes sure that you stay up to date with changing hardware and operating systems. They provide you with updates that fix problems in the system and provide new features. Your staff's productivity increases and everyone is happy.

At it's worst, the project is a mess. The salesperson omitted important information. You get a product that does not meet your needs well. You pay too much for it. (Yes, they have enormous room to deal.) The installation takes months longer than expected. The people who have to work with the system hate it and are seriously de-motivated.

On average you will get something that mostly works for your company. It will cost more than expected, it will take longer than expected to make it work and it will leave a sour taste in your mouth much like that last car you bought.

Alternatively, you search for a technical manager with expertise in these areas, he or she then hires developers and you begin a project to build software, which is exactly to your requirements.

At it's best, the technical staff gets it built in a modest time frame, it works well, and there are few problems to fix over time. You keep a few of the technical people permanently to make sure it stays up to date. While this is usually more expensive than buying an application, you get exactly what you want and do not have to re-design your business to fit the software.

At it's worst, the software takes months or years longer than you expected. It contains many problems. And you need almost the entire development staff just to keep it working. The people who have to work with the system hate it and are seriously de-motivated.

On average such projects it will take between 50% and 100% longer than the originally estimated. There will be a moderate number of problems than need to be fixed. You will keep most of the junior developers on staff to maintain it.

While the pitfalls of both approaches can be managed and / or mitigated, it can easily require much time, money and effort on your part. I suggest that both approaches have good and bad points. I would suggest that you take the best of both and combine them into a better method.

You have a business to run, you do not really have the time and space to research the products, check references, work with the staff to determine how the new software will fill their needs, and figure out what the salesperson does not want you to know.

Buy and Customize

There are very few tasks in business that are not common to most businesses, and every business has a few things that make them unique. This can be thought of as an 80-20 rule, 80% of what you need is already available and 20% is unique to your needs. Find the existing package that fits your 80% and then develop only the last 20%.

At it's best when you can begin using the 80% very quickly and bring the remaining 20% online when it is becomes available. Because you are not building from scratch you do not need to invest in the development and maintenance of the bought 80%.

This approach has a very different set of problems to manage. Developers may suffer from NBH (not built here) syndrome in that they believe that they can do it better and do not want to 'deal' with someone else's mess, making them close-minded. Not all software vendors are open minded about you adding to their system, they may withhold key information about how the parts of the system you want to modify work.

On average by getting buy in up front that all parties (vendors and developers) are in partnership for your success, this approach can easily give the best result and the lowest cost both up front and over the long run.

Copyright 2001 Paul Rubin