When purchasing a new refrigerator, a buyer will typically calculate acquisition cost by combining the purchase price, delivery fee, and installation charge.
The estimated yearly operating cost (provided as part of the EnergyGuide label) may also be part of the buyer's cost evaluation. This cost is then weighed
against other criteria (e.g., size, feature, availability) and a selection is made. Total cost is rarely the single evaluation criterion. The same is true
with software applications. This section will cover the components of cost that should be included in a decision analysis, but we recognize that other factors
may provide greater influence on the decision to acquire an application.
This section does not address the internal calculations about how software prices are set except to provide some guidelines for comparing locally-built applications with off-the-shelf products. Just as the refrigerator buyer does not have insight into how the manufacturer derived the dollar amount listed on the price tag, neither can this guide suggest how application prices are set.
The cost of implementing an application is not easy to calculate. The license fee is an inadequate indicator of the total cost of implementing a wide-reaching application such as these PM management solutions. Research into broader business applications shows that the fee may represent as little of 20% of the total costs of implementation. To further complicate matters, many surveys find a wide variation in the deployment costs for a single application, rendering reference information unreliable. The most dependable answer will come from an understanding of your local environment combined with the operating requirements of the application. The following is a brief guide to the calculation of total cost of ownership (TCO). It is meant to help you understand the components of cost and assist you in developing a cost comparison that meets your local requirements. Readers are urged to consult information technology literature sources such as bitpipe (http://internetworld.bitpipe.com/), Forbes IT Research Library (http://itresearch.forbes.com) or Becta (http://www.becta.org.uk) for more comprehensive discussions of the topic.
Several schemas exist for segregating the costs of owning a computer system. The elements of cost are not at issue Ď just the way to aggregate them. This document uses a breakdown popularized by the Gartner Group (the leading provider of research and analysis on the global IT industry) and others: Capital, Administration, End-User Operations, and Technical Support. The following table lists the major components of each category and the percentages of the total for each category.
The easiest part of the capital cost to determine is usually also the smallest component of the cost - the cost of the license for the software application. If the system is to reside on local equipment, hardware must be purchased to support the application itself; additional hardware for the associated middleware (i.e., a database management system like Oracle, a web application like WebLogic) may also be necessary. Depending on the local requirements for dealing with network connectivity, routers, hubs, or switches to support the bandwidth that the new application requires may have to be purchased or upgraded. Each workstation that is attached to the system must meet a minimum configuration of processing capacity, RAM, and storage. The minimum is rarely adequate, necessitating upgrades. Further, additional licenses to meet the Standard Operating Environment (SOE) may need to be purchased. The SOE is a set of products that the application assumes will be present in the workstation. Examples include operating systems (i.e., Windows XP, Windows 2003), print processing (i.e., Crystal Reports), or analysis (e.g., MS Excel or SAS).
Moreover, a systematic approach to upgrading the installed base in a timely fashion must be established. An annual capital requirement for 5-10% of your original investment is typical. This is beyond the operational costs of the system and may be higher or lower depending on your jurisdiction╠s procurement policies. The trend toward leasing equipment has reduced the need to acquire significant capital funds, a major relief for many agencies. Therefore, forward capital planning may not be necessary.
Almost every application requires some level of administration by both the IT and end-user organizations. Maintenance of additional equipment, its associated operating environment, and requirements of the selected application will require personnel resources Ď typically called system administrators. IT organizations must be cognizant of implementation plans to ensure appropriate staff are available. First, initial installation of the application must be supported. Typically, the vendor will provide installation for an additional fee; this may include training local administrators as well. Some IT organizations require a readiness or security review prior to opening up availability of the application. The contract with the installation vendor should include support for that activity. More time for installation should be allotted if additional requirements are discovered. Keep in mind that all applications require some system administration, including operating system patches and upgrades, backup and continuity of operations activities, and database maintenance.
Most applications allow an ¤end-userË administrator to maintain the security of the system, i.e., someone must be designated to grant passwords and rights. Your computing environment may not allow you to do this yourself (not entirely a bad thing), so policies must be investigated beforehand. If a system administrator will perform these activities, he must have enough time to respond in an adequate manner. Consider requesting special ¤dispensationË for a period of time after initial set-up to enable the myriad of adjustments that always occur to be made in an expeditious manner. This is key to the integrity of your operation. Make sure a responsible person who is capable of handling time-consuming, detailed work is assigned this task.
¤If you don╠t internally test your applications, someone else will.Ë That ¤someone elseË could be users, managers, or vendors. It is wise to develop a small, focused test team to check out each change in the operating or application environment. They may find errors that cannot be addressed before deployment, but the test results will allow user teams to be notified of potential problems in advance. This increases the perceived reliability of the application and keeps users on your side.
One of the largest expenses of a new application system is the migration of data. Most vendors will assist in the conversion of data from another electronic format ñ as part of the installation fee or for an additional charge. Because they best understand their internal data structures, it is usually a wise to obtain these services from the vendor. Typically, the greatest costs are related to the conversion of paper records. As part of implementation planning, a determination must be made as to what extent conversion of past records will be done. Many jurisdictions end up with a multi-part plan: up-front complete conversion of a small time window (e.g., 6 months-1 year); conversion upon access of a larger time window (e.g., 1-3 years); and continued use of older, paper records. Your plan should be built on an understanding of how you intend to use the application and consideration of the accessibility of your previous paper records. Remember that data conversion does not refer only to "historic" data. Records, messages, tests, and other items will continually need to be entered into the system. The time it takes to enter this information will be greater than the time it took to ìfileî the paper documents. The cost savings will be in the retrieval and access of the information. The long-term administrative expense of a data entry clerk may need to be considered.
End-user operations relate to the time spent by end users on the non-job-related computer activities that are due to the presence of the system. In essence, end users have had ¤computer administratorË added to their job descriptions because the typical organization has starved official technical support head count or has not invested in labor-saving technical support and administration tools - or both. While this component of the TCO model looks at end-user costs, it does not measure end-user productivity.
Formal learning is when an end user goes to a classroom for lectures, or to a learning lab for video-based or computer-based training. Retention is typically low, as low as 10% after 30 days. Additionally, typically only 40% of the end users who should receive formal training actually participate. Before investing in formal learning, evaluate the learning methods of your organization. Can people be away from their jobs for a defined time frame (typically a minimum of 4 hours)? How many people can be out of the office at the same time? Are there many common functions to be performed, or will each user have a significantly different experience with the system? If your jurisdiction is like many others, you may not find formal learning methods to be satisfactory beyond the introduction to the system. System administrators, ¤power usersË, and designated points-of-contact may benefit most from this type of training.
The effort end users make to learn more about a function they are using at the point in time they are trying to use that function is called casual learning. Traditional tools for casual learning include reading manuals, getting information from co-workers, using a system╠s help screen, and using trial-and-error experimentation. Advanced casual learning uses hypertext and multimedia-based JITT tools. Casual learning can have a higher knowledge retention rate because it occurs in smaller portions (one function at a time), at the highest point of motivation (when the user wants to use a function), and in the best setting (when end users are sitting at their own systems). Some vendors offer ¤walking aroundË training. In this scenario, they spend several days in each environment moving from user to user, offering specific instruction on items that the users are encountering in their daily work. Further, orientation of new staff must be considered when developing a training plan. If the vendor does not offer appropriate materials, a staff member may be assigned to outline an introduction to the system for new employees.
Futz refers to spending an excessive amount of time on cosmetic changes to documents or data in the system, or using the system for purposes not originally intended. Examples of cosmetic activities include spending time on getting the colors ìjust rightî in a graphic, formatting a report to "look just like the old one," or editing data to a higher level of quality than defined in the data migration. People like to make a system their own. They have been futzing with things throughout their careers; computer systems seem to make it possible for them to impact more people with their futzing. If I spend extra time making all my file folders color indexed, it may lower my productivity, but has no impact on the rest of my team. If I spend time re-editing electronic medical records to show proper spacing and punctuation, it may keep others from working on the record. This cannot be prevented but workflow in the second 6 months of operation should be monitored to see if any such bottlenecks are occurring. Additionally, futz must be taken into account when considering vendorsí claims of productivity. Because of futz, a system that allows someone to enter 5 times as many records as previously will not necessarily result in 5 times the productivity.
Technical support provided by end users outside of the official technical support framework is considered peer support. The key here is "official framework", because end-user-based resources can be part of the official technical support organization. There are two types of peer support: encouraged and informal. Encouraged peer support occurs when your department has decided to let certain knowledgeable workers (so called ìpower usersî) help their co-workers. If peer support will be included in operational plans, job descriptions or requirements may need to be modified. Alternatively, establishing a help desk may be considered. The purpose of this help desk is not to provide technical consulting, but to answer typical questions and direct users to appropriate instructional materials. Depending on the size of your implementation, it may be more cost-effective to ìbuy inî to some existing help desk service elsewhere in your jurisdiction. You may be charged by the call or by the length of time spent in support. Typically, the need for this service will decline greatly after the implementation period and may be replaced with web-based FAQs (Frequently Asked Questions) or email query services (questions submitted by email only). The danger is that not enough formal technical support is provided resulting in a lot of informal peer support. This is what Gartner Group calls "Hey, Joe!" support, where an end user will turn to the closest co-worker and ask for help. ìHey, Joe!î support is especially expensive because, if Joe does not know the answer immediately, other co-workers could be drawn into the discussion, resulting in more people being unproductive for a longer period when a 2-minute call to the help desk could have solved the problem.
Two types of technical support contribute to the total cost of ownership: (1) the cost for technical support from the vendor, and (2) maintenance of a quality computing environment.
A traditional maintenance agreement not only provides the latest features for the software, but also security and maintenance patches, current documentation, and access to a technical help desk for administrators and programmers. If these items are not included in the standard maintenance package, it must be determined how this support will be provided. Similarly, a support agreement (e.g., a service-level agreement) with a local computing center may be in place. This agreement will provide the same features for your hardware and SOE.
Application consulting (for the vendor to develop site-specific enhancements) may be purchased. If access to an application development resource is not available, a mechanism to get support from the vendor, if only for emergencies, must be established. See Section 6 for more information about local enhancement costs.
The second area of technical support is associated with the maintenance of a quality computing environment. At a minimum, the local computing environment should have configuration management, product review, disaster recovery, and installation procedures. These may be charged as part of a monthly fee or per occurrence. These activities are critical to a continued, stable operation; therefore, associated costs must be considered.
Comparing costs for locally-built applications
In the special case of developing a "cost" for locally-built applications, all the preceding cost categories still apply. One note of caution - frequently the labor cost estimates calculated are based purely on salary or contract rates. In actuality, most organizations are charged some type of "burden," "overhead," or "contract charge" on top of these rates. With internal employees, this charge accounts for employee benefits (e.g., pension, sick leave), space, equipment and supplies, and a portion of the supervisory efforts associated with the employee. This figure should run in the range of 15-35% of salary for benefits and another 40-75% of salary for the remaining items. Contract rates may also have a charge attached to cover the administration of the contract (purchasing surcharge). All costs associated with the development, test, and maintenance environment must also be calculated - equipment, licenses, and space that would otherwise not be used. These are real costs that the organization is paying, so they should not be ignored in this analysis.
Ovum Research. Implementing enterprise application software - costs and strategies. February 2003
Among others: Compaq Corporation, "Total Cost of Ownership", 2004; JOHN TAYLOR BAILEY AND STEPHEN R. HEID, "Why Is Total Cost Of Ownership (TCO) Important?", Question #74 from Business Driven Information Technology: Answers to 100 Critical Questions for Every Manager edited by David R. Laube and Raymond F. Zammuto, Stanford University Press; Osten, Marc, "The Hidden Costs of Technology," TechSoup.org, May 2, 2001.
McAlearney, Shawna. "Application security: How much does software really cost?", June 17, 2004, Security Wire Perspectives.
SAIC Desktop Services. Report on the Internal Total Cost of Ownership. January 1996
Jacqueline Emigh, ¤Total Cost of OwnershipË, Computerworld, December 20, 1999.
Skip Navigation | Assessment Guide | How to Get Started | Requirements Definition | Business Models | Support | Data Migration
Local Enhancements and Customizations | Costs | Funding | PHIN Compatibility | Decision Model Tool | Glossary | Results