Saturday, February 09, 2008

ITSM – Information Technology Infrastructure for Service Management




Definition

ITIL is a "framework of best practice approaches intended to facilitate the delivery of high quality IT services". It outlines an extensive set of management procedures that are intended to support businesses in achieving value for money and quality in IT operations. These procedures are supplier independent and have been developed to provide guidance across the breadth of the IT infrastructure"

ITIL (the IT Infrastructure Library) is essentially a series of documents that are used to aid the implementation of a framework for IT Service Management. This customizable framework defines how Service Management is applied within an organization.

Although ITIL was originally created by the CCTA, a UK Government agency, it is now being adopted and used across the world as the de facto standard for best practice in the provision of IT Service. Although the ITIL covers a number of areas, its main focus is on IT Service Management

History of ITIL

It was initially developed during the 1980's, by the CCTA, and was widely adopted in the 1990's. This in turn led to the development of a number of standards.

ISO and ITIL

ISO/IEC 20000 is the international standard for ITSM, and aligned generally with ITIL. It comprises a 'specification' (part 1) and a 'code of practice' (part 2)

ISO 20000-1: This is the Specification for Service Management, the 'cerifiable' element of the pair.

ISO 20000-2: This is the 'Code of Practice for Service Management', which designed to work with the Specification, and outlines requirements, etc.

These two parts specify service management processes and form a basis for the assessment of a managed IT service.

Part 1 may typically be used by:

Organizations seeking tenders for outsourced services
Organizations that require a consistent approach by all service providers in a supply chain
Existing providers to benchmark their IT service management
As the basis for formal certification; and so on.

Part 2 provides guidance to auditors, implementation staff and others.

The ISO 20000 Toolkit

Implementation of any major quality standard is a complex operation. In addition to the learning curve, which can be steep, the demands of international standards are often rigorous. For this reason, a specific kit has been designed to aid both implementation and understanding.

The contents of the toolkit are both diverse and comprehensive, covering all the major processes. Included are the standards themselves, templates, guides, presentations and checklists.

How is ITIL organized?

ITIL is organized into five core publications that revolve around the service lifecycle. These provide best practice guidance for an integrated approach to IT service management.

The five core titles are:

1. Service Strategy
2. Service Design
3. Service Transition
4. Service Operation
5. Continual Service Improvement

To reflect this practice based approach, ITIL actually is formally known as 'ITIL Service Management Practices'.

Version 2 Background

The previous version of ITIL was organized into a series of sets, which themselves were divided into two main areas:

1) Service support
2) Service delivery:

Service Support was the practice of those disciplines that enabled IT Services to be provided effectively.

Service Delivery covered the management of the IT services themselves. It involved a number of management practices to ensure that IT services were actually provided as agreed between the Service Provider and the Customer.






What is ITIL Toolkit?

The ITIL Toolkit is a collection of resources brought together to accompany ITIL.

The materials included are intended to assist in both understanding and implementation, and are therefore targeted at existing ITIL users and beginners.

The toolkit includes:

A detailed guide to ITIL and service management
The ITIL Fact sheets - 12 two page documents, serving as a concise summary of each of the ITIL disciplines
A management presentation, inclusive of speaker notes
An ITIL audit/review questionnaire and reporting set based on MS-Excel
Materials to assist in the reporting of the above results (eg: presentation template)

What is ITIL Triangle?

This is a diagram that describes the relationship between ITIL, the ISO20000 service management standard, and your own in-house procedures.

Essentially, this top down illustration starts at the highest level with ISO20000, the BSI standard specification for IT service management. The next level presents a code of practice for ITSM (e.g.: PD0005, which was produced by CCTA, ITSMF and DISC/BSI). ITIL itself is the third layer, with in-house procedures represented by the bottom layer.


PPB and PCB...

Process Performance Baseline

Process Performance is a measure of the actual results achieved by following a process.

PPB is a documented characterization of the actual results achieved by following a process, which you use as a benchmark for comparing actual process performance against expected process performance. You establish a process performance baseline typically at the project level, [PPB=Project Level] although you will use the PCB to derive initial process performance baseline.

PPB documents the historical results achieved by following a process for a given project. Once a PPB is developed, it is then used as a benchmark for comparing actual process performance in a project against expected process performance. PPB for each project is collected and is used to define PCB (at organization level).
Process Capability is the range of results that can be achieved by following a process.

Quantitative Process Management is achieved by using Process Database, and PCB (Process Capability Baseline). PCB is derived from PDB and contains capability of different processes in quantitative terms.

Process Capability Baseline

PCB is a documented characterization of the range of expected results that would normally be achieved by following a specific process under typical circumstances. A process capability baseline is typically established at an organizational level. [PCB=Organization Level]

PCB specifies, based on data of past projects, what the performance of a process is. That is, what a project can expect by following a process. The performance factors of a process are primarily those that relate to quality and productivity. PCBs define - Productivity, Quality, Effort Distribution, Defect Distribution, Defect Injection Rate, CoQ, etc.

Using the capability baseline, a project can predict at a gross level the effort that will be needed for various stages, the defects likely to be observed during various development activities, and quality and productivity of the project.

SCAMPI-A & SCAMPI-B Differences...



Thursday, December 20, 2007

Risk Management

Risk Exposure = Level of Impact X Probability

Level of Impact: This is an estimate of the overall scale of the impact following an occurrence of risk. This is rated on the following scale: Very high impact, High impact, Medium impact, etc.

Probability: Likelihood of occurrence of an event.

Mitigation: This is an action to avoid the occurrence of the risk or to mitigate/lessen the chances/impact of the risk. On failure of mitigation, contingency plan is used. Mitigation is preventive. You apply mitigation plan even before the risk has occurred (to avoid occurrence of risk).

Early warning: This is an assessment of known parameters which are indications of risk, and are those which if not controlled can lead to occurrence of the risk. This is useful for taking the mitigation actions.

Contingency: Alternative actions to be taken in case, despite applying mitigation strategy, the risk occurs. Generally, risk realization leads to a change in schedule, effort, cost, project control, customer satisfaction, defects, etc. Hence, contingency is applied to identify which parameters would be affected by the risk and how they would be handled. Contingency is corrective. You apply contingency after the risk has occurred.

  1. When a project starts, prepare its risk profile (which is the threat the project poses for the business.)
  2. Pick up (from the PPDB) the most commonly occurring risks the project might be exposed. Record them in the risk tracker.
  3. Identify other probable sources of risk
  4. Classify the risks, identify their Impact on the business
  5. Identify their probability of realization
  6. Identify Mitigation and Contingency plans
  7. Define the threshold for mitigation and Contingency
  8. Revisit the risks at regular intervals (during weekly team meets / client calls).
  9. Note: At any point in time, PM and team should be aware of the three top risks plaguing the project.

Thursday, December 13, 2007

Process implementation...

For long running projects without defined processes, do not attempt a big bang approach. People are resistent to change. A big bang approach will lead only to greater resistance. Try to work out the as-is process and suggest improvements. Apply metrics to see the current level of performance. This will help in understanding areas which can be oiled for maximum efficiency. The measurements also allow for assessing the weakest links, forging of which will lead to enhanced performance.

After you have set up basic metrics in place, reach out to the client team to understand their expectations. Report the metrics to the client team. Facts will provide a handle to justify (realize if process tweak is necessary) the efforts of development team.

Talk with the development team to understand the challenges of implementing a defined process. Come out with a basic ETVX model for the as-is process. Suggest improvements to it. After the process flow has been established in consultation with the project manager, disseminate the information to the entire team via classroom sessions. Randomly check each developer to see if the defined process is being followed. Capture metrics at each stage of the defined process.

Compare the new metrics with the older ones to see the improvement in proces performance.

If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...