How does the Capability Maturity Model Integration CMMI improve the business processes in a IT company?

3.1.1 Capability Maturity Model Integration

The Capability Maturity Model Integration (CMMI) is a process improvement framework developed more than 20 years ago and governed by the Software Engineering Institute (SEI) at Carnegie Mellon University (USA). CMMI is sponsored by the U.S. government (especially the U.S. Department of Defense) and is in use by organizations of all sizes world-wide. It has helped to streamline costs, reduce rework and defect rates and improve timelines and quality [7].

CMMI by itself is a process improvement framework that has been developed to address a broad range of application environments. There are three different models based on the CMMI framework [7]:

CMMI for Development, a process model for process management and improvement in software development organizations

CMMI for Acquisition, a model for organizations that have to initiate and manage the acquisition of products and services

CMMI for Services, a process model for organizations to help them to deploy and manage services

By its nature, CMMI for Development is the right choice for process improvement in data warehouse development. It can be used to increase the efficiency of development processes for software products (such as a data warehouse), including processes for planning, management, and control of development activities [7]. The CMMI for Development standard provides best practices from successful development organizations and experiences from software quality experts [7]. The idea is to set organizations on a track of process improvement by enabling them to predict the outcome of their (defined and managed) processes. The prediction of process outputs (including the time-frame and quality of the product) results in a lower risk of exceeding budget, encountering quality problems and going over schedule [7].

It is possible to integrate CMMI with other frameworks and best practices, such as agile development, PMP and Six Sigma. That is because CMMI doesn’t define how the software development has to be done. Instead, it defines what must be done in order to improve development processes. Therefore, the CMMI framework supports agile principles by providing a reference framework for successful development environments [8]. It supports the integration of Six Sigma with the option of implementing CMMI process areas as Six Sigma (e.g., DMAIC) projects [9]. PMP is also supported due to an overlapping between Project Management’s Body of Knowledge (PMBOK’s) knowledge areas and CMMI process areas [7].

There are two different representations of CMMI: the continuous representation and the staged representation. These representations exist to provide organizations with different requirements and a unique set of tools for process improvement [10]. The staged model is focused on the overall organization and provides a road map as a series of stages (hence the name). These stages are called maturity levels and indicate the maturity of the organization regarding a set of process areas. While the organization is advancing on the maturity levels, it implements more and more practices from various process areas. As soon as the organization has satisfied the goals of all process areas in a maturity level, it can advance to the next level to further improve its processes [10]. The continuous model is different from the staged model as it provides less guidance on the order of the process areas that should be implemented and improved. Instead, the focus is on the individual process area and how it can be improved. Each process area is on its own capability level. The grouping of process areas is not followed in the continuous model [10].

The next sections present the capability and maturity levels of CMMI in more detail.

Origin

You are probably familiar with Capability Maturity Model Integration (CMMI) [7]. It is a maturity model of processes for system and software development. The successful usage of CMMI at Nedbank Limited (South Africa) brought up the idea of developing exactly the same model for business processes. This is how the BPMM emerged. With some intermediate stops, the maturity model was passed over to OMG that now assumes responsibility.

Watts Humphrey

Watts Humphrey laid the groundwork for maturity models. In the late 1980s, he developed the process maturity framework at Software Engineering Institute (SEI). This formed the basis for the Capability Maturity Model (CMM) for software in the mid-1990s and the successor CMMI in early 2000. Due to the common history, BPMM is similar to CMMI.

Maturity Levels

A total of five maturity levels exist in BPMM (Table 7.1). Maturity levels 2 through 5 define process groups. These process groups must meet the goals of the corresponding maturity level, in order to reach it. These are best practices that describe what needs to be done. However, they don't outline how this is achieved in practice. BPMM doesn't provide any methods.

Table 7.1. BPMM Maturity Level

Process Group

A maturity level is not a universal solution that addresses all business processes of an enterprise. Maturity level 2, for example, includes requirements and configuration management, and 7 further processes areas.

Compliance

Appraisal teams determine whether concrete business processes of an enterprise comply with a maturity level of BPMM. These teams consist of an external team leader and team members, some of them working for the enterprise appraised. The appraisers review process artifacts and interview process managers as well as persons that execute the process. There are four different types of appraisals:

Starter appraisal—The appraisal only takes a few days to obtain an overview as to what extent the business processes of an enterprise comply with BPMM. Quantitative data is determined.

Progress appraisal—All process areas of a maturity level are examined in detail to advance development towards a maturity level or anticipate results of a confirmatory appraisal. Quantitative data is determined and compared with the review's results.

Supplier appraisal—This appraisal is identical to the progress appraisal, except that no employees of the enterprise examined are members of the appraisal team.

Confirmatory appraisal—All stipulated practices of a maturity level are checked in detail and examined with regard to the requested process goals of the maturity level. An organization can advertise the maturity level if it passes this appraisal successfully.

How Does CMMI Contribute to the Methodology?

Carnegie Mellon's Capability Maturity Model Integration (CMMI) contains the foundations of management, measurement, and optimization. These components are applied to the methodology at the levels of key process areas (KPAs) and key performance indicators (KPIs). These pieces are necessary in order to understand and define what the business processes are and should be around the implementation and life cycle of the business intelligence build-out.

The business of building business intelligence solutions needs to mature. In order to accomplish these goals, the implementation team must first accept that a BI system is a software product. As such, software development life cycle (SDLC) components, along with best practices of managing, identifying, measuring, and optimizing must be applied—particularly if the team is to become and remain agile going forward. Fig. 6.4.2 demonstrates how CMMI levels map to Data Vault 2.0 methodology. It is not a complete map, just a representative portion of the entire piece.

The end goal of CMMI is optimization. Optimization cannot be achieved without metrics (quantitative measurements) or KPIs. These KPIs cannot be achieved without the KPAs or definitions of key areas to be measured, which of course cannot be achieved without first managing the project.

The road to agility is paved with metrics and well-defined/well-understood business processes. The Data Vault 2.0 methodology relies on the necessary components of CMMI in order to establish a solid foundation on which to build and automate enterprise business intelligence systems.

Taking a step back, here is a simplified definition of what CMMI cares about:

In CMMI, process management is the central theme. It represents learning and honesty as demonstrated through work according to a process. Process also enables transparency by communicating how work should be done. Such transparency is within the project, among projects, and being clear about expectations. Also, measurement is part of process and product management and provides the information needed to make decisions that guide product development. http://resources.sei.cmu.edu/asset_files/TechnicalNote/2008_004_001_14924.pdf

Page 17

CMMI brings consistency to the processes; it also brings manageability, documentation, and cost control. CMMI helps the people assigned to the project execute with a specific quality metric in mind. It also assists with the measurements of those metrics by identifying common processes that must happen in every business intelligence system.

CMMI provides the framework to operate within. Teams implementing Data Vault 2.0 methodology inherit the best parts of CMMI level 5 specifications and can successfully hit the ground running. Why? Because Data Vault 2.0 methodology provides the transparency, defines many of the KPAs and KPIs, and also enriches the project process by allocating template-based predefined deliverables, utilized during the implementation phases.

Transparency is implemented in the Data Vault 2.0 projects in different manners. The first recommendation for teams is to set up an in-company wiki, one that can reach any and all employees (including executives) in the firm. All meetings, all models, all templates, designs, metadata, and documentation should be recorded in the wiki.

The wiki should be updated at least once a day (if not more) by different members of the team. There will be more updates at the start or kickoff of new projects than at any other time during the life cycle. This should indicate a level of communication (which is stressed in agile/Scrum) with the business users.

The second component is the recording of business requirement meetings. All business requirement meeting “time” can be shortened, and the quality of the requirements increases when the meetings themselves are actually recorded utilizing an MP3 recorder. The audio files should be submitted to the wiki, so that team members (if out of the office) can retroactively attend or review when necessary.

This leads to a more agile business requirement meeting. Noise makers in these meetings tend to be quiet when it is recorded until or unless they have a significant contribution to make that would impact the outcome of the project goals. Please note that the rest of the explanation of how and why this works is beyond the scope of this book and is available in Data Vault 2.0 Boot Camp training classes and online at http://LearnDataVault.com.

A Business View

The methodology utilizes best practices from software development best practices such as CMMI, Six Sigma, TQM, Lean Initiatives, and cycle time reduction and applies these notions for repeatability, consistency, automation, and error reduction.

DV2 methodology focuses on rapid sprint cycles (iterations) with adaptations and optimizations for repeatable data warehousing tasks. The idea of DV2 methodology is to enable the team with agile data warehousing and business intelligence best practices. DV2 encompasses methodology as a pillar or key component to achieve the next level of maturity in the data warehousing platform.

Other methodologies are available for use; however, the DV2 methodology is uniquely geared to leverage the benefits of the DV2 model, process designs, and much more.

Service management

Organizations structuring their operations using service-based models such as ITIL or Capability Maturity Model Integration (CMMI) for Services describe and manage their business processes and operational capabilities in terms of the services they provide for internal and external customers. Many organizations believe that the customer-centricity of service-oriented management models is aligned more closely to quality management and process improvement objectives and facilitates effective governance by ensuring organizational resources are allocated appropriately to meet service delivery needs. Organizations can certify their IT service management capabilities using the ISO/IEC 20000 standard, which addresses the initial establishment of service management capabilities as well as service operations, maintenance, and improvement [30]. ISO/IEC 20000 certification can provide an independent evaluation of an organization’s implementation of an external service management framework such as ITIL or of the compliance (and presumed effectiveness) of internally developed capabilities. Certification based on the Software Engineering Institute’s CMMI for Services model appraises the relative maturity of a service provider’s processes and capabilities for delivering services to internal or external customers [31].

Abstract

Assurance of software quality has been supported by evolving testing practices and technologies surrounding it. Capability Maturity Model Integration (CMMI) on the other hand has prescribed processes and managerial practices for software development as a whole contributing to managerial practices with respect to quality assurance. However these practices do not provide guidance on engineering the software process (including all stages in software life cycle) so that people playing different roles in the process are aware of their contribution to software quality and assuring it through related activities and design. In this book chapter, we present an approach to engineer software process to assure software quality. Before we describe the approach, we present our notion of processes which forms basis for the approach.

A.6 CMMI®: Detailed ROI Estimation Procedures

Now, let’s examine the dynamics of estimating the costs, benefits, and ROI of CMMI® using the formulas for B/CR and ROI%.

Inspection costs for CMMI®: CMMI® may involve the use of inspections for CMMI® Level 3 compliance. So, let’s examine the cost of implementing inspections for CMMI® Level 3 compliance by our four trained inspectors. Let’s assume the project will develop 10,000 software source lines of code (SLOC), which is not unlikely for a web project in modern times. (Inspections of requirements, designs, and tests drive the Inspection costs even higher, but are omitted for simplicity’s sake.) At an Inspection rate of 240 SLOC per meeting, that comes to approximately 41.67 meetings. Since each Inspection run requires about 17 hours for planning, overviews, preparation, meetings, rework, and follow-up, we then multiply 41.67 by 17 for a total of 708.33 hours. Once again, at $100 per hour, that comes to $70,833 for our four trained inspectors to perform Inspections on 10,000 SLOC.

Process costs for CMMI®: Let’s begin by modeling the costs for developing the policies and procedures for CMMI® Levels 2 and 3. CMMI® Levels 2 and 3 require 416 policies and procedures at approximately 26.02 hours each. That comes to 10,826 hours for 416 CMMI® Level 2 and 3 policies and procedures. Multiply 10,826 by $100. The cost of developing CMMI® Level 2 and 3 policies and procedures is $1,082,600. However, let’s assume only half of this cost is for software engineering. Let’s adjust it accordingly to $541,300. Now let’s examine the cost of putting CMMI® Level 2 and 3 into practice for a single project. CMMI® Levels 2 and 3 require 429 work products at about 18.67 hours each. That comes to 8,008 hours for 429 CMMI® Level 2 and 3 work products for a single project. Multiply 8,008 by $100, and the cost of CMMI® Level 2 and 3 work products is $800,800 for a single project. However, let’s assume only half of this cost is for software engineering, and adjust it accordingly to $400,400. Add 5,413 hours for developing CMMI® policies and procedures to 4,004 hours for developing CMMI® Level 3-compliant documentation and this totals 9,417 hours or $941,700 (at $100 per hour).

Assessment preparation costs for CMMI®: Let’s estimate one project of eight people in 20 indoctrination courses at 2 hours each which totals 320 hours. Let’s similarly estimate one project of eight people in 20 response conditioning courses at 2 hours, each which also totals 320 hours. Finally, let’s estimate one project of eight people in one 40 hour mock assessment or two 20 hour mock assessments. This totals 320 hours. Now, let’s add 320 indoctrination hours, 320 response conditioning hours, and 320 mock assessment hours. This totals 960 hours. Finally, let’s multiply 960 by $100 for a total of $96,000 in assessment preparation costs. Half of this is software engineering, which amounts to $48,000.

Assessment costs for CMMI®: And, let’s not forget the assessment itself. For our one software project of four people, let’s estimate 127 hours for the plan and prepare for appraisal stage. Let’s estimate 204 hours for the conduct appraisal stage. And, let’s estimate 21 hours for the report results stage. This totals to 352 hours. Multiply 352 by $100 for an internal labor estimate of $35,200. Add an assessment fee of $12,500 for a total assessment cost of $47,700.

Costs for CMMI®: Finally, add $70,833 for Inspections, $941,700 for processes, $48,000 for appraisal preparation, and $47,700 for the appraisal itself. This comes to a grand total of $1,108,233 to achieve CMMI® Level 3 compliance and implement Inspections for 10,000 SLOC.

Benefits for CMMI®: The estimated total life cycle costs for 10,000 SLOC after our software engineers apply CMMI® Level 3-compliant policies and procedures are $1,486,933 (as illustrated from the benefit model in Table VII). The estimated total life cycle costs for 10,000 SLOC without CMMI® are $4,509,997 (as also shown in Table VII). So, our software engineers have saved $3,023,064 on their very first implementation of a CMMI®-compliant software project.

B/CR for CMMI® (the formula for B/CR is benefits divided by costs): Therefore, divide the $3,023,064 in CMMI® benefits by the $1,108,233 in CMMI® costs and the B/CR for CMMI® is 3:1.

ROI% for CMMI® (the formula for ROI% is benefits less costs divided by costs times 100): First subtract the $1,108,233 in CMMI® costs from the $3,023,064 in CMMI® benefits and divide the results by the $1,108,233 in SW-CMM® costs and multiply by 100 for an impressive ROI% of 173%.

1.2 Immediately After the Project Starts

(c) One has to know how to do strategic planning (e.g., CMMI, Capability Maturity Model Integration); homework #3 is related to the CMMI-based description of all related project issues, for the case that the afore-mentioned DataFlow proposal was accepted. (d) How to do a day-to-day planning of the DataFlow research based on the accepted proposal (e.g., Microsoft MS Project with a stress on agile planning); homework #4 is related to Microsoft MS Project-based description of specific core phases and insists on agile planning.

CMMI Versus Agility

Scrum agility development or DAD is still necessary to manage the individual sprint cycles or miniprojects that need to occur. CMMI manages the overall enterprise goals and provides a baseline consistency to the enterprise wide efforts so everyone in IT is on the same page (at least those involved with the BI project).

An agile implementation should be tailored to match an organization’s actual maturity level; however, implementing agile when an organization is at CMMI level three can result in less rework and improve the overall CMMI initiative while providing the significant benefits of agile. Implementing a CMMI compliant software development process that is also agile will bring the repeatability and predictability offered by CMMI. Agile, by design, is highly adaptable and therefore can be molded into a CMMI-compliant software development process without altering the primary objectives set forth by the Agile Manifesto.†

Please keep in mind that teams don’t wake up one day and just decide to be agile right there on the spot. It’s an evolutionary process; the team must undergo training both in agile and in Data Vault 2.0 Methodology to achieve the desired goals. Most teams that undertake training with Data Vault 2.0 start with seven-week sprint cycles (if they have had zero exposure to CMMI and agile previously).

Usually the second sprint cycle reduces seven weeks to six weeks. The third, if the team is working in earnest, measuring their productivity, and following the agile and Scrum review process, can see sprint cycles drop to about four weeks. From there, it simply improves to two weeks as the team gets better at it. Currently there is a team implementing Data Vault 2.0 Methodology and attempting to achieve one-week sprint cycles. There doesn’t seem to be a bottleneck to optimizing the processes.

But as a reminder, the optimization of these processes comes from CMMI in direct correlation to the KPAs and KPIs of building a data warehouse. It is tied as well to repeatable designs, pattern-based data integration, pattern-based models, and pattern-based BI build cycles. The value of Data Vault 2.0 Methodology is it provides the patterns out of the gate, to get the teams kick-started in the right direction.

Implementation Overview

The Data Vault system of business intelligence (BI) provides implementation guidelines, rules, and recommendations as standards. As noted in previous sections of this chapter, well-defined standards and patterns are the key to success of agile, Capability Maturity Model Integration (CMMI), Six Sigma, and total quality management (TQM) principles. These standards guide the implementation of:

The data model, finding business keys, designing entities, applying key structures

The ETL/ELT load processes

The real-time messaging feeds

Information mart delivery processes

Virtualization of the information mart

Automation best practices

Business rules – hard and soft

Write-back capabilities of managed self-service BI

Some of the objectives of managing implementation through working practices include meeting the needs of TQM, embracing master data, and assisting in alignment across business, source systems, and the enterprise data warehouse.

Before going any further, it is necessary to understand that the highest level of optimization can only be reached if the process, design, and implementation is pattern based and data driven.