Choosing a software application resource

Word Count:
789

Summary:
Its hard to choose a right software application. One can make it easy by considering some elements


Keywords:
software, solutions, choosing software. application


Article Body:
"Use the right tool for the job" is a good motto for software sourcing. There are several options for software sourcing these days. In-house development, software packages, domestic outsourcing, offshore outsourcing, and application service providers (ASPs) are all possible sources for software applications. All have their place in a software sourcing strategy. But they are not all equally suited to all tasks. Industry experience shows that in-house development and purchased software packages are the pillars of software sourcing. The rest are niche solutions. 

Results from my company's latest survey, Strategic Trends in Information Technology, show that 50% of existing production applications were delivered by in-house development, 46% by purchased packages, 3% by domestic outsourcing, almost 1% by ASPs, and less than 1% by offshore outsourcing.

These results surprise many people who see them. All of the attention lavished on outsourcing and ASPs has given most people the impression that there has been a stampede to those sources. The reality is that the outsourcing and ASP markets continue to grow but their contribution to the total base of installed software is small. 

In-house development and purchased software packages are the leading software sources for good reason. At the top of the list is commitment. Employees know that their success depends on corporate success. They know they need to deliver the application to support the company-and they are emotionally committed to doing so. There is no substitute for this intimate connection between project success and personal success. Even projects that use contractors or other outsiders get the benefit of this commitment as long as responsibility for project success remains within the company.

Company knowledge is another powerful element of internal projects. Employees know a lot about the company. They know the products and they know how the company operates. Most importantly, they understand company culture. They understand it because they are part of it. Not only does this help get things done, it also helps determine what is important and what's not.

Physical proximity is another asset of most internal projects. Developers and users are close enough to each other to have regular face-to-face meetings. And they often have informal contact too-the classic "coffee-pot bull-session," for example. All of this promotes better personal relationships that, in turn, promote better project results. 

Internal projects have a lot going for them. It's no wonder that so much software has been delivered that way.

So what is the big argument in favor of outsourcing and ASPs over in-house development and purchased packages?

Cost, less financial cost. Quality, time to market, and other arguments are sometimes made, too, but day in and day out, the big argument in favor of outsourcing and ASPs is cost.

Cost is a powerful argument, but before any financial benefit is realized outsourcing and ASPs have to overcome major obstacles. The obstacles they face are exactly contrary to the strengths of internal projects.

Instead of employee dedication, we have the vendor's dedication to making a profit. Not an insignificant factor to be sure, but not the same as an employee's personal interest in project success.

All company knowledge that is important to the project, both factual and cultural, must be transferred from employees to the vendor. The more complex or unusual the application, the more difficult it becomes to transfer all knowledge.

The vendor is not part of the culture. The vendor is always an outsider, at least to some extent. This makes it difficult for the vendor to know the subtleties that can make the difference between success and failure. It can even make it difficult to communicate less-subtle knowledge.

Distance makes regular face-to-face meetings between developers and users rare on many outsourced projects. On some offshore outsourcing projects there may be no such meetings. A representative of the outsourcer meets with company representatives and relays information to developers, who remain offshore. Distance also complicates simple communication like phone calls, when team members have to struggle with eight-, ten-, or twelve-hour time differences.

All of these things can be overcome, or at least managed, but external projects have trouble competing directly with internal projects. The implication of this is that internal and external projects are not suited for the same types of projects. The more commodity-like the project the better suited it is for external development. The more unique-which usually means the more critical to corporate success-the better suited it is for internal development. This can also be applied within a large project by contracting out for the simple functions and using internal development for the subtle or complex functions.

If there is any trick to software sourcing, it is to ignore the hype and focus on the job at hand. Then it's just a matter of using the right tool for the job.