Frameworks for IT Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net
7 CMMI Capability Maturity Model Integration CMMI-DEV, V1.2; (Capability Maturity Model Integration for DEVelopment) is a process improvement maturity model for the development of products and services. It consists of best practices that address development and maintenance activities that cover the product lifecycle from conception through delivery and maintenance. Owner of the copyright: Distribution: Origin/history: When: Founding fathers/who participated in developing the framework? Certification bodies? The Software Engineering Institute (SEI) is a federally funded research and development center sponsored by the US Department of Defense. Copyright 2006 by Carnegie Mellon University. Worldwide. The CMMI is the successor of CMM, which was developed from 1987 until 1997. It was created by members of industry, government and the SEI. In 2002 version 1.1 was released: v1.2 followed in August 2006, containing three portions: Development, Services and Acquisition. These last two are still being developed. The program manager for the version 1.2 release was Mike Phillips. He coordinated the efforts of the following teams: model team SCAMPI upgrade team training team architecture team hardware team piloting team quality team No formal certification body, however SEI has developed the Standard CMMI Appraisal Method for Process Improvement (SCAMPI). This is a method which uses the CMMI as a baseline to identify the strengths and weaknesses of software and/or systems processes of an organization or agency. The method relies on a discipline and strict rules which assure the exhaustiveness and objectivity of an evaluation. It is characterized largely by consensus (the evaluation is conducted by a team) and by the implication of the entity in its own evaluation. 69
Frameworks for IT No certificate is issued to the company or agency assessed. In order to support its claims of being categorized at a specific maturity level, the organization has to show, as needed, the results of the SCAMPI as reported. By Kobi Vider 7.1 Origin/history The first Capability Maturity Model for software (CMM-SW) was originally published by SEI in 1987 as a framework for understanding and improving software development practices, under the sponsorship of the Department of Defense (DoD) of the United States government. The CMM framework was predicated on the assumption that improved process capabilities would lead to better results from software development projects. Its primary purpose was to be a tool for supplier assessment: to assist organizations acquiring software in identifying those organizations with sufficient quality and reliable processes. Since then, a number of related maturity models have been developed and established, each with different criteria and frameworks. To align and provide a common means of describing maturity, these models have been integrated into the CMMI version 1.1. The CMMI embraces different disciplines: Software (SW); System (SE); Integrated Product and Process Development (IPPD) and Supplier Sourcing (SS), in the current version is 1.2. This integrates all disciplines into one model that reflects all four disciplines in its content. Figure 7.1 outlines the milestones in the history of the CMMI Framework. 1987 1991 1993 1995 1997 2000 2002 2006 First CMM Published Model Refined and Published as SW-CMM v 1.0 SW-CMM v 1.1 Published CMMI Initiative Launched CMMI-SE/SW Version 1.0 Published CMMI-SE/SW/PPD/A Version 1.1 Published CMMI-DEV Version 1.2 Published Software Acquisition (SA-CMM), Systems Engineering (SE-CMM), Integrated Product Development (IPD-CMM), Organizational Workforce Capability Development (People CMM) Developed CMMI for Services and CMMI for Acquisition being developed. Figure 7.1 History of the CMMI CMMs focus on improving processes concerning product (software and systems) planning, developing, quality control and implementation in an organization. They contain the essential elements of effective processes for one or more disciplines and describe an evolutionary 70
CMMI Capability Maturity Model Integration improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness. Although these models have proven useful to many organizations in different industries, the use of multiple models has been problematic. Many organizations would like their improvement efforts to span different groups in their organizations. However, the differences among the disciplinespecific models used by each group, including their architecture, content, and approach, have limited these organizations capabilities to broaden their improvements successfully. Further, applying multiple models that are not integrated within and across an organization is costly in terms of training, appraisals, and improvement activities. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework. The CMMI Product Team s initial mission was to combine three source models: the Capability Maturity Model for Software (SW-CMM) v2.0 draft C [SEI 1997b] the Systems Engineering Capability Model (SECMM) [EIA 1998] the Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98 [SEI 1997a] The combination of these models into a single improvement framework was intended for use by organizations in their pursuit of enterprise-wide process improvement. Recently, the CMMI model architecture was improved to support multiple disciplines and the sharing of best practices among disciplines and their member models. Work has begun on two new disciplines: one for services (CMMI for Services) and the other for acquisition (CMMI for Acquisition). This work was created in the performance of Federal Government Contract Number FA8721-05- C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute (SEI), a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use (part of) the work 1. The SEI is a federally funded research and development center sponsored by the US Department of Defense. 7.2 Where is CMMI used? The Software Engineering Institute s CMMI has been in use since 1987. It is now used in 46 countries, by organizations with as few as a dozen software engineers and in giant corporations with thousands of employees. Evidence collected from successive appraisals demonstrates that the CMMI has been successful in helping the software community to improve process maturity and reduce the risk of failed projects. 1 Copyright license under the clause at 252.227-7013. 71
Frameworks for IT Many industries, including aerospace, banking, computer hardware, software, defense, automobile manufacturing, and telecommunications, use CMMI for Development (Figure 7.2). Unknown (No Data Provided) 6.7% Offshore (SIC Code Not Applicable) 50.0% Business Services 6.7% Public Administration (Including Defense) 16.7% Instruments And Related Products 3.3% Transportation Equipment 6.7% Health Services 3.3% Engineering & Services 6.7% Figure 7.2 SEI Process Maturity Profile (March 2006; SEI) With business functions increasingly relying on software-intensive systems, the impetus to improve the success rate of IT projects has never been greater. Most people working with such systems will find at least a summary knowledge of CMMI s goals, structure, uses and benefits valuable. Models in the CMMI for Development contain best practices that cover project management, process management, engineering that is including systems, hardware and software, and for supporting processes used in development. The CMMI for Development also covers the use of integrated teams for development and maintenance activities. CMMI Process Project Engineering Support Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment Project Planning Project Monitoring and Control Supplier Agreement Mgmt. Integrated Project Mgmt. Risk Quantitative Project Mgmt. Requirements Requirements Development Technical Solution Product Integration Verification Validation Configuration Mgmt. Process and Product Quality Assurance Measurement & Analysis Decision Analysis and Resolution Causal Analysis and Resolution Figure 7.3 CMMI V1.2 Orientation overview 72
CMMI Capability Maturity Model Integration 7.3 Description and core graphics 7.3.1 Background A model is a simplified representation of the organization s processes and internal standards. Capability Maturity Models (CMMs) contain the essential elements of effective processes for one or more bodies of knowledge. These elements are based on the concepts developed by Crosby, Deming, Juran, and Humphrey (Crosby 79, Juran 88, Deming 86, Humphrey 89). Like other CMMs, Capability Maturity Model Integration (CMMI) models provide guidance to use when developing processes. CMMI models are not processes or process descriptions. The actual processes used in an organization depend on many factors, including application domain(s) and organization structure and size. In particular, the process areas of a CMMI model typically do not map one to one with the processes used in an individual organization. A process is a leverage point for an organization s sustained improvement. The purpose of CMM Integration is to provide guidance for improving an organization s processes and its ability to manage the development, acquisition, and maintenance of products or services. CMM Integration places proven approaches into a structure that helps an organization appraise its organizational maturity or process area capability, establish priorities for improvement, and implement these improvements. An organization can use a CMMI model to help set process-improvement objectives and priorities, improve processes, and provide guidance for ensuring stable, capable, and mature processes. A selected CMMI model can serve as a guide for improvement of organizational processes 7.3.2 CMMI representations The basic building blocks in every CMMI model are called process areas. A process area does not describe how an effective process is executed (for example entrance and exit criteria, roles of participants, resources). Instead, a process area describes the practices and goals of effective processes. In a Capability Maturity Model, process areas can be organized into one of two representations, a continuous representation or a staged representation. Table 7.1 gives an overview of the differences between the Continuous and Staged representation. Whether used for process improvement or appraisals, both representations are designed to offer essentially equivalent results. Table 7.2 compares the six capability levels (continuous representation) to the five maturity levels (staged representation). The only difference is in the starting points. The staged representation does not have a maturity level 0, so this starts at level 1, maturity level Initial, whereas the capability level is Performed. From level 2 on, all capability and maturity levels have similar names. 73
Frameworks for IT Continuous Representation The organization selects process areas and capability levels based on its process improvement objectives. Improvement is measured using capability levels. Capability levels: Measure maturity of a particular process across an organization. Range from 0 through 5. Capability level profiles are used to target and track process improvement performance. Equivalent staging allows an organization using the continuous approach to process improvement to derive a maturity level as part of an appraisal. Staged Representation The organization selects process areas based on the maturity levels. Improvement is measured using maturity levels. Maturity levels: Measure maturity of a set of processes across an organization. Range from 1 through 5. Maturity levels are used to target and track process improvement performance. There is no need for an equivalence mechanism back to the continuous approach. Table 7.1 Comparing Continuous and Staged Representations (source: SEI) Level Continuous Representation Capability Levels Staged Representation Maturity Levels Level 0 Incomplete Not applicable Level 1 Performed Initial Level 2 Managed Managed Level 3 Defined Defined Level 4 Quantitatively Managed Quantitatively Managed Level 5 Optimizing Optimizing Table 7.2 Comparison of Capability and Maturity levels (source: SEI) This is because the continuous representation concerns selecting both a particular process area to improve and the desired capability level for that process area. In this context, whether a process is performed or incomplete is important. Therefore, the name incomplete is given to the continuous representation starting point. As the staged representation is concerned with the overall maturity of the organization, whether individual processes are performed or incomplete is not the primary focus. Therefore, the name initial is given to the staged representation starting point. Representations: Continuous or Staged? There are many valid reasons to select one representation or the other. An organization will usually choose to use the representation it is most familiar with. The following lists describe some of the possible advantages and disadvantages to selecting each of the two representations. Continuous representation If continuous representation is chosen for the organization, the model will do the following: allows selection of the order of improvement that best meets the organization s business objectives and reduce the organization s risks enables comparisons across and among organizations on a process area by process area basis or by comparing results through the use of equivalent staging 74
CMMI Capability Maturity Model Integration CMMI Staged Level 2 Managed Level 3 Defined Level 4 Quantitatively Managed Level 5 Optimizing CMMI Continuous Process Organizational Process Focus Organizational Training Organizational Process Definition and IPPD Organizational Process Performance Organizational Innovation and Deployment Engineering Requirements Requirements Development Product Integration Technical Solution Validation Verification Support Configuration Measurement and Analysis Process and Product Quality Assurance Decision Analysis and Resolution Casual Analysis and Resolution Project Project Planning Project Monitoring and Control Supplier Agreement Risk Integrated Project and IPPD Quantitative Process Figure 7.4 CMMI overview affords an easy comparison of process improvement to International Organization for Standardization and International Electrotechnical Commission (ISO/IEC) 15504, because the organization of process areas is similar to ISO/IEC 15504 Staged representation If the staged representation is chosen for the organization, the model will do the following: provides a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next permits comparisons across and among organizations by the use of maturity levels provides a single rating that summarizes appraisal results and allows comparisons among organizations Staged Continuous ML5 ML4 ML3 ML2 ML1 Organization Figure 7.5 SEI; CMMI Overview Staged vs. Continuous Capability 0 1 2 3 4 5 PA PA PA Process Area (PA) 75
Frameworks for IT 7.3.3 Model components / terminological conventions used in CMMI Capability levels A capability level consists of a generic goal and its related generic practices as they relate to a process area, which can improve the organization s processes associated with that process area: Capability Level 0: Incomplete process - a process that either is not performed or partially performed. One or more of the specific goals of the process area are not satisfied, and no generic goals exist for this level since there is no reason to institutionalize a partially performed process. Capability Level 1: Performed process - satisfies the specific goals of the process area. It supports and enables the work needed to produce work products. Capability Level 2: Managed process - a performed (capability level 1) process that has the basic infrastructure in place to support the process. It is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. The process discipline reflected by capability level 2 helps to ensure that existing practices are retained during times of stress. Capability Level 3: Defined process - a managed (capability level 2) process that is tailored from the organization s set of standard processes according to the organization s tailoring guidelines, and contributes work products, measures, and other process improvement information to the organizational process assets. Capability Level 4: Quantitatively Managed process - a defined (capability level 3) process that is controlled using statistical and other quantitative techniques. Quantitative objectives for quality and process performance are established and used as criteria in managing the process. Quality and process performance is understood in statistical terms and is managed throughout the life of the process. Capability Level 5: Optimizing process - a quantitatively managed (capability level 4) process that is improved based on an understanding of the common causes of variation inherent in the process. The focus of an optimizing process is on continually improving the range of process performance through both incremental and innovative improvements. Maturity levels A maturity level is a defined evolutionary set of process improvement. Each maturity level stabilizes an important part of the organization s capabilities to plan, perform and execute successful projects. The CMMI staged representation model defines five maturity levels, each a layer in the base for the next phase in the ongoing process improvement, designated by the numbers 1 through 5. Maturity Level 1: Initial - processes are ad hoc and chaotic. The organization does not provide a stable environment to support the processes. Success depends on the competence and heroics of the people in the organization and not on the use of proven processes. In spite of this chaos, maturity level 1 organizations often produce products and services that work; however, they frequently exceed their budgets and do not meet their schedules. Maturity Level 2: Managed - the projects of the organization have ensured that processes are planned and executed in accordance with policy; the projects employ skilled people who have 76
CMMI Capability Maturity Model Integration adequate resources to produce controlled outputs; involve relevant stakeholders; are monitored, controlled, and reviewed; and are evaluated for adherence to their process descriptions. Maturity Level 3: Defined - processes are well characterized and understood, and are described in standards, procedures, tools, and methods. The organization s set of standard processes, which is the basis for maturity level 3, is established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by tailoring the organization s set of standard processes according to tailoring guidelines. Maturity Level 4: Quantitatively Managed - the organization and projects establish quantitative objectives for quality and process performance and use them as criteria in managing processes. Quantitative objectives are based on the needs of the customer, end users, organization, and process implementers. Quality and process performance is understood in statistical terms and is managed throughout the life of the processes. Maturity Level 5: Optimizing - focuses on continually improving process performance through incremental and innovative process and technological improvements. Quantitative process improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process improvement objectives. Both the defined processes and the organization s set of standard processes are targets of measurable improvement activities. Process areas A process area is a cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area. Specific goals Specific goals apply to a process area and address the unique characteristics that describe what must be implemented to satisfy the process area. They are required model components and are used in appraisals to help determine whether a process area is satisfied. Specific practices A specific practice is an activity that is considered important in achieving the associated specific goal. The specific practices describe the activities expected to result in achievement of the specific goals of a process area. Generic goals Generic goals are called generic because the same goal statement appears in multiple process areas. Achievement of a generic goal in a process area signifies improved control in planning and implementing the processes associated with that process area, thus indicating whether these processes are likely to be effective, repeatable and lasting. Generic practices Generic practices provide institutionalization to ensure that the processes associated with the process area will be effective, repeatable and lasting. Generic practices are categorized by generic goals. 77
Frameworks for IT Subpractices Subpractices are detailed descriptions that provide guidance for interpreting specific or generic practices. Typical work products Typical work products are an informative model component that provides example outputs from a specific or generic practice. Generic practice elaborations The elaboration provides information about how the generic practice should be interpreted for the process area. Discipline amplifications Model components that provide guidance for interpreting model information for specific disciplines (for example IPPD, systems engineering, or software engineering). 7.3.4 SCAMPI appraisal programs The SCAMPI method is used for appraising organizations using CMMI, and one result of an appraisal is a rating. If the continuous representation is used for an appraisal, the rating is a capability level profile. If the staged representation is used for an appraisal, the rating is a maturity level (for example maturity level 3) rating. Equivalent staging is a way to compare results from using the continuous representation to those of the staged representation. A capability level profile is a list of process areas and the corresponding capability level achieved for each. This profile enables an organization to track its capability level by process area. 7.4 Approach/how to 7.4.1 CMMI implementation budget Treating the transition to CMMI like any other existing project in the organization will help ensure its successful completion. For example, the owner and major stakeholder of the CMMI transition project should develop a budget to support transition activities. While each budget is different, the following guidelines may be helpful: Plan on funding the experienced change agent full time. Experience shows that successful change agents can have only one agenda; in this case, helping the organization to make the transition to CMMI. Focus on one organization at a time and fund the Process Action Team (PAT) members at least 50 per cent of their time. For economics, keep the PAT membership small and of limited duration. Track expenditures and results of the PAT. Be prepared to adjust the funding or scope of activities if there are issues. 78
CMMI Capability Maturity Model Integration Include proper CMMI training for the change agent and the PAT. Budget for at least one week each of the introductory and intermediate CMMI courses. Once trained, the PAT can be used to cross-train the organization and other organizations. Investing in sending at least one member of the PAT to CMMI transition workshops is also beneficial. 7.4.2 CMMI implementation schedule A key part of managing the CMMI transition project is setting the schedule. The schedule of activities varies depending on the starting point in the organization s process improvement journey. While each starting point is different, consider the following guidelines: Making the transition to CMMI is like implementing other cultural changes in an organization; the further the starting point on the journey, the longer the trip will take. Based on SEI measurements on implementing the CMM for Software, organizations with little existing infrastructures or experience with process improvement projects typically require 18 to 24 months to reach maturity level 2 to reach maturity level 3 typically requires an additional 12 months. Organizations at higher maturity or capability levels in software and systems engineering will probably require one year, depending upon the current measurement programs and the number of new processes that need to be developed and rolled out. Typically, new processes take at least six months to be rolled out in an organization. 7.5 Relevance to IT management For the organizations that have IT as a competitive asset, CMMI is useful as the increasing complexity of systems and development processes require a high level of maturity. In short, CMMI is useful for IT organizations as: increasing demand for complex software systems; the market requires efficiency; organizations face complex development processes. Nowadays, IT professionals need more than their technical skills as engineering, project management, testing, process and methodology skills become increasingly important. IT professionals need to be able to quickly implement new skills, work with higher maturity processes and have best practices ingrained into daily work. 79
Frameworks for IT 7.6 Strengths and weaknesses 7.6.1 Strengths The model provides a large amount of background and guidance information based on industry best practice which can be very valuable, if used correctly. Hierarchy of process areas promotes an evolutionary approach to improvement which is more effective and sustainable. Separation of process areas allows for more focused and manageable process improvement efforts. Limitation of scope allows for a greater level of detail and guidance for project related processes. CMMI goals and generic practices are described in such a way as to be applicable to a wide range of organizations and projects. The CMMI contains a large amount of interpretive guidance for organizations and projects focused on large scale development. CMMI provides Maturity levels (staged) and Capability levels (continuous) as a means for setting and evaluating progress towards process improvement targets. CMMI has a strong focus on measurement which assists with determining the return on investment for process improvement activities. 7.6.2 Weaknesses With all CMM models the risk exists that they are being used as a checklist only, having the products in place, but not using them. The size of the model can result in information overload for readers, leading to either 'paralysis' or 'blind practice implementation'. The large number of separate process areas makes it difficult to identify and understand relationships clearly. In some cases organizations develop process architectures which reflect these process areas rather than business operations. The level of detail in the model may be interpreted as promoting development of complex, detailed processes in cases where simple ones are sufficient. There is limited support for non-project related business functions. Specific practices and interpretive guidance tends to be worded to apply to large scale development, and limited guidance is provided to interpret this for small enhancement or non-development projects. Implications of targets is not always understood which can lead to the CMMI becoming an end in itself and not a means to drive improvements. Timeframes for achievement of CMMI targets may be inconsistent with short-term business cycles. 7.7 Cross-references/relationships In recent years an increasing number of papers has been published about organizations successful integration of CMMI and other methods such as Six Sigma. These organizations have found the most efficient way to leverage process and quality is to coordinate and to use one leading framework (CMMI) and domain specific method (such as PMBOK), to overcome the perception 80
CMMI Capability Maturity Model Integration that the initiatives are competitors or mutually exclusive alternatives A partial list of methods that can be coordinated with CMMI is shown in the table below and in the references. General Quality Basics ISO PMBoK PRINCE2 Advanced OPM3 PMMM Six Sigma PSM Engineering RUP SWEBOK T-CMM SSE-CMM Agile IT SCRUM XP ITIL Manufacturing KAIZEN LEAN Table 7.3 Cross-references for CMMI 7.8 Links and literature 7.8.1 Books on CMMI Ahern, D. M., A. Clouse, & R. Turner (2003, 2 nd edition). CMMI Distilled: A Practical Introduction to Integrated Process Improvement. London: Addison Wesley. Ahern, D. M., J. Armstrong, A. Clouse, J. R. Ferguson, W. Hayes, & K. E. Nidiffer (2005). CMMI SCAMPI Distilled Appraisals for Process Improvement. London: Addison Wesley Professional. Bush, M., & D. Dunaway (2005). CMMI Assessments: Motivating Positive Change. London: Addison Wesley Professional. Crosby, P. B. (1979). Quality is Free. New York: McGraw-Hill. Deming, W. E. (1986). Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering Study. Humphrey, W.S. (1989). Managing the Software Process. London: Addison Wesley. Juran, J. (1988). Juran on Planning for Quality. New York: The Free Press. Kulpa, M. K., & K. A. Johnson (2003). Interpreting the CMMI: A Process Improvement Approach. London: Auerbach Publications. West, M. (2004). Real Process Improvement Using the CMMI. London: Auerbach Publications. 7.8.2 Links on CMMI www.sei.cmu.edu/cmmi - Capability Maturity Model Integration (CMMI). www.sei.cmu.edu/cmmi/appraisals - CMMI Appraisals. www.sei.cmu.edu/cmmi/results.html - CMMI Performance Results. https://bscw.sei.cmu.edu/pub/bscw.cgi/d426144/itil%20comparison - CMMI and ITIL Comparison. 81
Frameworks for IT www.clei.cl/cleiej/papers/v9i1p7.pdf - Implementing CMMI using a Combination of Agile Methods. www.sei.cmu.edu/pub/documents/05.reports/pdf/05tn005.pdf - Relationships Between CMMI and Six Sigma. www.dtic.mil/ndia/2002cmmi/solomon2b1.pdf - Using CMMI to Improve Earned Value. www.sei.cmu.edu/activities/cmmi/results/pdfs/04-303d.pdf - Quality for IT development and IT service operations. http://en.wikipedia.org/wiki/cmmi - Wikipedia on CMMI. 82
Colophon Title: A publication of: Editors: Publisher: Frameworks for IT itsmf-nl Jan van Bon (chief editor) Tieneke Verheijen (editor) Van Haren Publishing, Zaltbommel, www.vanharen.net ISBN(10): 90 77212 90 6 ISBN(13): 978 90 77212 90 5 Edition: First edition, first impression, September 2006 First edition, second impression, November 2006 Design and Layout: Printer: CO2 Premedia, Amersfoort - NL Wilco, Amersfoort -NL For any further enquiries about Van Haren Publishing, please send an e-mail to: info@vanharen.net The International itsmf organization, through its International Publications Executive Subcommittee (IPESC), comprised of a council of members from global itsmf chapters has given its formal itsmf International endorsement to this book. itsmf-nl 2006 All rights reserved. No part of this publication may be reproduced in any form by print, photo print, microfilm or any other means without written permission by the publisher. Although this publication has been composed with much care, neither author, nor editor, nor publisher can accept any liability for damage caused by possible errors and/or incompleteness in this publication. TRADEMARK NOTICES PRINCE2, M_O_R and ITIL are Registered Trade Marks and Registered Community Trade Marks of the Office of Government Commerce, and are Registered in the U.S. Patent and Trademark Office. COBIT is a registered trademark of the Information Systems Audit and Control Association (ISACA)/IT Governance Institute (ITGI). The PMBoK is a registered trademark of the Project Institute (PMI). etom is a registered trademark of the Tele Forum. Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net IV