INCREASING PRODUCTIVITY THROUGH THE CMM

Transcription

1 INFORMATION MANAGEMENT: STRATEGY, SYSTEMS, AND TECHNOLOGIES INCREASING PRODUCTIVITY THROUGH THE CMM Brian Keane INSIDE Defining the Challenge, The Origin of the Challenge, A Fundamental Change in Role, The Capability Maturity Model, A Means to Assess Process Maturity, The Levels of the CMM, The Benefits of Process Improvement, Process Improvement and the Year 2000, Building Blocks for Successful Improvement, The Improvement Process The Work Processes of an Organization Can Either Enhance or Cripple Its Effectiveness The scale and complexity of business software applications have increased dramatically since the introduction of computers. Today, few, if any, significant business processes operate without some form of software support, and a typical corporate portfolio now includes a range of platforms, operating environments, and languages. Moreover, the proliferation of business applications and their complexity shows no signs of abating. Despite the rapid advancements in technology, many IS organizations still cope with development and support operations on an ad hoc basis using tools and processes rooted in the beginnings of the computer era. While these methods may have been adequate in the days of centralized computers and small teams of technical specialists, they are poorly suited to the demands of modern business organizations. Software practices must undergo the same dramatic transformation that occurred in the manufacturing industry with the advent of the assembly line. The goal of this article is to provide information to enable managers to enhance the performance of their organizations successfully through IS process improvements. In examining the need to focus on processes, this article presents the Software Engineering Institute (SEI) Capability Maturity Model (the CMM) as a framework for examining the adequacy of the processes of an organization and improving those processes. PAYOFF IDEA As IS organizations recognize the importance of formal, consistent processes as a means of increasing their productivity and effectiveness, they are turning to the Capability Maturity Model (CMM). This article defines CMM and the advantages to be derived by moving up the model. Auerbach Publications 1998 CRC Press LLC

2 The SEI at Carnegie Mellon University studies software development and support practices. Its researchers observed that the performance of a software development organization could be measured by assessing the maturity of its processes. As expected, those organizations that follow formal, well-defined processes are far more effective than ad hoc organizations. Further, it found that organizations could be arranged into categories based upon their level of process maturity. These studies led to the development of the CMM. This model formalizes the process of determining organizational maturity and provides a road map for improvement. IS organizations can achieve dramatic results by progressing from one level to the next. Corporations are increasingly understanding the importance of formal, consistent processes as a means of effectively operating their businesses. The success of franchise operations provides clear proof of the power of implementing standard processes across an entire company. Most IS organizations, however, operate with little or no formalization of processes. As application portfolios grow and new technology is introduced, the lack of standards will present a serious detriment to the businesses they support. This section examines the most-compelling reasons for IS organizations to revisit their processes. DEFINING THE CHALLENGE Businesses now depend on information to make rapid decisions as they navigate their way through a global economy. Technology enables competition. Companies leapfrog each other with new goods and services developed in ever-decreasing product cycles. Time to market is the watchword. Those companies with the shortest time to market survive, whereas those unable to respond quickly fall by the side. These business pressures apply equally to IS organizations. They must deliver the software functionality to support new business ventures faster than ever before. Moreover, they must be flexible in how they provide this functionality and how they respond to shifting requirements. As a result, the way that information systems are built and managed is changing. Information and the computing power that provides it is no longer housed in a single central location where it can be carefully controlled and managed. Computers appear on virtually every desk, and functions that used to require dedicated programmers are performed by computerliterate businesspeople. End-user applications that were once limited to custom reporting now handle mission-critical business functions. The growth of the Internet has led to an explosion of information sources and an assault on traditional IS values. Anyone can get data from anywhere, and traditional programming methods no longer apply. The rapid evolution and adoption of technology increases the complexity of the information infrastructures on a daily basis. Years ago, IS

3 organizations had one system platform and dealt primarily with a small handful of vendors. Today, those same organizations have many different types of platforms and operating environments using components provided by dozens, if not hundreds, of individual software and hardware providers. Unfortunately, the practices used by IS organizations have not kept pace with the evolution of the environment. Although automation has filtered into programming, technology is often poorly applied and productivity remains low. Corporate business areas frequently complain about the lack of IS responsiveness in meeting their needs. These complaints are underscored by a Standish Group study that found that only 16 percent of IS projects are delivered on time, within budget, with their specified functionality. 1 A staggering 30 percent of the projects are canceled outright. Worse yet, IS organizations have not transferred the knowledge from their past to the new programmers of today. Hard-won lessons, such as structured programming, adequate documentation, and code walkthroughs, have not appeared in many newly built applications. As a result, many C/C++ applications are actually less maintainable than their predecessors. Internet applications abound with programming inconsistencies (such as erasing all entered fields on a form when encountering an error) that would be unthinkable to an experienced programmer. These weaknesses have a direct effect on business operations. They are reflected in long lead times for new functionality, high costs for development and support, and increased operational risk. Delays in system deployment result in delays in entering the market with a new product or slow response to competitive pressures. Overall software reliability remains low. Low reliability impacts business productivity and adds cost and risks from mistakes. Few businesses would accept these shortcomings with their core business functions. What manufacturing company would run an assembly line in the same way it builds and manages its applications? Yet, the same companies that invest millions of dollars to increase the efficiency of their assembly lines fail to apply the same principles to their IS organizations. Perhaps the greatest catalyst for change will be the ongoing Year 2000 crisis. Once senior executives recover from the shock of their Year 2000 exposure and the cost of its fix, they will focus their attention on the practices that allowed the problem to grow to crisis proportions. As Watts Humphrey observes, One way to measure the capability of a software organization is to observe what is does in a crisis. That is when good practices are most important and that is when software people often have the least guidance. 2 Few IS organizations will fare well under this scrutiny. The shortcomings exposed by the Year 2000 crisis will extend far beyond overreliance on two-digit year fields. For example, se-

4 nior executives will discover that their IS organizations had to devote an inordinate level of resources to simply find all the applications that they manage. Other discoveries will lead to troubling realizations. If the IS organization lacked the test data needed to assure Year 2000 compliance, how were they testing the application before the crisis? The result will be tremendous pressure on the IS organization to revamp itself and its practices. THE ORIGIN OF THE CHALLENGE As IS organizations have grown, standard practices have fragmented into multiple versions. Individual application teams devise their own methods for handling their daily work, and over time, little commonality exists between procedures that accomplish the same basic purpose. Few organizations have the discipline to enforce common practices. For example, a process reengineering study at one large IS organization found 18 different common processes for handling a standard production error. The Year 2000 crisis is also exposing the lack of common program routines. One Year 2000 project manager reported that her team uncovered over 128 different date routines to handle a much smaller number of distinct date functions! The lack of commonality adds significantly to the cost of support and training. Staff members must be retrained everytime they shift teams. Changes to a practice or a program routine have to be made in multiple locations, increasing the cost and effort of support and the risk of introducing an error. Most IS organizations are aware of the poor state of their processes. Unfortunately, few of these organizations have the luxury of being able to reengineer their practices. Process reengineering requires a great deal of time and commitment on the part of the IS organization and its managers. Once the processes are redesigned, the bigger challenge is getting the practices adopted throughout the organization. Daily pressures and project deadlines encourage staff members to revert to familiar practices rather than learn new procedures. As a result, new practices are rarely adopted. When an existing procedure cannot be applied to a new technology, the procedure is usually dropped rather than replaced. This phenomenon can be seen in the software management practices used to control client/server applications. These applications rarely have the same stringent configuration management and audit controls as their mainframe brethren. A FUNDAMENTAL CHANGE IN ROLE Early IS staff members were application builders responsible for translating business requirements to new applications. Little effort was spent on application maintenance. Over time, the portfolio of applications grew as more applications were added but few were retired. This portfolio re-

5 quires constant maintenance. As a result, the role of the IS organization has shifted from that of an application builder to that of a portfolio manager. Despite the attention devoted to new applications and new technology, the bulk of IS resources is spent on managing existing applications. To meet the challenges defined thus far in this article, IS organizations must shift their culture from that of individual programming artists to that of software engineers. As part of that shift, IS organizations must move past the ad hoc processes that are in place today to well-defined, formal processes that can ensure consistent, high-quality results. This shift will allow business applications to be developed and supported with a focus on business rather than technology. THE CAPABILITY MATURITY MODEL While many IS organizations realize that their processes could use refinement, they are often hard-pressed to determine which improvements are needed and where best to apply those improvements. Part of the confusion stems from examining processes on an individual basis. Most organizations can point to pockets of excellence in individual processes, but overall excellence is limited by the weakest processes in the chain. Further, the effectiveness of the processes of an organization is also limited by its ability to apply those processes consistently and correctly. In this section, the CMM is introduced as an objective means for evaluating the present processes of an organization and improving those processes. The model considers process availability i.e., the capability of the organization to deliver high-quality services in a timely manner and the institutionalization of those processes. Institutionalization, or maturity, indicates the ability of an organization to apply its processes, refine them, and introduce new processes as business and technical requirements demand. In presenting the CMM, this section also explores some of the benefits of mature organizations as well as the components and processes required to advance through the levels of the CMM. A MEANS TO ASSESS PROCESS MATURITY The CMM provides a template for evaluating the process maturity of an organization by comparing that organization against a series of well-defined levels. Each level is a plateau on the path toward becoming a mature software organization. The characteristics of the level are easily described, as is the set of actions required to reach the subsequent level. The model formalizes the process of determining organizational maturity and provides a road map for improvement. Before meaningful improvements can be made, a baseline of the current state of the organization is required. The current state is a summa-

6 tion of the states of all of the IS processes of the organization. Process availability, quality, level of redundancy, and consistency of use are all factors that contribute to the baseline. It is this summation that truly defines the capability of the organization to deliver high-quality services in a timely manner. The culture of the organization, including its ability to assimilate new processes, is equally important. Introducing new, improved processes is a pointless exercise unless those processes can be institutionalized. Advanced organizations have the mechanisms to update existing processes and deploy new processes quickly, whereas ad hoc organizations can at best accomplish change in a haphazard manner. An organization is as limited by its maturity for handling its processes as it is by the capabilities of the existing processes. The CMM was originally developed by Watts Humphrey and other researchers at the SEI at Carnegie Mellon University as part of an Air Forcefunded project. The objective of this study was to provide a method for evaluating the effectiveness of software contractors. As part of this study, researchers analyzed the strengths and weaknesses of the organizations that they evaluated to ascertain which characteristics best determined organizational capabilities. They discovered that the maturity of the processes of an organization were directly related to performance of the organization. As expected, those organizations that follow formal, welldefined processes are far more effective than ad hoc organizations. Further, they found that organizations could be arranged into well-defined categories based upon their level of process maturity. These categories became the levels of the CMM. Although the model was originally built to evaluate software contractors, its value to IS organizations was quickly recognized. In addition to providing a framework for analyzing organizational maturity, the model provides a road map for progressing to higher levels of maturity. To reach the next stage, an IS organization must implement the characteristics of that level. These characteristics and the transformations required to implement them are part of the CMM. THE LEVELS OF THE CMM The best method for understanding the value of the CMM is to understand each level of the model and its characteristics. As shown in Exhibit 1, the model defines five distinct levels of increasing process maturity: Initial, Repeatable, Defined, Managed, and Optimized. As organizations move from level to level, productivity is enhanced and risk is minimized. The characteristics of each level are described below. Level 1: Initial. Organizations at this level perform their work on an ad hoc basis with each programmer left to his or her own devices for the

7 EXHIBIT 1 Effect Moving up the CMM Has on the IS Organization quality of the efforts. These organizations typically lack formalized procedures for most of their work efforts. If any formal procedures exist, they lack the management mechanisms required to ensure their use. Project management disciplines are lax at best, and key software processes such as configuration management and project planning are applied haphazardly. Software tools are not integrated in the processes and are used at the whim of programmers. Programmers in these organizations tend to view quality assurance efforts as overhead not directly related to delivery of their work efforts. They fail to understand the consequences of their chaotic behavior. There is very little formalization of process, and hence successes are difficult to repeat and failures difficult to avoid. Results are unpredictable, the process is poorly controlled and successes are due to the efforts of dedicated individuals rather than the organization. Level 2: Repeatable. IS organizations at this level rely heavily on rigorous project management to control their efforts and meet project cost and time commitments. Although these enhancements are still rudimentary from a process perspective, they are sufficient to gain dramatic improvements in operational performance over level 1 organizations. These controls allow the organization to repeat previously mastered tasks successfully and to avoid repetition of failures. This strength is derived from the ability of the organization to capitalize on its experience at performing similar work. Although level 2 organizations have formal planning

8 and project controls in place, the bulk of their procedures is institutionalized through staff experience rather than documentation. This greatly increases the difficulty of adapting to new situations. Processes cannot be changed or tools added without significant disruption and resistance. There is no frame of reference for new activities, and instituting new tools or processes destroys the relevance of the prior experience. Level 3: Defined. At this level, processes have been formally defined and documented and are well understood and followed by IS staff. Formal process models establish best practices and illustrate the correct points to employ software tools. As a result, programmers implement the same task in the same manner. When faced with a crisis, programming teams will continue to use the procedures rather than revert to manual methods of attacking the problem. Once an IS organization has reached this level, it has created the foundation for continuing progress. New processes and tools can be introduced with minor disruption to the work effort. New staff members are easily trained to adopt the practices of the organization. Although this level represents a major improvement over the previous two levels, it does not capture the data to manage its processes proactively. Level 4: Managed. This level of process maturity focuses on the quality of the products delivered by each process. At this stage, processes are managed in a manner akin to the methods used to manage an assembly line. Quality targets are set for each process step and cost and yield data is collected. Processes are measured for efficiency and level of reworks. This data is used to identify and correct issues with process performance. When new tools or processes are added or adjustments are made to existing processes, the metrics data provides a means of assessing the success of the adjustment. The data can be used proactively to justify new tools and techniques. The greatest risk at this level is allocating excessive resources toward collecting and maintaining the process data. For this reason, only the most valuable data should be collected and automatic collection methods should be employed wherever possible. Level 5: Optimized. Organizations that reach this level of process maturity can devote their efforts to continuous process improvement. The data collected during process operation is used to tune the processes themselves. Process performance is continually monitored for opportunities for improvement. Since the previous stages focus on control and work product production, they run the risk of subprocess optimization. Subprocess optimization results when one subprocess is optimized at the expense of the processes that surround it. While the performance of the subprocess is enhanced, the performance of the overall process is degraded. Organizations at this level have the data and experience to mon-

9 EXHIBIT 2 CMM Project Statistics for a 200,000 LOC Development Project Organization s CMM Level Calendar Months Level of Effort Defects Shipped Median Cost Lowest Cost Highest Cost Level 1 30 mos. 600 person mos. 61 $5.5M $1.8M $100+M Level mos. 143 person mos. 12 $1.3M $.96M $1.7M Level 3 15 mos. 80 person mos. 7 $.728M $.518M $.933M Source: Master Systems, Inc. All rights reserved. itor and adjust their processes as a whole. These organizations go beyond being able to assimilate new processes quickly; they can proactively determine when new processes will be needed. THE BENEFITS OF PROCESS IMPROVEMENT As the previous section illustrates, IS organizations can achieve significant benefits from progressing through the CMM stages. These benefits appear in many forms. New development projects deliver new functionality faster, cheaper, and with fewer defects at each level of the maturity model. Exhibit 2 dramatically illustrates the types of gains that can be achieved moving between levels 1 through 3. The statistics in the chart above were taken from a database of 1300 completed projects and the costs were computed using a burdened rate of $110,000/year for each programmer. The gains achieved between level 1 and level 2 provide irrefutable justification for implementing project management controls. Although the change is less dramatic between levels 2 and 3, the cost and effort savings are still significant. Advanced organizations also enjoy a number of additional benefits beyond those identified in figure 2. These benefits are outlined below: Reduced Staffing Costs and Training Time Organizations with well-documented processes can quickly train and assimilate new personnel. Since the processes do not depend on years of experience within the organization, more junior staff members can be used where appropriate, freeing senior staff members for more-challenging projects. Since all projects use the same procedures, staff members can be rotated between projects with minimal loss of productivity. Team members can concentrate on learning the business-specific attributes of a new project rather than the details of the processes of the project. Greater Predictability Each level of process maturity provides a greater level of predictability in project delivery and quality. This predictability is a welcome change from the findings described earlier from the Standish Group study. The bud-

10 geting process is simplified and business areas can better plan for the delivery of their desired functionality. Higher-Quality Deliverables Advances in process maturity translate into improvements in deliverable quality. The level of defects drops at each level, and the statistics gathered at the higher levels of maturity can be used to determine the cost/benefit to the business of each deliverable. This capability enables the business areas to more target their expenditures more wisely. Enhanced Ability to Adapt to Changes Organizations that have reached the higher levels of process maturity have the mechanisms in place to allow them to assimilate new processes and tools quickly. Changes to their technology environments no longer cause the level of culture shock that occurs in level 1 and level 2 organizations. This capability enables advanced organizations to respond faster to new technologies and changing business requirements. From a corporate viewpoint, the business areas receiving the improved IS services gain a number of important benefits. The reduced time to market for new business functionality allows business areas to take advantage of new market opportunities rapidly and to respond more quickly to competitive challenges. An IS organization with mature processes is more flexible in its response to business requirements, offering the business areas more options in pursuing new opportunities. By spending less time fighting fires, the IS organization can proactively seek ways to strengthen the corporate business areas, thus becoming a true partner of the business rather than simply a service organization. Finally, the greater efficiency of the IS organization translates to lower costs for the services provided. Those savings can be passed to the bottom line or may be used to purchase additional services at the same cost. PROCESS IMPROVEMENT AND THE YEAR 2000 Despite the documented successes of organizations with mature processes, most IS organizations lag in their process maturity. According to Edward Yourdon, As of late 1994 about 90 percent of U.S. IS organizations were below Level 3. 3 Very few software organizations have been able to achieve the fifth (and highest) level. These statistics should worry senior executives facing the Year 2000 crisis. Year 2000 projects are primarily an exercise in large-scale project management. They require the flawless execution of multitudes of separate projects applying similar analysis and remediation techniques. In addition, these projects face a fixed end date with little room for recovery from errors.

11 It is easy to see that an IS organization must perform at least at level 2 (Repeatable) to have any chance of meeting its century-date project commitments. Organizations operating at level 1 will revert to firefighting (with its inevitable consequences) as their projects face increasing levels of stress. In contrast, IS organizations operating at level 3 and above have the necessary project management and process discipline to execute their Year 2000 projects effectively. These organizations can maximize their efficiency in the individual application projects by using standard processes wherever possible. As a result, these organizations will face significantly less project risk and deliver their projects faster and for less cost. BUILDING BLOCKS FOR SUCCESSFUL IMPROVEMENT Moving up the levels of the CMM requires the implementation of a number of critical components. The components described below are the building blocks used to construct a mature software organization. While some of these components may exist in an ad hoc organization, the key is how the blocks are assembled and managed. Processes Formal, defined processes are the foundation of any process improvement effort. A process is a series of repeatable tasks for performing a function or creating a major deliverable. All organizations have processes. The difference between a mature and an immature organization is the degree that those processes have been formalized and institutionalized. Organizations at the low end of the process maturity scale rely on their staff members to execute undocumented processes based on their experience. By contrast, advanced organizations rely on formal processes that are thoroughly documented and supported by metrics, tools, and a methodology, as shown in Exhibit 3. Metrics Metrics are an essential component of any mature process. Metrics are specific measures of quality, responsiveness, efficiency, and productivity. Continuous process improvement activities rely on metrics for statistical process control. They are used to monitor the effectiveness of the process and provide the data needed to tune process performance. Without adequate metrics, it is impossible to determine if a given process is improving or declining. To reduce the overhead of their collection and analysis, metrics should be an integral part of each process and their collection should be automated wherever possible. Exhibit 3 shows a few of the metrics used to monitor a formal process.

12 EXHIBIT 3 Task Layout in a Formal Process Management Controls Management controls consist of project management and technology management disciplines. Project management disciplines include requirements management, project planning with formal estimates, task prioritization, tracking and oversight of project activities, regular management reviews of project operations, and quality assurance reviews of project deliverables. Technology management disciplines include software configuration management, change and issue tracking, implementation of standards, and formal testing procedures. Although management controls can provide significant value even when applied at the project leader level of a single project, they provide their greatest benefit when they are uniformly applied across all projects and all layers of management. Automated Tools Processes do not need to be automated to be successful; however, one of the greatest advantages of formal processes is their ability to ensure the effective application of automation. If used, software tools can provide enormous improvements in productivity and deliverable quality. By providing a level of integration between otherwise independent tools, natural synergy between the tools can be exploited for additional gains. The quality and performance of the software tools available on the market have undergone tremendous improvement over the last few years. This provides mature IS organizations with an unprecedented opportunity to enhance their effectiveness through automation.

13 Methodology Methodologies are often misused as a means of introducing process disciplines into IS organizations at the low level of process maturity. These attempts usually fail as the organization is unable to assimilate the methodology. They face strong cultural resistance, and the organization quickly reverts to its old method in times of crisis. To be effective, a methodology must be the embodiment and documentation of the processes accepted by the organization. The methodology is the means for training new staff members and serves as a reference for experienced team members. Team members do not have to memorize the details of procedures that they perform infrequently, as those details are documented in the methodology. An effective methodology must be a repository of organizational knowledge, and it must evolve along with the processes that it supports. THE IMPROVEMENT PROCESS A level 1 software organization cannot achieve level 5 in the CMM is a single step. The full transformation usually takes years to accomplish and requires the organization to proceed through a series of steps. To develop the approach described below, the SEI analyzed the differences between software organizations at each level of maturity. The major differences were categorized into a set of common activities that are present in the higher-level organization but lacking in the lower-level organization. By successfully implementing and institutionalizing these activities, the organization moves to the next level of maturity. Institutionalizing the activities is a fundamental requirement. If the new level of process maturity is not fully embraced throughout the organization, it will quickly fall out of use and the organization will revert to status quo. Thus, the difficulty of implementing each step is determined by the willingness of the organization to embrace change and the level of management support behind the effort. Exhibit 4 shows how these improvement steps correspond to the levels in the CMM. Each step builds on the previous step, and its successful completion moves the organization up to the next level of process maturity. Fortunately, the organization reaps benefits from each step it takes. The process improvement steps are outlined below. Basic Management Controls Implementing the basic management controls described earlier in the section on Building Blocks for Successful Improvement is the crucial first step for process improvement. Until those disciplines are in place, the organization has no control of its work efforts. It can only determine

14 EXHIBIT 4 The Capability Maturity Model Improvement Process

15 the success or failure of an effort in hindsight, and can only guess at what it did right or wrong. This is often a difficult step to implement since these controls are viewed as overhead and management interference by staff members accustomed to operating as they please. This step requires considerable staff and management training and management to accomplish. Process Definition This step transforms the organization from individual projects working independently to coordinated efforts using common processes. It starts by finding and documenting the processes of the organization. Once the processes have been documented and reviewed, duplicate processes can be combined or deleted, gaps can be filled with new processes, and the organization can take advantage of standardizing its best processes. The newly documented processes are then available for reference and for training staff members. Formal programs are used to deliver this training. Although not as significant a culture shock as the previous step, the process definition exercise is often painful as staff members cling to the current processes and resist changing to the new versions. Process Management Once the processes of the organization have been defined and accepted, they can be managed. This step involves the creation of a formal process team that has responsibility for the maintenance and enhancement of the processes of the organization. This team can support the processes with a methodology and seek opportunities to add software automation where appropriate. Process Controls This step involves the addition of process metrics to monitor individual processes and track their operation as a whole. The metrics allow processes to be tuned for optimal performance. This is an enormous step from a quality perspective. It enables the organization to shift its focus from reactive activities such as defect correction to proactive activities like defect prevention. These improvements can cut across processes and organizational structures. For example, if Help Desk telephone logs identify an unusually high number of questions about a particular application business function, it may trigger a redesign of that function s interface to simplify its use and reduce the number of questions. This solution increases the productivity of the business users of the application while eliminating unnecessary effort within the IS organization. Continuous Process Improvement The final step in the improvement process is implementing a culture of continuous process improvement. This step is the culmination of all of

16 the steps that precede it. Processes cannot be put into place and forgotten. They need regular monitoring, tuning, and maintenance. That is why the final building block of a mature software organization is a culture of continuous process improvement. As its name implies, continuous process improvement is a long-term, ongoing activity designed to ensure the processes of the organization operate at ever-increasing effectiveness. Continuous process improvement must be part of the IS organization s culture. As they perform their routine tasks, IS staff members proactively seek methods to enhance and improve the processes used for those tasks. This article is copyright Keane, Inc., Brian Keane is responsible for the Information Services Division and Healthcare Services Division at Keane, Inc. He spearheads the strategic services business for Keane, which includes IT consulting, application outsourcing, Year 2000 compliance, application development, help desk outsourcing, and enterprise healthcare solutions. A graduate of Harvard College and Harvard Business School, Mr. Keane can be reached at KEANE. References 1. Johnson, Jim, Chaos: The Dollar Drain of IT Project Failures, Application Development Trends, Volume 2, Number 1, January Humphrey, Watts S., Managing the Software Process. Reading, MA: Addison-Wesley, Yourdon, Edward. Rise & Resurrection of the American Programmer. Upper Saddle River, NJ: Prentice Hall, 1996.