|
|
 |
Application Software: Buy It or Build It?
by Frank R. Hagy
|
As we travel around the state with our consulting services, often senior-management, elected and appointed officials ask whether they should be purchasing commercial-off-the-shelf software packages or developing them using in-house staff. For the information-systems industry, this has been a point of debate, with very vocal advocates on each side of the issue.
From our experience, local governments should be purchasing commercial, off-the-shelf packaged software (simply called “packaged software”) unless there is a valid, definable reason not to do so. That is, this decision should be approached with the concept that “we will purchase packaged software unless we can be convinced otherwise.”
Advantages of Purchasing Packaged Software
There are several reasons for local governments to purchase commercial, off-the-shelf packaged software.
1. Predictable cost and timeframes: Purchasing packaged application software allows a local government to more accurately predict costs. Properly identified features, functions and capabilities needed by a jurisdiction will lead to a highly predictable total cost of ownership for the life of the software. When developing application software using in-house staff, costs tend to vary widely and rarely are accurate or predicable. Local-government technology staffs often are responsible for both supporting current operations and developing new systems. This leads to conflicting priorities, delayed implementations and escalating costs. Another reason for cost escalation and project delays is the lack of fully defined or accurate functional requirements. For the most part, software packages have been used in many other municipal environments, and a forgotten or missed functional need is likely to have already been programmed into the software. Unlike in-house development efforts, the cost and time needed to install and implement packaged software can be closely estimated and, in fact, can be fortified through contractual penalties for delays.
2. Improved Maintenance and Support Cost: Maintaining an internally developed application requires a dedicated, knowledgeable maintenance team. Issues arise relating to internal staffing levels, how to maintain the skills of the support staff, and retention of trained technology personnel. Often, local governments cannot afford to dedicate the resources needed to staff such a team on a continuing basis. Typically, it is easier for a municipality to justify financial needs than to obtain additional personnel. Packaged software is backed by a commercial business dedicated to maintenance and viability of the system. In order to remain a commercially viable product, the software must be updated at regular intervals to keep pace with new technology and the functional needs of its clients. Because of this, internally built software tends to become obsolete in a much shorter time frame and, over time, may experience poorer ongoing maintenance and support.
|
|
3. Functionality of the application: Building a system in-house requires local government users to develop detail specifications and functional requirements of the application before it can be built. This step often is shortcutted, with disastrous results. Mature packaged software vendors have functional experts to design, develop, test and enhance the application over a period of many years with many clients. Also, these vendors support a wide variety of environments and attempt to put the best practices of the industry into their application to make their software more commercially attractive. Software built in-house requires detailed knowledge of the functions to come from within the local-government user community, which may have a more myopic view of the business function.
4. Improved use of limited resources: With the ever-increasing demands being placed on local governments, an emphasis on reducing cost of government while improving services to citizens is paramount. Purchasing packaged software applications allows limited technology resources to focus on those unique applications and services not readily available through packaged software.
5. Rapid deployment: With the rapidly changing technology environment and the limited application development resources of most local governments, many systems built in-house are obsolete before they are implemented. The ability to use packaged software applications reduces the time to bring a system operational, thus allowing a local government to gain productivity improvements sooner.
|
|
What are the negatives of purchasing commercial, off-the-shelf software?
1. Licensing issues: Perhaps the most difficult task in contracting for a software package is understanding the type, terms and conditions of the licensing. This varies from vendor to vendor, and may include enterprise licensing, per-seat licensing, server licensing, or a combination of these. Depending upon how the license is enforced (through security codes, etc.), issues may arise when the server/workstation hardware is broken, or you have to move the software to a new machine during a disaster. What about licenses for a test machine? What happens if we decide to allow employees to work from home? All of these issues should be reviewed, understood and negotiated during the contracting process.
2. Evaluating which software package can be difficult: Evaluating packaged software can be a difficult process. Unless you are able to obtain an evaluation copy and fully test the system, you are purchasing based upon vendor literature, references from other sites, and possible site visits. Often, local governments purchasing packages do so without creating any functional requirements. This makes a proper selection more difficult. It is often wise to obtain consulting help from an unbiased third party for the selection process.
3. Lack of ability to customize the software: Customizing software packages to meet specific and/or unusual needs of a local government can be difficult and costly. In most instances, the software vendors have a robust set of parameters that will allow package customization to suit known differences between local-government organizations. When working with a package, the local government should be ready and willing to modify its business practices (if appropriate) to live within the parameters of the package. Local governments need to select software packages that minimize customization. (None is preferred.)
4. Vendor corporate issues: When using packaged software applications, you are partnering with a commercial vendor. There always is the possibility that the vendor may go out of business. Choosing mature companies with large customer bases can minimize this risk. If the company falls on hard times, the odds are that another vendor will purchase the company and the contracts will be honored. However, there is a possibility that you could be stuck with software which is unsupported, or worse, that won’t run when you thought you would have it forever. These risks can be minimized by proper selection and contractual protections (such as escrowing the source code). Again, an unbiased, knowledgeable third party can be invaluable.
5. Responsiveness of the vendor: With in-house development software, you can demand immediate attention for urgent bugs, training or other issues. When dealing with a packaged software application vendor, you may find it difficult to have a bug fixed, special customizations developed, or other such events. Your ability to “control” is significantly reduced over use of in-house resources. The commercial vendor is going to work with the most pressing issues for all customers (which may not be your particular issue), and will place its emphasis on where revenue can be generated. Again, contractual terms and conditions can help to minimize this downside.
|
|
When should a local government build a system in-house?
There are several instances in which building a system in-house is a viable solution:
1. When the function is unique: This is often overplayed as “no ones does it like we do,” but there are legitimate functions that may be totally unique and for which no packaged application software is available. In these instances, the only recourse is to build the system in-house, or to contract to have it built for you.
2. When clearly, there is a significant cost difference: When you can clearly define the functions needed, accurately calculate the total cost of developing the software in-house over its life cycle, and that cost is significantly higher then the packaged software cost, you may want to develop the system in-house. The trick here is the ability to accurately calculate the total life-cycle cost (not just a single phase) of the in-house development effort. Don’t forget the timing issue. If you can purchase and implement a package solution within six months, but it’s going to take two years for in-house development, what is the lost productivity opportunity cost?
3. Small, quick hit projects: If the total project is small and can be accomplished by the technology staff within a few months, it may be less costly and more advantageous to build the system in-house. This consideration is especially important if an RFP process is required to obtain the commercial, off-the-shelf packaged software.
The Bottom Line
Purchasing commercial, off-the-shelf packaged software always should be considered as a viable alternative to building an application in-house. Gartner, a leading technology research and consulting firm, says that “build activities within an organization should be focused on quick and inexpensive ‘hits,’ as well as projects that just cannot be purchased at any price.” When considering whether to buy or build an application system, local governments should ask the following questions:
|
|
1. Do we have the skills and resources? Does the technology organization have the skilled staff and resources necessary to develop the new system in the timeframe desired while maintaining current operations? Also, does the technology organization have the skilled staff necessary to maintain and support the application for the life of the system?
2. Can our limited resources be better utilized elsewhere? Given the choices of how to spend limited technology resources, is building the application in-house a good choice? Building applications that are available from commercial firms may delay the building of more critical applications that are not commercially available.
3. What’s best in the long term? Market forces affect technology-staff turnover. How will this affect the in-house development effort and long-term maintenance of the system? Local governments constantly face issues with staff turnover in technology positions, for a variety of reasons. Although many of these same reasons apply to commercial software providers, the latter understand their contractual obligations and usually staff accordingly with contingency resources. Local government agencies rarely have the ability to have “contingency” resources.
4. How fast do I want the application implemented? Building systems in-house takes a great deal of time from both technology and end-user staff. Software built in-house has never been used or tested in other locations, and therefore requires extensive testing. This, coupled with generating detailed analysis and functional requirements, equates to significant lead times for implementing an in-house system of any size and complexity. Can you wait? What is the cost of lost productivity and revenue due to the waiting time required for in-house development efforts to be completed?
Frank R. Hagy is chief information officer for the Florida League of Cities. For more information, he may be contacted via e-mail, or by phone at (407) 835-3471.
Reprinted from Quality Cities May/June 2004
Back to Top
Back to Quality Cities Resource Library Listing
|
|
|
