This is “Understanding Technology beyond the Price Tag: Total Cost of Ownership (TCO) and the Cost of Tech Failure”, section 9.6 from the book Getting the Most Out of Information Systems (v. 1.4). For details on it (including licensing), click here.

For more information on the source of this book, or why it is available for free, please see the project's home page. You can browse or download additional books there. To download a .zip file containing this book to use offline, simply click here.

Has this book helped you? Consider passing it on:
Help Creative Commons
Creative Commons supports free culture from music to education. Their licenses helped make this book available to you.
Help a Public School
DonorsChoose.org helps people like you help teachers fund their classroom projects, from art supplies to books to calculators.

9.6 Understanding Technology beyond the Price Tag: Total Cost of Ownership (TCO) and the Cost of Tech Failure

Learning Objectives

  1. List the different cost categories that comprise total cost of ownership.
  2. Understand that once a system is implemented, the costs of maintaining and supporting the system continue.
  3. 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.R. Charette, “Why Software Fails,” IEEE Spectrum, September 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 complianceEnsuring that an organization’s systems operate within required legal constraints, and industry and organizational obligations (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.C. Rettig, “The Trouble with Enterprise Software,” MIT Sloan Management Review 49, no. 1 (2007): 21—27. 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)All of the costs associated with the design, development, testing, implementation, documentation, training and maintenance of a software system. 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.L. Dignan, “Survey: One in 3 IT Projects Fail; Management OK with It,” ZDNet, December 11, 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.”R. Charette, “Why Software Fails,” IEEE Spectrum, September 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.R. Lloyd, “Metric Mishap Caused Loss of NASA Orbiter,” CNN, September 20, 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 following:List largely based on R. Charette, “Why Software Fails,” IEEE Spectrum, September 2005.

  • 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)A process-improvement approach (useful for but not limited to software engineering projects) that can assist in assessing the maturity, quality, and development of certain organizational business processes, and suggest steps for their improvement., 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 improvement.R. Kay, “QuickStudy: Capability Maturity Model Integration (CMMI),” Computerworld, January 24, 2005; and Carnegie Mellon Software Engineering Institute, Welcome to CMMI, 2009, http://www.sei.cmu.edu/cmmi.

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.A. Shenhar and D. Dvir, Reinventing Project Management: The Diamond Approach to Successful Growth and Innovation (Boston: Harvard Business School Press, 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.
  • 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

  1. List the types of total ownership costs associated with creating and supporting an organization’s information systems.
  2. On average, what percent of firms’ IS budgets is spent to keep their systems running?
  3. What are the possible effects of not detecting and fixing major system errors before deployment?
  4. List some of the reasons for the failure of technology development projects.
  5. What is the estimated yearly cost of failed technology development projects?
  6. What was the reason attributed to the failure of the NASA Mars Observer project?
  7. What is capability maturity model integration (CMMI) and how is it used to improve the overall quality of a firm’s development practices?
  8. 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?