Chapter 2
Why Process Improvement Helps
We’ve described process as one way of getting a handle on activities that deal with creative thought, and as the mediator among your enterprise’s people, technology, and environment. It helps us order our thinking by defining common activities and artifacts. Process is also a means to capture and transfer the knowledge we gain in developing a particular product or service.
We learn about a process nearly every time we execute it. By taking time and effort, we can apply our knowledge to make the process better. Innovative ways to improve the productivity or predictability of a process may come to mind. Processes need to fit the task, so as the specific circumstances we are dealing with change, our processes need to respond. There are also times when we need to create new processes. We’ll almost never make them exactly right the first time.
All this leads us to the idea of improving processes. We want our processes to be the perfect balance of discipline and agility† so they enable us to create the most value with the least cost. This is rarely accomplished in a “one step to greatness” paradigm. The usual method is a stepwise refinement of the process, although in some cases, radical changes can require radically different processes.
† Discipline generally is defined as compliance or strong guidance. Agility is the flexibility to take advantage of or react quickly to limit the impact of unforeseen changes. You can find more about this in Balancing Agility and Discipline, by Barry Boehm and Richard Turner (Boston: Addison-Wesley, 2004).
This section addresses the “whys,” and some of the high-level “hows,” of process improvement. Each section deals with one of our fundamental tenets of process improvement. These tenets are reflected in various ways throughout the rest of the book.
2.1 Process Improvement Is About Learning
Processes are a means of capturing knowledge and passing it on to others. Knowledge can be explicit and written or tacit and observed. Process improvement can be thought of as identifying and deploying knowledge over larger and larger groups. Right now, some individuals within your organization know ways of doing their jobs that are more effective than the ways their peers use. This individual knowledge is an asset that is not intentionally or explicitly available to others. If the individual writes up guidance that can be shared, the knowledge becomes available to others, but there is no real organizational intention of using it. Process improvement helps incorporate that intention into the way the organization works.
Most process improvement models have levels or stages that can be used as targets for improvement initiatives. From a learning perspective, all the models describe the scope of knowledge deployment within an organization. The following stages of learning map well to maturity levels for any CMM:
• Individual learning. Knowledge resides within individuals and may be informally shared with others in an ad hoc fashion.
• Group learning. Knowledge is explicitly collected and shared within groups such as teams or projects, supporting better performance within the group.
• Organizational learning. Group-based knowledge is collected and standardized, and mechanisms exist that encourage its use across related groups.
• Quantitative learning. The organizational knowledge transfer and use are measured, and decisions are made based on empirical information in addition to qualitative information. Shared knowledge is deep and wide enough to determine where quantitative methods make sense within the organization.
• Strategic learning. Knowledge collection, transfer, and use are rapid across the organization; strong, deep, and wide channels for applying innovation are available, and their use is intrinsic in the organization’s behavior.
The first four stages generally focus on improving the operational effectiveness of the organization. Operations, as used here, are not limited to managing the manufacturing plant’s resources or maintaining the software; we mean improving the effectiveness of the day-to-day operations of whatever it is you’re doing. For many software organizations, improving operational effectiveness is mostly about improving the processes they use in software product development. The fifth stage is a bit different. It’s about using what you know about your operational capabilities to respond flexibly and effectively to changes in your environment: market changes, organizational changes, key personnel changes, and so on. One of the reasons we believe maturity models are so popular is that most individuals and groups recognize the learning stages reflected here as reasonable and appropriate. Another reason is that maturity models explicitly contain mechanisms for encouraging the improvement of the targeted processes with relation to this learning viewpoint.
2.2 Process Improvement Should Be Driven By Business Value
Your business status, objectives, and goals are major inputs into making process improvement work for you. To be most effective, you need to identify and rank the business processes that are most critical to achieving your goals.
Sometimes, this kind of analysis and reflection helps identify key targets for improvement. If your company is essentially a consulting firm, for example, the most critical processes might be those associated with responding to customers, identifying new clients, or generating proposals. On the other hand, if you build products, processes for handling quality control or meeting critical delivery timelines might warrant investigation. If your goals involve growth, looking at how your existing way of doing business will scale up may identify processes that need to be changed radically to meet the projected expansion of staff and business.
One of the reasons the Capability Maturity Models have been so widely applied is that they can help focus you on the things that have historically been critical success factors in their particular domain. Other aids in identifying critical factors include domain competency models like the Project Management Body of Knowledge Guide 1 and domain standards such as those published by industry organizations like the IEEE (Institute of Electrical and Electronics Engineers) and SAE (Society of Automotive Engineers), as well as international standards bodies like ISO (International Organization for Standardization).
1. Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). 3d ed. (Newton Square, Penn.: Project Management Institute, 2000).
Regardless of how you do the analysis, the key issue is to target processes where improvement seems most likely to yield a strong return on investment. Be careful, however, not to miss the interaction of processes. Often, there are enabling processes that support the processes you want to improve. If your version control for products is out of whack, changing your customer delivery system may result only in delivering the wrong product faster—not necessarily an improvement in business value. Or improving the performance of your order management system could overload your order processing or shipping processes and lead to delays rather than shorter schedules. This interaction is a key reason planning and executing process improvement efforts is more complex than it may seem.
2.3 Process Improvement Can Be Valuable For Organizations Of All Sizes
Often, small businesses and organizations assert that process improvement works only for the big guys—that you have to have large overhead resources and dedicated process people to be effective. Fortunately, this is often not the case at all. We agree that the traditional approaches to process improvement (a la CMMs) have tended toward larger efforts—but if you think about it, they evolved through application within larger projects (such as the aerospace world of satellites, shuttles, and ground stations) and very naturally reflected that environment. Conway’s law concerning the structure of a developed system reflecting the organizational structure of its developers can come into play for human systems, too.2 And we believe it has.
2. Conway, Melvin E. “How Do Committees Invent?” In Datamation, April 1968, pp. 28–31.
Consider for a moment the evolution of agile software development methods. They have been harangued for being unscalable, but because they were a product of small internal IT development projects, they reflect the ways things were accomplished in those shops. Despite their heritage, however, they are now being selectively applied in very large settings with promising, if varied, success. The success usually depends on how creative the folks are who apply them. In a similar way, creative and energetic people (like us) have found ways to apply process improvement in such a way that consideration is given to the size of your organization, making process improvement an asset to enterprises of any size.
Almost every technique or approach we describe in this book can be applied to small organizations. Additional information on process improvement in smaller settings is available in the CMMI adoption pages of the Software Engineering Institute (SEI) Web site (www.sei.cmu.edu/cmmi/adoption/acss).
2.4 You Have Choices In Your Improvement Approach
One thing that makes doing process improvement challenging is that there are many ways to approach it. These approaches usually are called process improvement life cycles, and almost all of them have been successful somewhere. The question is, which approach will be most successful for you?
In the following sections, we very briefly describe a few of these life cycles. These are the ones we’ve worked with or seen working successfully in multiple contexts. Understand that this is a personal, selective, and noninclusive list; you can choose among dozens of life cycles, and you have many sources for learning about how to use each one. If you look into the ones we identify and decide that none of them fits your situation, you will find resources in Chapter 15 that offer even more choices.
The last life cycle in this section, DLI, is a bit different from the others and is our synthesis of what we’ve seen work from other life cycles. It is elaborated more fully in Part 2.
2.4.1 Ideal
The IDEAL model is a process improvement life cycle developed by the SEI to provide organizations with a high-level set of activities that they can follow to execute an improvement program. It is a variation on a basic Plan-Do-Check-Act (PDCA) cycle, also known as a Shewhart cycle.3 Each of the letters in IDEAL stands for one phase of the life cycle:
3. McFeeley, Robert. IDEAL: A User’s Guide for Software Process Improvement. CMU/SEI-96-HB-001. (Pittsburgh: Carnegie Mellon University, 1996).
I=Initiation. The fundamental sponsorship and business reasons for engaging in improvement are established within the organization, and resources are prepared to begin the improvement effort.
D=Diagnosis. The organization attempts to understand the gaps between its intended process state and its current processes. This gap analysis should be based on the process needs of the organization, which in turn are based on the organization’s business goals.
E=Establishment. The infrastructure for the process improvement effort is set up, and the resources for engaging in effective process improvement activities are established.
A=Action. The process improvement teams engage in activities to make improvements in the processes that were identified in the Diagnosis phase as being necessary to improve the organization.
L=Learning or Leveraging. The organization looks across the improvement activities that have taken place and learns from what went well and what didn’t go well so as to improve its approach to the next cycle of improvement.
Figure 2-1 shows a graphical depiction of the IDEAL cycle. The SEI Web site contains a substantial amount of information on the phases of IDEAL. Start at www.sei.cmu.edu/ideal to get to free SEI resources related to IDEAL. You will also find presentations related to IDEAL at conferences devoted to systems and software process improvement, such as the Systems and Software Engineering Process Group (SEPG) conference. Chapter 15 lists several annual conferences that may provide useful information for you.
Figure 2-1: IDEAL cycle
2.4.2 Six Sigma
Jeannine Sivy and Eileen Forrester at the SEI describe Six Sigma as “an approach to business improvement that includes a philosophy, a set of metrics, an improvement framework, and a toolkit of analytical methods. Its philosophy is to improve customer satisfaction by eliminating and preventing defects, resulting in increased profitability. Sigma () is the Greek symbol used to represent the statistical value known as standard deviation, or the amount of variation in a process. The measure six sigma (6), from which the overall approach derives its name, refers to a measure of process variation (six standard deviations) that translates into an error or defect rate of 3.4 parts per million, or 99.9997 percent defect free. In the Six Sigma approach, defects are defined as anything in a product or service, or any process variation that prevents the needs of the customer from being met.”4
4. Bergey, John, Jeannine Sivy, Eileen Forrester, et al. Results of Independent Research and Development Projects and Report on Emerging Technologies and Technology Trends. CMU/SEI-2004-TR-018. (Pittsburgh: Carnegie Mellon University, 2004), pp. 33–42.
One of the primary improvement frameworks associated with Six Sigma is DMAIC (Define, Measure, Analyze, Improve, Control), which is illustrated in Figure 2-2.
As you probably guessed, this is another PDCA cycle variant, with more emphasis on the Do-Check part of the cycle.
Some organizations use Six Sigma methods and tools to help implement their process improvement strategy. The SEI technical report Results of SEI Independent Research and Development Projects and Report on Emerging Technologies and Technology Trends 5 summarizes a study conducted by the SEI on using Six Sigma to enable successful technology transition. The primary technology under study was CMMI, so you may find some useful ideas in the Six Sigma section of this report.
5. Bergey, John et al., Results of SEI Independent Research and Development Projects and Report on Emerging Technologies and Technology Trends, CMU/SEI-2004-TR-018. (Pittsburgh: Carnegie Mellon University, 2004).
One thing that makes Six Sigma techniques attractive in conjunction with CMMI-based improvement is that Six Sigma constantly and consistently emphasizes alignment of the improvement tasks/approaches with business goals, so it acts as an amplifier for one of the philosophies of CMMI that is sometimes hard to see in the details of the model.
Figure 2-2: Summary of Six Sigma DMAIC cycle
2.4.3 Qip
The Quality Improvement Paradigm (QIP) is an improvement approach that has evolved over a period of 25 years of experience with improving software in the NASA Software Engineering Laboratory, a joint effort of the University of Maryland, Computer Sciences Corporation, and NASA Goddard Space Flight Center.6 Developed by Dr. Victor Basili of the University of Maryland, QIP builds a continually improving organization based upon identifying and assessing against its own evolving goals.7 QIP, as illustrated in Figure 2-3, is a cyclical process for organizational improvement that focuses practitioners on understanding how quantitative measures across projects contribute to larger organizational goals.8
6. Basili, V., and S. Green. “Software Process Evolution at the SEL.” In IEEE Software, July 1994, pp. 58–66.
7. Basili, V. “The Experience Factory and its Relationship to Other Improvement Paradigms.” In Proceedings of the Fourth European Software Engineering Conference (ESEC) in Garmish-Partenkirchen, Germany. The Proceedings appeared as lecture notes in Computer Science, September 1993.
8. Shull F., C. Seaman, and M. Zelkowitz. “Quality Time: Victor R. Basili’s Contributions to Software Quality.” In IEEE Software, January 2006, pp. 16–18.
QIP is a two-feedback loop process (project and organization loops) that is a variation of the scientific method.9 It consists of six fundamental steps:
9. Basili, V., G. Caldiera, F. McGarry, R. Pajerski, G. Page, and S. Waligora. “The Software Engineering Laboratory—An Operational Software Experience Factory,” In Proceedings of the Fourteenth International Conference on Software Engineering, May 1992.
1. Characterize the project and its environment with respect to models and metrics.
2. Set quantifiable goals for successful project performance and improvement.
3. Choose the appropriate process models, supporting methods, and tools for the project.
4. Execute the processes, construct the products, collect and validate the prescribed data, and analyze the data to provide real-time feedback for corrective action.
5. Analyze the data to evaluate current practices, determine problems, record findings, and make recommendations for future project improvements.
6. Package the experience in the form of updated and refined models and other forms of structured knowledge gained from this and previous projects, and save it in an experience base to be reused by future projects.
The QIP uses two tools that are key to its successful implementation: the Goal/Question/Metric (GQM) paradigm and the Experience Factory Organization (EFO). GQM supports QIP by providing a systematic approach for tailoring and integrating goals with models according to the specific needs of the project and organization. The EFO is an organizational structure, separate and distinct from the project, that performs the experience-building activities specified by the QIP in steps 5 and 6.
Figure 2-3: Quality Improvement Paradigm
QIP prescribes a foundational mechanism within the organization that represents what is expected from a CMMI Maturity Level 5 organization. Level 5 organizations can manipulate process to achieve various product characteristics through the use of a process and an organizational structure to:
• Understand processes and products
• Measure and model the project and the organization
• Define and tailor process and product qualities explicitly
• Understand the relationship between process and product qualities
• Feed back information for project control
• Experiment with methods and techniques
• Evaluate successes and failures
• Learn from experience
• Package and reuse successful experience
Because QIP drives the process improvement efforts through an understanding of the business—product and process problems, business goals, local experiences with methods, and so on—the motivation for the process improvement initiative is the same as the motivation for organizational success.
2.4.4 Agile Methods
Surprisingly, agile software development methods—long seen as an anathema to “process mature” organizations—have a lot to offer when it comes to process improvement. Although not specifically aimed at organizational processes, the principles of agile methods provide mechanisms that help meet several typical process improvement goals, particularly at the team or project level. First, their insistence on short cycle times and iteration, if applied to process improvement, fulfills the need to show value early in the process. Second, many methods include a post-iteration analysis or “reflection” on what went well, what didn’t, and how the team could do it differently in the future. Because data on the velocity of the work and the productivity of the team is maintained, changes can be evaluated empirically to validate their benefit. Quick application of process changes and feedback mean that “wrong” directions are caught early and useful changes can be propagated quickly.
For summaries of popular agile methods (as well as summaries of plandriven methods such as CMMI and TSP), Balancing Agility and Discipline, by Barry Boehm and Richard Turner, is a good place to start.10
10. Boehm, Barry, and Richard Turner. Balancing Agility and Discipline. (Boston: Addison-Wesley, 2004).
2.4.5 Dli
For many organizations, IDEAL is a favored life cycle. It was developed explicitly for supporting model-based process improvement, and it provides more detail than many other life-cycle models, which is useful for many people. We also have encountered people who find the Initiating phase of IDEAL to be more than they are ready to invest in. In fact, the question they often ask is “How can I prove to myself and my management that investing in the infrastructure recommended by IDEAL will be worth it?” Our answer to that question is a precursor life cycle to IDEAL that can help you navigate the initial choices you need to make even before you commit to building a process improvement infrastructure. Based on some of the agile principles, DLI (Decision-based Lifecycle for Improvement) takes you through a trial use of the model to see just how it helps solve the problems and meet the goals of your business. In this way, it provides information you need to make a decision as to whether to stop, continue, or redirect your process improvement initiative.
Figure 2-4 illustrates the DLI stages. In Chapter 4 we describe the DLI model in much more detail.
Figure 2-4: A Decision-based Lifecycle for Improvement
2.5 You Have Choices In Your Reference Model
As we mentioned in the introduction to Part I, you can use several models or standards as a reference in designing, implementing, and evaluating your organizational processes. Some are specific to certain domains or businesses, and some are very general. Some are explicit in their guidance, and others are more abstract. All have constituencies that support (and sometimes proselytize) their use.
Although having a reference model to guide you in your improvement effort is not absolutely necessary, in our experience, it usually is a good idea. Using a model:
• Provides a common framework and language to help you communicate across your organization and with other organizations
• Leverages years of experience as to critical success factors for the processes within their scope
• Limits “tunnel vision” by reminding you of the big picture
• Allows you to concentrate on improving more than creating
• Generally is supported by training, consulting, and ancillary literature
• Provides an arbiter for disagreements
In this section, we briefly describe some of the most widely used references. In Chapter 5, we discuss what you need to know to choose the one that best fits your business and operating environment. Like our description of lifecycles, this is a selective, noninclusive list based on our experiences.
2.5.1 No Reference Model
You can choose to forgo a reference model and still have a successful process improvement initiative. It may be that your particular work environment is unique or is not sufficiently addressed in any of the common reference models. You can readily apply to your particular needs many of the techniques and approaches we discuss throughout the book. Even without a model, however, it usually is good to have some way of disciplining your thought processes. Six Sigma, Total Quality Management, Business Process Reengineering, and the Quality Improvement Paradigm are examples of proven, documented approaches that don’t require a reference model.
2.5.2 Cmmi
CMMI-DEV is the latest in the evolution of capability maturity models from the Software Engineering Institute (SEI) at Carnegie Mellon University in the United States. SEI is a research organization that receives its core funding from the U.S. Department of Defense and is chartered to improve the performance of the software industry.
At its simplest, CMMI-DEV (CMMI for Product Development) is
• A framework of management, engineering, and support best practices organized into 22 topics called Process Areas
• An approach to improving the capability of any of the 22 Process Areas by incrementally applying a set of Generic Practices that enhance the functioning of an individual process
• Best thought of as a set of “process requirements” that help guide an organization that is defining and implementing processes related to the 22 topics
• Not a predefined, implementable, “as is” process definition
CMMI is a terrific product, albeit a bit on the voluminous side and strongly aligned to product development in its initial version. It has rapidly become a popular international improvement framework; as of May 2006, over 50,000 people from all over the world have been through the three-day “Introduction to CMMI” course.† Although we use CMMI in many of our examples in this book, we want to stress that it is not the only process improvement paradigm. We discuss others in the next few paragraphs and will discuss CMMI in much more detail in the next chapter and in Part II. If the material on CMMI is intriguing, a good starting place for managers and other “non-process-savvy” people to learn more is CMMI Distilled, by Dennis Ahern, Aaron Clouse, and Richard Turner.11 The full-blown model is available for download from the SEI Web site and in CMMI: Guidelines for Process Integration and Product Improvement, 2d ed., by Mary Beth Chrissis, Mike Conrad, and Sandy Shrum.12
† To keep up with current adoption statistics, access the SEI’s public transition aids site and look for the “CMMI Today” folder that contains the most recent public briefing slides on CMMI: https://bscw.sei.cmu.edu/pub/bscw.cgi/0/395854.
11. Ahern, Dennis, et al. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. 2d ed. (Boston: Addison-Wesley, 2004).
12. Chrissis, Mary Beth, et al. CMMI: Guidelines for Process Integration and Product Improvement. 2d ed. (Boston: Addison-Wesley, 2006).
Organizations can be appraised against CMMI, using a team led by an authorized lead appraiser who can assign capability or maturity ratings. The results can be posted at an SEI-refereed Web site to share with current and potential customers (not to mention the soon-to-be-envious competition). The SEI administers authorization programs for lead appraisers and Introduction to CMMI instructors. Using authorized instructors and lead appraisers ensures that you are getting authentic SEI services from SEI partners who have gone through appropriate training and mentoring for their role.
2.5.3 Iso 9000 Series
The International Organization for Standardization (ISO, after its name in French) is a nongovernmental, worldwide organization that coordinates the development of international standards for a broad variety of disciplines and domains. ISO 9000 is a series of quality-management and quality-control standards. It has been applied to manufacturing, printing, electronics, steel, computing, legal services, financial services, retailing, aerospace, construction, pharmaceuticals, publishing, telecommunications, health care, hospitality, and dozens of other business sectors and domains.
ISO 9001 establishes a set of requirements (called normative clauses) for a quality-management system.13 Businesses develop their own quality processes that meet these requirements. After the quality system is up and running, several audits are conducted (both internal and external) to make sure all requirements are met. If the system passes the audit by an official Registrar, the organization is certified and registered, and may use this certification in its marketing and advertising. A company doesn’t have to complete certification to use 9000 to improve its quality processes, of course, but most companies do identify certification as a goal.
13. ISO 9001:2000(E). Quality Management Systems—Requirements. International Organization for Standardization. Dec. 15, 2000. 3d ed.
Information about ISO is available at www.iso.org. Although the standards are available only from ISO, a wealth of consulting organizations, auxiliary publications, and conferences support ISO 9000. There is even a book that covers using ISO 9001 (and a few other standards) with CMMI: Systematic Process Improvement Using ISO 9001:2000 and CMMI, by Boris Mutafelija and Harvey Stromberg.14
14. Mutafelija, Boris, and Harvey Stromberg. Systematic Process Improvement Using ISO 9001:2000 and CMMI. (Boston: Artech House Publishing, 2003).
2.5.4 Iso 15504/12207/15288
There is also a set of ISO standards related to software and system development that organizations can use to support their process assessment and improvement efforts.
ISO 12207 focuses on software development and management.15 ISO 15288 focuses on system development and management.16 ISO 15504 is an assessment and evaluation standard that allows the use of a Process Reference Model (PRM) as the basis of assessment.17 Either 12207 or 15504 could be used as the PRM for ISO 15504. Other models are also used as the PRM for 15504, usually nationally created standards such as Mexico’s MoProSoft.18 The SEI is working with the ISO 15504 team to achieve PRM status for CMMI.
15. ISO/IEC 12207. 1995 Information Technology—Software Life Cycle Processes, Edition 1.0, International Organization for Standardization/International Electrotechnical Commission, Aug. 1, 1995; ISO/IEC 12207/Amd1:2002 Information technology—Software life cycle processes—Amendment 1. International Organization for Standardization/International Electrotechnical Commission, May 1, 2002; ISO/IEC 12207/Amd1:2002 Information technology—Software life cycle processes—Amendment 1, International Organization for Standardization/International Electrotechnical Commission, May 1, 2002.
16. ISO/IEC 15288:2002. Systems engineering—System life cycle processes. International Organization for Standardization/International Electrotechnical Commission. Nov. 1, 2002.
17. ISO/IEC TR 15504-5:1999. Information technology—Software Process Assessment—Part 5: An assessment model and indicator guidance. International Organization for Standardization/International Electrotechnical Commission (technical report), May 1, 1999.
18. Oktaba, Hanna. MoProSoft: modelo de procesos para la industria de software, pp. 251–260. (Cartagena: C.F.C.E., 2003).
If you are involved in a marketplace that recognizes these standards, familiarity with them and ability to cite compliance with them could be an advantage for you. In the United States, the source for official ISO standards documents is ANSI (American National Standards Institute). You will find consulting and appraisal resources fairly easily by searching the Internet, but the penetration of these standards across the world marketplace is quite spotty. In some regions, you will find a great deal of support for them; in others, you will have trouble finding the resources you need.
Also, because of the fairly tight controls ISO puts on intellectual-property rights for the standards, you won’t find as many books on the market that explain and help you learn about them in comparison with some of your other choices.
2.5.5 Itil
The Information Technology Infrastructure Library (ITIL) is a collection of documents that addresses the whole range of internal information technology service management and delivery activities.19 Developed in the United Kingdom, it has gained extensive popularity in business and government, particularly in the traditional IT business processing environment. ITIL truly is a library. There are seven sets of documents, each set addressing a particular facet of IT. The current sets are Service Support, Service Delivery, Planning to Implement Service Management, Information and Communications Technology (ICT) Infrastructure Management, Applications Management, Security Management, and The Business Perspective. The ITIL is managed by the UK Office of Government Commerce (OGC).20
19. BS ISO/IEC 20000-1:2005. Information technology. Service management. Specification. British Standard/International Organization for Standardization/International Electrotechnical Commission. ISB 0-580-40470-6; BS ISO/IEC 20000-2:2005. Information technology. Service management. Code of practice. British Standard/International Organization for Standardization/ International Electrotechnical Commission. ISBN 0-580-41125-7.
20. www.ogc.gov.uk (ITIL managing organization).
ITIL currently does not have an organizational certification or evaluation method. Rather, individuals can be certified as to their knowledge and understanding of the library through official examinations at three levels: Foundation, Practitioner, and Manager. These certifications are administered by Examination Institutes regulated by the OGC. More information is available at http://www.itil.co.uk.
2.5.6 Cobit
Control Objectives for Information and related Technology (COBIT) is an IT governance framework and supporting tool set. It supports the establishment of processes to control and govern IT-related activities.21 COBIT is maintained by the IT Governance Institute (ITGI), a not-for-profit, externally funded research institute that studies how IT policy interacts with and supports business strategy, technical risk, and corporate control. ITGI was established by the Information Systems Audit and Control Association (ISACA), a not-for-profit professional organization that formerly was the EDPA Auditors Foundation, founded in 1969.
21. ISACA. Control Objectives for Information and Related Technology (COBIT). 4th ed. (Rolling Meadows, IL: ISACA, 2005). Available at www.isaca.org.
COBIT is structured hierarchically. There are four Domains, each divided into Processes, with each Process further divided into Control Objectives. Below the Control Objectives are around 1,600 Control Practices. The Control Objectives are stated in terms of a condition and so are auditable. No specific evaluation method is associated with COBIT, although several auditing methods are suitable. More information about COBIT is available at www. ITGI.org and www.ISACA.org.
2.5.7 “Interoperable” Process Improvement
As you may guess from the brief survey of selected reference models in the preceding sections, there is a good chance that in your business environment, more than one of the references mentioned (or some that weren’t mentioned) will be of interest to you. You may even have to be audited or appraised against more than one of these. You are not alone in facing this challenge. In the same way that many of your software systems now need to interoperate with other systems that were not originally conceived to work with yours, your processes will need to interoperate with more than one reference model or standard. SuZ has started calling this need interoperable process improvement, whereas the Systems and Software Consortium refers to it as multi-compliant frameworks. Other terms you may hear include transparent process architecture and unified process improvement architecture.
You have three ways to approach dealing with multiple standard reference models:
• Deal with each individually—that is, map your processes onto ISO 9001 requirements; next, map them onto CMMI; and then map them onto whatever else you’re asked to interoperate with.
• Make your internal processes the unifying reference—that is, each of your processes would contain tagging that shows all the different areas of all the standards you are dealing with.
• Make one of the standards you work with the unifying reference—that is, map each of the other standards to the selected standard and then map your processes to that standard as the unifying reference.
We believe that the third choice is the one that holds the most promise long term. Figure 2-5 provides a diagram illustrating what this might look like.†
† Thanks to Pat Kirwan and Urs Andelfinger for the animated discussions that led to clarifying this concept. The initial work on Unified Process Improvement Architecture made it possible to see and coherently discuss the issues around working with multiple standards.
For this approach to work, the unifying reference has to be detailed enough that it covers most of the content in the other standards you use. It also needs to be publicly available so that you can easily map the other standards to it. We favor (huge surprise!) CMMI for this reference. Here are a few reasons we think this approach is fruitful:
• CMMI normative (the content you get audited or appraised against) and informative content is publicly available at detailed levels and covers much of the content in standards commonly referenced.
Figure 2-5: Interoperable process improvement with CMMI as the unifying reference
• Public mappings of different standards to CMMI are available from multiple sources, making it possible to review/validate them.
• Because of the different audiences, purposes, and levels of detail of the different standards, you’ll never be able to say, “If I do x on this standard, it automatically covers y on this other one.” But being able to say, “If I do x on CMMI, I probably should look at how that affects y in the related clause of <standard>” is still a valuable way to cut down on how much of each standard you have to look at to satisfy yourself that you’re progressing toward compliance where it’s needed.
• When (not if) changes to one of the standards occurs, you can do an impact analysis via the reference (CMMI), and you can count on others needing to do that too, so there is a high likelihood that you’ll be able to find articles, assets on public Web sites, and the like to help you through the change. If the changes don’t change the mapping, you still look in the same place in your own process for content related to that standard; if the mappings change, you know that you may have to change the way you implement that element of the standard.
• When (not if) changes to CMMI occur, you can look at the changes implied in your own processes, and also look to see whether those changes alter your mapping to other standards and proceed accordingly.
One critical principle is that your process users should not have to understand or use terminology related to all the different standards you’re working with. This is the responsibility of the staff working on improvement.
We don’t want to duplicate the material you can find in other good sources on this subject. If you will need to deal with multiple standards, take some time to check the current literature; we expect that the approach we describe is only one of many ideas you will see on this subject.