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:
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".
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.
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.
