Simplifying Service Management

One of the things that troubles me at times is how often people try to make the world more complex than it needs to be. The world is really a rather simple place if you take the time to step back and avoid complexity. I recently read a statement that made think upon this problem again.
The opposite of “simple” is “elaborate”, not “complex”— Dan Roam, The Back of the Napkin
What people call complex, may in reality be elaborate. They confuse the two ideas. This can lead to issues in the delivery of Business and IT Services to customers. If someone believes a service is too complex they can often be less willing to make the effort to provide the service, or support it or improve it. Most likely the service is just elaborate (having lots of underpinning elements and components), not really complex (being of a nature that is difficult to understand).

So how do we move away from complexity and towards seeing Service Management in terms of simplicity and elaboration? Here are several techniques that might help:

1. Visualize: Draw out concepts, topologies, hierarchies, structures, models etc. on paper or using a tool like Microsoft Visio. Seeing the idea put into a visual structure can help someone see the paths and interconnections that make up a system or service.

2. Quantify: Put numbers and facts to systems and services using measurement and metrics techniques like the 7-Step Improvement Process found in the ITIL© Continual Service Improvement publication. Having factual data and information tied to systems and services can help show volumes, durations and frequencies associated with systems

3. Qualify: Use Deming’s Plan-Do-Check-Act cycle. Map terminology and actions into the four steps of the cycle to see how the process or flow of actions or steps can be simplified to some basic ideas.

4. Analyze: Use deductive and inductive reasoning techniques to break apart (deduction) or recompose (induction) structures, processes, steps, models, etc. to see the interrelations and structures

5. Map: Use mind-mapping or brainstorming tools to again visualize the ideas and concepts, or parts and pieces of a system or service. These diagrams show how elaborate systems and services often point back to a single central idea.

Each of these techniques has its own uses and appropriate place and time. The key with any of the techniques is to maintain the approach that delivery of service is at its most basic a simple idea. By keeping in mind the goal of finding the simplicity rather than focusing on the complexity, these techniques can be very powerful.

Prioritizing Changes

The Professor recently received the following question:

Having put together a spreadsheet of information that I need to assess the impact of a change,  what I need to do next is figure out how to assess the impact of a change as being high, medium, or low? Any guidance you can give me on how to do this would be greatly appreciated.”

The  ITIL V3 Service Transition book provides great guidance on assessing the impact of changes (ST 4.2.6.4). This section provides 7 questions that must be answered to fully understand the impact. Many of these questions are answered using information in your spreadsheet. Others you may want to consider adding. 

• Who RAISED the change?
• What is the REASON for the change?
• What is the RETURN required from the change?
• What are the RISKS involved in the change?
• What RESOURCES are required to deliver the change?
• Who is RESPONSIBLE for the build, test and implementation of the change?
• What is the RELATIONSHIP between this change and other changes?

You can then develop guidelines/a matrix that categorizes the impact based on the answers.

The Microsoft Operations Framework (MOF) Change and Configuration Service Management Function (Table 6) gives the following guidelines for prioritizing changes based on business impact, urgency and required resources:

• Low. The change can wait until the next scheduled release.
• Medium. Because of its impact level, the change cannot wait until the next scheduled release.
• High. The change needs to be released as soon as it is complete and has been tested.
• Emergency. The change needs to be released as soon as possible; many of the approval and the development steps are abbreviated.

NOTE: If your organization has too many "emergency" and "high priority" changes, this may indicate that staff are avoiding the process or that the process is not effective.

 

ITIL and MOF also factor in risk when assessing changes and looks at both change impact, and the probability of that impact. For example, a change that has the possibility of high impact and also the probability of high impact will be the highest category of risk. High impact, low probability, the next highest category, and so forth. 

Using CSI to Meet Customer Needs

I recently posted a blog about returning to a service desk I had managed and spoke about how the changing business environment had impacted management’s ability to sustain the current list of Critical Success Factors (CSFs) and Key Performance indicators (KPIs). The 1st question was “What should we measure?” Within the new business reality, we reviewed how the corporate vision, mission, goals and objectives had changed. We spoke with service owners, business process owners, business analysts and customers and asked what was critical to them.  We could then determine the services that were creating the most value  and enabling them to meet these new goals and objectives.

Management then identified the gaps of “what we should measure”, to “what we can measure”. From this, a more customer-centric list was developed. The overriding objective of these new service measurements was to provide a meaningful view of the IT service as experienced by our customers. The three key areas that customers most cared about were: 

• Is the service available?
• Is it reliable?
• Is it being delivered with the proper level of performance?

The Service desk together with Technical Management began to tie incidents to specific CIs to measure component availability. Management reviewed the “Expanded Incident Lifecycle” and reliability of services and components. They measured the maintainability of components and CIs tied to particular service incidents. They measured the serviceability of their suppliers to meet contracted services. From a performance perspective, they worked with capacity management and tied performance related incidents of services to components and CIs. All of these positively impacted the availability and reliability of those critical business services on which the customer depended.

ISO 20K Certification Process

Thinking about ISO/IEC 20000 certification? Here are the steps involved.

1. Questionnaire:
The service provider contacts one or several Registered Certification Bodies (RCBs). Each RCB will send a questionnaire with information needed to submit a quotation. Based on the quotations, the provider can select a RCB.

2. Application for assessment:
An application form is completed and returned to the chosen RCB. A lead auditor is assigned and an initial visit scheduled. The auditor will explain the assessment process, an audit program will be agreed and the assessment date selected.

3. Optional pre-audit:
This is a high-level evaluation to determine where the company stands in compliance with ISO/IEC 20000. The auditor will point out any areas of concern to give the provider an opportunity to improve before the initial audit.

4. Initial audit:
In this session the scoping statement is agreed upon and the auditor plans the certification audit. Documentation and evidence of compliance are reviewed. Non conformance items are added to the Corrective Action Plan (CAP).

5. Certification audit:
The assessment to the standard is now being executed. The RCB will look for records, proof, that the management system is in line with the ISO 20000 specification. On completion of the audit the RCB will present the findings in a written report. Non conformances will feed into the CAP. Following a successful certification audit and the decision by the RCB to grant registration; a certificate of registration is awarded. The client is now permitted to use the certification body certification mark and the relevant ISO 20000 certification mark.

6. Surveillance audits:
A schedule of surveillance audits are undertaken over a three year period to ensure that the management system is working properly. The actual frequency will depend on the RCB.

7. Re-certification audit:
This is carried out every three years. All controls are evaluated to ensure that the QMS is operating properly and if it is, certification is renewed for another three years. Any non-conformity will be added to the CAP, where it will be addressed. The three year surveillance audit process starts all over again.

Early Life Support

I have found, after doing a number of releases throughout my career, that a solid Early Life Support program (ELS) can really enhance the acceptance and support of any new or changed service. The ITIL Service Transition definition of ELS is the “Support provided for a new or changed IT service for a period of time after it is released." During ELS the IT Service Provider may review the KPIs, Service Levels and Monitoring Thresholds, and provide additional resources for Incident and Problem Management.

Although stakeholders have agreed to the entry and exit criteria in the Service Design stage, it may become necessary to finalize the performance targets and exit criteria after the build and testing of the service has been completed. This will help to clarify the deployment process and set the proper expectation of the operational resources that will perform the support after ELS has been completed. ELS ensures that appropriate resources are available to resolve operational and support issues quickly and reduce the amount of unavailability while enhancing acceptability of the new services by the user community. It will also allow the support teams to better define role assignments and responsibilities, security policies and procedures, raising incidents and change requests.

Once the agreed milestones have been met by the ELS program, Service Transition will monitor the performance and determine if the exit criteria has been achieved. Some key criteria is:

• Users can utilize the service to complete their business activity 
• Service and process owners have agreed to operate the service within documented SLAs 
• Service levels and performance are being consistently achieved 
• Training and knowledge transfers have been completed 
• SLAs, agreements and contractual obligation have been signed off

Once we move from ELS to operational support, a review of the deployment should be undertaken. It should include:

• Capturing feedback on user and service provider satisfaction 
• Any criteria not met 
• Check that all fixes and changes are complete 
• Review targets and achievements 

Formal closure should happen with a Post Implementation Review (PIR) performed by Change Management.