15 9.6 Total Cost of Ownership (TCO): Tech Costs Go Way beyond the Price Tag
Learning Objectives
After studying this section you should be able to do the following:
- List the different cost categories that comprise total cost of ownership.
- Understand that once a system is implemented, the costs of maintaining and supporting the system continue.
- List the reasons that technology development projects fail and the measures that can be taken to increase the probability of success.
Managers should recognize that there are a whole host of costs that are associated with creating and supporting an organization’s information systems. Of course, there are programming costs for custom software as well as purchase, configuration, and licensing costs for packaged software, but there’s much, much more.
There are costs associated with design and documentation (both for programmers and for users). There are also testing costs. New programs should be tested thoroughly across the various types of hardware the firm uses, and in conjunction with existing software and systems, before being deployed throughout the organization. Any errors that aren’t caught can slow down a business or lead to costly mistakes that could ripple throughout an organization and its partners. Studies have shown that errors not caught before deployment could be one hundred times more costly to correct than if they were detected and corrected beforehand (Charette, 2005).
Once a system is “turned on,” the work doesn’t end there. Firms need to constantly engage in a host of activities to support the system that may also include the following:
- providing training and end user support
- collecting and relaying comments for system improvements
- auditing systems to ensure compliance (i.e., that the system operates within the firm’s legal constraints and industry obligations)
- providing regular backup of critical data
- planning for redundancy and disaster recovery in case of an outage
- vigilantly managing the moving target of computer security issues
With so much to do, it’s no wonder that firms spend 70 to 80 percent of their information systems (IS) budgets just to keep their systems running (Rettig, 2007). The price tag and complexity of these tasks can push some managers to think of technology as being a cost sink rather than a strategic resource. These tasks are often collectively referred to as the total cost of ownership (TCO) of an information system. Understanding TCO is critical when making technology investment decisions. TCO is also a major driving force behind the massive tech industry changes discussed in Chapter 10 “Software in Flux: Partly Cloudy and Sometimes Free”.
Why Do Technology Projects Fail?
Even though information systems represent the largest portion of capital spending at most firms, an astonishing one in three technology development projects fail to be successfully deployed (Dignan, 2007). Imagine if a firm lost its investment in one out of every three land purchases, or when building one in three factories. These statistics are dismal! Writing in IEEE Spectrum, risk consultant Robert Charette provides a sobering assessment of the cost of software failures, stating, “The yearly tab for failed and troubled software conservatively runs somewhere from $60 to $70 billion in the United States alone. For that money, you could launch the space shuttle one hundred times, build and deploy the entire 24-satellite Global Positioning System, and develop the Boeing 777 from scratch—and still have a few billion left over” (Charette, 2005).
Why such a bad track record? Sometimes technology itself is to blame, other times it’s a failure to test systems adequately, and sometimes it’s a breakdown of process and procedures used to set specifications and manage projects. In one example, a multimillion-dollar loss on the NASA Mars Observer was traced back to a laughably simple oversight—Lockheed Martin contractors using English measurements, while the folks at NASA used the metric system (Lloyd, 1999). Yes, a $125 million taxpayer investment was lost because a bunch of rocket scientists failed to pay attention to third grade math. When it comes to the success or failure of technical projects, the devil really is in the details.
Projects rarely fail for just one reason. Project post-mortems often point to a combination of technical, project management, and business decision blunders. The most common factors include the following2:
- Unrealistic or unclear project goals
- Poor project leadership and weak executive commitment
- Inaccurate estimates of needed resources
- Badly defined system requirements and allowing “feature creep” during development
- Poor reporting of the project’s status
- Poor communication among customers, developers, and users
- Use of immature technology
- Unmanaged risks
- Inability to handle the project’s complexity
- Sloppy development and testing practices
- Poor project management
- Stakeholder politics
- Commercial pressures (e.g., leaving inadequate time or encouraging corner-cutting)
Managers need to understand the complexity involved in their technology investments, and that achieving success rarely lies with the strength of the technology alone.
But there is hope. Information systems organizations can work to implement procedures to improve the overall quality of their development practices. Mechanisms for quality improvement include capability maturity model integration (CMMI), which gauge an organization’s process maturity and capability in areas critical to developing and deploying technology projects, and provides a carefully chosen set of best practices and guidelines to assist quality and process improvement1 (Kay, 2005).
Firms are also well served to leverage established project planning and software development methodologies that outline critical businesses processes and stages when executing large-scale software development projects. The idea behind these methodologies is straightforward—why reinvent the wheel when there is an opportunity to learn from and follow blueprints used by those who have executed successful efforts. When methodologies are applied to projects that are framed with clear business goals and business metrics, and that engage committed executive leadership, success rates can improve dramatically (Shenhar & Dvir, 2007).
While software development methodologies are the topic of more advanced technology courses, the savvy manager knows enough to inquire about the development methodologies and quality programs used to support large scale development projects, and can use these investigations as further input when evaluating whether those overseeing large scale efforts have what it takes to get the job done.
Key Takeaways
- The care and feeding of information systems can be complex and expensive. The total cost of ownership of systems can include software development and documentation, or the purchase price and ongoing license and support fees, plus configuration, testing, deployment, maintenance, support, training, compliance auditing, security, backup, and provisions for disaster recovery. These costs are collectively referred to as TCO, or a system’s total cost of ownership.
- Information systems development projects fail at a startlingly high rate. Failure reasons can stem from any combination of technical, process, and managerial decisions.
- IS organizations can leverage software development methodologies to improve their systems development procedures, and firms can strive to improve the overall level of procedures used in the organization through models like CMMI. However, it’s also critical to engage committed executive leadership in projects, and to frame projects using business metrics and outcomes to improve the chance of success.
- System errors that aren’t caught before deployment can slow down a business or lead to costly mistakes that could ripple throughout an organization. Studies have shown that errors not caught before deployment could be 100 times more costly to correct than if they were detected and corrected beforehand.
- Firms spend 70 to 80 percent of their IS budgets just to keep their systems running.
- One in three technology development projects fail to be successfully deployed.
- IS organizations can employ project planning and software development methodologies to implement procedures to improve the overall quality of their development practices.
Questions and Exercises
- List the types of total ownership costs associated with creating and supporting an organization’s information systems.
- On average, what percent of firms’ IS budgets is spent to keep their systems running?
- What are the possible effects of not detecting and fixing major system errors before deployment?
- List some of the reasons for the failure of technology development projects.
- What is the estimated yearly cost of failed technology development projects?
- What was the reason attributed to the failure of the NASA Mars Observer project?
- What is capability maturity model integration (CMMI) and how is it used to improve the overall quality of a firm’s development practices?
- Perform an Internet search for “IBM Rational Portfolio Manager.” How might IBM’s Rational Portfolio Manager software help companies realize more benefit from their IT systems development project expenditures? What competing versions of this product offered by other organizations?
1Carnegie Mellon Software Engineering Institute, Welcome to CMMI, 2009, http://www.sei.cmu.edu/cmmi.
2List largely based on R. Charette, “Why Software Fails,” IEEE Spectrum, September 2005.
References
Charette, R., “Why Software Fails,” IEEE Spectrum, September 2005.
Dignan, L., “Survey: One in 3 IT Projects Fail; Management OK with It,” ZDNet, December 11, 2007.
Kay, R., “QuickStudy: Capability Maturity Model Integration (CMMI),” Computerworld, January 24, 2005.
Lloyd, R., “Metric Mishap Caused Loss of NASA Orbiter,” CNN, September 20, 1999.
Rettig, C., “The Trouble with Enterprise Software,” MIT Sloan Management Review 49, no. 1 (2007): 21–27.
Shenhar A. and D. Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation (Boston: Harvard Business School Press, 2007).
