Drew Allison

An IT Services Scenario Applying CMMI® for Services The Story of How HeRus Improved Its IT Services

 

 

Abstract		Contents
This report describes how a fictional information technology (IT) service organization called Heros Are Us (HeRus) applied the CMMI® for Services (CMMI-SVC) to improve their service performance, reduce cost, and increase customer satisfaction. By reading the report, the purpose of each of the seven Service Process Areas (PAs) in the CMMI-SVC will become clearer. In addition to addressing the Service PAs, the report describes how HeRus used Configuration Management (CM) and Measurement and Analysis (MA) to support their implementation of the Service PAs. Mappings between the scenario text and some goals in the CMMI-SVC are provided to help the reader make the connection between the scenarios and the model and to increase the reader’s depth of knowledge about CMMI-SVC.	An IT Services Scenario Applying CMMI for Services About the CMMI for Services Introduction to the HeRus Scenario Strategic Service Management (STSM) Service Delivery (SD) Capacity and AvailabilityManagement (CAM) Measurement and Analysis (MA) Service Continuity (SCON) Incident Resolution andPrevention (IRP) Service System Development (SSD) Service System Transition (SST) Configuration Management (CM) Conclusion References

 

Systems and Software Consortium, Inc. (SSCI) intellectual property is used with the permission of SSCI

The authors are interested in any comments you have in the area of service management, especially concerning the following topics:

• What benefits have been realized by your organization from implementing the CMI-SVC and/or other service management frameworks?
• What have the greatest challenges been in implementing the CMMI-SVC and/or other service management frameworks?
• What lessons learned from implementing the CMMI-SVC and/or other service management frameworks stand out?

Please send your response to these questions and any other comments to drewallison@sysdevco.com, referencing the title of this paper in the subject line.

The CMMI^® for Services (CMMI-SVC) is the newest CMMI released by the Software Engineering Institute (SEI). It is intended to improve the quality and performance of service processes and result in higher customer satisfaction and cost savings. Although services are more than 80% of the world economy, there have been few process improvement frameworks addressing service work. Service management frameworks such as Infrastructure Technology Information Library (ITIL) and ISO 20000 are focused on information technology (IT) services only. In contrast, the CMMI-SVC can be used for a variety of services, including health, education, transportation, and IT. It is also distinguished from other models by the clear improvement path it offers as well as a standard appraisal method that provides either Maturity Level (ML) ratings or capability profiles to indicate where on the improvement path an organization sits. The service community can benefit from a proven model of practice designed for them, as an alternative to using the CMM^®I for Development (CMMI-DEV).

Approximately 77% of the material in the CMMI-DEV is shared with the CMMI-SVC, which provides the opportunity to reuse many processes developed for the CMMI-DEV or maintain common processes for both service work and development work. In addition to the following areas of practice shared with CMMI-DEV, there are additional areas of practice that replace the engineering practices in the CMMI-DEV.

 

• Planning service work
• Monitoring and controlling service work
• Managing suppliers
• Supporting service management
• Managing processes and service improvement
• Training

The engineering practices are replaced in the CMMI-SVC with practices for service establishment, delivery, and management, such as

• Establishing service agreements
• Handling service requests and incidents
• Preventing incidents through analysis and resolution of underlying causes
• Managing capacity and availability
• Planning for service continuity
• Establishing strategic service plans
• Establishing service catalogues

The CMMI-SVC uses the same structure and model elements as CMMI-DEV, including PAs, PA Categories, Specific Goals (SGs), Generic Goals (GGs), Levels, Continuous Representation, and Staged Representation. Just as in the CMMI-DEV, there are two types of best practices in a PA:

• Specific Practices (SPs) are unique to the PA and are organized by an SG.
• Generic Practices (GPs) are the same in all PAs and are organized by GGs.

GPs provide institutionalization of SPs in increments toward higher maturity and capability. Institutionalization is an important concept in process improvement and means “the ingrained way of doing business that an organization follows routinely as part of its corporate culture” [CMMI Product Team 2009]. It is important that best practices become an ingrained way of doing business and that they are retained in times of stress and despite personnel turnover. The same set of GPs is found in all PAs. The institutionalization provided by the GPs is a great strength of the CMMI-SVC.

The same GGs and GPs are present in the CMMI-SVC, with some elaborations added for services. All GPs are present in the CMMI-SVC:

• GP 2.1 Establish an Organizational Policy
• GP 2.2 Plan the Process
• GP 2.3 Provide Resources
• GP 2.4 Assign Responsibility
• GP 2.5 Train People
• GP 2.6 Manage Configurations
• GP 2.7 Identify and Involve Relevant Stakeholders
• GP 2.8 Monitor and Control the Process
• GP 2.9 Objectively Evaluate Adherence
• GP 2.10 Review Status with Higher Level Management
• GP 3.1 Establish a Defined Process
• GP 3.2 Collect Improvement Information
• GP 4.1 Establish Quantitative Objectives for the Process
• GP 4.2 Stabilize Subprocess Performance
• GP 5.1 Ensure Continuous Process Improvement
• GP 5.2 Correct Root Causes of Problems

 

The CMMI-SVC has 24 PAs and 4 PA Categories. The core PAs reused by the CMMI-SVC are in the Process Management, Support, and Project Management PA Categories. The Engineering PA Category does not exist in the CMMI-SVC. It is replaced with the Service Establishment and Delivery PA Category, which contains the bulk of new CMMI-SVC PAs. It is shown in bold in Table 1 and contains 5 of the 7 new Service PAs with the other 2 in the Project Management PA Category.

 

The only PA retained from the Engineering PA Category is Requirements Management (REQM), and it is placed in the Project Management PA Category in the CMMI-SVC. Service System Development (SSD) in the Service Establishment and Delivery PA Category is not required to achieve ML 3. Table 1 shows all 24 PAs of the CMMI-SVC organized by ML and by PA Category. The 7 Service PAs are bolded, and the SSD PA has an asterisk (*) to indicate that it is optional.

 

Table 1 . CMMI-SVC 24 PAs

 

 

 

This report describes how a fictional IT service organization called Heros Are Us (HeRus) applied the CMMI-SVC to improve their service performance, reduce cost, and increase customer satisfaction. By reading the report, the purpose of each of the seven Service PAs in the CMMI-SVC model will become clearer. In addition to addressing the Service PAs, the report describes how HeRus used CM and MA to support their implementation of the Service PAs. Mappings between the scenario text and some goals in the CMMI-SVC are provided to help the reader make the connection between the scenarios and the model and to increase the reader’s depth of knowledge about CMMI-SVC. For help with terms, please refer to the glossary of the CMMI-SVC [CMMI Product Team 2009].

The following paragraphs provide purpose statements for the seven Service PAs, CM, and MA that are taken directly from CMMI-SVC V1.2. Clicking on the PA name takes you directly to where that PA is addressed in the scenario. The presentation order of the PAs in the scenario follows a service lifecycle flow and the order in which HeRus contemplated service process improvements.

The seven Service PAs:

• Capacity and Availability Management (CAM). The purpose of CAM is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.

 

• Incident Resolution and Prevention (IRP). The purpose of IRP is to ensure timely and effective resolution of service incidents and prevention of service incidents, as appropriate.

 

• Service Continuity (SCON). The purpose of SCON is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.

 

• Service Delivery (SD). The purpose of SD is to deliver services in accordance with service agreements.

 

• Service System Development (SSD). The purpose of SSD is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.

 

• Service System Transition (SST), The purpose of SST is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.

 

• Strategic Service Management (STSM). The purpose of STSM is to establish and maintain standard services in concert with strategic needs and plans.

 

The two core PAs addressed in this scenario are:

• Configuration Management (CM). The purpose of CM is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
• Measurement and Analysis (MA). The purpose of MA is to develop and sustain a measurement capability used to support management information needs.

Ms. Shandra Takie manages the IT department for HeRus, a medium-sized (approximately 900 employees), privately held (family owned), government contractor providing database management, application development, service desk, and data center services primarily to Department of Defense (DoD). The IT department has 50 employees who support the work of HeRus, and like the employees they support, their motto is to be “Johnny on the spot.”

HeRus has aggressive growth plans for the next 5 years and would like to go public. To realize its growth plans, HeRus must justify and control costs, increase performance, improve quality, and showcase the value its services provide. HeRus is under pressure from competitors, particularly in the area of cost. To realize its growth plans, HeRus must adopt industry best practices. Instead of relying on heros and rewarding “end justifies the means” behavior, HeRus seeks to rely on procedures and processes standardized across the company but adaptable to the requirements of each contract.

The business development office scans for Request for Proposals (RFPs) from federal and state civil agencies and the Department of Defense (DoD) in the area of IT services. Bidding on, ramping up for, and shutting down contracts consume a great deal of time and effort at HeRus. The business development office is often far along in developing a proposal before the right technical stakeholders internal to the company are identified and brought in to provide advice. Sometimes the advice of technical experts is obtained too late, and commitments are made to provide services that are not in the best interests of HeRus’s future. Current services and service levels provided are not documented in any centralized fashion. What little information exists on current services is documented in various contracts and Service Level Agreements (SLAs) with customers without a basis in standard services.

Shandra has been assigned the role of IT Service Process Czar with the goal of piloting new IT service processes with the internal IT staff before deploying them to new contracts and eligible existing contracts. Shandra attended a recent SEI Software Engineering Process Group (SEPG) conference and learned the importance of aligning services with business goals. Shandra has her own motives for moving forward with the process improvement initiative.

Budget cuts in recent years have resulted in reduction of support for existing systems and applications as well as reduced purchasing of new capacity. Shandra wants to be able to show the value to HeRus’s bottom line of the IT services her department is providing. She knows that in order to support corporate growth plans, an upgrade to the IT systems is needed, but in the current climate, strong rationale backed by data would have to be provided.

Shandra knows that with better data and the means to estimate required capacity and availability to support HeRus’s growth plans she will be able to justify needed upgrades and increase automation of processes. Currently, HeRus relies on primarily manual processes that hinder the IT department’s ability to provide quality services at required service levels. She would like to be able to justify greater investment in tools and automation of processes.

Shandra knows the bottom line is that the more closely IT services and service processes are aligned to the business objectives and business processes, the more successful she will be. To achieve success, she must provide greater visibility into the achievements, challenges, performance, quality, costs, and contributions IT makes to HeRus. She must move the IT department from being focused on technology and infrastructure to being focused on service, with business objectives and processes driving IT service plans and processes.

Shandra plans to begin the IT service process and performance improvement initiative by establishing a service strategy. She begins by gathering and analyzing data about the strategic needs and capabilities of HeRus and developing plans for standard services provided internally (SG 1) based on her knowledge of those needs and capabilities. She knows that more than just documenting current services, she must decide what services HeRus’s IT department should provide. She knows that she will later expand the plans to include services provided to external clients, but for now she focuses on the services her IT department provides internally.

Shandra knows that she must document a service catalogue and make people aware of it. HeRus does not have a clear picture of all the services currently provided and a way to identify the current customers and maintainers of each service. As the corporate IT infrastructures and services have grown, it has become increasingly difficult to get a handle on the details of each service. Before jumping in to describe the standard services, she documents the properties of those services and service levels (SG 2). These properties include critical attributes, service levels, and common and variable parts.

She wants SLAs at HeRus to be based on the service catalogue. The service catalogue will provide a single source of consistent information on HeRus’s services that are operational or being prepared to be run operationally (those being prepared for transition to the live environment). HeRus will start with a business service catalogue containing details of interest to customers but plans to provide a description of underpinning services and other aspects of interest to IT in a technical service catalogue.

 

Shandra has had no SLA for IT operations, but the number and frequency of complaints indicate that IT is not meeting expectations. A service-level management process owner is appointed to address how HeRus plans, coordinates, agrees (Service Delivery PA), monitors and reports on SLAs (Project Monitoring and Control PA), and maintains the SLAs (Service Delivery PA). The process owner will provide templates of SLAs for use by HeRus’s service-level managers.

The service-level management process owner decides that, as a first step, service-level managers should base their SLAs on the service catalogue and analyze existing SLAs and data, including input from the capacity management process, availability of management process, incident management process, problem management process, service continuity process, information security process, and various IT functions. With this input, the SLA will then be defined, negotiated, and agreed. Quality Assurance (QA) will check whether the SLA is available to service providers, customers, and end-users, as planned. QA will also check whether the SLAs are periodically updated (SG 1).

Up until this time, no documentation existed to describe how preparation for service delivery is done and how service delivery is actually carried out. HeRus has relied on the knowledge of its experienced IT staff. Shandra knows that 50% of IT knowledge is in people’s heads, and 45% of IT will retire within 5 years. For this and for reasons of increasing consistency and quality, Shandra decides it’s time to document how IT services prepares for SD and carries it out. Standard processes and process assets will be stored in a Process Asset Library (PAL) available to the organization and used by QA in its compliance activities. QA is thrilled that it will have better information on what item to check, but given the increased awareness of what actually needs QA’s involvement, they’re lobbying for more resources (SG 2).

Shandra’s IT service process improvement steering committee decides to use the service desk as a pilot for its processes for SD preparation and fulfillment. The service-desk manager will now document the approach used for SD, including how service requests are handled and what resources are required. What the service-desk manager documents will likely be elevated to a standard service-desk process for use on future contracts. Service-desk staff will now confirm readiness to deliver services according to procedures, and evidence of having followed readiness check procedures will be documented. Shandra has read the latest literature on the importance of checklists for improving service quality so she encourages the use of checklists in the new processes (SG 2).

Service requests currently are processed and tracked in the same system as incidents, and there have been problems with the volume of service requests bogging down incident management staff. Shandra decides that separate processes for service requests are needed. Service requests will be distinguished clearly from incidents, and procedures and mechanisms for storing, accessing, updating, tracking, and reporting service request records will be defined. Shandra will argue for investment in more self-help and self-service mechanisms to free the service-desk staff to work on incidents (SG 2).

The service-desk staff now reports that they are receiving and processing service requests according to the SLA and meeting their targets consistently. The incident management staff reports that their performance has improved as a result of having clearer service request processes, including clear assignment of responsibility and authority (GP 2.4). Now that service-request staff consistently review service-request status and resolution and confirm results with relevant stakeholders, customer satisfaction is way up. The service logs, performance reports, customer satisfaction data, and request management system records all show that the service system is being operated to deliver services according to the SLA and in compliance with processes (QA has confirmed this!). It is clear from looking at maintenance notifications, logs, and schedules that the service system is being maintained to ensure the continuation of service delivery (SG 3).

The IT department has been achieving a decent 99.9% uptime, but the downtime occurs at the worst times, and with the cutbacks in purchasing, increased demand, and lack of demand management, Shandra anticipates that she will not be able to maintain this uptime rate. To support HeRus’s long-term growth plans, a strategic approach to capacity and availability management is needed that considers future capacity and availability requirements.

She knows these requirements are influenced by the other processes being defined, including the service continuity process and future innovations and emerging technologies, as well as patterns of business activity and demand, including how much influence can be exerted on it. Up until now, capacity and availability management has had an operational perspective focused on monitoring the performance, utilization, and throughput of primarily the IT infrastructure and some aspects of IT services, such as response to incidents. HeRus has also monitored availability and reliability to a certain extent, with an eye to whether agreed targets will be met.

There is little analysis going on, and HeRus relies on the expert knowledge of its IT staff for many of the activities in CAM. There is little documented information about what thresholds are set and why and what action is supposed to take place when certain conditions are met. Shandra knows that when the economy improves some of her expert staff will leave for greener pastures. The reliance on “expert judgment” and ad hoc practices has led to inconsistent performance and quality and represents a risk for HeRus.

When SLAs are documented, CAM data is rarely consulted, which is due in part to the lack of data. When decisions are made about changes to the service system, CAM data is rarely consulted. IT service continuity plans at HeRus do not have a firm foundation on data from other processes, such as capacity management or availability management. Shandra would like that to change because she knows the performance of the new processes relies in part on the availability and use of good data.

Shandra knows that IT service quality and performance at HeRus will improve with more analysis, a proactive approach to CAM, more reporting to relevant stakeholders, and more input from CAM to other processes, such as:

• Service-level management (to enable better decisions about what targets are agreed in SLAs)
• Change management (to enable better decisions about change)
• IT service continuity management (to enable better continuity planning and reduce the risk of not being able to meet IT service continuity requirements)

 

The approach to CAM has been largely reactive at HeRus, and Shandra knows that has to change. She understands that with the budget constraints and competition in the marketplace, including vendors who represent possible IT outsourcing opportunities for HeRus, she must implement more sophisticated CAM practices and tools that will support a more proactive, data-based approach. She would like to see HeRus reduce cost and increase performance by using tuning and exploring demand management.

Shandra establishes a process owner for capacity management and another process owner for availability management and reminds them that they need to get started right away on defining measures and analytic techniques to support the analysis she hopes to put in place. Shandra would like to see baseline models of current performance and resource utilization as a start. She knows these baseline models must be established before more predictive models can be established to help answer “what if” questions about changes, workload allocation and volume, SLAs, application sizing, and other questions from the design team, problem management group, and service continuity planning group.

Shandra and the process owners for the capacity management process, availability management process, service-level management process, incident management process, problem management process, service catalogue management process, IT service continuity, information security management process, and others understand that the weak measurement program in place at HeRus is a major Achilles’ heel for their improvement objectives and for the future of the IT department. They obtain approval and funding to hire a measurement specialist to head up their measurement program and institute measurement based on ITIL’s Continual Service Improvement book and CMMI’s MA PA.

Kathy Thompson is hired as the measurement specialist, and she works with the process owners and IT service managers and staff to establish measurement objectives that are derived from their information needs and objectives. She wants to be sure that technology, process, service, compliance, quality, performance, and business value are considered. She develops templates to help the staff with measurement responsibilities to refine the objectives into specified measures with operational definitions to support repeatability. The templates contain fields to describe data collection and storage procedures, data analysis, and communication.

Ms. Thompson sets about understanding what can be measured currently in parallel to understanding what HeRus should measure based in part on input from the service catalogue, SLAs, vision and mission statements, corporate goals and objectives, IT and other department objectives, legislative requirements, governance requirements, and input from the finance department. She identifies the gaps, and based on priorities, makes a case for enhancing HeRus’s measurement capabilities.

Over time, the templates are used, and the data is collected and analyzed. The data and analysis results are managed, stored, and reported as specified. Now the managers at HeRus really begin to get excited about Shandra’s IT service improvement initiative because they have better means to report their accomplishments and challenges and build their cases for investment in corrective actions. HeRus has taken a step forward to data-driven management.

 

HeRus has very weak business continuity plans and policies, which mention almost in passing, the importance of ensuring that there are contingency plans in place for “computer systems” and IT. Shandra knows this is a woefully inadequate treatment of IT service continuity. She knows that detailed plans must be put in place, personnel need training on the plans, and the plans should be validated and tested to ensure that IT services can be resumed within required, agreed-to timeframes (SG 2).

Shandra helps the IT service continuity process owner begin planning by identifying and prioritizing the essential functions that must be performed and the essential resources to ensure service continuity (SG 1). They do this in close coordination with HeRus’s business process owners knowing that their ultimate goal is to support business continuity. To understand the essential resources, they will need input from CM and other HeRus IT service processes.

Having a good start on the service catalogue provides valuable input to their planning efforts. To maintain their IT service continuity plan adequately, they must receive inputs from HeRus’s change management process (to assess potential impact of changes on their plans); CM (to understand the relationships between services, technology, and business processes); and other processes.

Having finished the HeRus IT Service Continuity Plan, they establish training to be sure that the plans will be successfully executed. Having conducted the training, they analyze the evaluations and determine that some improvements are needed to both the training and their plans before they will be ready to verify and validate the plans. Once the improvements are made and preparations for verification and validation of the IT service continuity plan are made, they conduct the verification and validation activities as planned and analyze the results, making additional improvements where necessary (SG 3).

HeRus’s internal IT department has only been able to meet the target response time (35 minutes) for incidents about 30% of the time. There has been no single repository for incidents, their underlying causes, and approaches to addressing them, and partly because of this, communication has been poor between the service desk and the rest of the IT department, particularly about known errors, and incidents and their underlying causes. Causes of incidents were not being tracked sufficiently, and in fact, no effort was being made to discover the underlying causes of incidents and prevent their recurrence.

Shandra decided to define an incident management process focused on handling interruptions to normal service and returning normal service as quickly as possible. She also defined a process for preventing incidents, developing workarounds, and addressing underlying causes of selected incidents. She decided to clearly assign responsibility and authority (GP 2.4) for incident management, preventing incidents, developing workarounds, and developing action plans for underlying causes when documented criteria were met (SG 3).

Staff members were trained on the processes (GP 2.5). Responsibilities included identifying, controlling, and addressing incidents (SG 2). Staff now responded in specific ways to specific incidents. They consulted the incident management system to know whether there were workarounds. Information recorded in the incident management system and other sources was used as input to help prevent incidents (e.g., through trend analysis). Information about incidents was recorded and could be grouped and linked to support analysis of trends and underlying causes.

Monitoring the status of incidents and communicating with stakeholders throughout incident handling (SP 2.5, SP 2.6) were emphasized in the training because many complaints had been received in the past about “being kept in the dark” and having to call the service desk to find out what was happening with an incident. These weaknesses were publicly acknowledged, and the new procedures were advertised to make sure stakeholders were aware that the IT department was doing something to address its poor service image.

The processes included preparing for incident resolution and prevention by establishing an approach to them and establishing an incident management system (SG 1). The approach included definitions of incidents and incident categories, incident handling, and incident reporting mechanisms.

Following the introduction of incident management and problem management processes based on the CMMI-SVC’s IRP PA, the target response time is being met 85% of the time, and the number of recurring incidents has dropped.

In the past, poor consideration has been given to the design of the release, deployment, and operation of new systems and applications. Deployments of new and updated applications have often been made without the development staff documenting and communicating information about known errors to the operations staff.. This has resulted in a high volume of calls to the service desk during and following deployment. Little thought has been given to carefully designing the interfaces between the processes, work products, consumables, people, and other resources that are required for HeRus’s IT services. There have been handoff issues between the development staff and the operations staff , and historically there has been tension between the two groups.

Shandra thinks that training her engineers and service providers on systems thinking and systems engineering will help them to take a systems view of IT services. She is sure that with a more disciplined systems engineering approach applied to SSD, the quality and performance of IT services at HeRus will improve. She also knows that some of the other IT service processes, such as release and deployment management, will be important to smoothing some of the interfaces between the development group and the service providers at HeRus.

The service systems needs to include requirements development, analysis, and validation, not just application requirements, so Shandra makes sure that the service-level managers, service catalogue manager, IT function leads, customers, and other process owners work with the requirement leads to document a set of requirements for the service system (SG 1).

Shandra decides that the service desk will be a good place to pilot the new systems engineering approach to IT services at HeRus. Although the service system is already in place and operating, there are issues and improvements needed to increase quality and performance and support HeRus’s growth plans. Optimal service system solutions need to be put in place as improvements to service processes are made and more automation is supported. Shandra would like to see more formal evaluations done when selecting service system solutions from alternative solutions because they have learned the importance of doing that in their systems engineering training.

Service system designs are developed against the requirements, and in the process many improvements are identified that address IT service processes, technology, people, and their interfaces. The new service-desk service system is developed (SG 2). As part of the new approach to SSD, peer reviews are implemented, and a more disciplined, formal approach to testing and validation is followed (SG 3). The release and deployment manager, CM manager, and Change Advisory Board (CAB) work closely with the SSD team to ensure that all changes to the service system are made and transitioned into the live environment in a controlled, efficient, and effective manner, resulting in fewer performance and quality issues and less tension between the development group and the service providers.

When new applications, systems, and technologies are deployed at HeRus, incidents have occurred during and following the deployment, and the impact to business processes has been poorly managed. Plans for retiring old systems, applications, and technologies have not been adequately developed. Updates to applications have occurred without consideration for the changes needed to systems and other applications communicating with them.

Information about equipment in the field, who is using it, spares, what equipment is still working, and what equipment should be retired is scattered in pockets of the IT department. Some information is documented, and some exists only in the heads of senior IT specialists. If a move is planned (for example when HeRus consolidates staff from two buildings into one), there are no records of what equipment is in each building. When new patches are deployed, it is not clear when or if the patching is complete because no plan for deployment of the patch was formulated, no success criteria were documented, and no post implementation review was held.

Shandra would like to implement a more systematic, disciplined approach to deploying new or changed services that includes detailed plans and preparation for significantly changed services. Plans will include details of how the changes and their deployment will be communicated to relevant stakeholders and what training will be provided for relevant stakeholders to prepare them for the deployment, operation, and end-use of the new or changed service. Plans will also include back-out and remediation approaches (SG 1).

Following the deployment of new or changed services into the delivery environment according to plans, the impacts of the transition will be evaluated. Instead of waiting for the calls to come in about issues that have occurred as a result of the deployment, the evaluation will proactively help determine whether rollback plans should be implemented or other mitigations or corrective actions should be taken (SG 2).

Shandra would like to see analysis of the functionality and compatibility of the current service system and the new or changed services take place prior to rollout. She also realizes that the success of the improvements to the release and deployment process depends, in part, on improvements to the CM and change management processes.

 

Herus has established a CM system that houses configuration items (CIs) that exist throughout HeRus, as well as the relationships between CIs. The status of CIs can be viewed or reported at any time. Records of CIs are maintained, although there have been release and deployment failures linked to inaccurate configuration records. Device configuration data, relationship information, and other details related to the IT architecture are lacking. Shandra would like to see systematic configuration audits conducted to maintain the integrity of configuration baselines. She would also like to see policies and procedures for creating and releasing baselines and other aspects of CM and change management. She would also like to see a definitive media library created and increased awareness by the release and deployment staff about managing and co

 

In addition, there have been complaints about how long it takes the staff that troubleshoots applications and does root cause analysis to resolve issues. Shandra would like to upgrade the CM system to be able to track configurations and automatically provide comparisons between configurations before and after issues occur. She would also like to see automated discovery capability in the upgraded tool. These upgrades and new practices would support analysis, troubleshooting, resolution, and more efficient and effective root cause analysis, not to mention better support for impact analysis and change management in general.

Shandra suspects that some of the CM issues are due to HeRus’s various business units implementing new software without an authorizing body and without benefit of policies to guide their activities. Shandra would like to see HeRus implement a more formal change management system to support controlling work products more effectively, controlling changes to CIs, and tracking change requests for CIs.

With improvements to the CM process, accurate information about CIs and their relationships will be available for the following: service failure impact analysis, incident triage, change impact analysis, service-level management (through a greater understanding of dependencies and relationships between components and how they support services and associated SLA targets), incident prevention, and point of failure vulnerability analysis.

With improvements to the change management process, the handling of changes will be efficient and prompt, changes will be traceable, the likelihood of conflicting changes will be reduced, decisions about changes will consider overall business risk and opportunity, changes will be prioritized, and authorization for change activities will be clear.

Five years after initiating service process improvements at HeRus, Shandra received a Success Contributor Award on behalf of the internal IT department. The improvements implemented there have been adopted throughout HeRus and have been a major contributor to HeRus’s achievement of its growth plans. The service process improvements have helped HeRus remain competitive by delivering quality and performance while holding costs in check and increasing customer satisfaction.

 

[CMMI Product Team 2009]	CMMI Product Team. Capability Maturity ModelÒ Integration (CMMI®) for Services (CMMI-SVC) Version 1.2, CMU/SEI-2009-TR-001. Pittsburgh, Pennsylvania: Software Engineering Institute, Carnegie Mellon University, 2009.
[ISO/IEC 2005]	International Organization for Standardization/InternationalElectrotechnical Commission. ISO 20000.: InternationalOrganization for Standardization/International ElectrotechnicalCommission, 2005.
[OGC 2007a]	Office of Government Commerce. Continual Service Improvement. Information Technology Infrastructure Library. Norwich, England. Office of Government Commerce, 2007.
[OGC 2007b]	Office of Government Commerce. Service Design. Information Technology Infrastructure Library. Norwich, England. Office of Government Commerce, 2007.
[OGC 2007c]	Office of Government Commerce. Service Operations. Information Technology Infrastructure Library. Norwich, England. Office of Government Commerce, 2007.
[OGC 2007d]	Office of Government Commerce. Service Strategy. Information Technology Infrastructure Library. Norwich, England. Office of Government Commerce, 2007.
[OGC 2007e]	Office of Government Commerce. Service Transitions. Information Technology Infrastructure Library. Norwich, England. Office of Government Commerce, 2007.

 

About SysDevCo, Inc.

SysDevCo offers Certified expertise in ITIL and CMMI to help your organization improve performance through improved processes.  SysDevCo, Inc. enables its customers to solve complex challenges in the area of process improvement. SysDevCo, Inc. provides leadership and business-advancing intelligence on standards and trends to help organizations enhance their business performance.