Rationale for the CMMI for Services

Transcription

1 Rationale for the CMMI for Services Eileen Forrester, CMMI-SVC Team Additional writing by Hal Wilson; additional research by Craig Hollenbach, Brandon Buteau, and Drew Allison. Introduction CMMI for Services (CMMI-SVC) is a CMMI constellation that covers the activities required to manage, establish, and deliver services. The project has been undertaken at the request of the CMMI user community to answer a clear problem and demand. The CMMI-SVC work is only accomplished with the excellent work of volunteers from many organizations, which reflects their commitment and ensures that they get a model that meets their needs. With the approval of the CMMI Steering Group, and endorsement from the NDIA Systems Engineering Division, a team began work on the CMMI-SVC in August The CMMI for Services team is led by Northrop Grumman, and includes participants from the Boeing, DNV, Lockheed Martin, Mitre, SAIC, SEI, SRA, and the Systems and Software Consortium (SSCI). The SEI is supporting the team during the development cycle and will maintain the CMMI-SVC product suite upon release. This document summarizes the rationale for the development of the CMMI for Services and the status of the project to date. Background Capability maturity models are developed to codify sets of effective practices that will lead to improvements in quality, cost, and schedule for both the providers and purchasers of goods and services. The Software CMM was developed to capture effective practices for developing software. At the time of its writing, no comparable model existed to guide the producers and acquirers of software-intensive systems. The developers of the Software CMM relied on participating practitioners to agree on a set of practices to manage and improve the process for developing software. When the CMMI was developed, more models, standards, and other references were available to draw upon. With Version V1.2 of the CMMI, the steward and Steering Group of the CMMI product suite have set an architecture that allows for CMMI constellations. A constellation has the 16 process areas that comprise the CMMI model framework (CMF). Constellation development teams then add material unique to the area of interest (or material shared amongst some but not all the constellations). The first three constellations called for by the CMMI steward and Steering Groups are for development, acquisition, and services. Constellations are developed when a sponsoring organization makes a proposal to the CMMI Steering Group and is granted the authority to proceed.

2 Summary of the Need for CMMI-SVC Currently, some service organizations apply CMMI V1.1 or CMMI-DEV V1.2 to service delivery, but this requires significant interpretation by both the organizations and their appraisers. CMMI-SVC will improve consistency and payoff and provide fuller coverage for process areas necessary to services that are not covered by the current CMMI model. Services comprise 80% of the world economy and more than half of what the DoD acquires more than it spends on weapon systems. In addition, 70 universities have established curricula in services. Even traditional manufacturers of hard goods, such as Caterpillar, increasingly are redefining what they do as service, in part because of the importance of remanufacturing and shaping their product lines to the needs of specific customers, often in the government. Yet the only full and readily available frameworks specifically designed for services are those written for IT services, such as ITIL and ISO These are good frameworks, but they only address IT services. They also do not provide a clear improvement path to increasing capability. Other frameworks such as AS9100 and TL9000 are particular to specific services or industries, and some are proprietary. We referred to these and other frameworks (such as COBIT and IT Service CMM) as we developed the CMMI-SVC, but tried to broaden the practices to allow for a wide range of services. We intend that the CMMI-SVC will be compatible with and complementary to proven frameworks such as ITIL, which provide additional how-to guidance for IT that the CMMI does not. In addition, the current community of CMMI users wanted to prevent or end the misappropriation of appraisal results from development contexts to service contracts. Instead, CMMI users want service delivery organizations to have the same opportunities for improvement and reliable benchmarking that the CMMI brings to product development. What is the requirement or problem to be solved with the CMMI-SVC? The CMMI-SVC will provide the basis for measurable improvement in maintenance, operation, logistics, IT, and other services for DoD, other government, and industry. The model must be a consistent benchmark for process improvement for service providers that is appropriate to the work they do and based on proven approaches (such as CMMI-DEV, ITIL, ISO20K, IT Service CMM, and COBIT). While not required, it would also be helpful to have a model that works well with other improvement frameworks and tools of interest to the DoD, such as Lean Six Sigma. Currently, the DoD, other government, and industry providers do not have a model specific to the improvement of services such as operations and sustainment, yet the majority of life-cycle costs reside in these phases. Further, IT organizations are cobbling together their own ITIL and CMMI solution, reinventing the wheel over and over. And that wheel is irrelevant to services other than IT. Service providers are requested by their customers to demonstrate a CMMI rating or capability profile. Interpretations of the CMMI-DEV for service contexts exist but are insufficient. While they are admirable make-do solutions, they represent neither CMMI results nor service needs entirely. The very fact that at least four published interpretations exist illustrates that applications

3 of CMMI for service are urgently needed and that none are adequate. They also serve a useful interim step toward more correct content for service delivery. One of the drivers that brought volunteers to the table to help develop the CMMI-SVC was the misuse of CMMI-DEV appraisals and appraisal results in service contexts. Attempts to use the CMMI-DEV distort the integrity of appraisal results when they are misapplied or misappropriated. To the credit of the volunteer organizations, they want a credible improvement model suitable to service delivery and compatible with CMMI, and they resist the market incentives to claim coverage of their service efforts by use of development appraisal results. Are there known benefits from process improvement applied to services? Data from DoD repair depots (see, for example, Pauling 2006) provide insight into potential benefits. Pauling reports 50% improvement in reliability of the top 10 LRUs from use of continuous process improvement, $1.8 million in annual repair savings, $10.7million in annual procurement savings, and $427.6million seven-year present value savings to repair. ITIL practitioners claim cost savings, reduction in downtime ROI, performance and quality improvements, and competitive edge from improving process. The IT Process Institute (Behr, Kim, and Spafford, 2005) has data on measureable improvements in operations and security by focusing on release, resolution, relationship, and service delivery processes. Lean six sigma practitioners claim service improvement results in diverse settings. Lean Six Sigma for Service (George, 2003) records improvements in speed, cost, and quality by improving service processes at Lockheed Martin, Bank One, Stanford University Hospital, and the city of Fort Wayne. Among many results, Bank One reports cycle time improvements from 30-75%. The city of Fort Wayne decreased the average road repair time from 20 to 9 hours. Stanford hospital decreased ICU hours of care per patient day from 29.6 to 19; they saved $25M annual material costs, $2.6M in cardiac surgery costs, $4.4M in cardiology costs, and cardiac bypass graft surgery costs of $2400 per case. Expected ROI for service adopters should be similar to that seen for CMMI-DEV. How are services different? A service is an intangible, non-storable product. Services are delivered by the operation of a service system. A service system is an integrated and interdependent combination of processes, resources, and people that satisfies service requirements. Unlike the systems developed using CMMI-DEV, portions of the service system may not be delivered to the customer or end user. The service system encompasses everything required for service delivery, including work products, processes, infrastructure, consumables, and customer resources. Services rely on customer and supplier relationships that are governed by service agreements. Service delivery means the provider interacts with the customer or end user throughout the performance of the agreement. Service levels are also contractually specified and measured according to agreement.

4 Delivery of services has a different business rhythm than development. The service may have a clear beginning and then be ongoing, with an end only coming when provider and customer agree to end the delivery of the service. Service delivery may be continuous or episodic. Development projects have a clear beginning and end. Services are often variable and repetitive. Once the agreement is established, service requests are used to prompt an instance of the service. Because of the variability and repetition caused by the rhythm of service delivery, capacity, availability, continuity, and incidents must be actively monitored and managed to ensure customer satisfaction. What distinguishes CMMI-DEV from CMMI-SVC? Some users of CMMI-DEV who deliver services as well as develop goods have made the most they can of DEV to improve service delivery. However, even good-faith use of CMMI-DEV for services can have unintended adverse consequences, leading to improper claims that are a disservice to DoD and other acquirers, and prevent service providers from having the improvement path that would benefit all. CMMI-DEV has some content that is not service friendly and is missing content needed to manage service delivery. Using CMMI-DEV for services requires very liberal interpretations of development PAs. Some engineering PAs are not applicable to many services. CMMI-DEV also has language and informative material that is not suitable to service delivery. Further, CMMI-DEV does not address the end-to-end management of the service life cycle; instead, the life cycle for development ends at the delivery to the customer. CMMI-DEV has no practices for deployment and operation. The repetitive delivery over time and variation in requests and customers is not addressed by CMMI-DEV. Most important, CMMI-DEV does not have specific service-delivery best practices with benefits such as reduction in service failures and unplanned non-availability, effective and efficient resolution of service incidents, reduction in cost, increase in the consistency and quality of service, and achievement of agreed continuity. What distinguishes CMMI-SVC from other service models? No other models focus on the service management practices applicable to the full set of DoD and industry service needs. Some of the best known and readily available models, such as COBIT, ITIL, ITSCMM, and ISO20000 cover a limited scope, usually only IT services. Some of these, such as ITIL, are much more prescriptive and lack an improvement path (however, these characteristics make CMMI and ITIL good complements for IT use). Other models are either proprietary or limited in scope and application, such BPM, AS9100, and TL9000. Other models are missing positive elements common to all CMMI models. CMMI-SVC makes use of the CMMI model foundation; in fact, 77% of the DEV and SVC is currently shared, and this overlap may increase during revision. CMMI models have common vocabulary, training, appraisal methods, governance, and infrastructure supporting authorization, certification, and quality control. While a few models have a broad base of support at least in some parts of the world (such as ITIL), none has the large user base of educated, process-savvy practitioners using CMMI.

5 In addition, many other service models are best used for one service type only, such as IT service or operations in telecom, or business process in finance. Can a broad spectrum of services be governed by a single model? In the same way that CMMI-DEV is used to develop a broad range of product and system types and CMMI-ACQ is used to acquire all kinds of goods, CMMI-SVC is meant to manage the delivery of a broad range of services. Given that other service models use a tighter scope, the CMMI-SVC team gave additional care and attention to this issue. It was crucial to the developers that CMMI-SVC cover a range of services. Team members represent experience in more than 75 service types (see appendix), covering all categories of the federal procurement data system. The team conducted a DAR study early in the project to explore the benefit to various types of services and chose top-priority services to use as touchstones and test cases during model development. These included operations, maintenance, logistics, and IT. Based on team experience, variation in services is seen most strongly in the do it or execution part of service delivery (the Service Delivery PA). After the model is fully developed, the team recommends that development of specific guides be encouraged to provide additional help for users of CMMI-SVC using particular service types. The team members conducted pilots and desk studies in their own organizations, and found the model content applicable to all services they examined, such as HR, research, and IT. Before the SG issued a stop work order, the team had selected pilots that include book shelving, IT services, IV&V, and financial operations. DAR criteria to select these pilots were weighted toward non-it and small businesses. Some of these began and one completed with positive results. In initial conversations with the intended pilots, no organization identified material in CMMI-SVC not applicable to them, except some common CMMI terminology (such as project ). In the strong response to the team request for review (hundreds of organizations producing in excess of 900 change requests), virtually none of these suggested that CMMI-SVC could not govern their service. The single exception: a couple of IT service providers commented in CRs that ITIL would continue to suffice for many of their needs. The CRs did not call for the elimination of any of the model content, but most often for reorganization of some PAs and additional examples from other services. This response suggests that reviewers from 50 companies of varying size, 14 DoD organizations, 4 academic institutions, and 7 other professional, government, or research centers did not have substantive concerns about applicability of CMMI-SVC to their service types. Planned pilots, site visits, and interviews can be used to continue to examine this question. In addition to the official pilots that the CMMI-SVC team will oversee, team members hear from a range of users who are already applying the draft model released for comment. Early users conducting their own pilots include industry and government organizations performing research, maintaining aircraft, and delivering educational guidance.

6 What is the experience of pilots so far? Only one of the planned four external team pilots completed before the SG asked the team to stop work. However, the team has preliminary results from this pilot and team internal pilots. Most of the piloting organizations had implemented CMMI-DEV. Some had separate ITIL and ISO20000 initiatives. Most are moving toward integration under a CMMI umbrella. The pilots represented the following service domains: IT application operations and support, banking, logistics, applications O&M, HR, and IT. The pilots saw these benefits: Improved quality of services Encouragement of disciplined culture for service management, including better management visibility into services, fewer surprises, and fostering of process improvement Less interpretation needed and lower appraisal expense than with CMMI-DEV Applying a CMMI process to the services brought credibility and buy in from stakeholders Increased sharing between development and services communities, including common processes, standard terminology, and integrated process improvement standards and models End-to-end life cycle process approach identifies service requirements, eases deployment issues, reduces stove-piped groups, and improves efficiencies of support-related groups for IT applications The pilots saw these challenges: Obtaining funding in environments that are primarily based on LOE Differences in terminology between development and services, such as project vs funding period, product vs service, and product component Interpreting the project term for services Need for standard life cycle definitions for services Instilling project management culture in services Ownership of service system components Need more help for release management and deployment to non-standard, constantly changing environments Finding CMMI-knowledgeable individuals who also know services Integrating process groups and assets Services where customer and provider share resources and processes Staff augmentation

7 Model Content The review draft CMMI-SVC constellation has 22 required process areas and 3 process areas that are independent named additions. The PAs are grouped into three categories familiar to users of CMMI-DEV (process management, project management, and support) plus a fourth new category: establishment and delivery of services. CMMI has 8 new service PAs; we have also added a goal to one engineering PA (REQM). IRM is at maturity level 2, and all the others are maturity level 3. The PAs are summarized below. Capacity and Availability Management (CAM) is about managing current and future capacity based on demand. Its purpose is to plan and monitor resources to support service requirements. Incident and Request Management (IRM) ensures the timely resolution of requests for service and incidents that occur during delivery; both of these, if not resolved, can cause the service provider to break its service commitments. Organizational Service Management (OSM) ensures the satisfaction of customers by establishing and maintaining standard services and analyzing customer satisfaction data. Problem Management (PRM) prevents incidents from recurring by identifying and addressing underlying causes; it is similar in some respects to CAR, but does not require the optimized statistical process control implied by CAR. Requirements Management (REQM) has been extended to include the establishment and maintenance of written agreements on service requirements and levels between service providers and customers. Service Continuity (SCON) is meant to establish and maintain contingency plans for continuity of services during and following any significant disruption of normal operations. Service Delivery (SD) encompasses activities to deliver services in accordance with service agreements (this includes operating, managing, and maintaining existing service systems). Service System Development (SSD) has as its purpose to analyze, design, develop, integrate, and test service systems to satisfy existing or anticipated service agreements. A service system is an integrated and interdependent combination of components, consumables, and people that satisfies service requirements. Organizations may use either CMMI-DEV or this PA for service system development. Service Transition (ST) covers activities to deploy new or significantly changed service systems while managing their effect on ongoing service delivery. For further detail on the model content, see the CMMI for Services Architecture Overview, by CMMI-SVC architect Brandon Buteau, or the full model. Both are available at the URL below.

8 Current Status At the November 2007 meeting of the CMMI Steering Group, the SG confirmed that services content will be included in the CMMI product suite. The CMMI-SVC development team has begun work again, and will begin resolving CRs identified in the expert review. Summary of Rationale for CMMI for Services This section was written by Hal Wilson. CMMI-SVC is a desirable and necessary addition to the CMMI Framework for the following reasons: The CMMI-SVC focuses on bringing discipline and repeatability to services delivery, two of the capabilities that differentiate the most successful service delivery organizations. There is worldwide emphasis on improvement of services and a business need to link specialized attempts to address services into the CMMI Framework. CMMI-SVC is intended to complement the detailed practices of ITIL and ITS CMM rather than compete with them, providing additional value to organizations that have begun adoption of ITIL and other services practice tools. The CMMI-SVC has a broad base of industry support, especially among NDIA members. To date, development of the he CMMI-SVC has been funded entirely by industry with no OSD or government contribution. Notwithstanding comments to the contrary, there is more stated support for CMMI-SVC within the DoD Services and other government agencies than there was initially for CMMI- DEV at this stage of its development. Because there is nearly 80% commonality with the CMMI-DEV, adoption of CMMI-SVC provides a significant advantage (up to 5 to 1) to organizations that have already adopted the CMMI for Development or Acquisition. Adoption of CMMI-SVC first likewise provides the same advantage to organizations when adopting CMMI-DEV or CMMI-ACQ. More Information The following Web page provides more information on this project: The draft that went out for comment is there, along with presentations, FAQs, and notices. To get more information or to be added to the alias for news about CMMI-SVC, send to customer-relations@sei.cmu.edu

9 Appendix: Service Background represented by CMMI- SVC team members Services in which CMMI-SVC team members report individual and organizational experience: administrative (HR, financial) application O&M appraisal against standards (CMMI, ISO, ITIL, TL9000, medical devices) asset monitoring and tracking authorization (of appraiser, certifiers, instructors) bill review and processing business analysis and transformation business modeling business process management certification (of management system, climate change, corporate responsibility, food safety, product, professional standard, security, training) classified data management communication: writing, editing, design, publication configuration management construction (ship and plane) consulting (change management, facilitation, HR development, process improvement, BPR, compliance to standards) content management continuity planning credit services data management (access, browsing, connectivity, metadata construction, rights, storage) disaster recovery engineering entertainment (gaming, music, and theatre) estimation event management experimental design facilities management fleet support image management and processing information management (enterprise, business intelligence, customer)

10 installation (hardware, software, network, equipment) IV&V IT knowledge management laboratory legal services logistics maintenance (aircraft, IT, documentation, software, electronic equipment, ships, military equipment, phone, cable, satellite systems) management marketing measurement merger and acquisition integration modeling and simulation monitoring and control (asset, data, process, auditable controls) operations (network centers, IT, customer service, help centers, maintenance, rocket control, test ranges, satellite systems) process engineering procurement support procure-to-pay and requisition-to-receipt production (equipment, entertainment, printing, design, multimedia, software) profitability determination program management support prototyping publishing (documentation, magazines, web pages) real estate services refugee services research research and development risk assessment (security, enterprise, business, systems and software, safety, health, environment, assets) sales and business development science and technology planning service-oriented architecture design service social services security management

11 SETA studies and analysis strategic planning subcontractor management supply chain management systems acquisitions management services technology assessment and planning technology innovation management testing training transition assessment and planning transportation Markets or industry sectors in which team members report individual and organizational service experience: aerospace automotive defense education energy entertainment finance gaming and lottery government health care hotel and lodging legal manufacturing maritime nuclear offshore and process industries retail space and satellite telecom

12 DoD is the federal organization mentioned most often as client for these services, but other US government organizations include these: various agencies in the intelligence community (NRO, NSA, etc.) Department of Homeland Security (DHS) US Coast Guard Federal Emergency Management Administration (FEMA) USVISIT Customs and Border Protection Federal Bureau of Investigation (FBI) Secret Service Centers for Medicaid/Medicare Services (CMS) Bureau of the Census Nuclear Regulatory Commission (NRC) Department of the Interior (DoI) Forest Service Bureau of Land Management (BLM) Park Service General Accountability Office (GAO) General Services Administration (GSA) Department of Education Department of Agriculture Department of State US Agency for International Development (USAID) Internal Revenue Service (IRS) Veterans Affairs (VA) Social Security Administration (SSA)