What we are trying to avoid by using the PDCA discipline is the "Ready, Fire, Aim" fallacy where people jump to the solution without identifying the problem and assessing if their proposed solution fixes it, or even results in another problem. The Act step makes sure we don't have to fix it again in a couple of years. At a base level PDCA forms the theoretical underpinning for many process improvement methodologies.The four major steps in PDCA are: PLAN Identify the Problem Select problems to be analyzed and establish a precise problem statement Set measurable goals for the problem solving effort Establish a process for coordinating with and gaining approval from leadership Analyze the Problem Identify the processes that impact the problem and select one List the steps in the process as it currently exists Identify potential causes of the problem Collect and analyze data related to the problem Verify or revise the original problem statement Identify root causes of the problem DO Develop Solutions Establish criteria for selecting a solution Generate potential solutions that address the root causes of the problem Select a solution Plan the solution implementation Implement a Solution Implement the chosen solution on a trial or pilot basis CHECK Evaluate the results Gather data on the solution Analyze the data on the solution ACT Determine Next Steps If the desired goal was not achieved, repeat the PDCA process If the goal was achieved, identify systemic changes needed for full implementation Adopt the solution and monitor results Look for the next improvement opportunity

Deming Cycle

Rate of change, that is, rate of improvement, is a key competitive factor in today's world. PDSA allows for major 'jumps' in performance ('breakthroughs' often desired in a Western approach), as well as Kaizen (frequent small improvements associated with an Eastern approach). In the United States a PDSA approach is usually associated with a sizable project involving numerous people's time, and thus managers want to see large 'breakthrough' improvements to justify the effort expended. However, the Scientific Method and PDSA apply to all sorts of projects and improvement activities.

The power of Deming's concept lies in its apparent simplicity. The concept of feedback in the Scientific Method, in the abstract sense, is today firmly rooted in education. While apparently easy to understand, it is often difficult to accomplish on an on-going basis due to the intellectual difficulty of judging one's proposals (hypotheses) on the basis of measured results. Many people have an emotional fear of being shown "wrong," even by objective measurements. To avoid such comparisons, we may instead cite complacency, distractions, loss of focus, lack of commitment, re-assigned priorities, lack of resources, etc.

Deming CritiqueR Deming's 14 pointsR Watch Video of Deming's Impact on management

CMMI Background

The adaptation of the PDCA to a process maturity framework was the work of Watts Humphrey and his colleagues at IBM® in the early 1980s^R. Humphrey noticed that the quality of a software product was directly related to the quality of the process used to develop it. Having observed the success of total quality management in other parts of industry, Humphrey wanted to install a Shewart-Deming improvement cycle (Plan-Do-Check-Act - PDCA) into a software organization as a way to continually improve its development processes.

At the time of Humphrey's outline organizations had been installing advanced software technologies for a decade using methods akin to the PDCA cycle but without much success. Humphrey’s unique insight was that organizations had to eliminate implementation problems in a specific order if they were to create an environment that supported continuous improvement. Hence, Humphrey concluded that the Shewart-Deming cycle had to be installed in stages to systematically remove impediments to continuous improvement.

This staged structure underlying the maturity framework was further elaborated by Crosby in "Quality is Free". Crosby’s quality management maturity grid described five evolutionary stages in adopting quality practices in an organization. This framework was then adapted to the software process by Ron Radice and his colleagues working under the direction of Humphrey at IBM. Their model postulated that the adoption of any new practice by an organization would occur in five stages. The organization would...

• become aware of the new practice,
• then, learn more about it,
• then, try it in a pilot implementation,
• then, deploy it across the organization, and
• lastly, would achieve mastery in its use.

In Humphrey’s original maturity framework these stages would integrate principles from three domains in vogue at the time:

1. the targeted domain of processes,
2. total quality management practices, and
3. organizational change.

The movement through these stages can be represented graphically in Graphic 1 prepared by Suzanne Garcia for Carnegie-Melon:^R

Graphic 1: Maturity Levels - Evolving Improvement Paradigms: Capability Maturity Models

Regardless of the target of improvement, either an individual process or an entire organization, both continuous and staged perspectives of CMM Integrated reflect an evolution along two dimensions of interest that are notionally captured in the figure to the left. Using the staged model maturity level terms, it illustrates an evolution from the use of primarily qualitative data or opinion to much greater use of quantitative data, and a cyclic focus between process control and process improvement.

Graphic 2: Maturity Levels - Process at Different Stages

An organization can have process areas at different maturity levels. graphic 2 illustrates one way of viewing process (area)s at differing maturity levels. Each diamond notationally represents the amount of focus needed on a particular topic to achieve the kinds of improvement shifts highlighted in the quadrant illustrated previously. Nor do the characteristics of a process area imply identical maturity requirements. Some topics require a heavy focus early on, and either continue in that focus (see the diamond with an elongated middle portion) or require less focus to hang on to the improvements achieved (see diamonds with wide areas at the bottom and narrower areas at the top). Moreover. some topics have other processes as prerequisites for their improvement to be successful, and so their focus early on is much lighter (indicated by a space below the level at which focus becomes plausible). We might view each ITIL process area as one of these diamonds, or, if we wish, we can express a more granular approach, by selecting specific activities within ITIL best practice areas for review. The choice is up to the organization undertaking a service improvement initiative.

The movement towards the top, right quadrant (ie. continual improvement through quantitative analysis) is accompanied by a shift in the organization's cultural domain from reacting to events, to proactively managing events and finally to predicting events and removing their cause before it happens. In this migration the organization will exhibit the following characteristics:

Reactive Organizations

Complex distributed IT environments are typically the result of an evolutionary process. Simple management solutions target specific components of the overall IT enterprise and therefore most often involve point process and tool solutions in a narrow enclave of the IT environment. Repeating this framework throughout the IT organization results in a assemblage of processes and tools that are meshed together to provide service to particular business lines. This model is common to large distributed IT environments and its evolution closely parallels how distributed systems made their way into the IT enterprise in the first place. Over time, systems were released into the live infrastructure, supported by different teams and imbuing to different technology standards and IT directions.

Likewise, networks, systems, databases and applications migrated into the production business environment, with their own sets of standards, support and operational characteristics, and this further confounds the multiplicity of unintegrated components. In this state, when IT service is disrupted or degraded it is problematic to predict business impact. Instead, the IT organization can only react when a failure or deterioration in service occurs.

Proactive Organizations

The proactive organization takes steps to eliminate failures and outage before they occur. Proactive organizations will spend more time in analysis and invest in integrated tool sets to provide the necessary information. Proactive organizations are more likely to have a robust CMDB to provide robust information on the state of the infrastructure and to compile availability and capacity data in associated databases. They will have a technical architecture defining the management tools and technical integration points to enable efficient execution of an integrated process structure.

Reaching this state requires a focus on workforce practices. There are likely to be organizational changes that need to occur to align the people needed to execute the more robust processes. Also, their is a need for more integrated management tools such as data warehouses, analytical engines and simulation modeling.

In its initial implementation, the proactive organization will involve significant expenditure because of the size of the investments required and the time lag between collecting information and achieving a critical mass to make it useful. For example, the historical use of incident data to identify problems requires a dedicated effort in properly recording symptoms, actions and resolutions according to a coding scheme (such as Category, Type and Item) and over a sufficient time interval to identify patterns. The organization seeking to be more proactive will often be called upon to stay the course in the face of rising expenditures with little initial return on the investment. While this may seem to be a complex task, a methodology can be employed to provide a structured approach. This will typically be piloted in trial areas so that benefits can be identified and quantified for further roll-out.

Predictive Organizations

Predictive organizations acquire the capability to predict the occurrence of events within the infrastructure. The data warehouses provide the information necessary to utilize data mining techniques to undertake simulation modeling of the environment. These models discover interrelationships amongst events comprising the components of the infrastructure. Once known, automated systems can monitor the enterprise and either resolve faults before they impact business operations or provide alerts to that mitigating actions can be initiated.

Capability Maturity Models Today

The original formulation of the maturity framework adopted Crosby’s approach of evolving each process through these five stages. However, Humphrey realized organizations were not succeeding in long-term adoption of improved software development practices when they applied this maturity framework to individual practices or technologies. Humphrey identified serious impediments to long-term adoption that had to be eliminated if improved practices were to thrive in an organization. Since many of these problems were deeply ingrained in an organization’s culture, Humphrey realized that he had to formulate an approach that addressed the organization, not just its individual processes. The success of software CMM is demonstrated by the following finding of the Software Engineering Institute.

CMM Integrated (CMMI)

The aim of CMM Integrated, CMMI, was to provide guidance for improving an organization’s processes and an ability to manage the development, acquisition, and maintenance of products or services. CMMI places different approaches into a structure that assists an organization in assessing it's organizational maturity or process area capability, establish priorities for improvement, and implement these improvements.

The theoretical marriage involved in integrating the theory in different disciples led to the creation of two 'streams' or representations. The Continuous representation allows an organization greater flexibility in implementing CMMI methods. It suggests that an organization can select different orderings of improvement initiatives. These orders will uniquely reflect the needs of the organization.

The Staged representation requires that certain improvements must occur first as necessary conditions for subsequent improvements. This staged representation provides a sequence of improvements, beginning with basic management practices and progressing through a pre-defined and proven path of successive levels, each serving as a foundation for the next stage or maturity level.

The CMMI disciple with the greatest similarity to IT Service Management processes is Product and Process Development (IPPD). This area portrays systematic approach that seeks a collaboration of relevant stakeholders throughout the life of the product to better satisfy customer needs, expectations, and requirements. The staged representation organizes process areas into five maturity levels (with the same descriptors as for Software CMM) to support and guide process improvement. The staged representation groups process areas by maturity level, indicating which process areas to implement to achieve each maturity level. Maturity levels represent a process-improvement path illustrating improvement evolution for the entire organization pursuing process improvement. The CMMI model describes general and specific goals which must be achieved to successfully operate at a particular maturity level. The features common to the general functions are: the organization's commitment to perform - ie. management and staff alignment and focus on the goal and its' fulfillment the organization's ability to perform - the existence of particular tools and skill sets necessary to fulfill goals and objectives the organization's ability to direct and complete implementation on the basis of a plan verification of when the goal has been reached

The staged representation identifies the maturity levels through which an organization should evolve to establish a culture of excellence. Because each maturity level forms a necessary foundation on which to build the next level, trying to skip maturity levels is usually counter-productive However, it should be recognized that process improvement efforts should focus on the needs of the organization in the context of its business environment and that process areas at higher maturity levels may address the current needs of an organization or project. For example, organizations seeking to move from maturity level 1 to maturity level 2 are frequently told to establish a process group, which is addressed by the Organizational Process Focus process area that resides at maturity level 3. While a process group is not a necessary characteristic of a maturity level 2 organization, it can be a useful part of the organization’s approach to achieving maturity level 2.

Each maturity level in CMMI is characterized by defined processes.

People Capability Maturity Model (P-CMM) ^R

P-CMM place in establishing the necessary foundation for successfully implementing service improvement initiatives like ITIL or CobIT is evident in the following quotation from P-CMM.

The overall goal of P-CMM is embodied in the following excerpt.

Since an organization cannot implement all of the best workforce practices in an afternoon, the People CMM introduces them in stages. Each progressive level of the People CMM produces a unique transformation in the organization's culture by equipping it with more powerful practices for attracting, developing, organizing, motivating, and retaining its workforce. Thus, the People CMM establishes an integrated system of workforce practices that matures through increasing alignment with the organization's business objectives, performance, and changing needs.

Workforce capability can be defined as the level of knowledge, skills, and process abilities available for performing an organization's business activities. Workforce capability indicates an organization's:

• readiness for performing its critical business activities,
• likely results from performing these business activities, and
• potential for benefiting from investments in process improvement or advanced technology.

1. In mature organizations, workforce capability is directly related to business performance.
2. Workforce capability is a competitive issue and a source of strategic advantage.
3. Workforce capability must be defined in relation to the organization's strategic business objectives.
4. Knowledge-intense work shifts the focus from job elements to workforce competencies.
5. Capability can be measured and improved at multiple levels, including individuals, workgroups, workforce competencies, and the organization.
6. An organization should invest in improving the capability of those workforce competencies that are critical to its core competency as a business.
7. Operational management is responsible for the capability of the workforce.
8. The improvement of workforce capability can be pursued as a process composed from proven practices and procedures.
9. The organization is responsible for providing improvement opportunities, while individuals are responsible for taking advantage of them.
10. Since technologies and organizational forms evolve rapidly, organizations must continually evolve their workforce practices and develop new workforce competencies.

Like all Maturity models, each maturity level in P-CMMM has specific process requirements which must be adequately performed to achieve that maturity level.

Project Management Maturity Models

Organizational Project Management Maturity Model (OPM3) ^R

OPM3 provides a framework for advancing project management improvement within an organization. It is roughly based on the Software Engineering Institute's (SEI) Capability Maturity Model's (CMM®) five evolutionary maturity levels, and examines maturity development across nine knowledge areas in PMBOK ^R. OPM3 integrates standards for project and process management, the PMBOK Guide and CMM, respectively, to provide a plan for advancing organizational project management maturity.

Within OPM3, best practices are obtained by demonstrating mastery of a series of Capabilities that incrementally indicate the achievement of progressively higher levels of maturity. A Capability is demonstrated by the existence of corresponding Outcome(s) as demonstrated on the left. An Outcome is the tangible or intangible result of demonstrating or applying a Capability. Every Outcome should have a Key Performance Indicator (KPI), which represents the means to measure an Outcome. The OPM3 standard goes further by outlining the dependencies among the best practices. This complexity allows organizations trying to improve project management services to understand all of the Capabilities that may impact the achievement of a specific project management area. An OPM3 assessment element provides a means to navigate these components and compare an organization against industry averages according to the PMBOK Guide Process Groups N. This initial high-level assessment provides a macro look at an organization's organizational project management maturity. The identification of dependencies between the Capabilities, the use of multiple categorizations for both Best Practices and Capabilities, and the provision to conduct both high level and detailed assessments collectively provide organizations with flexibility in analyzing the results of their assessment and developing a detailed improvement plan.

Project Management Maturity Model (PMMM)

Consistent with an evolving recognition of maturity modeling the Office of Government Commerce in Great Britain introduced a government standard Project Management Maturity Model (PMMM), designed to measure project management maturity across the wider organization and the effectiveness of the project outputs and outcomes. Like, OPM3, it was based upon PMBOK..

PM Maturity Levels ^N

View PMMM vs 5.0 from CCTA OGC

Architecture Maturity Model ^R

The Department of Commerce IT Architecture Capability Maturity Model consists of six levels and nine architecture characteristics. The six levels are highlighted on the left. The nine IT Architecture Characteristics are: IT Architecture Process IT Architecture Development Business Linkage Senior Management Involvement Operating Unit Participation Architecture Communication IT Security Architecture Governance IT Investment and Acquisition Strategy

Architecture Characteristics	1 Initial	2 Under Development	3 Defined	4 Managed	5 Optimizing
Architecture Process	Exists in ad-hoc or localized form or early draft form may exist. Some IT Architecture processes are defined. There is no unified architecture process across technologies or business processes. Success depends on individual efforts.	Being actively developed. Basic IT Architecture Process program is documented based on OMB Circular A-130 and Department of Commerce IT Architecture Guidance. The architecture process has developed clear roles and responsibilities.	well defined and communicated to IT staff and business management with Operating Unit IT responsibilities. The process is largely followed.	IT Architecture process is part of the culture, with strong linkages to other core IT and business processes. Quality metrics associated with the architecture process are captured. These metrics include the cycle times necessary to generate IT Architecture revisions, technical environment stability, and time to implement a new or upgraded application or system.	optimize and continuously improve architecture process.
Architecture Development	IT Architecture processes, documentation and standards are established by a variety of ad hoc means and are localized or informal.	IT Vision, Principles, Business Linkages, Baseline, and Target Architecture are identified. Architecture standards exist, but not necessarily linked to Target Architecture. Technical Reference Model and Standards Profile framework established.	Gap Analysis and Migration Plan are completed. Architecture standards linked to Business Drivers via Best Practices, IT Principles and Target Architecture. Fully developed Technical Reference Model and Standards Profile. The architecture aligns with the DoC and Federal Enterprise Architectures.	documentation is updated on a regular cycle to reflect the updated IT Architecture. Business, Information, Application and Technical Architectures defined by appropriate de-jure and de-facto standards. The architecture continues alignment with the DoC and Federal Enterprise Architectures. An automated tool is used to improve the usability of the architecture.	Defined and documented IT Architecture metrics are used to drive continuous process improvements. A standards and waivers process is used to improve architecture development process improvements.
Business Linkage	Minimal, or implicit linkage to business strategies or business drivers.	Explicit linkage to business strategies.	integrated with capital planning and investment control and supports e-government. Explicit linkage to business drivers and information requirements.	Capital planning and investment control are adjusted based on the feedback received and lessons learned from updated IT Architecture. Periodic re-examination of business drivers.	Architecture process metrics are used to optimize and drive business linkages. Business involved in the continuous process improvements of IT Architecture.
Senior-Management Involvement	What is Architecture? Why do we need it? Limited management team awareness or involvement in the architecture process.	Management awareness of Architecture effort. Much nodding of heads. Occasional/ selective management team involvement in the architecture process with various degrees of commitment/ resistance.	Senior-management team aware of and supportive of the enterprise-wide architecture process. Management actively supports architectural standards.	Senior management reviews architecture and variances.	Senior-management team directly involved in the optimization of the enterprise-wide architecture development process and governance.
Operating Unit Participation	Limited Operating Unit acceptance of the IT Architecture process. We support the architecture process as long as it represents the standards we have already chosen. Standards will only inhibit our ability to deliver business value.	IT Architecture responsibilities are assigned and work is underway. There is a clear understanding of where the organization=s architecture is at present time. Recognition that it is painful supporting too many kinds of technologies. Perhaps tired of distributing Anot fully-developed or tested applications@ to Operating Unit IT operations and support.	Most elements of Operating Unit show acceptance of or are actively participate in the IT Architecture process. Recognition that architectural standards can reduce integration complexity and enhance overall ability to Operating Unit IT to achieve business goals.	The entire Operating Unit accepts and actively participates in the IT Architecture process.	Feedback on architecture process from all Operating Unit elements is used to drive architecture process improvements.
Architecture Communication	Little communication exists about the IT Architecture process and possible process improvements. The DoC IT Architecture Web Page contains the latest version of the Operating Unit=s IT Architecture documentation.	The Operating Unit Architecture Home Page, which can be accessed from the DoC IT Architecture Web Page is updated periodically and is used to document architecture deliverables. Few tools (e.g., office suite, graphics packages) are used to document architecture. Communication about architecture process via meetings, etc., may happen, but sporadic. May have been handed out to IT staff.	Architecture documents updated and expanded regularly on DoC IT Architecture Web Page. Tools are used to support maintaining architecture documentation. Periodic presentations to IT staff on Architecture content.	Architecture documents are updated regularly, and frequently reviewed for latest architecture developments/ standards. Regular presentations to IT staff on Architecture content. Organizational personnel understand the architecture and its uses.	Architecture documents are used by every decision maker in the organization for every IT-related business decision.
IT Security	considerations are ad hoc and localized.	IT Security Architecture has defined clear roles and responsibilities.	IT Security Architecture Standards Profile is fully developed and is integrated with IT Architecture.	Performance metrics associated with IT Security Architecture are captured.	Feedback from IT Security Architecture metrics are used to drive architecture process improvements.
Governance	No explicit governance of architectural standards. Limited agreement with governance structure.	Governance of a few architectural standards (e. g. desktops, database management systems) and some adherence to existing Standards Profile. Variances may go undetected in the design and implementation phases. Various degrees of understanding of the proposed governance structure.	Explicit documented governance of majority IT investments. Formal processes for managing variances. Senior management team is supportive of enterprise-wide architecture standards and subsequent required compliance.	Explicit governance of all IT investments. Formal processes for managing variances feed back into IT Architecture. Senior-management team takes ownership of enterprise-wide architecture standards and governance structure.	Explicit governance of all IT investments. A standards and waivers process is used to improve architecture development and governance - process improvements.
IT Investment and Acquisition Strategy	strategic planning and acquisition personnel in enterprise architecture process. Little or no adherence to existing Standards Profile.	Little or no formal governance of IT Investment and Acquisition Strategy. Operating Unit demonstrates some adherence to existing Standards Profile.	IT acquisition strategy exists and includes compliance measures to IT Enterprise Architecture. Operating Unit adheres to existing Standards Profile. RFQ, RFI and RFP content is influenced by the IT Architecture. Acquisition personnel are actively involved in IT Architecture governance structure. Cost-benefits are considered in identifying projects.	All planned IT acquisitions are guided and governed by the IT Architecture. RFI and RFP evaluations are integrated into the IT Architecture planning activities.	Operating Unit has no unplanned IT investment or acquisition activity.

IT Service Capability ^R

Termed the Kwintes project, it led to efforts to describe the maturity of IT service providers. A group of experts on IT service management and on the Software CMM developed a first sketch of the IT Service CMM and a detailed specification of the level two key process areas. In September 2000, a follow-up project was started, aimed at further specifying level three of the IT Service CMM.

The IT Service CMM is a maturity growth model, consisting of five maturity levels. Each maturity level describes a stage in the maturity of an IT service provider:

1. Organizations at level one are characterized by working in an ad hoc manner and by unpredictable performance. If IT services are delivered successfully, it is because of individual heroism.
2. Organizations at level two, the repeatable level, deliver services with a repeatable quality. That is, they can repeat earlier successful performances in similar circumstances.
3. The Defined level, is aimed at standardization of services. Organizations at level three employ standard processes to deliver standard services and have implemented organization-wide processes to train employees and manage resources and problems.
4. The Managed level, is aimed at attaining quantitative control over the IT service processes.
5. The optimizing level, is aimed at continuous process improvement.

Key Practices

IT Service Management Processes By Maturity level

ITIL Implementation

ITIL doesn't totally ignore the constraint of organizational maturity. Appendix C of the Implementing ITIL Booklets presents simplistic variant on the maturity model. The stated purpose is to assist in devising a readiness assessment for the introduction of ITIL processes. The approach measures the IT organization's influence and alignment with business goals and objectives against six elements: Vision and Strategy Steering Processes People Technology Culture The organization's maturity level is determined by the IT organization's primary focus which migrates as it matures through the following stages: Technology focused Product/Services focused Customer focused Business focused Value-chain focused

The following grid compares these elements against the primary foci:

Stage	Vision and strategy	Steering	Processes	People	Technology	Culture
Technology	Business views role of IT as Infrastructure provider of hardware, software and network provider). No clear vision statement on role of IT.	Principally driven by cost. Stability, availability and performance of IT platforms and networks are the main focus and implicit steering parameters.	Focus on Systems and Network Management, IT design and implementation	Technology excellence.	Systems and Network Management tools are independently purchased and used to manage technology subsets.	'We are IT experts'. There is little interaction or understanding of providing 'services' to the business
Product/Service	The IT Organization recognizes that it delivers a portfolio of products and services to the business. Evidence of IT strategic planning, little input from business.	Services are defined in technology terms such as bandwidth, processing performance, disc capacity. Reporting and steering on IT defined parameters.	Strong focus on ITIL Service Support processes and the more operational aspects of the ITIL Service Delivery processes, such as performance measurement and tuning, availability measurement and building resilience. Reporting mechanisms are used to improve product and service performance.	Clearer definition of IT functions. Recognition of first and second-line expertise.	More product standardization. Design of architectures and integration into management tools and systems.	Team and product orientation. Customer awareness and promotion towards Customers.
Customer Focus	IT seen as IT service provider IT strategy linked to business strategy.	Service Level Agreements steer IT. Change Management integrated into project structure for ensuring smooth hand over from new IT development.	Service Level Management, formalized Account Management. More focus on planning aspects in delivery processes. Support processes deliver clear service and Customer related performance. Process reporting under pins service level agreements.	Service Management training and defined activities and roles. Evidence of process ownership, Formalized Account Management and Service Management roles in place.	Integrated systems and Service Management platforms, manageability built into technology designs and solutions. Operational requirements defined for hand-over into production environment	Customer satisfaction.
Business Focus	IT is seen as a partner to the business. IT demonstrates strategy realization for the business. IT strategy input to business strategy making process	IT strategic goals, IT proposals made and discussed at board level. Business priority and risk assessments of investing and not investing in IT. Service levels are defined more in business terms, such as 'business transactions processed', 'availability of business functionality'	Business and IT-alignment processes. Strong Integration between Systems development and IT Service Management processes. Processes deliver 'dashboard steering information'. Service delivery and support processes integrated. Delivery processes deliver sound planning and advice to the business.	Business intelligence and business competencies. CIO role and CTO role. Equal roles in business and IT.	R and D and technology pilots. An enterprise-wide management framework exists defining integrated service and systems management tool sets.	The IT Organization provides help and advice to the business.
Value chain	IT is seen as business enabler. IT helps shape and drive business Change and is seen as a value-added partner that helps determine business strategy.	IT is steered on added value to the business. Business improvements through use of IT.	Business and IT strategy making. The IT Organization ensures seamless integration with systems development and all other IT suppliers in the value chain to manage real end-to-end services for the business.	Strategy making, business planning, managing partners and suppliers. Infrastructure Integrators.	Technology interaction between suppliers. Solutions integration.	The IT Organization enables the business.

CCTA CMM

In 1997, the CCTA reacted to this need and introduced a five-level process maturity model, based on similar models that had been developed for software production units, e.g. the Software Engineering Institute’s Capability Maturity Model (CMM) and ISO’s Software Process Improvement and Capability determination (SPICE). This was revised to include intermediate stages with the result being a nine stage ITIL implementation measure. The CCTA developed a series of questions for each stage. The total score in any ITIL area would determine the organization's maturity with regard to that process.

This treatment acknowledges maturity as a key concept but by modifying the definitions at each level abandons much of the CMM maturity framework at each of those levels. CMM Integrated describes a key set of activities at each of those levels. These activities are replaced in this treatment with another broad (though related) set of descriptors deemed more reflective of processes such as ITIL.

This does, of course, follow directly from the intent of this scale which is to devise a set of questions which permits the assignment of a scale reflective of the maturity of that process area in order for the consulting firm to recommend and implement improvements. Once must, however, be careful in interpreting the scales...

• while the devised questions will reflect concerns at each of the levels the importance (ie. weighting) attached to each area will differ according to the area. Therefore, comparing a score in one ITIL process with another process area may be misleading
• the treatment fails to acknowledge that different processes as described in the ITIL manuals require more mature organizations than other processes.
• there is little debate on the validity and reliability of the assessments since the results will be considered the proprietary property of the client and administering consulting firm

IT Governance Maturity Framework (COBIT)

The COBIT scale is based upon the Software Institute CMM scale. Each maturity has a general description which is subsequently adapted for meaning with each of the 34 governance process areas. The Maturity Models are built up starting from the generic qualitative model to which practices and principles from each of the following domains are added in increasing manner through the levels: Understanding and awareness of risks and control issues Training and communication applied on the issues Process and practices that are implemented Techniques and automation to make processes more effective and efficient Degree of compliance to internal policy, laws and regulations Type and extent of expertise employed.

The following table describes this increasing application of practices over the levels for the different topics. COBIT suggest that together with the qualitative model, it constitutes a generic maturity model applicable to most IT processes.

Level	Initial	Repeatable	Defined	Managed	Optimized
Understanding & Awareness	Recognition	Awareness	Understanding of need to act	Understand full requirements	Advanced, forward-looking understanding
Training & Communications	Sporadic communication on issues	Communication on the overall issue and needs	Informal training supports individual initiatives	Formal training supports a managed program	Training and communications support external best practices and use leading edge concepts
Processes & Practices	Ad hoc approach to process and practice	Similar/common, but intuitive process emerges	Practices are defined, standardized and documented; sharing of better practices begins	Process ownership and responsibilities are set; process is sound and complete; internal best practices are applied	Best external practices are applied
Techniques & Automation		Common tools are appearing	Tool set is standardized; currently available practices are used and enforced	Mature techniques are used; standard tools are enforced; limited tactical use of technology	Sophisticated techniques are deployed; extensive optimized use of technology
Compliance		Inconsistent monitoring on isolated issues	Inconsistent monitoring; measurement emerges; balanced score card adopted occasionally; root cause analysis is intuitive	Balanced scorecards are used in some areas; exceptions are noted; root cause analysis is standardized	Balanced scorecard is globally applied; exceptions are consistently noted and acted upon; root cause analysis is always applied
Expertise			Involvement of IT specialists in business processes	Involvement of all internal domain experts	Use of external experts and industry leaders for guidance

CobIT Maturity Descriptions

CobIT Process Area	Maturity Level					Description
	1	2	3	4	5
PLANNING AND ORGANIZATION
Strategic Planning
Architectural Planning
Technology Direction
IT Organization and Relationships
IT Investment Management
Communicate Mgmt Aims & Directions
Manage HR
Ensure Compliance w. External Requirements
Assess Risks
Manage Projects
Quality Management
ACQUISITION AND IMPLEMENTATION
Solutions Development
App SW Acquisition & Maintenance
Tech. Acquisition & Maintenance
Tech. Procedures Documentation
Implementation & Accreditation
Change Management
DELIVERY AND SUPPORT
Service Level Management
External Provider Management
Performance/Capacity Management
Service Continuity Management
Security Access Management
Cost Accounting
User Education and Training
Service Desk
Configuration Management
Incident/Problem Management
Data Management
Facilities Management
Operations Management
MONITORING
Process Monitoring
Controls Assessment
Assurance Reviews
IT Audit

Executive Maturity

The achievement of higher levels of maturity must be preceded by an increasing involvement and participation of management. As sponsors of the movement they cannot simply "start the ball rolling" and hope that the momentum will be maintained. Instead, support must be continuous and include:

• a project plan which demonstrates continuing benefits from the effort in order to sustain momentum and provide them with evidence to their senior management peers.
• continuing and sustained championing reflected in identified ownership of the initiative as well as individual processes
• continued financial support and the provision of highly qualified and trained project teams

Sustaining Gains

Commitment to Perform

Commitment to Perform describes the actions the organization must take to ensure that the activities constituting a process area are established and will endure. Commitment to Perform typically involves establishing organizational policies, executive management sponsorship, and organization-wide roles to support practices to develop workforce capability.

Level 2 Sub-Processes
• Establish and maintain an organizational policy for planning and performing the process.

Ability to Perform

Ability to Perform describes the preconditions that must exist in the unit or organization to implement practices competently. Ability to Perform typically involves resources, organizational structures, and preparation to perform the practices of the process area.

Level 2 Sub-Processes
• Establish and maintain the plan for performing the process.
• Provide adequate resources for performing the process, developing the work products, and providing the services of the process.
• Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process.
• Train the people performing or supporting the process as needed.

  Level 3 Sub-Processes

• Establish and maintain the description of a defined process.

Measurement and Analysis

Measurement and Analysis describes measures of the practices and analysis of these measurements. Measurement and Analysis typically includes examples of measurements that could be taken to determine the status and effectiveness with which the Practices Performed have been implemented.

Level 2 Sub-Processes
• Place designated work products of the process under appropriate levels of configuration management.
• Identify and involve the relevant stakeholders as planned.
• Monitor and control the process against the plan for performing the process and take appropriate corrective action.

Verifying Implementation

Verifying Implementation describes the steps to ensure that the activities are performed in compliance with the policies and procedures that have been established. Verification typically encompasses objective reviews and audits by executive management and other responsible individuals.

Level 2 Sub-Processes
• Establish and maintain an organizational policy for planning and performing the process.

  Level 3 Sub-Processes

• Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization’s processes and process assets.

Reference Models

Best Practices