IT Challenge: BuyIt, Build It, or Have It Built?

Mar 01, 2004 10:30 PM  By

Information technology executives and managers at catalog companies face a never-ending demand for new or enhanced software systems. Motivation for seeking a new system might be increased productivity and cost savings, enhanced functionality and ease of use, and improved information.

IT systems are no longer a matter of simple software programming. Hiring a few more software engineers is not likely to have much effect on the overall performance, because the IT world has become much more complicated, and programming is just one piece of the IT system process. No matter how big or small your system application might be, arriving at the right solution for your company is really a project with four steps: definition, implementation, integration, and deployment.

Each step needs different resources. For instance, the definition phase requires a business expert able to functionally describe the work to be done and a systems architect to design the software architecture and understand the hardware configuration. Implementation requires software programmers, continuing participation of the architect, and some amount of effective software project management. Integration involves the programmers, one or more quality assurance (QA) people, and technical troubleshooters who understand the multiple consequences of integrating the new system into your complex IT environment. Finally, deployment uses the operations people in place to get the system running and maintained properly. Overseeing all the above should be a project manager who “owns” the project and drives it to completion.

The most common error of an IT department’s clients — those pesky marketing people — is to not understand this process or to believe that buying or developing a system requires no more than some simple additional programming. The IT department must educate clients about the full extent of this multistep process, remind clients that at any point in time multiple IT projects are in different phases of completion, and explain that the price of work overloading can be delays or breakdowns in progress or — even worse — in current operations.

The three choices and what’s behind them

To implement desired solutions you have three choices: look for an off-the-shelf software package that will fit the bill, build software systems inhouse, or outsource the building of a custom system. The three choices affect the balance and emphasis on each of the four steps in each project.

For example, buying a software package can cut down on the definition phase and dramatically reduce the implementation (programming) phase, but it often increases the integration and deployment phases. Newly introduced products can force IT environmental changes that for custom systems were already planned at the architecture phase.

And there are tradeoffs with the high cost of some of today’s new software products compared with their expected life of use or the cost of building a custom system to do the same work. Don’t assume that it is always cheaper/smarter to buy off the shelf. Some software companies price their products so high that it is cheaper to build a solution yourself or to outsource the building of it.

The IT executive needs to look at all three options from a risk/opportunity perspective as well as by considering the constraints of each. Focusing too much on constraints sometimes squeezes out the bigger issues of what the real rewards and risks of the decision are.

Experienced executives understand risk because most have had project failures of some sort. It might be a failed inhouse software development project, the purchase of an expensive off-the-shelf product that fell short of expectations, or using the wrong vendor to build a system.

Risk is real, and it is far more important than cost because cost by itself offers little insight into whether a project will be completed successfully. Cost as a concept does not relate to how we will get our work done through the new system. Few of us have gotten fired for paying too high a price for a system, as opposed to getting the boot for a key project failure. Regardless of cost, the project has to succeed, and the system has to work.

The other side of risk is return — or better said, opportunity. For most projects, companies focus on the opportunity for revenue growth, lower operating costs, better information, a better customer experience, or any combination of the above. Better software — better information technology — not only offers the opportunity to achieve these benefits, but it can make or break a business, especially in the new Internet- and information-driven retail environment.

Option #1: buying a software product

The benefits of buying software products usually include:

  • faster project time to completion because the development phase is already completed.
  • lower inhouse technical capabilities required because development is done.
  • an expertise injection if the off-the-shelf package is industry-specific. For example, if you buy a software package for a vertical industry such as retail video sale/rentals, the system would have features built in to help you manage a video store. This is helpful if you’re new to the business.
  • the inclusion, often, of lots of bells and whistles that impress marketing people.

The risks or disadvantages of buying off-the-shelf products can be:

  • functional mismatch — the product was designed for everyone, not necessarily for you.
  • incompatibility with current systems on site and integration difficulties.
  • sometimes, sidestepping of the creative process of thorough customer system specification.
  • making low use of staff technical talent

Broad-based, low-cost software products such as Word and Excel are priced so that it’s uneconomic to develop one’s own spreadsheet or word-processing software. But when products begin costing $50,000-$100,000, an IT executive needs to look at the cost of building software inhouse or outsourcing the creation of a software product, or he may be leaving more money on the table than he needs to.

Option #2: building software inhouse

Developing software inhouse is usually a choice only for large, well-staffed companies that can afford to employ permanent IT development people. These kinds of architects and programmers insist on developing software (as opposed to maintaining software) as the primary focus of their jobs. Software architects and programmers have specialties, so an effective inhouse development staff generally requires at least six people.

If your company has such staff within the IT department, it is one of the few that can develop software inhouse and is entitled to be subject to these commonly known risks:

  • not enough employees to get job done.
  • skill set of employees falls short in some way.
  • not enough time given to project because other jobs are on the plate.
  • changing specifications can affect an accessible development staff.
  • employees may quit during a project.

Failed and abandoned projects, as well as never-ending ones have converted a good number of IT executives to the view that all software development should be outsourced or a software product found to get the work done.

The risks of developing your own software and systems are high, and the returns from it are in most cases rather low. The same results can generally be achieved with much lower risk and often lower cost if one has access to good outsourcing alternatives. But there are some instances when a business or an industry is unique and a company is forced to do the work itself.

Setting aside the questionable risk/return ratio of developing software inhouse, the economics of inhouse software development is worth understanding. It is not unlike having a mini-software company within your IT department but without the need to sell.

Including benefits, training, facilities, and so on, a small but first-class software development group will cost roughly $150,000-$250,000 a month. The development team might include a project or department manager/supervisor; systems and software architects; Windows, Unix, database, network, graphics/user interface, and specific language programmers; a QA and test engineer; a tech or documentation writer; a software librarian/software code control engineer; and a master troubleshooter.

It is important to recognize also that software development is not operations, the primary activity of IT. The classic IT charter is to use available technology for its maximum value to the company, not to develop technology. So the typical IT organization has sophisticated operations people running complex systems, providing topnotch technical support, and working under great pressure. Those people are generally quite different from software developers. The same staff sharing operations and software development responsibilities is generally impossible. Daily operations demands inevitably squeeze out software development time and progress when people share these responsibilities.

A common trap is to believe that you can hire a couple of programmers and suddenly begin developing effective software and systems inhouse. As discussed earlier, programmers are experts at just a piece of the four-step project process; many other skilled resources are required. Relying solely on programmers would be like buying 25% of a shoe.

Another peril is that there is no point in trying to be in the business of developing software without building a group that is demonstrably first class in experience, intelligence, motivation, and credentials, because the process of software development is difficult. It is art and science. We know that three-month software development projects can become nine-month projects and cost three times more than projected. So one has to hire the best people, and in the U.S. experienced programmers can cost $120,000 a year, while architects cost more. Also, you would be competing with software companies for talent. In short, going inhouse is sensible only for those with deep pockets and a certain appetite for risk, or for those with no other choice.

Option #3: outsourcing software development

The upside return for outsourcing your software development includes:

  • a system functionally specific to the immediate needs of the job.
  • easier integration with current systems, as integration was designed in.
  • relieving IT staff of time demands.
  • involving inhouse technical staff in the four-step project process, which enriches job experience.
  • need of the “user client” to have clear specifications and knowledge about how the work will get done; this drives improved knowledge of the business.

As we know, risk and return generally travel together in life. The high returns of successfully outsourced software development projects are accompanied by these risks:

  • the outsource firm hired can turn out to be less than highly competent.
  • the project can his snags and get delayed.
  • costs can spiral out of control.

The key peril is hiring the wrong people to do the work. It is important that the selected firm has built similar systems before, has the correct and broad-enough skill set, has a reputation of both honesty and successful job completion, and can lay out the four-step process with IT staff. The biggest hint that a company is not the right partner for you would be its failure to articulate the four-step project process in a credible way.

Identify the right firm by treating the selection as a classic hiring decision, and do your evaluation homework. Meet with the people who will manage your project face to face. If possible, create a first-phase evaluation piece, and hire your target firm to do that piece only. You can use that experience to determine whether or how to continue with them for the whole project. A good firm will develop a first-phase deliverable that will be useful to you even if you end up taking the project elsewhere or developing the software yourself.

Snags and delays are usually the result of poor management or poor communication. The best software development firms stay closely involved with IT staff and help to mentor them in any reasonable way to build their skills for the hand-off of the system. This is an extra, unpaid deliverable that enriches IT staff and makes the project more fun and easier to get done. And it’s a natural outgrowth of the early definition phase of the project where the technical staff worked with the outsourcer to define how the system would function. The front-end definition phase is enriching in and of its own value because it forces the client to address and understand his business down to the system level. Buying software products can blind much of the definition phase because the definition has been prepackaged into the product.

Project costs for outsourcing can cost anywhere from a few thousand dollars or a few million. Regardless, cost can be a risk. Outsourcing software development can cost more or less than the other alternatives; there is no rule of thumb.

Try to get a fixed price quotation for your project; if you can’t tightly specify the functionality of your system, though, or if you have a corporate culture of changing specifications, the vendor will be unable to estimate firm costs and offer a fixed price.

In such cases, break the project down into more pieces to isolate the tough-to-define parts, pay for those on a time and materials basis, and fix the price for everything else. Usually, only small parts of a project are difficult to define.

Also, if it is practical, you could mix some inhouse development with your vendor, keeping the harder-to-define aspects inhouse. Admittedly, this can be tricky and should only be done where there is an unusually high level of trust and experience between both parties at a developer-to-developer level.

A cautionary tale

The bottom line is that you have to do what’s right for your business and within your resources. The following tale of two systems seekers is a true story. In the 1970s a large electronic component distributor, Cramer Electronics, decided to build a system to manage its operations and huge inventory, which were spread over about 30 locations. It wanted to create a “perpetual” inventory system — a new concept in those days — with sophisticated cost and location tracking.

A well-financed upstart competitor, Arrow Electronics, wanted much the same for its business, but it outsourced the building of it to a relatively young company called EDS. As years passed, Cramer’s system meandered and floundered, while Arrow’s performed. Largely as a result of the difference in their operating capabilities based on these systems, Arrow eclipsed Cramer. In 1980, Arrow acquired Cramer, folding Cramer into its business, using its systems.

Maybe this scenario would have turned out exactly the opposite with different people. But the point is that IT executives can reap rewarding results by astutely considering the full range of choices of how to get their software development work done — and then making the right choice.


Peter Amons and Dave Howard are principals of Howard Software, a Manchester, NH-based firm that develops software for multichannel retailers.