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:

  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 (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

  • Information systems are expensive to build and maintain. The full cost (called total cost of ownership, or TCO) includes software, support, training, security, backups, and more.
  • Many information systems projects fail because of technical problems, poor planning, or management mistakes.
  • Using good development methods (like CMMI), strong leadership, and clear business goals can improve success.
  • Fixing errors after a system is launched can cost up to 100 times more than catching them early.
  • Most companies spend 70–80% of their IS budget just keeping current systems running.
  • About one-third of technology projects never get fully deployed.
  • Careful planning and proven development practices help organizations build better systems.

 

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?

 

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.

License

Share This Book