Introduction to Service Management

Welcome to HCI IT Service Management - that is IT Service Management as I think it should be

operationalized. In the sections which follow (chose section from list box in top right hand corner), I
describe an approach to IT Service Management. This approach is targeted at organizations
struggling to define and embed better service management processes. Enterprises which have
already attained these capabilities (perhaps demonstrated by ISO:9001 certification or CMMI level 3
maturity) may find the discussion sophmoric. I would encourage them to review "HCI Processes"
descriptions for relevancy. For organizations seeking to achieve more than basic (performed) service
management capabilities (usually typified by organizations focused on putting out fires), they will find
a phased approach to implementing best practices supported by the early introduction of key
enablers.

IT service management can best be introduced and assimilated into an organization through a series
of planned stages which recognize the accumulated wisdom of a number of complementary sources -
most notably ITIL, CobIT and CMMI. Taken together these three sources describe best practices, how
they can best be implemented for sustained benefits (ie., institutionalized) and baselined for ongoing
assessment and evaluation.

My approach is divided into sections. This introduction is followed by a discussion of current service
management reference (ie. framework) models. Today, the most topical of these is ITIL. Variations on
ITIL by vendors such as Hewlett-Packard and Microsoft extend ITIL's coverage so as to be more
exhaustive of the activities a typical IT Service Division would undertake. A secondary grouping
of frameworks is focused on improving overall management capabilities. These "improvement"
frameworks describe processes which are as important to an IT service provider as to any class of
business operation. In many ways they describe key enabling processes which are crucial or
beneficial in expediting IT service delivery.

An organization needs to target a maturity level to realistically implement many ITIL processes. Most
will strive to achieve level 3 - a defined level of maturity as a goal. This milestone is deemed to be
90% congruent with ISO-9001:2000 certification and, indeed, many companies set achieving this as a
strategic goal. The establishment of documentation standards and the codification of key processes
are key elements in realizing these capabilities. A discussion on Process Modeling is intended to
stress the importance of properly documenting and maintaining key process artifacts in the
achievement of a Defined maturity level.

ITIL is a library of best practices. I discuss the meaning of best practices and how they can be utilized.
Best practices require a conscientious effort in selecting and tailoring them to a unique
corporate methodology - "the collected sum of best practices that, when carefully orchestrated, create
synergistic, tangible value to an organization".

Weaving these best practices is not a quick nor easy exercise. It is dependent upon the fabric of the
organization: it's internal management and workforce as well as process and project management,
engineering and support capabilities. How these inter-dependently operate constitute the
organization's maturity. In my discussion of maturity models I describe these capabilities and what
they mean to an enterprise undertaking IT service improvement schemes.

While Maturity Modeling originated with CMM - to improve the quality of software delivery, versions
soon encompassed product and process delivery. Eventually, the separate streams were generalized
into CMM Integrated. Specific applications of CMM/CMMI have been described for workforce, project
management and IT service management. As well, several variations have been advanced on CMMI
which accept the notion of a graduated scale of organizational capabilities but vastly simplify the
criteria on which the capabilities are based. ITIL, in it's Implementation book, advances such a simple
maturity schema. While it serves to acknowledge the need to recognize organizational maturity as a
pre-requisite for implementing many ITIL processes, this presentation lacks the rigour necessary for
successful implementation. On the other hand, CobIT is far more thorough. Many organizations
evaluate their implementations of the CobIT Control Objectives within each of the 34 CobIT processes
areas for compliance with Sarbannes-Oxley (or some other government's variant of the legislation).
Two pre-requisites in CMMI for achieving a Defined level of maturity are Organizational Process
FocusD and Organizational Process DefinitionD. Processes include the set of standard processes and
the defined processes from which they are "tailored". The organizational process assets are used to
establish, maintain, implement, and improve the defined processes. Process assets enable consistent
process performance and provide baselines for subsequent improvements. The process asset
library is a collection of items maintained for use by the people and projects of the organization. This
collection includes descriptions of processes and process elements, descriptions of life-cycle models,
process tailoring guidelines, process-related documentation, and data.

Standard procedures and methods should be established governing the modeling and description of
processes. An outcome of the modeling exercise should be the identification of gaps between what is
desired and what is currently in place in the organization and the establishment of a project plan to
achieve the desired state. Typically gaps fall into one of four primary types:

1. Service - An absence of appropriate concepts dealing with service management - the

organization doesn't describe accurately what it wishes to accomplish;
2. Delivery - Key capabilities to implement and sustain service improvements may be missing -
the organization cannot deliver what it wishes to;
3. Expectations - management doesn't properly articulate its' service goals - the organization
doesn't know what to expect;
4. Awareness - Management and key stakeholders may be unaware of the existence of
services and processes - management doesn't track performance very closely.

A literature review of the key concepts and timings relevant in implementing service improvement
projects is presented to suggest possibilities and to facilitate the construction of an overall service
improvement plan. The traditional methodology for implementing processes is described and criteria
are advanced for the selection of projects.

The ITIL process areas may be too large and ambiguous to be fruitfully used as service improvement
projects by many organizations. I decompose the ITIL best practices areas into sub-processes. At this
level of detail an improvement project can be more meaningfully described. The granularity better
recognizes process interdependencies, particularly with regard to project timing so that a more
efficient and effective project improvement schedule can be developed based upon selected
candidates.

Lastly, I discuss key process enablers. These are derivable from the generic practices described by
CMMI. Achieving a basic capability in these areas is crucial to sustaining the gains achieved from
service improvement initiatives. In each area, I advance one or more key enablers for undertaking a
service improvement process. Gartner, Forrester and Meta have mentioned the large number of
service management project failures.

I believe past service management failures are explained by existing

operational and management practices which are the platform upon which
ITIL processes and activities are layered. A house is only as good as it's
foundation. Paying attention to pre-requisites, enablers and process
interdependencies will increase the success rate associated with service
improvement initiatives. The organization which uses all three of ITIL,
CobIT and CMMI stands a better chance of success - three tools, used
appropriately, are better than one.

Contents of Approaches to Service Management

 Introduction: Multiple tools are better than one - use all that are available
 Reference Models: How others have conceptualized IT Service Management
  Maturity Frameworks: What Maturity Models are available and why and how are they
applicable to IT service management
 Best Practices: What are best practices, how do I employ them and what are the pifalls
 Process Modeling: Why is it important and what standards are available
 Implementation Issues: What are the key issues in implementing IT service management
 Project Strategies: What strategies should be used to select service improvement initiatives
 Project Options: Typical IT service management improvement projects
 Enablement: Key organizational capabilities which need to be in place to facilitate IT service
improvement.

Know Your Game 

Perfecting IT service management is like playing golf.
There is enough golf coverage on television that we all
know who does it best - that is who we should try to
emulate. And, we can pick and choose amongst the best
golfers for different aspects of the game - driving, iron
play, putting, etc. There are many instructional books
dissecting these different facets of the golf game,
however, while the packaging differs, there is often very
few variations as to the key concepts (ie. best practices).
Choosing the right book will help, but it's far more
important at this time to get started. After gaining some experience it becomes far easier to identify
the finer points in what the reference sources are describing. Furthermore, the best source may reflect
additional considerations related to your own physical attributes - size, physical ability, etc.

How the book is organized (i.e. its' methodology) will go a long way in helping you understand what
needs to be done and in what order. Traditional divisions such as the 'long game', the 'short game',
chipping', 'putting' break the game down into understandable divisions based upon discrete and
separable facets. They aren't always exhaustive of all elements inherent in the game of golf, but
emulating them will help you improve your game.

There are four relevant aspects in learning golf which, I believe, have current parrallels in the IT
service management field.

1. what the game looks like when played correctly. We get this from watching major
championships and reading instructional books. N
2. instructional material on how we can make our body cooperate to do the things necessary to
action the best practices.
3. agreed-upon scoring methods which outline how well we are doing in relation to others and
how we are improving over time.
4. how to select the best clubs and other equipment to improve our game.

The Information Technology Infrastructure Library, is becoming widely recognized as a definitive

source for what good IT service management looks like. Like a golf instructional book, it contains
divisions (and, the divisions may not exhaustive of all aspects of IT service management), which
break service management down into discrete units. Like golf these aspects are interdependent in
many, and often varying ways, so that it is necessary to understand the entire library to score
properly. These interdependencies are like "course management" - knowing where the hazards are
and how to best avoid them.

While ITIL describes important "best practices" (i.e., what the game looks like when played properly),
it isn't prescriptive as to what you need to accomplish to attain that level. Capability Maturity Modelng,
is used to decompose elements into instructional material. Following the analogy, it describes such
things as the levers involved in a golf swing and how a human torso should be 'twisted' to best employ
these levers (i.e., club and arms) to generate consistent force in the right direction. The integrated
version of CMM outlines some generally recognized practices (like proper conditioning, mental
preparedness, etc) and some specific practices for each aspect of the golf game.

"In golf, many players copy Tiger Wood’s swing to improve their game. But
there is only one Tiger Woods! If you are shorter, less flexible, weaker, or
less practiced than Tiger (as most of us are), then you need to adapt Tiger’s
swing to your unique requirements".

Remedy Corp, Adapting Best Practices for IT Service Management

Furthermore, CMMI emphasizes how to "tailor" a standard swing process for a driver, or a short-iron
(or how to draw and fade for that matter). Like Tiger Woods, no two golfers are exactly the same.
Each must "tailor" their swing for their unique physical conditions and the unique environmental
conditions of the course they are playing on. yet, in both sets of circumstances the "unique" aspect is
derived from a standard set of shots which have been tested and verified for performance. There
should be little variation from expectations, though the the risks of failure will be commensurate with
the difficulty of the shot.

Control Objects for IT-related Technology describes how well you are doing in different aspects of the
game. This is different from a balanced scorecard which empirically measures certain facets of the
game - including overall score. Instead, it breaks the game into its' constituent elements and
describes how well you are doing on each of them (like physical conditioning, knowledge of the game,
etc.). It attempts to be exhaustive of all facets of the game - 34 distinct processes ordered into 4
categoriesN. The level of play it uses are set out as maturity levels:

 can you repeat the element (eg. swing) consistently

 have you defined the elements and try to operate according to the description (eg. defined the
elements of the swing)
 have you quantified the key elements and used the data for improvement (i.e. analyzed the
mechanics of the swing for defects - e.g. deviation from consistent swing plane)
 do you review and attempt to remove deviations from the defined (i.e. optimal or best
practice)

Lastly, you can improve the assistive devices you employ in the game. Within specified parameters,
the right clubs will increase your distance and accuracy N. Increasingly, IT service management is
demanding (and vendors are responding) with integrated toolsets which recognize the
interdependencies amongst IT disciplines. Beyond this there are a variety of specialized devices
providing failure alerts, the compilation of management data, etc.

"While ITIL guidance is strong in the areas of performance and relating

responsibly, it is weak in conformance aspects. To cover these, one should
look to the internationally recognized guidance contained in CobiT, which is
also internationally recognized guidance, in this case focusing on control
and compliance. A standards-based approach leveraging ITIL and CobiT
helps ensure a defensible compliance position and accelerates compliance."

IT Governance: Toward a Unified Framework Linked to and Driven by Corporate Governance, David
Pultorak, p 304-5

The key point I'd like to make with regard to this is that no prevailing approach - ITIL, CMM, CobIT, or
existing tools - is currently sufficiently developed (i.e., robust) to provide all the answersN. You can
have a vision of what an ideal golf game might look like, but you also need a plan for how to achieve
it, and, you need a way of telling you how you are improving. In short, you need to understand all
three of these elements for sound IT service management. N
However, it is not necessary for this to occur for an organization to undertake improvements. An
understanding of the three aspects can provide the necessary knowledge to commence
improvements. Furthermore, it is not necessary to have a detailed knowledge of your physical make-
up to commence the improvement exercise. While at some point it is beneficial (and some would say
imperative) to have this done there are many aspects of play which can be undertaken without
detailed understanding of the finer points of the game. Everyone can play better through repetition,
and, everyone should play better through better definition of the game and feedback on how well they
are doing. Unfortunately, there are those who advocate the need for an extensive appraisal of your
general health prior to undertaking any play.

Get Started Now

I've participated in, or supervised investigations into, the state of organizational processes - financial,
strategic planning, results reporting; with mixed results at best, far too often to be proud of. Clearly,
many of these organizations struggle to do things correctly the first time. Even fewer have systematic
and sustained methods to learn from and apply past experiences.

None of these efforts were ever declared to be failures. After a far too few number of years it is often
difficult to find anyone who could even review or report on the undertakings - let alone resurrect any
recommendations which had been accepted. This never proved to be an impediment for further
"study". Continuing "research" often gives the appearance of action wrapped as proactive leadership
seeking dynamic service improvements. All too frequently the original "champion" had "moved on"
before any concrete deliverables were achieved (or evaporated in subsequent years). Realizing
and/or sustaining promised benefits can prove elusive as the improvement project unfolds, and
changes to project champions and managers often taxes project management systems heavily reliant
on the talent of particular individuals. Accountability for non-achievement of results is most often lost
as new projects are launched to get the situation under control again. Stop, start, stop, start - with no
sustained progress.

"It is also important to sustain motivation throughout the project that

typically takes long time, and the senior management can play a key role to
keep morale high throughout the project. Without senior management
support, alignment cannot be achieved even if the best IT management
consultant in the world is brought in for help."

"There are certain characteristics that make alignment a complex project.

The organization must be mature enough and must have a culture that
encourages employees to spend time for communication as well as
organizational learning. Organizations must create the environment for these
activities to take place."

Mardi Merdinoglu, Bored With Business-IT Alignment?, ITSM Watch, May 1, 2005

Capability Maturity Modeling envisions this as an organizational inability to perform - the need to
institutionalize gains so the organization can utilize past learning to modify and learn. Practices are
less reliant on individual leadership because the focus and processes are directed at corporate rather
than individual learning.

"Institutionalization practices are practices that help to institutionalize the

implementation practices in the organization’s culture so that they are
effective, repeatable, and lasting. These institutionalization practices, taken
as a whole, form the basis by which an organization can institutionalize the
implementation practices (described in the Practices Performed section of
the process area). Institutionalization practices are equally important,
however, for they address what must be done to support and institutionalize
the process areas.
  Commitment to Perform: actions the organization must take to
ensure that the activities constituting a process area are established and
will endure - typically involves establishing organizational policies,
executive management sponsorship, and organization-wide roles to
support practices to develop workforce capability.
 Ability to Perform: preconditions that must exist in the unit or
organization to implement practices competently - typically involves
resources, organizational structures, and preparation to perform the
practices of the process area.
 Measurement and Analysis: measures of the practices and analysis of
these measurements - typically includes examples of measurements
that could be taken to determine the status and effectiveness with
which the Practices Performed have been implemented.
 Verifying Implementation: the steps to ensure that the activities are
performed in compliance with the policies and procedures that have
been established - encompasses objective reviews and audits by
executive management and other responsible individuals.

People CMM - Section 2

Consulting firms are tolerant of, or indifferent to these needs. Downplaying their relevance is often
convenient and lucrative. All too often they are omitted in the firm's proprietary methodology (because
of the complexity it introduces). Typically, a firm will suggest that service management initiatives must
be properly 'contextualized' within a framework which is unique to technological, cultural and
organizational nuances. Otherwise, the organization will not be properly "aligned" N. In the IT field this
means that the provision of IT services will risk being without appropriate reference to the larger
organizational vision, mission and goals and objectives.

Such context is, of course, highly desirable. The problem is that documenting and operating according
to appropriate alignment Nis a major undertaking requiring significant organizational maturity.
Developing and acting upon such high level frameworks is exceedingly difficult for organizations still
operating according to workforce practices characterized at a low maturity level. Both ITIL and CobIT
acknowledge the importance of achieving specified levels of maturity as preconditions for
implementing certain service management practices. Most consulting firms when developing the
framework don't mention thisN - those that do must include 'enablers'. The problem with 'enablers' is
that they must include explicit provision for 'institutionalizing' gains or the organization stands a strong
chance of reverting to previous processes when the original incentives are removed (champions move
on, sanctions against previous methods are eased, etc).

One of the primary benefits of "best practice" descriptions is their universality. The practices as
described by ITIL are almost always beneficial. Moreover, there is remarkable similarity amongst IT
organizations in their need for many of the practices. Each practice will have variants as to how it can
operate at different levels of maturity. For organizations just beginning to adopt ITIL practices the
need is often so fundamental that they can undertake some key initiatives with virtually no risk of any
incongruities with a top level review.

"Once an organization has decided to adopt ITIL best practices, the question
becomes ‘What is the best way to implement ITIL, and what are the
practical steps involved?’ One possibility is to follow the classic analytical
approach: assessment followed by design and then implementation. This has
the virtue of simplicity, but it also has its drawbacks. An assessment takes
time and resources, and may be perceived as unnecessary by those within
the organization who are already well aware of the main operational
functions or processes that need improvement. Similarly, the need to go
through a design stage may be questioned since ITIL best practices
 encapsulated within a process flow should be very much the same for any
organization, regardless of its size or industry sector. In other words it
should be possible to customize a ‘standard’ process design rather than
create a completely new one for each implementation."

Kerry Litten, Consulting Manager, Five Steps to Implementing ITIL, INS Whitepaper, January , 2005

This suggest that a streamlined version of the approach suggested by ITIL is possible. In this
document I will make some suggestions on how to implement IT service management. I believe that
many (if not most) full ITIL implementations have not delivered on the benefits expected (as listed in
the ITIL Service Management and Delivery booklets). This is because ITIL, though the best
compilation of industry best practices, provides little guidance on implementation where factors are
highly sensitive to organizational considerations - structure, culture, nature of the business. However,
given this, in almost all cases your chances of success can be increased by:

 establishing a clear Vision and baselines for initial and subsequent stages in implementation,
 increasing the organization's workforce, management and service delivery capacities as the
basis for implementing process improvement,
 re-considering ITIL processes according to requisite capabilities for implementation and
sustained use,
 staging the introduction of ITSM processes and activities according to the achievement of the
requisite capabilities,
 establishing criteria to recognize success.

I discuss current frameworks, and (like all good consultants), propose my own. This framework is
based upon utilizing views of the organization - business, work, information, application and
technology.

Implementing IT service management is like perfecting a new golf swing. ITIL provides the Vision of
what that swing would look like but doesn't provide a training plan on how to achieve it. Capability
Maturity Modelling is the closest thing to this, providing advice on how various muscle gorups must
work together to achieve the optimum swing. COBIT and assessments like PinkScan can be used to
assess the mechanics of that swing.

Process maturity models are reviewed as the means through which best practices might be
successfully implemented. The emphasis is on achieving a 'Defined' level of maturity wherein
processes are primary organizational assets. Subject to the rigour of internal Change Management
policies and procedures, all work associated with processes are managed according to process
descriptions which are periodically reviewed against business strategies, goals and directions.

KEY MESSAGES

1. The institutionalization of a process culture within the

organization is a pre-requisite to sustaining the gains from an
ITSM initiative. This includes the development, maintenance
and primary reliance by the organization on its' process assets,
instead of individual skill sets and approaches. Thus, processes
become major organizational assets.
2. It is possible to implement facets of the ITIL best practices
library which are not as reliant upon the achievement of a state
of organizational maturity.
3. Sustained gains and continued improvements can only be
realized if the necessary organizational prerequisite processes
(as defined by CMMI) are "institutionalized"
I will provide some advice on implementing ITIL processes and practices which acknowledge the
existing and "Maturity Vision" of the organization.

The process of implementing ITSM is described as a high level process under processes. Much of the
discussion in this document is based upon the frameworks and approaches advanced in this report,
and frequent references between the two documents are cited.

Reference Models
In this section I discuss frameworks - what a framework is and how having one can benefit the
organization.

A framework can help articulate the expression of appropriate IT governance for the organization -
who makes what kinds of decisions with regard to information technology. Most frameworks offer
some specialization in governance eg., ITIL offers guidance on decisions surrounding operations and
service management). Many authors argue that "organizations should never simply choose a single
framework, but instead try to use what they can from each"R. This implies that no single framework
has all the answers - "The issue broadly speaking is that Service Management needs to bridge with
the other Core process areas and also with the support and enabling process areas"R.

In this section I look at three kinds of frameworks:

1. Service Management - models describing how the pieces of an organization can "fit
together" to deliver better IT services;
2. Project Management - Process descriptions of how to deliver new services - applications,
processes, services;
3. Improvement Models - Descriptions of how best to deliver new services, etc given the
current state of the organization. These models outline sequenced representations of the
organizational capabilities necessary to obtain the described framework at
various Maturity  levelsN.

In "Multiple View Models" I suggest that the models can be seen from more than a single perspective
- following the principles enunciated by Zachmann. I provide a multiple view of IT Service
Management by building the view underscoring the ITIL Capacity Management book (view by the
business, by services offered or by the resources utilized).

Lastly, in this section I provide a comparison of the three primary reference models - ITIL, CobIT and
CMMI. The reader selects which of these three models to employ as the base reference and I provide
an assessment of how that reference sources maps to the other (and, where useful to additional
frameworks).

What's in this Section

Frameworks Reviewed !! Multiple View Model Compare Models -->
                          

IT Service Management Models

A framework is a basic outline - or frame -- which can be used to describe systems, activities, etc for
heuristic purposes.

"The purpose of the framework is to provide a basic structure which

supports the organization, access, integration, interpretation, development,
management, and changing of a set of architectural representations of the
organizations information systems. Such objects or descriptions of
 architectural representations are usually referred to as Artifacts.

The framework, then, can contain global plans as well as technical details,
lists and charts as well as natural language statements. Any appropriate
approach, standard, role, method, technique, or tool may be placed in it. In
fact, the framework can be viewed as a tool to organize any form of meta-
data for the enterprise.

Zachman Framework, Information Systems Architecture - Isa

The outline represents a particular viewpoint of how the systems under study are (AS-IS), or can be
(TO-BE) organized. The basic idea is that such systems can be thought of as operating or behaving
as a number of interrelated processes. To study and understand systems, one constructs ’process
models’ according to particular frameworks and using particular modeling techniques. A framework is
valuable because it provides an organizing structure for the process model as well as a standard
syntax and lexicon.

CIOs and the IT managers that report to them have all been in need of a
clear picture that depicts the IT processes required to deliver quality IT
services in support of their emerging e-services. Without a clear picture, IT
organizations will continue to struggle as they try to understand and
determine:

 The current state of IT with regard to process (the "as is")

 The desired future state of IT (the "to be")
 The gaps between the current and future states of IT
 The steps needed to bridge those gaps

Therefore, the need for a concise picture - one that reflects an enterprise
service management capability - is very real for most IT organizations and
critical to their success.

The HP IT Service Management Reference Model, White Paper, Version 2, January 2000

By implementing a well-known, proven framework such as ITIL your

company will undoubtedly experience a number of key benefits.

Firstly, why should you reinvent the wheel? In today's highly competitive IT
and business industries, time is a precious commodity. Therefore, why spend
all of the time and effort to develop and framework based on limited
experience when international developed standards such as ITIL already
exists.

Model frameworks also provide an excellent structure that companies can

follow. Essentially, employees can work towards the same goals, guided and
supported by a definite structure.

Indeed, standards have been developed over time and accessed by hundreds
of people and organizations all over the world. The cumulative years of
experience reflected in, for example, the ITIL model can not be matched b a
single organization's efforts.

Lastly, standards enable knowledge sharing. By following it, people can

share ideas between organizations, web sites, magazine, books and so forth.
Proponents of company-specific ad hoc approaches do not have this luxury.
 ITSMWatch July 12, 2004, By Wilhelm Hamman

I nformation  T echnology  S M
ervice  anagement (ITSM) is a generic term to describe the
basic management and operation of IT services on behalf of an enterprise. While each business may
deviate in terms of kinds of goods and services delivered there is a high degree of similarity in the
types of IT processes and tools and approaches employed. This conformity provides impetus for the
search for "best practices" in IT management. By using the lessons learned from other organizations,
an enterprise can avoid making many of the mistakes and mis-directions inherent in gaining needed
knowledge and experience.

Basic Management Functions

Most models in use within IT are derived from basic management functions widely accepted as
encompassing a well-run organization. The traditional formula for effective systems management of
any system, process, or activity consists of five sequential and iterative phases:

1. Setting Objectives
2. Planning
3. Execution
4. Measurement
5. Control

The ITIL disciplines can be organized according to this outline.

Phase Discipline Description

Setting Objectives Service level management Identify, negotiate, and agree to services to be provided,
quality measurement and IT performance targets to be
provided to users.

Planning Application & System Design Plan and design IT infrastructure to meet Service levels
committed to user.

Capacity Planning Plan for systems growth requirements

Configuration Management Create and maintain systems configuration information

Asset management Create and maintain asset inventory; track and monitor
such use of assets

Execution Incident Management Detect, record, resolve problems

Backup and recovery Design alternative systems and resources to immediately

restore IT services when problems occur.
 Measurement Performance Management Monitor system performance data; tune system for
optimal achievement of service levels committed to
users.

Control Change Management Control all changes to the system to ensure that change
does not degrade system performance

Security Management Control and administer access to the system to minimize

threats to system integrity

Availability Management Monitor and control system resources and IT operation

to maintain system availability

Problem Management Monitor and control system Known Errors and

proactively remove them from the environment

Financial Management Monitor and control system IT expenditures

Source: High Availability", Design, Techniques and Processes, Floyd Pidad, Michael Hawkins, Enterprise
Computing Series, Prentice-Hall, 2001

Utility Model of Computing

Many authors and technology futurists contend that IT technology is inexorably moving in
the direction of securing services and in this mileau a utility model, similar to the provision
of electricity, will likewise apply to the provision of IT services. From the perspective of
delivery and consumption, utilities demonstrate certain characteristics:

 Relationships are defined by service level agreements

 The delivery mechanism is hidden from the consumer
 They are provisioned dynamically
 They are charged on a usage basis
 They are typically delivered through standard interfaces

Utility or cloud computing is all about the ability of providers to reduce parts and labour costs, and to
do this they must:

 Work the economies of scale that the Internet and associated Web technology advances
have enabled via shared service provision
 Support SLAs that operate on usage metrics delivered at a lower level of granularity than was
possible before the introduction of IP networks and "net native" software
 And then, introduce transparent billing and pricing to enable clients to more efficiently manage
consumption of the service being delivered

In general, utility customers do not own any of the physical infrastructure. By avoiding capital
expenditure by renting usage from a third-party provider, they consume resources as a service and
pay only for resources that they use. Sharing "perishable and intangible" computing power among
multiple tenants can improve utilization rates, as servers are not unnecessarily left idle (which can
reduce costs significantly while increasing the speed of application development). A side-effect of this
approach is that overall computer usage rises dramatically, as customers do not have to engineer for
peak load limits. In addition, "increased high-speed bandwidth" makes it possible to receive the same
response times from centralized infrastructure at other sitesR.

A Utility Model will usually present some combination of five primary functions based upon a parrallel
with electric lighting:

Connection: Turning the lights on

 Service Requests - password resets, equipment MACs

 Project Management - support for IT projects
 Release Management - product test and build services and release to production

Availability: Keeping the lights on

 Technology Toolset provisioning for new employees

 Operations - Keeping systems in peak performance
 Application maintenance and database management
 Security Services - Ensuring integrity of information and systems

Restoration - Turning the lights back on when they go off

 Incident Management - password resets, equipment MACs

 Change Management - introducing changes

Capacity: lighting - bright, anywhere, anytime

 Capacity Planning - Ensuring enough capacity to meet current and future requirements
including regular workstation and server refresh, participation in bandwidth planning
 Usage Monitoring and Forecasting
 Mobile Services - extending capacity by increasing the reach of service or usage

Efficiency - Lowering the costs of lighting

 Configuration Management - maintaining inventory of assets and their interconnection

 Architectural planning - improving the overall design of systems

WikipediaR offers the following characteristics of Cloud computing:

 Agility improves with users able to rapidly and inexpensively re-provision technological

infrastructure resources.
 Cost is claimed to be greatly reduced and capital expenditure is converted to operational
expenditure. This ostensibly lowers barriers to entry, as infrastructure is typically provided by
a third-party and does not need to be purchased for one-time or infrequent intensive
computing tasks. Pricing on a utility computing basis is fine-grained with usage-based options
and fewer IT skills are required for implementation (in-house).
 Device and location independence enable users to access systems using a web browser
regardless of their location or what device they are using (e.g., PC, mobile). As infrastructure
is off-site (typically provided by a third-party) and accessed via the Internet, users can
connect from anywhere.
  Multi-tenancy enables sharing of resources and costs across a large pool of users thus
allowing for:
o Centralization of infrastructure in locations with lower costs (such as real estate,
electricity, etc.)
o Peak-load capacity increases (users need not engineer for highest possible load-
levels)
o Utilization and efficiency improvements for systems that are often only 10–20%
utilized.
 Reliability improves through the use of multiple redundant sites, which makes cloud
computing suitable for business continuity and disaster recovery.[36] Nonetheless, many
major cloud computing services have suffered outages, and IT and business managers can at
times do little when they are affected.
 Scalability via dynamic ("on-demand") provisioning of resources on a fine-grained, self-
service basis near real-time, without users having to engineer for peak loads. Performance is
monitored, and consistent and loosely-coupled architectures are constructed using web
services as the system interface.
 Security typically improves due to centralization of data[39], increased security-focused
resources, etc., but concerns can persist about loss of control over certain sensitive data, and
the lack of security for stored kernels[. Security is often as good as or better than under
traditional systems, in part because providers are able to devote resources to solving security
issues that many customers cannot afford. Providers typically log accesses, but accessing the
audit logs themselves can be difficult or impossible. Furthermore, the complexity of security is
greatly increased when data is distributed over a wider area and / or number of devices.
 Sustainability comes about through improved resource utilization, more efficient systems,
and carbon neutrality. Nonetheless, computers and associated infrastructure are major
consumers of energy.

The ITIL Reference Framework

I T I L
ITIL - the  nformation  echnology  nfrastructure  ibrary is a set of best practices for Service
Management originally advanced by the CCTA (now absorbed into the Office of Government
Commerce - OGC) in Great Britain.

The concept of a formal approach to the management of operational IT

services was developed during the mid-1980’s in response to growing
concerns about the value for money delivered by IT Departments.

At that time, there had been considerable research into software

development, resulting in a number of development methodologies, some
proprietary and others in the public domain. One common deficiency in the
methodologies that were available was the lack of any detailed guidance on
the operational stage of an IT service (sometimes called the support &
maintenance phase).

Michael Davies, IT Service Management: An Overview, ISSUE 3, 11 September 2002, p.4

The initiation of the concept was fraught with problems of the order in which the publications would be
made available and an absence of overall integration amongst, and a framework for, the publications.
The impact of Service Level Management being one of the first areas of release is poignantly
presented in the following commentary.
 Why then did OGC place so much emphasis on the SLA? They didn’t. The
problem was that ITIL was a huge project costing in excess of five million
pounds sterling, involving only a small group of people working to pull
together best practices from many sources. The original intention was to
publish books in related sets. A lack of clear overall vision and
underpinning process models led to volumes being published as and when
they completed the quality assurance process. It took four years for all of the
original books to be published, by which time the inconsistencies were
apparent and a market established that would give rise to ‘the cult of the
SLA’.

Back to the Future, Pink Elephant - June 2003

When the CCTA published the library, other organizations quickly saw its' benefits and began to adopt
facets of the approach. ITIL has continued to evolve and mature as the CCTA and, more recently, the
UK Office of Government Commerce (OGC) have striven to maintain its' continued relevance through
research and periodic updating of the framework. The OGC once described ITIL as the world's "de
facto standard for service management" because of its widespread use — especially in European
countries. Finally, the ITIL books were published in compendiums to emphasize the importance of
taking a holistic look at an area rather than focusing on a single process. The new library has several
books: Service Support, Service Delivery, Planning To Implement Service Management, Applications
Management, Security, ICT Infrastructure Management and last, but definitely not least, The Business
Perspective. These titles represent subjects that were included in the original library. Published in this
manner however, they should get the recognition they deserve. After all, service management and
ITIL is about more than just SLAs.

ITIL is an acronym - Information Technology Infrastructure Library. Infrastructure denotes a logical

means of dividing the overall IT environment into components of related functionality. So ITIL is
divided into logical segments of the environment. Secondly, Library is a depository built to contain
books and other materials for reading and study. So the division describes procedures and guidelines
for specialized segments of the IT environment. So, ITIL consists of a series of documents that are
used to help implement a framework for IT Service Management (ITSM). This framework defines how
Service Management is applied within specific organizations.

reference model for structuring the ITIL publication set is presented in the publication "Planning to
Implement ITIL". The diagram is reproduced here. As an action framework this depiction is overly
simplistic. While it acknowledges the central placement of service management and surrounds the
approach with anciliary services, as an organizing concept it's use is rudimentary. ITIL’s best-practice
approach is outlined in a series of seven books, includingR:

 Business Perspective - aims to familiarize management with the underlying components

and architecture design of the Information and Communications Technology (ICT)
infrastructure necessary to support their business processes and gain an understanding of
Service Management standards and better practice R.
 Planning to Implement Service Management - helps Service Providers plan their
implementation of Service Management best practice while at the same time helping the
business to talk on level terms with the Service Provider.
 Service Delivery - focuses on delivering IT services to IT customers through agreed-upon
service levels
 Service Support - defines how to maintain the delivery of services by providing user support,
managing changes and managing releases within the infrastructure
 ICT Infrastructure Management encompasses IT planning and architecture as well as day-
to-day infrastructure operations
 Security Management - explains how to best manage defined levels of infrastructure security
 Application Management - outlines the entire application life cycle, from requirements to end
of life
 Planning to Implement Service Management - helps organizations under-stand, assess
and implement service management within an IT organization

The following depiection is taken from the ITIL Business perspective document. While this is the
closest thing yet to an ITIL process description it has two curious ommissions - Configuration
Management and Incident/problem management are missing from the description.
These ommissions are resolved in the following two, more granular presentations. In the diagram
below, the ITIL primary service management functions are grouped into the division encompassed by
this middle box:
Service Support

 Service Desk -
services
associated
with registering a
service request
with an agent
(either live or an
application
interface)
 Incident
Management -
processes
associated with
the resolution of a
reported fault,
either by a person
or through an
automated alert,
in the
infrastructure.
Since many of the
procedures
associated with
initiating a
Service Request
are similar to
processes
encompassed by
either Service
Desk or Incident
Management,
ITIL does not
distinguish these
processes.
However, many
organizations do
delineate separate
processes.
 Change
Management -
processes
associated with
modifying the
known and
trusted state of the
infrastructure in a
controlled
manner,
 Configuration
Management -
processes
associated with
recording,
updating and
using information
describing the
 components of
the infrastructure,
 Problem
Management -
processes
associated with
tracking the
Known Errors
existing in the
infrastructure and
attending to their
removal,
 Release
Management -
processes
associated with
moving hardware
and software
components from
development to
production status

This model highlights

the central role of
information describing
the state of the
infrastructure -
the Configuration
Management Database
(CMDB). Each of the
five management
processes reference this
data source within their
process descriptions
and all the processes
are driven by
customers, client
and/or user groups.
There is nothing
mysterious about this.
Indeed, these (and the
service delivery
processes) are derived
from basic
management functions.
Service Delivery

 Availability
Management -
processes
associated with
keeping keeping
the infrastructure
operational
including the
speedy restoration
of services in the
event of failure,
 Capacity
Management -
processes
associated with
ensuring that
users of IT
resources,
services and
businesses have
sufficient (but not
costly excessive)
capacity to
perform their
roles,
 Service
Continuity -
processes
designed to keep
business
operations going
in the event of a
severe and
prolonged outage
and procedures to
restore business
capacities in the
event of failure
 Service Level
Management -
services designed
to ensure that the
level of service
offering conforms
to business
directions.
 Financial
Management -
services designed
to monitor and
apportion the
costs associated
with maintaining
the IT
infrastructure.
A recent article available at ISAAC idenitfied two principal concepts as underscoring ITIL thinkingR:

 Holistic service management — IT service managers:

o Assure the consideration of functional and non-functional requirements
o Ensure that services are appropriately tested before live operational use
o Assess the possible risks and impact on existing infrastructure caused by new or
modified systems
o Define future service requirements
 Customer orientation — IT services are provided at a level of quality that allows permanent
reliance on them. To assure this quality, responsibility is assigned to individuals who:
o Consult the users and help them use the services in an optimal manner
o Collect and forward opinions and recommendations of users
o Resolve incidents
o Monitor the performance of the services delivered
o Manage change

View ITIL Refresh report for thinking on next version of ITIL, April, 2005

BS15000 Standard in IT Service ManagementR

The BS15000 IT Service Management standard has two modules - BS15000-1: 2002 and BS15000-2:
2003. Part one is the specification for service management and defines what is required of an
organization when delivering high quality, managed services to customers.

B.1.1. Management System

As a management system, BS 1500011 not only specifies the requirements for service management
processes, but it also specifies the requirements for management and implementation of service
management capabilities within the context of business and customer requirements. Ownership and
responsibility of the management system, and of each process, lies with senior-level management,
who ensure that best practices in service management are adopted and sustained through the
establishment of suitable policies, plans and objectives, provision of adequate resources, training and
development, management of risks, and measurement, review, and control. For effective planning,
operation and control of service management, BS 15000 requires documentation of service-
management policies, plans, procedures, processes, agreements, and records [BSI 2002].

B.1.2. Planning and Implementation

For planning and implementing service management, the standard requires the Plan-Do-Check-Act
(PDCA) methodology in continuous loop.

 Plan service management (Plan)

 Implement service management and provide the services (Do)
 Monitoring, measuring and reviewing (Check)
 Continuous improvement (Act)

While there is a focus on core service management processes, BS 15000 requires due diligence in
planning and implementation using the PDCA methodology. This ensures ongoing control, greater
efficiency, and opportunities for continuous improvement through coordinated integration and
implementation of the service management processes [BSI 2002]. Organizations undergoing an audit
are expected to show evidence of meeting these requirements for planning and implementing service
management.

The standard also has requirements for planning and implementing new services and changes to
existing services. Organizations are required to take into consideration cost as well as organizational,
technical, and commercial impacts that could result from the delivery and management of new
services or changes. Planning is required to cover roles and responsibilities, changes to existing
services, contracts and agreements, necessary skills and training, processes, methods and tools,
budgets, schedules, acceptance criteria, and expected outcomes from the new or changed services.
A post-implementation review is required to compare and report actual outcomes against
expectations.

B.1.3. Service Management Processes

Part 1 of the standard (BS 15000-1:2002) specifies the required standard that an organization’s
service management processes should meet to manage and deliver IT services in conformance with
the best practices of the BS 15000 series. BS 15000 requires management commitment in the form of
process ownership.

For each service management process shown below, the standard specifies the objectives and
controls that need to be implemented as part of an integrated approach to service management. Click
on the function for a description of its' objectives.

BS 15000 requires that the interfaces between processes are clearly defined, are well-understood,
coordinated, integrated, and suitably documented [BSI 2002]. For many organizations process
interfaces map onto organizational interfaces, a feature that can lead to the incorrect assumption that
service management best practices require each process to be a separate organizational group. In
reality the BS 15000 series makes no requirement for specific organizational form.

For each service management process shown above, the standard specifies the objectives and
controls that need to be implemented as part of an integrated approach to service management.

BS 15000 requires that the interfaces between processes are clearly defined, are well-understood,
coordinated, integrated, and suitably documentedR.
Proactive Variation on ITIL
Proactive, an Australian IT
service management
company, also distinguishes
service delivery and service
management sub-sets of
ITIL. The Service Delivery
functions are closely related
to the annual planning cycle
and ongoing review during
the year and therefore form a
logical grouping. If high
quality IT services are to be
provided, then it is essential
to know the criteria by which
this quality will be judged.
Service Level Management is
of great value because the
creation of service level
agreements (SLAs) provides
a mechanism for
documenting customer
requirements and defining
performance targets. Once
agreements have been
negotiated, ongoing
monitoring is needed to
ensure that all parties to the
agreements remain satisfied.

The Service Support

elements are integral to
service delivery. They are
concerned with day to day
operations, although each
management areas can also
have a longer term view
when dealing with business-
driven considerations rather
than IT-initiated. The British
Standards Institution (BSI)
describes Service Support as
providing a number of related
types of process:

 The control
processes of (Asset
&) Configuration
Management and
Change
Management
 The release process
of Release
Management
 The resolution
 processes of Incident
Management and
Problem
Management.

In addition, Service Support

includes the Service Desk
function which in many
organizations owns the
Incident Management
process.

Art of Service Framework

This framework is based upon a distinction between 'Customer' and 'User' so as to differentiate
between those people (generally senior managers) who commission, pay for and own the IT Services
(the Customers) and those people who use the services on a day-to-day basis (the Users).

The semantics are less important than the reason for differentiation. The primary point of contact for
individuals using services is (or should be) a Service Desk (or in less sophisticated environments, a
basic help desk). Therefore the user population is most at risk from an inadequate service support
function.

Customers of service providers increasingly rely upon contracts to define the relationship of the
service provider to the business (even in the case of in-house service provision) and use the contracts
to formalize areas of performance that are frequently underpinned by Service Level Agreements
(SLAs). The day-to-day impact of service provision (unless catastrophic), is largely ignored in favour
of prearranged meetings to discuss deviations from contractual issues. Therefore the prime focus for
customers is the Service Manager, who controls the Service Level Agreement and who is involved in
contractual issues.
It is therefore important to distinguish the different, but related, needs of users and customers in the
provision of services. Certainly, their goals may be at odds and need to be balanced; for example
users may demand high availability whereas customers look for value for money at different levels of
availability. There are information flows that must be maintained and key process elements that must
be defined for use by both parties; possibly the best example is configuration management. If
configuration management is defined only from the perspective of the user, then the cost of
introduction is not likely to be the principal issue (100% availability, predicated on extensive
knowledge about all configuration items, regardless of cost is more likely!). On the other hand if
configuration management is designed solely from the perspective of the customer, then service
availability will not be considered key, as the customer may not have the goal face knowledge to
understand the need to back-up fragile service elements, (which would require extensive knowledge
about all configuration items) or perhaps be unwilling to increase costs by doing so.

A Simple Model of IT Management

Reid Shay, in a recent publicationR, develops an IT management model based upon distinguishing
business and IT "space". He then divides the IT space into "Tool" and "Management" categories.

SLM relationship
Day-to-day business functions comprise many individual business processes within the business
space. These business processes make use of IT Tools and, as such need to be decomposed into
distinct processes which will map to the appropriate tool sets used for their administration...

The reason for breaking down the operations into individual processes is to
properly track the importance of specific matching IT tools that manage or
provide for that process.

A Simple Model of IT Management, p. 74

Processes and Tool Relationship
These relationships are many to many. Most tools have the capability to handle multiple business
processes. In order to understand the importance of an enabling tool, and thereby make an intelligent
decision on service levels, the relationship with key business processes must be understood.

Instrumentation
In order to properly manage the toolsets, data on the health and status of the tools needs to be
maintained along with its' potential impact on business operations from various kinds of service
deterioration:

 Trouble Ticket: The Help desk is the most common source for gathering business effects. A
ticket is created to fulfill a request for service - either itsd' initiation or recovery.
 Agents and Probes: IT Tool Data is system, storage, application, or network based. Agents
are . Probes are specific, stand-alone devices (hardware or software) that gather information
about a target environment.
 Business Impact data: creates data on the impact of each tool to the effected business
processes. The data can be gathered automatically or manually.
Management Data
Once the business, IT tool and business impact datasets are combined management data is created.
It is this management data which provides the basis for the management of the overall IT
infrastructure -

This combined management data is the basis used to manage the IT tool
environment.

A Simple Model of IT Management, p. 81

Management Information
Management data is massaged to become Management Information. This information takes several
forms:

 Event Information: The important information to track for an event is the time, source, object
and any available detailed description.
 Device relationship: tells how things are connected. The logical connection among devices
is often critical to solving problems.
 Prioritization Information: Previously collected information on the impact of IT tools on
business processes is combined with the relative importance of different business processes
(including time of day, week, month, variations on interactions, etc) to create a prioirity for IT
Management action.
Management Analysis
This is the step where all of the management information if consolidated and analyzed for appropriate
actioning. The two primary types of actioning are:

1. Problem Analysis: The basic problem resolution process is comprised of:

o recognizing something is wrong
o identifying what is wrong
o isolating what is causing the problem
o determining what will fix the problem
o implementing the fix
o testing and verifying the result
2. Change Analysis: managing changes is made up of a number of overlapping steps:
 o plan
o design
o install
o configure
o test
o adjust for impact

The analysis step represents the culmination of the management process...

In an ideal world, all of the preceding steps in the management process have
one by one provided the necessary information to allow for a straight-
forward analysis. <

A Simple Model of IT Management, p. 87

Once the analysis is complete the issue is resolved. Actions should include items that indicate that the
desired results have been achieved.

Hewlett Packard Reference Model

Hewlett-Packard has developed their framework over a decade. The latest HP reference model is
described in its’ White Paper - The HP IT Service Management Reference Model. Their rendition
recognizes four primary functions interacting in a continuous loop to plan, design, implement and
operate an IT service. Supporting this cycle are quality assurance functions represented by Service
Level, Configuration and Change Management. HP states "the model provides a coherent
representation of IT processes and a common language, making it useful in initiating a meaningful
dialogue between all parties involved in IT process requirements and solutions."
The HP ITSM Reference Model's primary focus is on distributed environments. The model is focused
on datacenters ( a primary HP business), but also addresses non-integration issues that are prevalent
in existing, mainframe-centric process models.

The five primary components of the model areR:

Business-IT Alignment
The strategic processes contained in this quandrant involve aligning IT strategy with business goals
and developing a service portfolio that provides excellent business value.

 IT business assessment - examines organizational markets for IT services, determines

business needs, and then defines the business requirements that drive IT strategy and
contribute to the corporate value chain.N.
 IT strategy & architecture planning - evaluates the overall IT value proposition and, based
on the findings of the business assessment, generates an IT strategy and IT architecture
plan.
 Customer management - facilitates partnership between the IT service provider (including
any outsourced services) and company LOB (lines-of-business) customers.
 Service planning - building on the outcomes of the IT strategy and architecture planning
process, service planning seeks to ensure that new services are properly planned for and that
the IT organization understands the risks associated with their delivery. Service planning also
 involves finding ways to maximize the ROI of new and existing services by leveraging them
across multiple business units or customers.
Service Design and Management
Service design and management processes provide the detailed service information needed to design
new services, manage the availability and quality of those services, and balance service quality with
costs.

 Security management - defines, tracks, and controls the security of corporate information
and servicesN. This process accounts for the implementation, control, and maintenance of the
total security infrastructure. All services must adhere to strict corporate standards of
information security.
 Continuity management - addresses the IT organization's ability to continue providing
predetermined service levels to customers following a serious interruption to the businesN.
 Availability management - defines, tracks, and controls customer access to servicesN.
 Capacity management - defines, tracks, and controls service capacities to confirm that
service workloads are ready to meet agreed-upon performance levelsN.
 Financial management - determines the cost of providing services and to recover these
costs via charge allocation structuresN.
Service Development and Deployment
Service development and deployment processes allow you to build and test services and related
infrastructure components, such as procedures, tools, hardware staging, software installation,
application development, and training plans, according to service design specifications.

After a service and its components have been successfully built and tested, the service is deployed
and integrated into a production environment, where it is tested again prior to final project signoff and
release. These processes reduce service activation risks and minimize implementation costs.

 Service build & test - after a service specification is completed, the service build and test
process develops and validates a functional version of a component, service function, or end-
to-end service. As part of this process, the IT organization acquires or builds the necessary
components, service functions (such as backup capability or Web functionality) and even end-
to-end service solutions (such as SAP Financials). The process also enables you to test for
adherence to security policies and guidelines as well as documenting instructions for
replication and implementation of a production copy. Once assembled, the component,
function, or end-to-end service is thoroughly tested. Service build and test interacts
extensively with change management, configuration management, and release to production,
as well as other processes in the model.
 Release to production - creates one or more production copies of a new or updated
component, service function, or end-to-end service for a specific customer, based on a
detailed production plan known as a master blueprint.
Service Operations
The processes identified under service operations work together to monitor, maintain, improve, and
report on the IT services. These processes provide command and control capabilities, as well as
continuous service improvement and support for the IT environment. They also help the organization
maintain customer satisfaction by managing day-to-day IT customer service requests and confirming
that service quality meets agreed-upon levels.

 Operations management - manages and performs the normal, day-to-day processing

activities required for service delivery in accordance with agreed-upon service levelsN.
 Problem management - proactive focus on reducing the number of incidents in the
production environment by addressing the root causes of closed incidents. Its activities,
including ongoing trend analysis and error control, help ensure that the IT organization
implements long-term solutionsN.
  Incident & service request management - timely restoration of service availability,
minimizing service disruptions, and responding to customer needs. Reactive in nature, its
activities focus on handling incidents in the infrastructure or those reported by users via
efficient first-, second-, and third-level support service, as well as responding to service
requests. A help desk that uses this process does more than simply handle service-related
incidents - it also deals with requests for information and other types of administrative
assistance. This process interacts frequently with change management and configuration
management.
Service Delivery Assurance
The service delivery assurance process group resides in the center of the HP ITSM Reference Model
because all other process groups revolve around this central hubN.

 Service-level management - defines, negotiates, monitors, reports, and controls customer-

specific service levels within predefined standard service parameters. With a detailed service
specification, the service-level management process seeks to determine measurable,
attainable service-level objectives for potential customers - and enables organization
commitment to meaningful SLAs. Both service planning and service-level management
processes are dependent on the results of and interactions with other related IT processes.
 Change management - ensures that the IT organization uses standard methods and
procedures for handling all production environment changes in order to minimize the impact
of change-related problems on service quality. This process logs all significant changes to the
enterprise environment, coordinates change-related work orders, prioritizes change requests,
authorizes production changes, schedules resources, and assesses the risk and impact of all
changes to the IT environment.
 Configuration management - centrally registers, tracks, and reports on each IT
infrastructure component - known as configuration items (CI) - under configuration control.
The process involves identifying CI attributes, CI status, and their relationships. This data is
stored in a logical entity known as the Configuration Management Database (CMDB). Any
other IT process that affects the infrastructure must interact with this processN.

Visit HP Reference Model Website

View HP-COBIT mapping diagramR

Microsoft Operations Framework

Microsoft has its’ version of ITIL which it covers under its’ Microsoft Operating Framework (MOF).

"In contrast to the descriptive ITIL approach, the MOF approach is

prescriptive, promoting continuous improvement of IT service management
capabilities throughout the IT life cycle. IT organizations are ideally in a
constant state of improvement. To assist in achieving this ongoing
development, MOF provides prescriptive, process-driven tools and best
practices through a growing number of specific service management
functions. By combining MOF with Microsoft Solutions Framework
(MSF),1 organizations can implement an end-to-end framework to manage
their infrastructures—from planning and building through operations and
support."

Microsoft Technet web site


Microsoft presents a brief comparison of MOF to ITIL:
Topic ITIL
Planning to  Business continuity
Implement management, partnerships and
Service outsourcing, surviving change,
Management and transformation of business
practices through radical
change
 Looks at IT in business terms
as a means of improving
services and reducing costs
 Includes cross-organizational
integration with IT services and
decision-making governance
Business  Planning the steps required to
Perspective implement or improve IT
service provision
Service  The management of services to
Management meet the customer’s
requirements
 Includes performance
management, service
acquisition management, and
service provision management
 Supporting Quadrant - Resolve incident
service requests and other end-user problems in
a timely and effective way. Includes the SMFs
required to identify, assign, diagnose, track, and
resolve incidents, problems, and service
requests in SLAs.
 Changing Quadrant - Effectively and quickly
introduce approved changes into the IT
environment with minimal disruption of service.
Includes the SMFs required to identify, review,
approve, and incorporate change into a managed
IT environment.
 Operating Quadrant - Execute day-to-day
operations tasks, both manual and automated, in
a highly predictable and reliable way. Includes
the SMFs that help an IT organization achieve
and maintain its service level commitments.
 Optimizing Quadrant - Drive changes that
optimize cost, performance, capacity, and
availability while delivering IT services.
Includes the SMFs that help an IT organization
review outages and incidents, examine cost
structures, assess staff performance, conduct
systems availability and performance analysis,
and forecast system capacity needs.
MOF
 Continuous Improvement Roadmap (CIR)
applies business perspectives to IT as a strategic
asset
 Helps companies assess current service
management and form a Service Improvement
Program (SIP) based on business value
 Changing Quadrant highlights best practices for
planning and managing change
 MOF Team Model defines roles and
responsibilities for a transparent decision-
making process
 Changing Quadrant addresses implementation
planning
 MSF provides project implementation guidance
 Applies universal service management themes to
the specific operational needs of the Microsoft
platform
 Embodies the service management framework
for Microsoft products
 Divides service management into four functional
quadrants and 21 service management functions
  Also contains the topic areas of
Service Support and Service
Delivery
Service  Service desk, incident
Support management, problem
management, configuration
management, change
management, release
management, and the necessary
interactions between these and
other core IT service
management disciplines
 Updates best practice to reflect
recent changes in technology
and business practices
Service  Service level management,
Delivery financial management for IT
services, IT service continuity
management, availability
management, contingency
planning, and capacity
management
Security  The process of security
Management management within IT service
management
 Focuses on implementing
security requirements identified
in the IT service level
agreement (SLA)
 Does not address business
aspects of security policy
ICT  Network service management,
Infrastructure operations management,
Management management of local
processors, computer
installation and acceptance, and
systems management
Applications  The software development life
Management cycle
 Provides details on business
change, emphasizing clear
requirement definitions and
spanning the entire service life cycle
 Supporting Quadrant addresses service support
with service desk, incident management, and
problem management guidance
 Related service management functions
encompass those listed in the ITIL definition of
service support
 Addressed within the MOF Process Model and
in the Optimizing Quadrant
 Adds security management, workforce
management, and infrastructure engineering
 Expands service delivery into the Operating
Quadrant to include guidance for system
administration, security administration, service
monitoring and control, directory services
administration, network administration, storage
management, and job scheduling
 Optimizing Quadrant addresses the areas
defined in ITIL Security Management
 Expands security administration into the
Operating Quadrant to address issues
surrounding data access, data management and
integrity, and user permissions
 Optimizing Quadrant incorporates infrastructure
engineering guidance
 Windows Server System Reference Architecture
(WSSRA) provides architectural guidance and
blueprints, addresses dependencies between
infrastructure components, and enables systems
architects to design for operations
 Microsoft provides management and
infrastructure solutions to deploy Microsoft
products in adherence to WSSRA, MSF, and
MOF principles
 MSF includes project life cycle guidance on
software development and deployment projects
 Changing Quadrant provides guidance through
the change management, configuration
management, and release management functions
 implementation to meet
business needs

Service Management Functions

Each of the SMFs
within a particular
quadrant shares a
common service
mission or goal.
Many SMFs are
based on ITIL. The
notable exceptions
are workforce
management (in the
Optimizing Quadrant)
and all SMFs in the
Operating Quadrant,
which ITIL does not
address.

These additional
elements
demonstrate that, at
least from a
framework
perspective, MOF
presents a more
useful depiction or
model of IT service
operations that does
ITIL:

 it contains
additional
elements which
present a more
complete
rendering of the
IT service
environment
 the quadrant
concept reflect a
basic
acknowledgeme
nt of
organizaitonal
maturity with the
"optimizing
processes"
encompassing
ITIL Service
delivery
components -
clearly requiring
relatively mature
organizations to
 be considered -
and requiring
propr experience
with "changing"
and "operating"
SMFs.
 the collection
and definition as
milestones
and/or reviews
represents a
refinement in the
treatment of
these
processes/functi
on within ITIL.
 MOF presents a
better
rationalization of
sub-processes
and roles in
related process
areas such as
(1) Change and
Release, (2)
Availability,
Service
Continuity and
Service Level
Management
and (3) Financial
(budgeting) and
Capacity

However, the heavy

relience in MOF SMF
descriptions is often
at the expense of
clarity of concepts.
These process-
oriented descriptions
will often make
reference to key
concepts which are
not explained as well
as they are in ITIL
(eg. DSL, Capacity
Plan, etc). They are
often referenced (and
defined in a Definition
section) but their
importance and
usage is all too often
left unclear.
MOF SMFs Milestones/Reviews
Quadrant/Description
Changing Quadrant  Change Management - describes a
consistent set of processes to initiate
Describes processes,
infrastructure changes, assess and
responsibilities, document their potential impacts, approve
reviews, and best their implementation, and schedule and
practices that help review their deployment.
organizations manage
 Configuration Management - a key
changes to their IT
principle in effectively managing an IT
infrastructure. Through infrastructure is to document its
classification of change components and the relationships between
types, the appropriate them. The Configuration Management
assignment of SMF provides the foundation for decision-
authorization making in the Changing Quadrant,
responsibilities, and a negotiating Service Level Agreements,
consistent change assessing IT capacity, and other critical
management and processes.
release process,  Release Management - An effective
organizations following release management process creates a
MOF best practices bridge between development or
acquisition of new services and the IT
reduce incompatible or
organization responsible for operating
conflicting changes and
them. The Release Management SMF
streamline their release
efforts. coordinates efforts to deploy services and
applications into a managed environment
Operating Quadrant  Directory Services Administration -
Provides processes and best practices for
The Microsoft
the routine management of the directory
Operations Framework systems used to locate users, files,
(MOF) Operating services, and servers. This service is
Quadrant is the crucial to effective use of a distributed
collection of processes infrastructure.
and IT functions
 Job Scheduling - handle the sequencing of
dedicated to the various batch jobs and other workloads
ongoing maintenance, (printing, database, backups, and others)
monitoring, control, for optimal use of network resources.
and protection of IT
 Network Administration - Defines and
infrastructure assets.
delivers the processes and procedures
Efficient required to operate basic network services,
implementation of including Dynamic Host Configuration
MOF best practices in Protocol, Windows Internet Name
this quadrant enables Service, and Domain Name System, on a
IT organizations to day-to-day basis.
move beyond simple  Security Administration - Deals with the
infrastructure daily, routine application of security
maintenance, such as policies and best practices to maintain a
patch management or secure operating environment.
backup-and-restore, to  Service Monitoring and Control -
proactive measures that Observing the health of the operating
help optimize for better environment is key to making rational
performance. decisions for maintenance, optimization,
risk mitigation, and proposed changes.
Service Monitoring and Control provides
best practices for monitoring and
resolving incidents and alerts in the
production environment.
 Change Initiation Review - is
the first formalized opportunity
for operations and production
stakeholders to review
proposed changes to the IT
infrastructure. Closely aligned
with the Microsoft Solutions
Framework planning activities,
this review facilitates the
alignment of proposed changes
with current IT standards and
policies
 Release Readiness Review - is
the final check given to a
developed application or
service prior to deployment. IT
stakeholders take this
opportunity to verify that the
release meets its stated
objectives, fulfills the design
criteria and requirements, and
can be safely released into the
production environment with
low risk of failure or
incompatibilities
 Operations Review - An
ongoing Operations Review
process gives IT managers the
opportunity to review service
management processes, and
their performance and
capabilities. Assessments of
various Service Operating
Level Agreements at these
reviews are used as the basis
for negotiating Service Level
Agreements with service
customers. The reviews also
provide a quality check on
operating practices, to assure
that daily activities are proper
documented in the
organization’s knowledge
management system.
 Storage Management - The most crucial
investment that an organization has in its
infrastructure is the data stored in it.
Storage Management is the set of practices
dedicated to safe, secure storage of data,
effective backup-and-restore policies, and
efficient use of storage resources to
optimize the business’s investment in
physical storage components.
 System Administration - The “glue” that
binds services together within the
operating quadrant, System
Administration is responsible for
managing a variety of services, with
varying levels of control. These include
crucial services, such as messaging,
databases, operating systems, Internet, and
telecommunications.
Supporting Quadrant  Incident Management - A critical process  Service Level Agreement
that provides organizations with the ability Review - Provides IT and the
Activities and
to first detect incidents and then to target customers it serves with the
processes that are the correct support resources in order to opportunity to examine current
performed to resolve resolve the incidents as quickly as service level commitments.
user and system- possible. Often, service requirements
generated queries, evolve over time, or new IT
 Problem Management - By implementing
issues, or problems are capabilities may allow
Problem Management processes at the
in the domain of the same time as Incident Management beneficial enhancements to a
Microsoft Operations processes, organizations can identify and service. This regular review
Framework (MOF) resolve the root causes of any significant helps IT organizations to stay
Supporting Quadrant. or recurring incidents, thus reducing the well-aligned with the business.
The Supporting likelihood of recurrence.
Quadrant contains  Service Desk - The Service Desk is the
those processes and first point of contact for the company; its
practices required to efficient and effective response to
fully support the customers’ problems and concerns can do
efficient use of an IT much to enhance the reputation of the
infrastructure. Specific company.
team role clusters from
the MOF Team Model
focus their activities on
accomplishing the
functions defined
within the quadrant.

Optimizing Quadrant  Availability Management - Availability of  SLA Review - Assesses the

IT services to users is one of the most effectiveness of IT operations
This Quadrant
critical of management functions. The in delivering services to meet
encompasses processes Availability SMF describes processes and negotiated performance
and IT functions best practices to ensure that services metrics. This review is
dedicated to planning achieve their service level agreements for complementary to the
and implementing availability. Operations Review, and
enhancements to the IT provides necessary input for
 Capacity Management - The flow of
environment, through a information through an organization is creation and management of
continuous cycle of dependent on many key performance Service Level Agreements
process improvement. factors. Capacity management works to through the Service Level
As organizations optimize capacity and improve system Management SMF.
become more mature performance through planning, sizing and  Change Initiation Review - Is
and capable in their controlling network resources as the first formalized opportunity
service management, efficiently as possible. for operations and production
Service Management  Financial Management - The Financial stakeholders to review
Functions (SMFs) in Management SMF defines IT service proposed changes to the IT
the optimizing quadrant budgeting processes, but also provides infrastructure. Closely aligned
assure tighter guidance for service charge-backs, with the Microsoft Solutions
accounting, and decommissioning. Framework planning activities,
alignment of operations
this review facilitates the
with business needs  Infrastructure Engineering - Consistent alignment of proposed changes
and longer term standards across an IT organization with current IT standards and
business strategies. improve interoperability, reduce risk of policies.
Recommendations deployment failures, and facilitate
spawned in the governance. The Infrastructure
optimizing quadrant Engineering SMF provides guidance for
generally are reflected collecting, creating, and managing
as changes in the IT standards and policies for IT services and
infrastructure, and are infrastructure.
instituted through the  IT Service Continuity Management -
change management Major IT outages occur outside the realm
process. of availability and incident management.
IT Service Continuity provides best
practices and guidance to support business
continuity through the implementation of
effective IT service recovery procedures.
 Security Management - The Security
Management SMF defines and
communicates the IT organization’s
security plans, policies, guidelines, and the
relevant regulations that mandate them. It
works in concert with Security
Administration, which implements these
policies, to secure corporate information
and assets by controlling access,
confidentiality, and authorization.
 Service Level Management - IT services
reflect a formalized commitment to
provide negotiated levels of performance.
Service Level Management provides a
structured process for business users and
IT service providers to discuss the service
levels needed and assess their current
performance.
 Workforce Management - Skilled IT
personnel are crucial to the evolution of an
efficient IT organization. Their
recruitment, training, readiness,
compensation, and retention are discussed
in this SMF.

Visit Microsoft Operation Framework web site]R

Application Development Models

Projects are the way that most new work gets delivered. Best practices suggest the use of a
structured project management methodology to guide the introduction of new systems, approaches,
processes - and 'service improvement initiatives, ITIL best practices included. The are three main
aspects to project management:

 Knowledge areas - Grouping of concepts germane to projects. The Project Management

Book of Knowledge (PMBOK) is widely recognized as the source of best practicesR.
 Project processes - Projects can be managed using a common set of project management
processes - regardless of the type of project. All projects should be defined and planned and
all projects should manage scope, risk, quality, status, etc.
 Lifecycle models - Just as there are common project management processes to manage most
projects, there are also common models that can provide guidance on how to define the
project lifecycle. These common models are valuable since they save project teams the time
associated with creating the project workplan from scratch each time.
Application development models are tailored versions of lifecycle models. The principles enunciated in
PMBOK are combined into a lifecycle model with the goal to produce quality systems on time and on
budget. A lifecycle models might be one of (or combined or derived from):
Lifecycle Description
Model
Waterfall Uses milestones as transition and
assessment points with each set of tasks
being completed before the next phase
begins.
Spiral The spiral is a risk-reduction oriented
model that breaks a software project up
into mini-projects, each addressing one or
more major risks. The model focuses on
the continual need to refine the
requirements and estimates for a project.
Modified Uses the same phases as the pure waterfall, Strengths
Waterfall but is not done on a discontinuous basis.
This enables the phases to overlap when
needed
Evolutionary Uses multiple iterations of requirements
Prototyping gathering and analysis, design and
prototype development. After each
iteration, the result is analyzed by the
customer. Their response creates the next
Comments
The waterfall works best for projects where it is
feasible to clearly delineate a fixed set of
unchanging project requirements at the start.
Fixed transition points between phases facilitate
schedule tracking and assignment of
responsibilities and accountability.
Early iterations of a project are often the
cheapest, enabling the highest risks to be
addressed at the lowest total cost, and, each
iteration of the spiral can be tailored to suit the
needs of the project. However, the many
iterations can easily result in great complication
requiring attentive and knowledgeable
management for success.
 More flexibility than the pure waterfall
model.
 If there is personnel continuity between the
phases, documentation can be substantially
reduced.
 Implementation of easy areas do not need
to wait for the hard ones.
Weaknesses
 Milestones are more ambiguous than for
the pure waterfall.
 Activities performed in parallel are subject
to miscommunication and mistaken
assumptions.
 Unforseen interdependencies can create
problems
Risk reduction spirals can be added to the top of
the waterfall to reduce risks prior to the waterfall
phases. The waterfall can be further modified
using options such as prototyping, JADs or CRC
sessions or other methods of requirements
gathering done in overlapping phases.
Strengths
 Customers can see steady progress.
 This is useful when requirements are
 level of requirements and defines the next
iteration.
Staged Although the early phases cover the
Delivery deliverables of the pure waterfall, the
design is broken into deliverables stages
for detailed design, coding, testing and
deployment.
Evolutionary Straddles evolutionary prototyping and
Delivery staged delivery.
Design-to- Like staged delivery, design-to-schedule is Strength
Schedule a staged release model. However, the
number of stages to be accomplished are
 Produces date-driven functionality,
not known at the outset of the project.
Design-to- The capability goes into a product only if it
Tools is directly supported by existing software
tools. If it isn't supported, it gets left out.
Besides architectural and functional
packages, these tools can be code and class
libraries, code generators, rapid-
development languages and any other
software tools that dramatically reduce
implementation time.
changing rapidly, when the customer is
reluctant to commit to a set of
requirements, or when no one fully
understands the application area.
Weaknesses
 It is impossible to know at the outset of the
project how long it will take.
 There is no way to know the number of
iterations that will be required.
Strength
Can put useful functionality into the hands of
customers earlier than if the product were
delivered at the end of the project.
Weakness
Doesn't work well without careful planning at
both management and technical levels.
Strength
Enables customers to refine interface while the
architectural structure is as planned.
Weakness
Doesn't work well without careful planning at
both management and technical levels.
ensuring there is a product at the critical
date.
 Covers for highly suspect estimates.
Weakness
Won't be able to predict the full range of
functionality.
Strength
When time is a constraint, may be able to
implement more total functionality than possible
when building everything "from scratch".
Weakness
 You lose a lot of control over the product.
 You may become "locked in" to a vendor.
If it is for long-term functionality, vendor
lock-in can become a weak link.
 May not be able to implement all features
desired or in the manner desired.
Off-the-Shelf Following requirements definition, Strength
analysis must be done to compare the
Available immediately and usually at far lesser
package to the business, functional and
cost.
architectural requirements.
Weakness
Will rarely satisfy all system requirements.

The initial artifacts of project management focus on defining the work and building a workplan which
will be focused on executing the project using one or more of the lifecycle models. Even if the
organization has a great project management processes in place, it will still need to select models for
the lifecycle.

System Development Lifecycle (SDLC)

The original and most common lifecycle model is the System Development Lifecycle (SDLC) The
model can take any one of the above forms waterfall, spiral, etc.

"The system development life cycle is a process, involving multiple stages,

used to convert a management need into an application system, which is
custom-developed or purchased or is a combination of both."

IS Auditing Guideline - System Development Life Cycle (SDLC), Review Document G23, ISACA
 The Systems Development Life Cycle (SDLC), was developed to better
ensure that computer systems being delivered satisfied user requirements,
and/or were being developed within estimated and established budget
and/or within specified timelines. The SDLC is a methodology to design
and implement systems in a methodical, logical and step-by-step
approach.

The SDLC for an application system often depends on the chosen

acquisition/development mode. Application systems could be
acquired/developed through various modes, including custom
development using internal resources, custom development using fully or
partly outsourced resources located onsite or offsite, vendor software
packages implemented as-is with no customisation, and, vendor software
packages customised to meet the specific requirements. At times, large
complex applications may involve a combination of these options.

An organiztions may use specific SDLC methodologies and processes,

either custom- or vendor-developed and these generally prescribe
standard processes for different modes of acquisition with the facility to
customize the process design for specific application systems. These may
be supported by appropriate tools to manage the SDLC. In such cases, the
SDLC would depend on a methodology tool. Where an application
system is developed instead of being purchased as a package, the SDLC
would depend on the development methodology used, such as waterfall
development, prototyping, rapid application development, CASE and
object-oriented development.

System Development Lifecycle Phases

Stage Description Deliverables

Preliminary the purpose of this stage is to  Information Service Request (ISR)

Investigation verify that a problem or
deficiency really exists, or to pass
judgment on the new
requirement. This phase is
typically very short, usually not
more than a day or two for a big
project, and in some instances it
can be as little as two hours!. The
end result, or deliverable, from
the Preliminary Investigation
phase is either a willingness to
proceed further, or the decision
to 'call it quits'. There are three
factors, typically called
constraints, which result in a 'go'
or 'no-go' decision:
 Information Service Request (ISR)
 Feasibility Study
 Time Accounting Number ISR
Number/Project Proposal
 Contacts List & Time Accounting Tasks
 Scope Statement / Vision Statement
 Project Definition Work Sheet
 Flow Diagram
 Logical Context Diagram
 Information Request Work Sheet
 Project Proposal Work Sheet with
Funding/Budget & Personnel Resources
included. (Automation Plan Request)
 Project Initiation Worksheet
  Technical - The project
can't be completed with the
technology currently in
existence. This constraint is
typified by Leonardo da
Vinci's inability to build a
helicopter even though he is
creditedwith designing one
in the 16th century.
Technological constraints
made the construction of the
helicopter impossible.
 Time - The project can be
completed, but not in time to
satisfy the user's
requirements. This is a
frequent reason for the
abandonment of the project
after the Preliminary
Investigation phase.
 Budgetary - The project can
be completed, and
completed on time to satisfy
the user's requirements, but
the cost is prohibitive.

Systems Sometimes called the Data  Context diagram

Analysis Gathering Phase, in this stage
the suggestion is studied,
deficiency or new requirement in
detail. Depending upon the size
of the project being undertaken,
this phase could be as short as
the Preliminary Investigation, or it
could take considerable time.
This phase should be completed
before any actual programming.
At the end of this phase,
the Requirements
Statement should be in
developmentN:
 System Flow diagram or Grid Flow diagram
 Interview Preparation Work Sheet
 Requirements Definition Document
 Business Functional Process (BFP)
Candidate List, Parking Lot list of
Assumptions and Questions
 Functional Specification
 Business Functional Process Script
 Business Functional Process Logic
Diagram
 Object Definition
 Occurrence Table
 Business Rules
 Business Process Map
 Project Schedule
 Signature of Sponsor

Systems Design Most programs are designed by  System Flow diagram

first determining the output of the
program. The reasoning here is
that if you know what the output
of the program should be, you
can determine the input needed
to produce that output more
easily. Once you know both the
 Physical diagram
 Entity Relationship Diagram
 Data Dictionary
 System Flow diagram/Specifications
 Quotes, updated Project Schedule.
 output from, and the input to the  Design Approval
program, you can then determine  Updated Physical Design
what processing needs to be
performed to convert the input to  Updated System Flows, Management
Approval
output. You will also be in a
position to consider what  Requirements Traceability Matrix
information needs to be saved,
and in what sort of file.

While doing the Output and Input

designs, more information will be
available to add to the
Requirements Statement. It is
also possible that a first screen
design will take shape and at the
end of these designs, and a
sketch will be made of what the
screen will look like.
Systems Examination and re-examination
Development of the Requirements Definition
Statement is needed to ensure
that it is being followed to the
letter. Any deviations would
usually have to be approved
either by the project leader or by
the customer. Changes are
applied to the requirements
Traceability Matrix.
The Development phase is often
split into two sections, that of
Prototyping and Production
Readiness. Prototyping is the
stage of the Development phase
that produces a pseudo-complete
application, which for all intents
and purposes appears to be fully
functional.
Developers use this stage to
demo the application to the
customer as another check that
the final software solution
answers the problem posed.
When they are given the OK from
the customer, the final version
code is written into this shell to
complete the phase.
Systems Any hardware that has been
Implementation purchased will be delivered and
installed. Software, which was
designed in the System Design
Phase, and programmed in
System development phase of
the SDLC, will be installed on any
PCs that require it. Any person
 Style Sheets, Images, Logos
 System Access Privilege Request (SAPR)
forms and Request for Development space
if Web application
 Technical Specifications, Updated
Schedule
 Updated Entity Relationship Diagram (ERD)
 Technical specifications
 Program Source Code, Database Stored
Procedures, Database Triggers, File
Folders with Code, Before/After Tests
 Testing results/Test Plan
 User's Testing Plan
 Testing Plan results/System Test Plan
 Successful Load Test Results
 forms
 User Training Plan
 Infrastructure
 Updated User Testing Plan/Test Results
 User Signature on User Acceptance
Document
 Operations Turnover Instructions, Run
Book
 Managerial Sign-off
 Implementation Plan Including Go-Live
Checklist
 Package deployment documentation
 Change Request
 Migrate Request/Developer, Verification of
program in staging
 Client signature
 that will be using the program will  Migrate Request/Developer, Verification of
also be trained during this phase program/system in staging
of the SDLC.  updated ISR/ISR Ratings
 Build Book
During the Implementation
phase, both the hardware and
the software is tested. Although
the programmer will find and fix
many problems, almost
invariably, the user will uncover
problems that the developer has
been unable to simulate.
Systems In this phase someone (usually  Support matrices
Maintenance the client, but sometimes a third  Maintenance requirements
party such as an auditor) studies
the implemented system to  Service level definitions
ensure that it actually fulfills the  Transitional requirements
Requirements Statement. Most
important, the system should
have solved the problem or
deficiency, or satisfied the desire
that was identified in the
Investigation Phase.

The Maintenance portion of this

phase deals with any changes
that need to be made to the
system. Changes are sometimes
the result of the system not
completely fulfilling its original
requirements, but they could also
be the result of customer
satisfaction. Sometimes the
customer is so happy with what
they have got that they want
more. Changes can also be
forced upon the system because
of governmental regulations,
such as changing tax laws, while
at other times changes come
about due to alterations in the
business rules of the customer.

This is the most basic SDLC process. There are many variations in the number and titling of stages.
The following two adaptations represent key "tailorings" which have particular relevence in the context
of IT service management improvement undertakings.
ITIL Application Lifecycle
The Application Lifecycle is a derivation of the
System Development Lifecycle. The
correspondence is detailed below.

SDLC - Application Lifecycle Model

Comparison
SDLC Application

Preliminary Investigation Requirements

Systems Analysis Requirements

Systems Design Design

Systems Development Build

Systems Implementation Deploy

Systems Maintenance Operate

Iterate Optimize

The Application Lifecycle shifts the continuum of

the SDLC beyond system development into the
application's operational sphere. These later
stages (Deploy, Operate and Optimize) begin to
impinge upon ITIL Service Support and Delivery
processes - most prominently, Release and
Change Management for Deployment, ICT
Infrastructure Management for Operate and
Application and Capacity Management for
Optimize.

Requirements
The phase during wherein the development team works closely with key business decision-makers to
determine organizational requirements for the application. Functionality, performance levels, and
other characteristics that the application are stated. The requirements developed in this phase serve
as a foundation for the remaining phases of the development process, and as the acceptance
criteriaN.

Considerations

 Functional requirements - the things an application is intended to do, and can be expressed
as services, tasks or functions the application is required to perform
 Non-functional requirements - used to define requirements and constraints on the IT
system and serve as a basis for early system sizing and estimates of cost, and can support
the assessment of the viability of the proposed IT system
 Usability requirements - ensure that the system meets the expectations of its Users with
regard to its ease of use
 Change cases - specify expected future application functionalityN
 Testing requirements - testing requirements against developed criteria for acceptance
In terms of CMMI this phase covers both Requirements Definition and Requirements
Management functions. The Requirements Management process takes the defined requirements and
manages them over the life of the project. One of the key tools for doing this is a
requirements traceability matrix.

Design
This phase ensures that an application is conceived with proper functionality and giving appropriate
acknowledgement to the need for management of the application. This phase takes the outputs from
the requirements phase and turns them into the specification that will be used to build the application.
A key element in this is tracking the requirements using a traceability matrix.

Considerations

 Ensure Proper Consideration for Non Functional requirements - giving non-functional

requirements a level of importance similar to that for the functional requirements, and
including them as a mandatory part of the design phaseN
 Risk-driven scheduling - Scheduling assigns higher-risk tasks a high priority and includes
risk priorities that are assigned to meet customer requirements.
 Managing trade-offs - Proper balancing of the relationship among resources, the project
schedule, and those features that need to be included in the application for the sake of quality
 Design management checklist - Testing the design against the high-level functional
requirements for the organization and any special non-functional requirements that have been
identified for the application
 Testing the requirements - Design actions need to comply with the functional requirements
 Change and Configuration Management - provide advice to the development team on how
the application can move from development/test to the live production environment

This stage is comparable to the CMMI Engineering Phase - Technical Solution.

Build
Once the design phase is completed, the application development team uses the designs to build and
test the application. This phase continues to address the non-functional aspects of the design
(responsiveness, availability, security) in order to reduce later re-work to accommodate these
considerations.

Considerations

 Coding Conventions - Standardized structure and coding style of an application (preferably

also amongst applications used by the organization) so that everyone can easily read,
understand, and manage the application development process
 Development Tools - Rather than creating all the pieces of an application from scratch,
developers can customize an existing template. They can also reuse custom components in
multiple applications by creating their own templates.
 Embedded Application Instrumentation - Incorporating the applications instrumentation
including performance reporting considerations into the drivers and executables, that is
efficient and easy to implement.
 Operability testing - As the application is built, it is tested to ensure that it meets all the
stated requirements and features that the business has requestedN
 Assemble a Build Team - The Team which will move the code from the development to the
production environment.
 Change and Configuration Management (CCM) - Provide advice to developers and the
Build Team on how to build the hooks and facilities into an application so that it conforms to
the required Change and Configuration Management standards in use
This process is covered in CMMI by the Engineering - Product Integration processN. This CMMI
function, however, would also cover part of the following Deploy process.

Additionally, this function is beginning to overlap with aspect of ITIL Service Support - Release
Management. Section 9.6.2 Designing, building and configuring a release discusses elements in this
phase - "Procedures should be planned and documented for building software Releases, reusing
standard procedures where possible".

Deploy
Once assembled the application need to be moved into the organization's production environment.
From this stage on there is overlap with Service Support functions. This occurs because the
processes are beginning to overlap with the production environment which is considered in ITIL to be
the defining line between development and operations and hence between application management
and service support processes. The following table highlights process similarities between the
Application Lifecycle and Release/Change Management.

Application Lifecycle Release/Change Management

5.5.2 Planning the deployment Release Management - 9.6.1 Release planning

5.5.3 Approving the deployment Change Management - 8.5.7 Change approval

5.5.4 Distributing applications Release Management - 9.6.6 Distribution and

installations

Considerations

 Planning the deployment - use standards and guidelines for deployment that tailored to
individual situations and organizations
 Approving the deployment - Obtaining approval from Change Management to implement
the change to the production environment.
 Distribution and installations - Considerations include packaging, deployment, flexible
software distribution targeting, deployment push functionality, pull
technologies, patching, feedback and reporting and back-out provisioning.
 Pilot deployments - A pilot deployment is a controlled test of the system-wide deployment,
using a small subset of the production system. The pilot project does not need to be a
complete test of all system functionality, but it should test enough of the system to determine
whether the chosen design will work well in the production environment.
 Deployment management checklist - The deployment of the application should be built and
tested against the high-level manageability requirements for the organization and any special
management requirements that have been identified for the application

Checklists conform to the CMMI Verification processes.

Operate
Actions which expedite ongoing operation of the application. Failure to perform a simple task, such as
monitoring the available disk space on a server, could result in the server running out of room and
causing the application to fail.

An SLA documents the clients service level expectations. Typically it cites the availability and
performance requirements of the business. Measurement of the application’s performance during its
operation provides data regarding stability and break/fix requirements, and provides management with
data on overall quality.
Considerations

 Regular maintenance activities - Preventative maintenance and the avoidance of costly

downtimeN
 Application state - restoring the application to a known and trusted stateN
 Benefits Realization - An assessment of the benefits provided by the application compared
with those that it was designed to deliverN
 Operations management checklist - operational comparison against the high-level
manageability requirements for the organization and any special management requirements
that have been identified for the application

Checklists conform to the CMMI Verification processes.

Optimize (Baseline)
The use and performance of an application should be reviewed periodically to ascertain whether it
continues to meet the' business and technical requirements of the infrastructure. The review process
can be initiated by:

 A designated review time - a fixed period of time has passed since the last review
 Application Faults - Problem Management has identified issues with the current version that
require modifications
 Business changes - business requirements are changing and the use of the current
application needs to be reviewed against these new requirements
 Infrastructure changes - the technical infrastructure that the application relies on has
changed and the application needs re-tooling

Alternatively, when an application is identified as no longer being required, the assessment would
generate a retirement proposal. This proposal should provide a road map of how the application will
be removed from live service.

Microsoft Solution Framework

The Microsoft Solutions Framework is

Microsoft's project management
framework with a view to support the
release of its' own product line. While it
originated from Microsoft's application
lifecycle model, it has evolved to combine
the principles of other process models.
They contend it may be applied across
any project type as a "phase-based,
milestone-driven, and iterative model".

MSF guidance for different project types

focuses on managing the "people and
process," as well as the technology
elements that most projects encounter.
The needs and practices of technology
teams usually evolve constantly. To this
end, the materials gathered into MSF
also change continually, expanding to the
ever-growing needs. The model follows the development of a solution from its inception to full
deployment. Each phase culminates in an externally visible milestone.

MSF interacts with Microsoft Operations Framework (MOF) to provide a transition to the operational
environment. Since so much of MOF is highly similar to ITIL this means the MSF provides a smooth
transition to ITIL best practices as well.

Envisioning Phase
This phase focuses upon the creation of a common team vision. This best ensures a common
understanding of project goals and creates a motivational platform for both the team and the
customer. Envisioning, by creating a high-level view of the project’s goals and constraints, provides a
venue for planning and helps create a more formal planning process that will take place during the
project’s planning phase.

The primary activities accomplished during envisioning are the formation of the core team and the
preparation and delivery of a vision/scope document. The documentation of the project vision and the
identification of the project scope are distinct activities; both are required for a successful project.
Vision is an unbounded view of what a solution may be. Scope identifies the part(s) of the vision can
be accomplished within the project constraints.

Risk management is a recurring process that continues throughout the project. During the envisioning
phase, the team prepares a risk document and presents the top risks along with the vision/scope
document. For more information, see the MSF Risk Management Discipline white paper.

During the envisioning phase, business requirements must be identified and analyzed. These are
refined more rigorously during the planning phase. The primary team role driving the envisioning
phase is the product management role.

The stage finishes with an approved vision/scope. At this point, the project team and the customer
have agreed on the overall direction for the project, as well as which features the solution will and will
not include, and a general timetable for delivery.

Deliverables

 Vision/Scope Document - defines a clear direction for the project team, sets expectations,
and provides the criteria for the designing and deploying the solution. There are four content
elements in the Vision/Scope Document which address the what, where, when, why, who,
and how of the project: The problem statement (or statement of objectives), vision statement,
user profiles, and solution concept.
 Risk Management Plan - ascertains the impact of the consequence by determining the
likelihood of its occurrence and the severity of the outcome relative to established project
objectives.
 Project Structure Document - defines how the project will be managed and supported, and
the administrative structure for the project team going into the Planning Phase.
 Next Phase Estimate - documents what comes next

Planning Phase
During this phase the functional specifications, design processes, work plans, cost estimates, and
schedules are all prepared for the various deliverables.

Early in the planning phase, the team analyzes and documents requirements in a matrix.
Requirements fall into four broad requirement categories:

 business
  user
 operations, and
 system (those of the solution itself).

As the team moves on to design the solution and create the functional specifications, traceability
between requirements and features needs to be maintainedN.

The design process gives the team a systematic way to work from abstract concepts down to specific
technical detail. This begins with a systematic analysis of user profiles which describe various types of
users and their job functions (operations staff are users too). Much of this is often done during the
envisioning phase. These are broken into a series of usage scenarios, where a particular type of user
is attempting to complete a type of activity, such as front desk registration in a hotel or administering
user passwords for a system administrator. Finally, each usage scenario is broken into a specific
sequence of tasks, known as use cases, which the user performs to complete that activity - often
referred to as “story-boarding.”

There are three levels in the design process: conceptual, logical, and physical designs. Each level is
completed and baselined in a staggered sequence and documented in functional specifications
describing the detail of how each feature is to look and behave and the underlying architecture and
design for the features.

The functional specification serves multiple purposes, such as:

 Instructions to developers on what to build

 Basis for estimating work.
 Agreement with customer on exactly what will be built
 Point of synchronization for the whole team.

Once the functional spec is baselined, detailed planning starts. Team leads prepare plans for the
deliverables that pertain to their role and participates in team planning sessionsN.

All plans are synchronized and presented together as the master project plan. The number and types
of subsidiary plans included in the master project plan will vary depending on the scope and type of
project.

Team members representing each role generate time estimates and schedules for deliverables. The
various schedules are then synchronized and integrated into a master project schedule. At the
culmination of the planning phase — the project plans approved milestone — customers and team
members have agreed in detail on what is to be delivered and when. At the project plans approved
milestone, the team re-assesses risk, updates priorities, and finalizes estimates for resources and
schedule.

At the project plans approved milestone, the project team and key project stakeholders agree that
interim milestones have been met, that due dates are realistic, that project roles and responsibilities
are well defined, and that mechanisms are in place for addressing areas of project risk. The functional
specifications, master project plan, and master project schedule provide the basis for making future
trade-off decisions.

After the team approves the specifications, plans, and schedules, the documents become the project
baseline. The baseline takes into account the various decisions that are reached by consensus by
applying the three project planning variables: resources, schedule, and features. After the baseline is
completed and approved, the team transitions to the developing phase.

After the team defines a baseline, it is placed under change control. This does not mean that all
decisions reached in the planning phase are final. But it does mean that as work progresses in the
developing phase, the team should review and approve any suggested changes to the baseline.
For organizations using MOF, the team submits a Request for Change (RFC) to IT operations at this
milestone.

Deliverables

 Conceptual Design Document - addresses what needs to be included in the product. While
it should be non-technical, it should be detailed regarding the new functionality in the
proposed solution, how the existing technology infrastructure will react to the introduction of
this functionality, how the solution will interact with the user, and what is included in the
performance criteria.
 Design Specification - describes how to implement the "what" defined in the Conceptual
Design Document and includes two major sub-deliverables: the technical specification and
the security plan. The technical specification includes four content elements: the logical and
physical design, standards and guidelines, change control methodology, and the life cycle
management plan.
 Test Lab Setup - serves to ensure that an appropriate isolated environment has been
established to simulate and test the functionality encompassed by the proposed solution. The
lab setup has been completed when everything that is required to conduct the isolated
testing, as defined in the Conceptual Design Document and the Design Specification, is in
place. This is critical because it is a prerequisite for the proof-of-concept and the pilot, which
will be conducted later in the project.
 Master Project Schedule - combines all the schedules from the various teams. After
Program Management has drafted the Conceptual Design and Design Specification, the team
leads map the individual functional components to specific tasks and assign the tasks to the
team members. Each team lead is responsible for providing a schedule that their teams can
commit to meeting during the development process. The Master Project Schedule has six
content elements: the task list, implementation schedule, test schedule, preliminary training
estimates, logistics schedule, and marketing schedule.
 Master Project Plan - a collection of plans from the various roles. The Development lead
maps out tasks based on the Conceptual Design and Design Specification and groups the
tasks into major interim releases.
 Life Cycle Management Plan - considers the rapid evolution of individual and aggregate
technologies, together with dynamic organizational factors. It provides a management
framework that encompasses the entire cycle, from the strategic planning stage through the
disposition of technology and back to the planning stage again. In addition, it encourages the
concept of planning while building.
 Change Control Methodology - similar to the reasoning behind the Vision/Scope Document,
the project team must determine the who, what, when, where, why, and how of proposed
changes. The team must be able to assess the risk and impact of the change and should
have a mechanism for tracking the changes that have been implemented. The controls
introduced by the methodology help the team to effectively direct its change-related activities,
avoiding costly errors while maintaining acceptable quality levels.
 Risk Assessment - Consolidated and rationalized assessment of the collected risks including
Probability and severity assessment and possible mitigation strategies.
 Business Manager Approval - Sign-off on above elements by business executive assigned
as champion of the initiative.

Developing Phase
During the developing phase the team accomplishes most of the building of solution components
(documentation as well as code). However, some development work may continue into the
stabilization phase in response to testing.

The developing phase involves more than code development and software developers. The
infrastructure is also developed during this phase and all roles are active in building and testing
deliverables.
The developing phase culminates in the scope complete milestone. At this milestone, all features are
complete and the solution is ready for external testing and stabilization. This milestone is the
opportunity for customers and users, operations and support personnel, and key project stakeholders
to evaluate the solution and identify any remaining issues that must be addressed before the solution
is released.

Deliverables

 Pilot Plan - Purpose is to test the solution in a real environment. With this in mind, the pilot
needs to include representatives from every user community and usage scenario impacted
and to validate the implementation, training, and support plans and procedures that will be
used in the production roll out.
 Training Plan - The probability of success of any infrastructure project is contingent upon the
quality and appropriateness of the training provided to the respective users. While training is
not an end product of the project, it is a critical component in determining the positive or
negative impact of the solution.
 Capacity Plan - Capacity planning and the optimization of infrastructure components are two
activities that must be approached cautiously and systematically because the conclusions
drawn from these activities can dramatically impact the overall effectiveness of critical
business processes.
 Business Continuation Plan - to recover only the elements of the technology that are
essential for conducting business, to minimize downtime and loss of revenue. Disaster
recovery encompasses business continuation and extends to the restoration of systems to
their pre-failure state.
 Roll out Plan - a step-by-step strategy for effectively deploying the solution to the targeted
users with minimal disruption to the organization’s day-to-day activities. It should address the
technical design and implementation issues associated with the new technology and
incorporate the training, security, procurement, and support plans and procedures discussed
earlier.

Stabilizing Phase
The stabilizing phase conducts testing on a solution whose features are complete. Testing during this
phase emphasizes usage and operation under realistic environmental conditions. The team focuses
on resolving and triaging (prioritizing) bugs and preparing the solution for release.

Early during this phase it is common for testing to report bugs at a rate faster than developers can fix
them. There is no way to tell how many bugs there will be or how long it will take to fix them. There
are, however, a couple of statistical signposts known as bug convergence and zero-bug bounce that
helps the team project when the solution will reach stability. These signposts are described below.

MSF avoids the terms “alpha” and “beta” to describe the state of IT projects. These terms are widely
used, but are interpreted in too many ways to be meaningful in industry. Teams can use these terms if
desired, as long as they are defined clearly and the definitions understood among the team, customer,
and stakeholders. Once a build has been deemed stable enough to be a release candidate, the
solution is deployed to a pilot group.

The stabilizing phase culminates in the release readiness milestone. Once reviewed and approved,
the solution is ready for full deployment to the live production environment.

The release readiness milestone occurs at the point when the team has addressed all outstanding
issues and has released the solution or placed it in service. At the release milestone, responsibility for
ongoing management and support of the solution officially transfers from the project team to the
operations and support teams.

Deliverables
  Release notes
 Performance support elements
 Test results and testing tools
 Source code and executables
 Project documents
 Milestone review

Deploying Phase
During this phase, the team deploys the core technology and site components, stabilizes the
deployment, transitions the project to operations and support, and obtains final customer approval of
the project. After the deployment, the team conducts a project review and a customer satisfaction
survey.

Stabilizing activities may continue during this period as the project components are transferred from a
test environment to a production environment.

The deployment complete milestone culminates the deploying phase. By this time, the deployed
solution should be providing the expected business value to the customer and the team should have
effectively terminated the processes and activities it employed to reach this goal.

The customer must agree that the team has met its objectives before it can declare the solution to be
in production and close out the project. This requires a stable solution, as well as clearly stated
success criteria. In order for the solution to be considered stable, appropriate operations and support
systems must be in place.

Deliverables

 Operation and support information systems

 Procedures and processes - in the Deploying Phase, the project team needs to determine
precisely how the projected “to-be” compares with the final solution. This information will then
serve as a solid basis for future technology implementations.
 Knowledge base, reports, logbooks
 Documentation repository for all versions of documents, load sets, and code developed
during the project
 Project close-out report
 Final versions of all project documents
 Customer/user satisfaction data
 Definition of next steps

Sources

1. Article - Project Lifecycle Models: How They Differ and When to Use Them
2. MSF Process Model v. 3.1, White Paper, Published: June 2002

Rational Unified Process (RUP)

The Rational Unified Process (RUP) is an interative software development process (based upon a
spiral project management model) created by the Rational Software Corporation (now a division of
IBM). It describes an approach for the deployment of software. It describes best practices in software
deployment to eliminate or reduce the impact of the identified root causes of software failure. To
remedy this six "best practices" were identified:

Develop Software Interactively

It is no longer possible to sequentially define an entire problem, design the entire solution, build the
software and then test the product at the end. Instead, an iterative approach is required, which builds
interactively through refinement upon problem understanding and definition. RUP employs an iterative
approach that addresses the highest risk items at every stage in the lifecycle thereby reducing a
project's risk profile. This iterative approach helps you attack risk through demonstrable progress —
frequent, executable releases that enable continuous end user involvement and feedback. Because
each iteration ends with an executable release, the development team stays focused on producing
results. This approach better accommodates tactical changes in requirements, features or schedule,
and, frequent status checks help ensure that the project stays on schedule.

Manage Requirements
RUP describes how to elicit, organize, and document required functionality and constraints; track and
document tradeoffs and decisions; and easily capture and communicate business requirements. The
notions of use case and scenarios proscribed in the process facilitates the capture of functional
requirements and ensures that they guide design, implementation and testing.

Visually Model Software

The process creates visual models (using Unified Modeling Language - UML) to capture the structure
and behavior of architectures and components, permitting the developer to hide details and write code
using "graphical building blocks." These visual abstractions help communicate different aspects of the
design and the interactivity amongst the design components.

Use Component-Based Architectures

The process focuses on early development and base lining of a robust executable architecture, prior
to committing resources for full-scale development. It describes how to design a resilient architecture
that is flexible, accommodates change, is intuitively understandable, and promotes more effective
software reuse. The Rational Unified Process supports component-based software development.
RUP provides a systematic approach to defining an architecture using new and existing components,
which are assembled in a well-defined architecture, either by themselves, or in a component
infrastructure such as the Internet, CORBA, and COM.

Verify Software Quality

Poor application performance and poor reliability are factors which plague application development.
Quality should be reviewed with respect to the requirements based on reliability, functionality,
application performance and system performance. Quality assessment is implicit in all RUP activities,
using objective measurements and criteria.

Control Changes to Software

RUP describes how to control, track and monitor changes to enable successful iterative development,
and provides a secure workspaces for developers by isolating workspaces from each other and by
controlling changes to software artifacts (e.g., models, code, documents, etc.).

RUP Process
The software lifecycle is broken into cycles, each cycle working on a new generation of the product.
The Rational Unified Process divides one development cycle in four consecutive phases.
1. Inception Phase

During the inception phase the business case for the system is established and the project
scope determined. All external entities with which the system will interact (actors) are
identified and the nature of all interactions is defined at a high-level (ie., identifying all use
cases and describing a few significant ones). Outcomes include:

o A vision document: a general vision of the core project's requirements, key features,
and main constraints.
o An initial use-case model (10%-20% complete).
o An initial project glossary (may optionally be partially expressed as a domain model).
o An initial business case, which includes business context, success criteria (revenue
projection, market recognition, and so on), and financial forecast.
o An initial risk assessment.
o A project plan, showing phases and iterations.
o A business model, if necessary.
o One or several prototypes.
Milestone: Lifecycle Objectives

At the end of the inception phase is the first major project milestone: the Lifecycle Objectives
Milestone. The evaluation criteria for the inception phase are:

o Stakeholder concurrence on scope definition and cost/schedule estimates.

o Requirements understanding as evidenced by the fidelity of the primary use cases.
o Credibility of the cost/schedule estimates, priorities, risks, and development process.
o Depth and breadth of any architectural prototype that was developed.
o Actual expenditures versus planned expenditures.

The project may be canceled or considerably re-thought if it fails to pass this milestone.

2. Elaboration Phase

Analysis of the problem domain, establishment of an architectural foundation, development of

the project plan, and elimination of the highest risk elements of the project. Architectural
decisions are made based upon the system's scope, major functionality and nonfunctional
requirements such as performance requirements.

At completion of this phase, the design is complete and a decision on whether to continue is
made prior to incurring major expenditures. While the process must always accommodate
changes, the elaboration phase activities ensure that the architecture, requirements and plans
are stable enough, and the risks are sufficiently mitigated to predictably determine the cost
and schedule for the completion of the development.
 In this phase, an executable architecture prototype is developed, which addresses the critical
use cases identified in the inception phase and which typically expose the major technical
risks of the project. Outcomes include:

o A use-case model (at least 80% complete) - all use cases and actors have been
identified, and most use-case descriptions have been developed.
o Supplementary requirements capturing the non functional requirements and any
requirements that are not associated with a specific use case.
o A Software Architecture Description.
o An executable architectural prototype.
o A revised risk list and a revised business case.
o A development plan for the overall project, including the coarse-grained project plan,
showing iterations" and evaluation criteria for each iteration.
o An updated development case specifying the process to be used.
o A preliminary user manual (optional).
Milestone: Lifecycle Architecture

At the completion of this phase the Lifecycle Architecture is finished. The detailed system
objectives and scope are determined as well as an architecture design and the resolution of
major risks. The project may be aborted or re-configured if it fails to pass this milestone.

3. Construction Phase

During this phase, all remaining components and application features are developed and
integrated into the product, and all features are thoroughly tested. Many projects are large
enough that parallel construction tasks might occur in unison . These parallel activities can
significantly accelerate the availability of deployable releases at the cost of added complexity
in resource management and workflow synchronization.

A robust architecture and an understandable plan are tightly linked in that a critical qualities of
the architecture is its "constructability". Thus, RUP stresses the balanced development of the
architecture and the plan during this phase. Outcomes include:

o The software product integrated on the adequate platforms.

o The user manuals.
o A description of the current release.
Milestone: Initial Operational Capability

The construction phase concludes with the Initial Operational Capability Milestone - the
readiness of the software, the sites, and the users for deployment. This release is often called
a "beta" release. Transition may have to be postponed by one release if the project fails to
reach this milestone.

4. Transition Phase

This phase transitions the software product into the production environment. Once the
product is in the hands of the end user, issues may arise that require a new release or patch
to correct some problems, or finish the features that were postponed. This phase is entered
when a baseline is mature enough to be deployed in the end-user domain, and typically
requires some usable subset of the system to be completed to an acceptable level of quality
and that user documentation is available. The transition phase focuses on the activities
required to place the software into the hands of the users, and normally includes several
 iterations, including beta releases, general availability releases, as well as bug-fix and
enhancement releases. Considerable effort may be expended in developing user-oriented
documentation, training users, supporting users in their initial product use, and reacting to
user feedback. At this point in the lifecycle, however, user feedback should be confined
primarily to product tuning, configuring, installation, and usability issues. The phase can range
from being very simple to extremely complex, depending on the type of product.

Milestone: Product Release

The Product Release Milestone completes this phase. In some cases, this milestone may
coincide with the end of the inception phase for a subsequent cycle.

Iterations
Each phase in RUP can be further broken down into iterations. An iteration is a complete
development loop resulting in a release (internal or external) of an executable product, a subset of the
final product under development, which grows incrementally from iteration to iteration to become the
final system.

Disciplines & Workflows

Nine core
"disciplines"N ta
ke place within
an iteration
described by
the four phases:


Business

modeling
 Requirements
 Analysis & Design
 Implementation
 Test
 Deployment
and three core "supporting" workflows:

 Project Management
 Configuration and Change Management
 Environment
Business Modeling
One of the major problems with most business engineering efforts, is that the software engineering
and the business engineering community do not communicate properly with each other. As a result
the output from business engineering is not used properly as input to the software development effort,
and vice-versa. The Rational Unified Process addresses this by providing a common language and
process for both communitiesN, as well as showing how to create and maintain direct traceability
between business and software models.

Requirements
Requirements describe what the system should do and allow developers and customers to reach
agreement on that description. To do this, required functionality and constraints are elicited, organized
and documented including tradeoffs and decisions. A Vision document is created, and stakeholder
needs are elicited. Actors are identified, representing the users, and any other system that may
interact with the system being developed. Use cases are identified, representing the behavior of the
systemN. Each use case is described in detail - showing how the system interacts step by step with
the actors and what the system does. The use cases function as a unifying thread throughout the
system's development cycle. The same use-case model is used during requirements capture,
analysis & design, and test.

Analysis and Design

To show how the system will be realized in the implementation phase. The system needs to:

 Perform - in a specific implementation environment - the tasks and functions specified in the
use-case descriptions.
 Fulfill all its requirements.
 Be robust (easy to change if and when its functional requirements change).

Analysis and Design results in a design model and optionally an analysis model. The design
model serves as an abstraction of the source code; that is, the design model acts as a 'blueprint' of
how the source code is structured and written. The design model consists of design classes
structured into design packages and design subsystems with well-defined interfaces, representing
what will become components in the implementation. It also contains descriptions of how objects of
these design classes collaborate to perform use cases.

The design activities are centered around the notion of architecture. The production and validation of
this architecture is a primary focus of early design iterations. Architecture is represented by a number
of architectural views. These views capture the major structural design decisions. In essence,
architectural views are abstractions or simplifications of the entire design, in which important
characteristics are made more visible by leaving details aside. The architecture is an important vehicle
not only for developing a good design model, but also for increasing the quality of any model built
during system development.

Implementation

 To define the organization of the code, in terms of implementation subsystems organized in

layers.
 To implement classes and objects in terms of components (source files, binaries,
executables, and others).
 To test the developed components as units.
  To integrate the results produced by individual implementers (or teams), into an executable
system.

RUP describes how you reuse existing components, or implement new components with well defined
responsibility, making the system easier to maintain, and increasing the possibilities to reuse.
Components are structured into Implementation Subsystems. Subsystems take the form of
directories, with additional structural or management informationN.

Test

 To verify the interaction between objects.

 To verify the proper integration of all components of the software.
 To verify that all requirements have been correctly implemented.
 To identify and ensure defects are addressed prior to the deployment of the software.

RUP proposes interative testing throughout the project permitting the detection of defects as early as
possible. Tests are carried out along three quality dimensions:

 reliability,
 functionality,
 application performance and system performance.

For each of these quality dimensions, the process describes how you go through the test lifecycle of
planning, design, implementation, execution and evaluation.

Strategies for when and how to automate test are described. Test automation is especially important
using an iterative approach, to allow regression testing at then end of each iteration, as well as for
each new version of the product.

Deployment
To successfully produce product releases, and deliver the software to its end users. It covers a wide
range of activities including:

 Producing external releases of the software

 Packaging the software
 Distributing the software
 Installing the software
 Providing help and assistance to users
 In many cases, this also includes activities such as:
 Planning and conduct of beta tests
 Migration of existing software or data
 Formal acceptance

Although deployment activities are mostly centered around the transition phase, many of the activities
need to be included in earlier phases to prepare for deployment at the end of the construction phase.

Project Management
Software Project Management is the art of balancing competing objectives, managing risk, and
overcoming constraints to deliver, successfully, a product which meets the needs of both customers
(the payers of bills) and the users.
This discipline focuses on the specific aspect of an iterative development process. Project
management is facilitated by:

 A framework for managing software-intensive projects;

 Practical guidelines for planning, staffing, executing, and monitoring projects;
 A framework for managing risk.
Configuration and Change Management
Ensures that resultant artifacts are not in conflict due to some of the following kinds of problems:

 Simultaneous Update - When two or more peopole work separately on the same artifact, the
last one to make changes might destroy the work of others;
 Limited Notification - When a problem is fixed in artifacts shared by several developers, and
some of them are not notified of the change.
 Multiple Versions - Most large programs are developed in evolutionary releases. One
release could be in customer use, while another is in test, and the third is still in development.
If problems are found in any one of the versions, fixes need to be propagated between them.
Confusion can arise leading to costly fixes and re-work unless changes are carefully
controlled and monitored.

Managing configurations provides guidelines for managing multiple variants of evolving software
systems, tracking which versions are used in given software builds, performing builds of individual
programs or entire releases according to user-defined version specifications, and enforcing site-
specific development policies.

We describe how you can manage parallel development, development done at multiple sites, and how
to automate the build process. This is especially important in an iterative process where you may want
to be able to do builds as often as daily, something that would become impossible without powerful
automation. We also describe how you can keep an audit trail on why, when and by whom any artifact
was changed.

This discipline also covers change request management, i.e. how to report defects, manage them
through their lifecycle, and how to use defect data to track progress and trends.

Environment Control
To provide the software development organization with the software development environment - both
processes and tools - that are needed to support the development team.

Environment Control focuses on the activities to configure the process in the context of a project and
on activities to develop the guidelines needed to support a project. A step-by-step procedure
describes how to implement a process in an organization.

Service Improvement Models

Improvement models describe processes for improving organizational capabilities. They may be
general to the subject matter being improved (eg. six sigma) or be integrated with the reference model
(eg. CMMI). These "Service Improvement Models describe processes an defined levels of
organizational capabilities.

Six Sigma
Six Sigma is a data-driven, methodical program of continuous improvement focused on customers
and their critical requirementsN. The ultimate goal is to eliminate defects and errors and the costs
 associated with poor quality. After defining which performance measures represent Critical to
Customer (CTC) requirements, data are collected on the number of defects and then translated into a
sigma numberN. Moving from 3 to 4 sigma is often classified as continuous improvement - 6 sigma is
almost perfect quality.

Learning topics that enable the organization to use Six Sigma to its fullest capability include change
management, teamwork, creativity, problem-solving, project management, statistics, process
improvement and design of experiments. The project management component of this process is
particularly important. There are five process steps to a Six Sigma Project:

 Define - Determines the scope and purpose of the project and includes a Project Charter, a
process map of the problem to be investigated and an analysis of customers to determine the
Voice of the Customer (VOC), resulting in Critical to Quality variables, or CTQs (sometimes
CTC, Critical to Customer)
 Measure - The collection of information on the current situation. Baseline data on defects and
possible causes are collected and plotted, and the sigma capability levels are calculated.
 Analyze - Determines the root causes of defects and explores and organizes potential
causes
 Improve - The development of solutions that are implemented to remove the root causes and
then measured and evaluated for desired results
 Control - Standardizes the improvement process to maintain the gains. The new standard
practices are documented, and performance is monitored

FCAPS (fault-management, configuration, accounting, performance, and

security)
FCAPS is an acronym for a categorical model of the working objectives of network management.
There are five levels, called the fault-management level (F), the configuration level (C), the accounting
level (A), the performance level (P), and the security level (S)R.

 At the F level, network problems are found and corrected. Potential future problems are
identified, and steps are taken to prevent them from occurring or recurring. In this way, the
network is kept operational, and downtime is minimized.
 At the C level, network operation is monitored and controlled. Hardware and programming
changes, including the addition of new equipment and programs, modification of existing
systems, and removal of obsolete systems and programs, are coordinated. An inventory of
equipment and programs is kept and updated regularly.
 The A level, which might also be called the allocation level, is devoted to distributing
resources optimally and fairly among network subscribers. This makes the most effective use
of the systems available, minimizing the cost of operation. This level is also responsible for
ensuring that users are billed appropriately.
 The P level is involved with managing the overall performance of the network. throughput is
maximized, bottlenecks are avoided, and potential problems are identified. A major part of the
effort is to identify which improvements will yield the greatest overall performance
enhancement.
 At the S level, the network is protected against hackers, unauthorized users, and physical or
electronic sabotage. Confidentiality of user information is maintained where necessary or
warranted. The security systems also allow network administrators to control what each
individual authorized user can (and cannot) do with the system.

The following table summarizes the features of each functional area of FCAPS:
Fault Management Configuration Accounting Performance Security
Management Management Management Management

Fault detection, Resource Track service & Utilization & error Selective resource
correction, isolation Initialization resource usage rates access

Diagnostic test Network Cost for service Consistent Enable NE functions

provisioning performance level

Network recovery Backup & restore Combine costs for Performance reports Security events
multiple resources reporting

Error logging & Copy configuration   Maintaining & Security-related

handling and software examining historical information
distribution logs distribution

Clear correlation       Security audit trail

log

The framework has had some success in the network management sphere. It provides essential
foresight and knowledge to optimize the network performance through fault, performance and
configuration management. It addresses security, which is a major concern to IT, service consumers
with respect to data protection. The object oriented approach, which helps in modularity; and this
increases the ability for abstraction and reliability. Also, the framework enables the development of
concurrent network applications on different OS platforms. The cost of porting is less than new
development effort.

Capability Maturity Modeling - Integrated

A capability maturity model delineates the characteristics of a mature, capable process. It identifies
the practices that are basic to implementing effective processes and distinguishes additional practices
necessary for more robust, mature processes. Typically a path is recommended through the various
practices for achieving higher levels of maturity which improve an organization's processes and
operations. The Integrated version of CMM was an attempt to find a more generic and widely
applicable set of organizational practices which could be applied in many settings.

CMMI distinguishes four major process areas for an organization:

 Process Management - Contains the cross-project activities related to defining, planning,

resourcing, deploying, implementing, monitoring, controlling, appraising, measuring, and
improving processes.
Basic Functions

o Process FocusD - the organization's set of standard processes and the defined
processes that are tailored from them. The organizational process assets are used to
establish, maintain, implement, and improve the defined processes.
o Process DefinitionD - process asset library is a collection of items maintained by the
organization for use by the people and projects of the organizationN.
o TrainingD - training to support the strategic business objectives and to meet the
tactical training needs that are common across projects and support groups.

Advanced Functions
 o Process PerformanceD - measure of the actual results achieved by following a
process.
o Innovation & DeploymentD - enables the selection and deployment of improvements
that can enhance the organization's ability to meet its quality and process-
performance objectives.
 Project ManagementN - Covers the project management activities related to planning,
monitoring, and controlling the project.
Basic Functions

o Project PlanningD - estimating the attributes of the work products and tasks,
determining the resources needed, negotiating commitments, producing a schedule,
and identifying and analyzing project risks. Iterating through these activities may be
necessary to establish the project plan.
o Project Monitoring & ControlD - the basis for monitoring activities, communicating
status, and taking corrective action.
o Supplier Agreement ManagementD - the acquisition of products and product
components that are delivered to the project’s customer.

Advanced Functions

o Integrated Project Management for IPPDD - establish and manage the project and the
involvement of relevant stakeholders according to an integrated and defined process
that is tailored from a set of standard processes.
o Risk ManagementD - addresses issues that could endanger achievement of critical
objectives.
o Integrated TeamingD - An integrated team understands its role in the structure of
teams for the overall project.
o Integrated Supplier ManagementD - evaluating sources of products that might help
satisfy project requirements, and using this information to select suppliers.
o Quantitative Project ManagementD - managing product performance using
quantitative methods.
 Engineering - Covers the development and maintenance activities that are shared across
engineering disciplines (e.g., systems engineering and software engineering.
Recursive Functions

o Requirements DevelopmentD - produce and analyze customer, product and product-

component requirements.
o Requirements ManagementD - manage the requirements of the project's products and
product components and identify inconsistencies between those requirements and
the project's plan and work products.
o Technical SolutionD - design, develop and implement solutions to requirements.
o Product IntegrationD - assemble the product from the product components, ensure
product is integrated, functions properly and deliver the product.
o VerificationD - ensure the selected work products meet their specified requirementsN.
o ValidationD -demonstrate that a product or product component fulfills its intended use
when placed in its intended environment N.
 Support - Covers the activities that support product development and maintenance. The
Support process areas address processes that are used in the context of performing other
processes. In general the Support process areas address processes that are targeted
towards the project, and may address processes that apply more generally to the
organization.
 Basic Functions

o Configuration ManagementD - establish and maintain the integrity of work products.

o Process & Product Quality AssuranceD - provide staff and management with objective
insight into processes and associated work products N.
o Measurement & AnalysisD - develop and sustain a measurement capability that is
used to support management information needs.

Advanced Functions

o Organizational Environment for IntegrationD - provide an IPPD infrastructure and

manage people for integration.
o Decision Analysis & ResolutionD - analyze possible decisions using a formal
evaluation process that evaluates identified alternative against established criteria N..
o Causal Analysis & ResolutionD - identify causes of defects and other problems and
take corrective action to prevent them from occurring in the future N.

The CMMI reference model distinguishes how these processes interact with each other according to
the organization's current maturity characteristics. There are five "maturity" levels through which an
organization can increase its capabilities and each level is distinguished by an implementation and
subsequent "institutionalization" phase. These "generic" processes measure the organization's:

 Commitment to Perform,
 Ability to Perform,
 how it directs implementation, and
 how it verifying implementation
Institutionalizing Processes
Institutionalization” is an important dimension in CMMI. It implies that the breadth and depth of the
implementation of the process and the length of time the process has been in place are appropriate to
ensure that the process is ingrained in the way the work is performed.

"the CMMI is based on the premise that if processes are institutionalized,

they will endure even when the circumstances around it are not optimal" (p.
123)

"If one were to select a single major contribution that the CMM and CMMI
have brought to the field of process improvement it would be the notion
of institutionalizationD."

Boris Mutafelija, Harvey Stromberg, Systematice Process Improvement

Using ISO 9001:2000 and CMMI, Artech House, 2003, ISBN: 1-58053-487-
2, p. 133
Level 1 - Performed Processes
At this maturity level the base practices of the process area are performed, formally or
informally, to develop work products and provide services to achieve the specific
goals of the process area.

Level 2 - Managed Processes

A critical distinction between a performed process and a managed process is the
extent to which the process is managed and executed in accordance with policy,
employs skilled people having adequate resources to produce controlled outputs,
involves relevant stakeholders; is monitored, controlled, and reviewed; and is
evaluated for adherence to its process description. Management of the process is
concerned with the institutionalization of the process area and the achievement of
other specific objectives established for the process, such as cost, schedule, and
quality objectives. A managed process achieves the objectives of the plan and is
institutionalized for consistent performance.

The objectives for the process are determined based on an understanding of the
project’s or organization’s particular needs. At this level of maturity objectives may
be stated qualitatively and may be specific objectives for the individual process or
defined for a broader scope (i.e., for a set of processes), with the individual processes
contributing to achieving these objectives.

A managed process is institutionalized by:

 Establishing an Organizational Policy - define the organizational expectations

for the process and make these expectations visible to those in the organization
who are affected.
 Planning the Process - determine what is needed to perform the process and
achieve the established objectives, to prepare a plan for performing the process,
to prepare a process description, and to get agreement on the plan from relevant
stakeholders.
 Providing Resources - determine what is needed to perform the process and
achieve the established objectives, to prepare a plan for performing the process,
to prepare a process description, and to get agreement on the plan from relevant
stakeholders.
 Assigning Responsibility - ensure that there is accountability throughout the
life of the process for performing the process and achieving the specified results.
The people assigned must have the appropriate authority to perform the assigned
responsibilities
 Training People - ensure that the people have the necessary skills and expertise
to perform or support the process
 Managing Configurations - establish and maintain the integrity of the
designated work products of the process (or their descriptions) throughout their
useful life.
 Identifying and Involving Relevant Stakeholders - establish and maintain the
expected involvement of stakeholders during the execution of the process.
 Monitoring and Controlling the Process - perform the direct day-to-day
monitoring and controlling of the process.
 Objectively Evaluating Adherence - objectively evaluate adherence of the
process against its process description, standards, and procedures, and address
noncompliance
 Reviewing Status with Higher Level Management - objectively evaluate
adherence of the process against its process description, standards, and
procedures, and address noncompliance
Level 3 - Defined Processes
A defined process is a managed process that is tailored from the organization's set of
standard processes according to the organization’s tailoring guidelines, and
contributes work products, measures, and other process-improvement information to
the organizational process assets.

The organization’s set of standard processes, which are the basis of the defined
process, are established and improved over time. Standard processes describe the
fundamental process elements that are expected in the defined processes. Standard
processes also describe the relationships (e.g., the ordering and interfaces) between
these process elements. The organization-level infrastructure to support current and
future use of the organization's set of standard processes is established and improved
over time. The organizational process assets are artifacts that relate to describing,
implementing, and improving processes. These artifacts are assets because they are
developed or acquired to meet the business objectives of the organization, and they
represent investments by the organization that are expected to provide current and
future business value.

A critical distinction between a managed process and a defined process is the scope of
application of the process descriptions, standards, and procedures. For a managed
process, the process descriptions, standards, and procedures are applicable to a
particular project, group, or organizational function. As a result, the managed
processes for two projects within the same organization may be very different.

At the defined capability level, the organization is interested in deploying standard

processes that are proven and that therefore take less time and money than
continually writing and deploying new processes. Because the process descriptions,
standards, and procedures are tailored from the organization's set of standard
processes and related organizational process assets, defined processes are
appropriately consistent across the organization. Another critical distinction is that a
defined process is described in more detail and performed more rigorously than a
managed process. This means that improvement information is easier to understand,
analyze, and use. Finally, management of the defined process is based on the
additional insight provided by an understanding of the interrelationships of the
process activities and detailed measures of the process, its work products, and its
services.

A defined process is institutionalized by:

 Establishing a process description - establish and maintain a description of the

process that is tailored from the organization's set of standard processes to
address the needs of a specific instantiation.
 Collecting improvement data - To collect information and artifacts derived
from planning and performing the process.

Level 4 - Quantitatively Managed Processes

A quantitatively managed process is a defined process that is controlled using
statistical and other quantitative techniques. Quantitative objectives for quality and
process performance are established and used as criteria in managing the process. The
quality and process performance are understood in statistical terms and are managed
throughout the life of the process.

Quantitative management is performed on the overall set of processes that produces a

product or provides a service. The sub-processes that are significant contributors to
 overall process performance are statistically managed. For these selected sub-
processes, detailed measures of the process performance are collected and statistically
analyzed. Special causes of process variation are identified and, where appropriate,
the source of the special cause is addressed to prevent future occurrences. The quality
and process performance measures are incorporated into the measurement repository
to support future fact-based decision making.

A quantitatively managed process is institutionalized by:

 Establishing quantitative objectives for the process -determine and obtain

agreement from relevant stakeholders about specific quantitative objectives for
the process. These quantitative objectives can be expressed in terms of product
quality, service quality, and process performance.
 Stabilizing sub-process performance - stabilize the performance of one or
more sub-processes of the defined (capability level 3) process that are critical
contributors to the overall performance using appropriate statistical and other
quantitative techniques.

Level 5 - Optimizing Processes

An optimizing process is a quantitatively managed process that is changed and
adapted to meet relevant current and projected business objectives. An optimizing
process focuses on continually improving the process performance through both
incremental and innovative technological improvements. Process improvements that
would address root causes of process variation and measurably improve the processes
are identified, evaluated, and deployed as appropriate. These improvements are
selected based on a quantitative understanding of their expected contribution to
achieving the process-improvement objectives versus the cost and impact to the
organization. The process performance of the processes is continually improved.
Selected incremental and innovative technological process improvements are
systematically managed and deployed into the organization and the effects of the
deployed process improvements are measured and re-evaluated.

A optimizing process is institutionalized by:

 Ensuring continuous process improvement - select and systematically deploy

process and technology improvements that contribute to meeting established
quality and process-performance objectives
 Correct root causes of problems - analyze defects and other problems that
were encountered, to correct the root causes of these types of defects and
problems, and to prevent these defects and problems from occurring in the
future.

Basic Interactions
It is desirable for the organization to achieve and subsequently institutionalize the processes at a
lower maturity level before undertaking more mature processes. Most organizations are aspiring to
achieve level 3 maturity, so CMMI distinguishes process interactions between "basic" and "advanced"
process descriptions. basic interactions are described in the following schematic:
Advanced Interactions
At an advanced operational level new process interactions augment the basic ones:
Control Objectives for Information and Related Technology - COBIT
COBIT is based on established frameworks, such as CMM, ISO 9000, ITIL and ISO 17799. However,
COBIT does not include process steps and tasks because, although it is oriented toward IT
processes, it is a control and management framework rather than a process framework. COBIT
focuses on what an enterprise needs to do, not how it needs to do it, and the target audience is senior
business management, senior IT management and auditorsR.

"Due to its high level and broad coverage and because it is based on many
existing practices, COBIT is often referred to as the ‘integrator’, bringing
disparate practices under one umbrella and, just as important, helping to link
these various IT practices to business requirements. (p. 10)

COBIT and ITIL are not mutually exclusive and can be combined to provide
a powerful IT governance, control and best-practice framework in IT service
management. Enterprises that want to put their ITIL program into the
context of a wider control and governance framework should use COBIT (p.
7). "

Aligning COBIT, ITIL and ISO 17799 for Business Benefit, ISAAC

Premise
CobIT notes that
"Successful
organizations ensure
interdependence
between their
strategic planning and
their IT activities." The
alignment of the IT
service provider with
organizational vision,
goals and objectives
is, therefore, crucial to
success. These goals
and objectives
provide organizational
direction which
indicates requisite
enterprise activities,
using the enterprise’s
resources. The results
of the enterprise
activities are
measured and
reported on, providing
input to the constant
revision and
maintenance of the
controls, beginning
the cycle again.

The underpinning concept of the COBIT Framework is that control in IT is approached by looking at
information that is needed to support the business objectives or requirements, and by looking at
information as being the result of the combined application of IT-related resources that need to be
managed by IT processes. To satisfy business objectives, information needs to conform to certain
criteria, which COBIT refers to as business requirements for information.

The COBIT framework helps align IT with the business by focusing on business information
requirements and organizing IT resources. COBIT provides the framework and guidance to implement
IT Governance. An organization depends on reliable and timely data and information. COBIT
components provide a comprehensive framework for delivering value while managing risk and control
over data and information.

Elements
Reworking this logical flow results in the following framework..

A - Business Strategy

To satisfy business objectives, information needs to conform to certain criteria, which COBIT refers to
as business requirements for information.

 Service Quality and Cost - priority is directed at properly managing risks:

o The usability aspect of Quality is transcribes into the Effectiveness Information
criterion.
o The delivery aspect of Quality was considered to overlap with the Availability aspect
of the Security requirements and also to some extent Effectiveness and Efficiency.
o Cost is also considered covered by Efficiency.
 Fiduciary Requirements - includes best practice areas and audit requirementsN:
o Effectiveness and Efficiency of operations
o Reliability of InformationN
o Compliance with laws and regulations
 Security Requirements - world-wide agreement on three elements:
o Confidentiality
o Integrity
o Availability

B - Information Criteria

how IT is organized to meet those requirements.

 Effectiveness - deals with information being relevant and pertinent to the business process
as well as being delivered in a timely, correct, consistent and usable manner.
 Efficiency - concerns the provision of information through the optimal (most productive and
economical) use of resources.
  Confidentiality - concerns the protection of sensitive information from unauthorized
disclosure.
 Integrity - relates to the accuracy and completeness of information as well as to its validity in
accordance with business values and expectations.
 Availability - relates to information being available when required by the business process
now and in the future. It also concerns the safeguarding of necessary resources and
associated capabilities.
 Compliance - deals with complying with those laws, regulations and contractual
arrangements to which the business process is subject, i.e., externally imposed business
criteria.
 Reliability of Information - relates to the provision of appropriate information for
management to operate the entity and for management to exercise its financial and
compliance reporting responsibilities.

C - IT Resources
a means to identify the resources required to execute processes.

 Data - are objects in their widest sense (i.e., external and internal), structured and non-
structured, graphics, sound, etc.)
 Application Systems - are understood to be the sum of manual and programmed
procedures.
 Technology - covers hardware, operating systems, database management systems,
networking, multimedia, etc.
 Facilities - are all the resources to house and support information systems.
 People - include staff skills, awareness and productivity to plan, organize, acquire, deliver,
support and monitor information systems and services.

D - IT Processes
what stakeholders expect from IT.

Model consists of 34 processes organized in four primary domains:

 Planning and Organization - covers strategy and tactics, and concerns the identification of
the way IT can best contribute to the achievement of the business objectives. Furthermore,
the realization of the strategic vision needs to be planned, communicated and managed for
different perspectives. Finally, a proper organization as well as technological infrastructure
must be put in place.
 Acquisition and Implementation - identification, development, acquisition, implementation
of IT solutions. N
 Support and Delivery - actual delivery of required services, which range from traditional
operations over security and continuity aspects to training. In order to deliver services, the
necessary support processes must be set up.
 Monitoring - regular assessment of processes for their quality and compliance with control
requirements. This domain thus addresses management’s oversight of the organization’s
control process and independent assurance provided by internal and external audit or
obtained from alternative sources.N

The CobIT model and 34 processes are depicted in the framework below. To the left are the process
descriptions. Those considered "core processes" are itemized in white with black background.N.
 PLANNING Activitie
AND s
ORGANIZATIO
N
Strategic Planning [SP]

Architectural [SP]
Planning

Technology [SP]
Direction

IT Organization and [SP]

Relationships

IT Investment [SP]
Management

Communicate [SP]
Mgmt Aims &
Directions

Manage HR [SP]

Ensure Compliance [SP]

Display larger view of CobIT framework w. External
Requirements

Assess Risks [SP]

Manage Projects [SP]

Quality [SP]
Management

ACQUISITION & Activitie

IMPLEMENTATI s
ON
Solutions [SP]
Development

Application SW [SP]
Acquisition and
Maintenance

Technology [SP]
Acquisition and
Maintenance

Technology [SP]
Procedures
Documentation
Implementation and [SP]
Accreditation

Change [SP]
Management

DELIVERY & Activitie

SUPPORT s

Service Level [SP]

Management

External Provider [SP]

Management

Performance/ [SP]
Capacity
Management

Service Continuity [SP]

Management

Security Access [SP]

Management

Cost Accounting [SP]

User Education and [SP]

Training

Service Desk [SP]

Configuration [SP]
Management

Incident/Problem [SP]
Management

Data Management [SP]

Facilities [SP]
Management

Operations [SP]
Management

MONITORING Activitie
s

Process Monitoring [SP]

Controls [SP]
Assessment

Assurance Reviews [SP]

 IT Audit [SP]

View HP-COBIT mapping diagramR

ISO 9001
The ISO 9000 series of standards is a set of documents dealing with quality systems that can be used
for external quality assurance purposes. They specify quality system requirements for use where a
contract between two parties requires the demonstration of a supplier's capability to design and
supply a product according to defined quality specifications. The two parties could be an external
client and a supplier, or both could be internal, e.g., marketing and engineering groups in a
company. Ref. ISO 9001:2000 is a standard that specifies criteria for a quality management system
(QMS). A QMS incorporates those elements of an organizations management system that direct and
control it with regard to quality. Such a system will need to be supported by top management who will
need to be able to demonstrate management commitment.

ISO 9001-2000 is the third revision to ISO 9001 since its inception in 1987. The new standard defines
the requirements for a quality management system based on "the process model" and aimed at
achieving customer satisfaction and continual improvement in performance. Effective document and
record control now must address new areas of concern which include continual improvement and
customer satisfaction as well as cope with the accelerating changes in the available technology for
information and knowledge management.

The standard was developed using a core set of eight quality management principles based upon a
simple "Plan-Do-Check-ActN" methodology which act as a common foundation for all standards
relating to quality management.R
Elements inherent in this process approach include:

 customer focus - organizations depend on their customers and should understand current
and future customer needs, should meet customer requirements, and strive to exceed
customer expectations.
 leadership - leaders establish unity of purpose and direction for the organization. They
should create and maintain the internal environment in which people can become fully
involved in achieving the organization's objectives
 people involvement - people at all levels are the essence of the organization and their full
involvement enables the organization to leverage their skills and experience
 process focus - desired results are achieved more efficiently when activities and related
resources are managed as a process
 system approach to management - identifying, understanding and managing interrelated
processes as a system contributes to the organization's effectiveness and efficiency in
meeting goals and objective.
 continual improvement - continual improvement should be a permanent objective of the
organization
 decision making based on empirical evidence - effective decisions are based upon the
accumulated and interpretation of factual data.
 supplier relationship - organizations and their suppliers provide a interdependent web in
service delivery which produces synergies in the creation of business value
The standard emphasizes the need for an organization to continually monitor their processes and
systems. Many of the clauses in the standard reference self monitoring and/or measurement as key
elements. This emphasis aims for an integrated approach to business processes. Instead of operating
to a business plan on one hand and a quality management system on the other, the standard aims to
integrate both of these functions into one system. R. An ISO 9001/2000 compliant QMS sees an
organization as a set of interrelated processes, each of which must be planned to include:

 defined goals
 a defined set of interrelationships with other processes
 to be continually measured, under continuous review and improvement.

The standard consists of the following sections:

4. Systemic Requirements

1. Establish your quality system - the organization must identify and manage the family of
processes needed to ensure conformity
2. Document your quality system - documentation forms the basis for understanding the system,
communicating its processes and requirements within the organization, describing it to other
organizations, and determining the effectiveness of implementation
5. Management Requirements

1. demonstrate commitment by conducting certain activities:

o communicate the importance of meeting customer, statutory and regulatory
requirements,
o establish quality policy,
o ensure quality objectives are established
o provide resources,
o perform management reviews,
o ensure availability of resources
2. ensure that customer requirements are determined and are met with the aim of enhancing
customer satisfaction,
3. ensure that the quality policy:
o is appropriate to the purpose of the organization,
o includes commitment to comply with requirements and continually improve the
effectiveness of the quality management system,
o provides a framework for establishing and reviewing quality objectives,
o is communicated and understood within the organization,
o is reviewed for continuing suitability
4. ensure that quality objectives are established at relevant functions and levels within the
organization. Quality objectives should be measurable and consistent with quality policy,
5. ensure that the quality system conforms to established process requirements and that
changes to the quality system are planned, implemented and documented,
6. ensure that responsibilities and authorities are defined and communicated within the
organization
7. appoint a Quality Manager who has responsibility for:
o ensuring processes needed for Quality management are established, implemented
and maintained,
o reporting on the performance of the Quality Management System (QMS) and the
need for improvement,
 o promoting awareness of customer requirements
8. ensure appropriate communications processes are established including communicating
effectiveness of QMS
9. review the QMS, at planned intervals to ensure continuing suitability, adequacy and
effectiveness
6. Resource Requirements

1. the organization should determine and provide necessary resources to implement and
maintain QMS and to enhance customer satisfaction by meeting customer requirementsN,
2. personnel performing work affecting product quality shall be competent on the basis of
appropriate education, training, skills and experienceN.
3. the organization should:
o determine personnel competencies needed,
o provide necessary training,
o evaluate effectiveness of actions taken,ensure staff are aware of relevance and
importance of activities and their contributions,
o maintain records of education, training, skills and experience
4. the organization should determine,provide and maintain an infrastructure to achieve
conformity to product requirements,
5. the organization should determine and manage a work environment
7. Realization Requirements

1. the organization should plan and develop the processes needed for product realization.
Realization would maintain consistency with other processes in the QMS. This should include:
o quality objectives and requirements,
o processes, documents and resources,
o verification, validation, monitoring, inspection and testing specific to the product and
its acceptance,
o evidentiary material to prove compliance against requirements (including regulatory)
2. the organization should determine customer requirements including...
o delivery and post-delivery activities,
o non-customer stated,
o statutory and regularly.
3. the organization should review the requirements prior to commitment to supply the product
ensuring that:
o requirements are defined,
o issues are resolved,
o commitments are achievable.

The organization should determine and implement necessary communications with

customers.

4. Outputs of Design and Development should be provided in a form that enable verification
against design and development inputs and should be approved prior to product release.
5. at suitable stages, systematic reviews of Design and Development are performed in
accordance with plans,
6. the Design and Development should be Verified to ensure that outputs have been obtained.
Records should be maintained.
 7. the design and Development should be Validated to ensure that products are capable of
meeting their defined requirements,
8. Changes to design and Development should be identified and records maintained. Changes
should be reviewed, verified and validated before implementation. The review of design and
Development changes should include evaluation of the effect of the changes on constituent
parts and products already delivered,
9. the organization should ensure that purchased products conform to purchasing requirements.
The organization should select suppliers in accordance with requirements. Criteria for
selection, evaluation should be established and records of the results of the evaluations (and
subsequent actions) maintained. Purchasing information should describe the product to be
purchased including:
o requirements for approval of product, processes and equipment,
o requirements for personnel qualifications,
o QMS requirements

. The organization should establish and implement inspections and other activities necessary
for ensuring purchased products meet specified purchasing requirements.

10. the organization should plan and carry out production and service provision under controlled
conditions which include:
o information describing the product,
o work instructions,
o suitable equipment,
o implementation and/or availability and use of monitoring and measuring tools,
o delivery and post-delivery activities.
11. the organization should validate any processes for production and service provision where the
resulting output cannot be verified by monitoring or measurement,
12. where appropriate, the organization should trace the product through any stages/milestones
during the realization process(es). Where traceability is a requirement, the organization
should control and record all unique outputs of the product.
13. the organization should ensure the conformity of the product during all intermediate
processes and ensure its overall integrity to the intended destination,
14. the organization should determine, implement and review monitoring and measurement to be
undertaken to product evidence of conformity
8. Remedial Requirements

1. the organization should plan and implement monitoring, measurement and analysis and
improvement processes as needed to:
o demonstrate product conformity,
o ensure conformity with QMS,
o continually improve effectiveness of QMS.

This should include determination of applicable methods.

2. the organization should monitor information relating to customer perception as to whether the
organization has met customer requirementsN,
3. the organization should conduct internal audits at planned intervals to determine the success
of the QMS:
o that it conforms to ISO standards and the requirements of the QMS as set by the
organization,
o is effectively implemented and maintained.
 4. the organization should apply suitable methods for monitoring and measuring the QMS.
Where planned results are not met, corrective action should be initiated
5. the organization should monitor and measure the characteristics of the product to verify that
its' requirements have been met. Evidence of conformity with acceptance criteria should be
maintained including appropriate authorizations for release. Products should not be released
until all planned arrangements have been satisfied or signed off by an appropriate
authorization,
6. the organization should ensure that non conforming products are identified and controlled to
prevent unintended effects. Controls and related authorities for dealing with nonconforming
products should be defined in documenting procedures. Nonconformance should initiate
appropriate actions including:
o actions to eliminate detected nonconformance,
o authorizing its use or acceptance under concession by a relevant authority, and,
where applicable, by the customer,
o actions to preclude its original intended use or application.

All actions and their reasons should be documented. When nonconforming products are
corrected they should be re-verified to demonstrate conformity. When nonconforming
products are detected after delivery or use has started, the organization should take actions
appropriate to mitigate or eliminate potentially deleterious effects from the nonconformity.

7. the organization should determine, collect and analyze information to demonstrate the
suitability and effectiveness of the QMS and to identify where improvements are possible and
cost efficient,
8. the organization should continually improve the effectiveness of the QMS through use of
quality policies, objectives, audit results, data analysis, corrective and preventative actions
and management reviews. The organization should take actions to eliminate the causes of
nonconformities in order to prevent their reoccurrence. The organization should determine
actions to eliminate the causes of potential nonconformities which should be documented in
procedures.

One of the basic tenets of ISO 9001:2000 is continuous improvement by critical self-evaluation. The
output from the self-evaluation is fed into a planning stage to determine actions needed to improve the
system. Following the planning and consultation comes the action phase where the proposed
changes are implemented. Then the cycle starts again by checking that the changes are effective and
meaningful by self-evaluation.

ISO 9001 2008 - Praxiom Research Group Ltd

CMMI - ISO function mappingR

Governance
A framework can contribute to the creation of a business model of an IT enterprise, or constituent
part(s) of that organization. When it does this, it will describe relationships amongst functions and
processes which are inclusive of the total functioning of the organization which it is describing. When
the organization under consideration forms part of a larger business enterprise the manner in which it
determines its' strategic and tactical operations is through "alignment" with corporate goals and
objectives. A key element in achieving this alignment is through a governance framework.
 "We define IT governance as specifying the decision right and
accountability framework to encourage desirable behavior in using IT."

Peter Weill, Jeanne W Ross, IT Governance, Harvard Business School Press, 2004, ISBN: 1-59139-
253-5, p. 2

A governance framework is, therefore, a specific view of the organization designed to identify
who systematically make and contributes to decisions.

All enterprises have IT governance. Those with effective

governance actively designed a set of It governance mechanisms
(committees, budgeting processes, approvals, and so on) that encourage
behavior consistent with the organization's mission, strategy, values, norms
and culture.....

Without a cohesive IT governance design, enterprises must rely on their

CIOs to ameliorate problems through tactical solutions rather than position
IT as a strategic asset.

Peter Weill, Jeanne W Ross, IT Governance, Harvard Business School Press, 2004, ISBN: 1-59139-
253-5, p. 2-3

Weill and Ross, in their book IT Governance, looked at some 300 private and public sector
organizations to assess best practice structures and practices for IT governance. They produce a grid
to perform this assessment outlining the kinds of decisions required by the organization,
(distinguishing each kind between providing input and making the decision) versus "archetypes" which
described the decision arrangements found in their research N.

Decision IT Principles IT IT Business IT Investment

Architecture Infrastructure Application
Archetype Strategies Needs

Business Monarchy          

IT Monarchy          

Feudal          

Duopoly          

Anarchy          

While the authors point out that the best governance "archetype" really depends on the culture, goals
and objectives of the organization (eg. need for flexibility due to market conditions versus stable
industry, private versus public sector focus, etc) they outline seven characteristics of top governance
performers. R:

1. More managers in leadership positions could describe IT governance in the organization,

2. Top governance performers achieved a higher percentage of senior management knowledge
about governance simply by engaging more often and more effectively,
3. More direct involvement of the senior leaders in IT governance,
4. Clearer business objectives for IT investment,
5. More differentiated business strategies,
 6. Fewer renegade and more formally approved exceptions to standards,
7. Fewer changes in governance arrangement from year to year.

Fusing ITSM and Governance

IT Governance serves a different purpose from
that of IT Service Management. "IT Governance
is often perceived as defining the “what” the IT
organization should achieve and ITSM as
defining the “how” the organization will achieve it.
"R. The management of IT is shifting in response
to the need for better strategic alignment.

R. Peterson distinguished between the two as

“Whereas the domain of IT Management focuses
on the efficient and effective supply of IT services
and products, and the management of IT
operations, IT Governance faces the dual
demand of (1) contributing to present business
operations and performance, and (2)
transforming and positioning IT for meeting future
business challenges”R. This relationship is
depicted on the right.

One of the IT Governance goals is to align with

the business objectives defined by the Enterprise
Governance. These high-level organizational
goals and objectives are used as input to derive
goals, objectives and performance metrics
needed to manage IT effectively. At the same
time, the auditing processes are put in place in
order to measure and analyze the performance of
the organization. Conceptually, the process can
be seen as an “IT results chain”R. ITSM, people,
processes and technologies manage and control
the IT services and the IT infrastructure
according to the objective received from
Enterprise Governance. Another IT results chain
is design to link ITSM with the service and
infrastructure.

Concurrent to these changes, the IT infrastructure is moving towards a centralized, highly adaptive
utility modelN. The future of IT infrastructure is geared towards a new computing model under which
infrastructure is shared among customers and dynamically optimized to achieve efficient use of
resources and minimize associated costs.

Multiple Views
There are some key elements which come out of the discussion of these frameworks:

 alignment is the key goal and can be represented as a boundary between the IT Provider and
the business community. Moreover, services have impacts and effects which differ between
the Consumer of the service and the Payer (ie. business unit management) - another
boundary. Service Level Management, Customer Relationship Management and the Service
Desk all operate at this boundary.
  ITIL Capacity Management highlights the difference amongst three primary views of the
organization:
1. Business
2. Services
3. Resources

This distinction is important in other ITIL disciplines are well. These viewpoints can be usefully
employed to distinguish Change Management forums (ie. Federal, Provincial, Local changes),
performance monitoring (component, service and end-to-end service monitoring), financial
management (budgetary, service and component cost tracking) and SLM (SLAs, OLAs,
service catalogues).

 ITSM discipline can co-exist at different levels of maturity in an organization with mixed
results. Grouping of activities both amongst and within respective areas require either more or
less maturity as measured by CMM). While acknowledged as important (and the subject of
many white papers) a definitive examination of this need has yet to be concluded.
 Moreover, the ability to achieve IT Service Delivery at an achievable level (Level 3, Defined
for many organizations) requires additional maturity in many non-IT areas - such as process
management, strategic alignment procedures, communications policies, benchmarking and
performance management.

To be useful a framework should capture a logical theme. It cannot capture too many themes without
becoming overly complicated and confusing. The framework presented here is based upon the above
two considerations.

There is a concept embedded in ITIL Capacity Management which should have a much wider
resonance. It suggests that the management of an organization's capacity can be viewed at three
distinction levels. An article by Humayun Beg in Smart Decision for Technology Leaders re-labels
these three ITIL perspectives:
 ITIL Term Humayun Beg Term

Term Description Term Description

Business responsible for ensuring that the future Strategic done when decisions to expand or contract
business requirements for IT Services are the infrastructure are made due to expected
considered, planned and implemented in a changes in demand by the business
timely fashion. These future requirements
come from business plans outlining new
services, improvements and growth in
existing services, development plans etc.

Service management of the performance of the Tactical done when new services are added into the
live, operational IT Services used by the infrastructure
Customers. It is responsible for ensuring
that the performance of all services, as
detailed in the targets in the SLAs and
SLRs, is monitored and measured, and
that the collected data is recorded,
analyzed and reported.

Resource the management of the individual Operational done by real-time monitoring and
components of the IT Infrastructure. It is adjustments to capacity as needed
responsible for ensuring that all
components within the IT Infrastructure
that have finite resource are monitored
and measured, and that the collected data
is recorded, analyzed and reported.
In short, the
concept of
views has is a
useful
methodological
tool for
describing ITIL
processes and
activities across
the entire array
of best practice
categories.
These three
views have a
wider theoretical
history. ---

Principles
are “general
rules or maxims which have repeatedly proven successful when followed.” Using established
principles can provide a basic guideline for action - based on the success of other organizations - (ie.,
adopting best practices). Years ago the Canadian Federal Government used a "Federal Blueprint for
Action" to describe a set of principles within a systemic framework. The schema highlights five key
architectural features of an action plan for the delivery of services. Looking at the organization from
each of these views permits a systematic analysis of a process needs, one which distinguishes many
of the primary features of a process:

 The business view highlights the high level businesses which support the organization.
 The work view details services and the physical activities performed throughout the
organization in support of its’ businesses. They are subject to organizational priorities over
time and hence should determined by strategic and operational planning designed to fulfill
organizational mandates and objectives in a strategic and coherent sense.
 The information view presents the intelligence required to support the work and business
views of the organization. It is at the juxtaposition of the four views because it supports each
equally. Without information there is no progress, no quality improvement, no continuing
research and analysis. The absence of good information may suggest a strategic thrust to
collect it in order to augment the organization's capabilities in the future.
 The application view establishes the software applications necessary to support the
information requirements.
 Finally, the Technology View pinpoints the basic hardware architecture to be employed in
achieving the objectives described by the other views.

Adapting these views to an IT service provider creates interesting and useful parallels with the three
views used to describe Capacity Management. The business view encompasses the "Business-IT
Alignment" quadrant in the HP model and is composed of the functions of IT Business Assessment, IT
Strategy Development, Service Planning and Customer Management. Within the COBIT framework
this would include many of the elements under "Planning and Organization".

The service or tactical view encompasses the Work view and the degree of conformance between this
and the business view does much to determine the degree to which the IT Division is "aligned" with
the business view. This view would include:

 an IT strategic plan
 the Availability Plan,
 the Capacity Plan,
 the Service Level Plan,
 Continuity Plans
 Financial Plan & IT budgets

"information is the "glue" that holds an organization structure together.

Information can be used to better integrate process activities both within a
process and across multiple processes."

Thomas H Davenport, Process Innovation, Harvard Business School Press, 1993, ISBN: 0-87584-366-
2, p. 75

The information view describes the source and format in which information is available to manage the
other views. This view would include:

 the Configuration management Database (CMDB)

 the Capacity database (CDB)
 the Availability Management database (AMDB)
 the Performance Database
  the Incident Management database
 Problem Management database
 Change calendar

The application and technology views together describe the "resources" which complete the pictures.
They represent the traditional Configuration Items (CIs) which comprise the infrastructure.

Plotting the three views against the ITIL disciplines highlights some interesting variants, some of
which have been addressed by the other previously noted frameworks:

ITIL process Business View Service View Information View Resource View
covered the Best
Practice

Service Desk In-house or outsourcing Service Request Configuration Items IM, CM, knowledge
policies (CIs) which databases
comprise the Service
Catalogue

Incident Recovery Strategies Service failure IM database Configuration Items

(CIs) which
comprise
the CI failure

Problem Feasibility Studies Service PM database RCA

Improvement Plan

Change Business Configuration Service Item CM database Configuration Items

Items (CIs) which (CIs) which
comprise the Processes comprise
(BPM) the Configuration
Item

Configuration Organizational Service Catalogue CMDB Configuration Item

structure

Release Feasibility Studies Service PM database Configuration Item

Improvement Plan

Service Level Feasibility Studies Service Service Catalogue MTBF

Improvement Plan CMDB

Availability Availability Plan - Availability Plan - AMDB Availability Plan -

Business View Service View CI View

Capacity Capacity Plan - Service Catalogue CDB Resource

Business View SLA

Continuity Business Continuity Service Continuity Recovery procedures Disaster Recovery

Management Management Plans

Financial Business Plans, Service Catalogue Financial database charging

Budgeting financials
The idea that an organization can be looked at in different ways is from new. In fact, it is the basic
premise behind the Zachmann Framework. Two key ideas are illustrated in the Zachman Framework:

 There is a set of architectural representations produced over the process of building a

complex engineering product representing the different perspectives of the different
participants.
 The same product can be described, for different purposes, in different ways, resulting in
different types of descriptions

Improvement Models
In this section I discuss the importance of maturity models for implementing best practices. I discuss
the theoretical migration from the basic PDCA management cycle to software CMM and then to the
generalized CMM Integrated. I then focus on three variations in the fields of workforce, Project and IT
Service Management. I mention what ITIL says on the subject of maturity (very little) and how
organizations such as Pink Elephant have presented maturity modeling within the ITIL context. I then
present COBIT as the current state of the art in using maturity modeling to assess the capabilities of
an IT organization. Lastly, I focus upon institutionalization as key to sustaining gains made by an
organizaiton in increasing it's capabilities.

Topics in this Section

Demin Maturity MODEL CMM CMMI People PMM ACMM IT ITIL CobIT Sustainin
g Cycle Modelin S --> CMM M Service Says g Gains
g s CMM

Deming Cycle
The concept underpinning many of the quality improvement methodology and approaches of the last
thiry years are rooted in Deming's "Plan Do Check Act"R approach to management.
What we are trying to
avoid by using the
PDCA discipline is
the "Ready, Fire,
Aim" fallacy where
people jump to the
solution without
identifying the
problem and
assessing if their
proposed solution
fixes it, or even
results in another
problem.
The Act step makes
sure we don't have to
fix it again in a
couple of years.

At a base level
PDCA forms the
theoretical
underpinning for
many process
Deming Cycle
improvement
methodologies.The
four major steps in
PDCA are:

1. PLAN
Identify the
Problem
o Sele
ct
probl
ems
to be
anal
yzed
and
esta
blish
a
preci
se
probl
em
state
ment
o Set
mea
sura
ble
goal
s for
the
probl
 em
solvi
ng
effort
o Esta
blish
a
proc
ess
for
coor
dinat
ing
with
and
gaini
ng
appr
oval
from
lead
ershi
p

Analyze the
Problem

o Ident
ify
the
proc
esse
s
that
impa
ct
the
probl
em
and
selec
t one
o List
the
step
s in
the
proc
ess
as it
curre
ntly
exist
s
o Ident
ify
pote
ntial
 caus
es of
the
probl
em
o Colle
ct
and
anal
yze
data
relat
ed to
the
probl
em
o Verif
y or
revis
e the
origi
nal
probl
em
state
ment
o Ident
ify
root
caus
es of
the
probl
em
2. DO
Develop
Solutions
o Esta
blish
criter
ia for
selec
ting
a
soluti
on
o Gen
erate
pote
ntial
soluti
ons
that
addr
ess
the
root
 caus
es of
the
probl
em
o Sele
ct a
soluti
on
o Plan
the
soluti
on
impl
eme
ntati
on

Implement a
Solution

o Impl
eme
nt
the
chos
en
soluti
on
on a
trial
or
pilot
basis
3. CHECK
Evaluate the
results
o Gath
er
data
on
the
soluti
on
o Anal
yze
the
data
on
the
soluti
on
4. ACT
Determine
Next Steps
o If the
 desir
ed
goal
was
not
achi
eved
,
repe
at
the
PDC
A
proc
ess
o If the
goal
was
achi
eved
,
ident
ify
syste
mic
chan
ges
need
ed
for
full
impl
eme
ntati
on
o Adop
t the
soluti
on
and
moni
tor
resul
ts
o Look
for
the
next
impr
ove
ment
oppo
rtunit
y
PDCA should be repeatedly implemented in spirals of increasing knowledge of the system that
converge on the ultimate goal, each cycle closer than the previousR. This approach is based on the
belief that our knowledge and skills are limited, but improving. Especially at the start of a project, key
information may not be known; the PDCA (ie., scientific method) - provides feedback to justify our
guesses (hypotheses) and increase our knowledge. Rather than enter "analysis paralysis" to get it
perfect the first time, it is better to be approximately right than exactly wrong. With the improved
knowledge, we may choose to refine or alter the goal (ideal state). Certainly, the PDSA approach can
bring us closer to whatever goal we choose.

Rate of change, that is, rate of improvement, is a key competitive factor in today's world. PDSA allows
for major 'jumps' in performance ('breakthroughs' often desired in a Western approach), as well as
Kaizen (frequent small improvements associated with an Eastern approach). In the United States a
PDSA approach is usually associated with a sizable project involving numerous people's time, and
thus managers want to see large 'breakthrough' improvements to justify the effort expended.
However, the Scientific Method and PDSA apply to all sorts of projects and improvement activities.

The power of Deming's concept lies in its apparent simplicity. The concept of feedback in the
Scientific Method, in the abstract sense, is today firmly rooted in education. While apparently easy to
understand, it is often difficult to accomplish on an on-going basis due to the intellectual difficulty of
judging one's proposals (hypotheses) on the basis of measured results. Many people have an
emotional fear of being shown "wrong," even by objective measurements. To avoid such
comparisons, we may instead cite complacency, distractions, loss of focus, lack of commitment, re-
assigned priorities, lack of resources, etc.

Deming CritiqueR
Deming's 14 pointsR
Watch Video of Deming's Impact on management

CMMI Background
The Deming Cycle's application was intended for quality control purposes and proposed continuous
improvement in quality of products/experiments. The cycle works well in this restricted application, but
not as well when applied to major organizational improvement. ISO recognized the need to provide
better guidance in this regard and published the ISO standard ISO 9004:2000, which replaced the use
of the term continuous improvement with continual improvementR. IT Service improvements may be
difficult to achieve if the organization's supporting processes aren't up to the task. The assessment
and improvement of a wide range of internal processes is the subject of process maturity models.
An awareness of (and perhaps a supporting strategic framework for) internal process capabilities is
crucial to the successful implementation of service improvement initiatives.R

The adaptation of the PDCA to a process maturity framework was the work of Watts Humphrey and
his colleagues at IBM® in the early 1980sR. Humphrey noticed that the quality of a software product
was directly related to the quality of the process used to develop it. Having observed the success of
total quality management in other parts of industry, Humphrey wanted to install a Shewart-Deming
improvement cycle (Plan-Do-Check-Act - PDCA) into a software organization as a way to continually
improve its development processes.

At the time of Humphrey's outline organizations had been installing advanced software technologies
for a decade using methods akin to the PDCA cycle but without much success. Humphrey’s unique
insight was that organizations had to eliminate implementation problems in a specific order if they
were to create an environment that supported continuous improvement. Hence, Humphrey concluded
that the Shewart-Deming cycle had to be installed in stages to systematically remove impediments to
continuous improvement.

This staged structure underlying the maturity framework was further elaborated by Crosby in "Quality
is Free". Crosby’s quality management maturity grid described five evolutionary stages in adopting
quality practices in an organization. This framework was then adapted to the software process by Ron
Radice and his colleagues working under the direction of Humphrey at IBM. Their model postulated
that the adoption of any new practice by an organization would occur in five stages. The organization
would...

 become aware of the new practice,

 then, learn more about it,
 then, try it in a pilot implementation,
 then, deploy it across the organization, and
 lastly, would achieve mastery in its use.

In Humphrey’s original maturity framework these stages would integrate principles from three domains
in vogue at the time:

1. the targeted domain of processes,

2. total quality management practices, and
3. organizational change.

1. CMM was designed to help an organization adopt best practices in

a targeted domain. The CMM for Software targeted software
engineering processes, while the People CMM targets workforce
management processes.
2. processes in the targeted domain are continuously improved to
become more effective and predictable using Total Quality
Management concepts
3. CMM constitutes a unique approach to organizational development
that introduces these practices in stages (maturity levels) to create a
succession of changes in the organization’s culture.

People CMM, Section 2, p.16

The movement through these stages can be represented graphically in Graphic 1 prepared by
Suzanne Garcia for Carnegie-Melon:R

Regardless of the target of

improvement, either an
individual process or an entire
organization, both continuous
and staged perspectives
of CMM Integrated reflect an
evolution along two dimensions
of interest that are notionally
captured in the figure to the left.
Using the staged model maturity
level terms, it illustrates an
evolution from the use of
primarily qualitative data or
opinion to much greater use of
quantitative data, and a cyclic
focus between process control
Graphic 1: Maturity Levels - Evolving Improvement Paradigms: Capability Maturity Models
and process improvement.
 An organization can have
process areas at different
maturity levels. graphic 2
illustrates one way of viewing
process (area)s at differing
maturity levels. Each diamond
notationally represents the
amount of focus needed on a
particular topic to achieve the
kinds of improvement shifts
highlighted in the quadrant
illustrated previously.

Nor do the characteristics of a

Graphic 2: Maturity Levels - Process at Different Stages process area imply identical
maturity requirements. Some
topics require a heavy focus
early on, and either continue in
that focus (see the diamond with
an elongated middle portion) or
require less focus to hang on to
the improvements achieved (see
diamonds with wide areas at the
bottom and narrower areas at
the top). Moreover. some topics
have other processes as
prerequisites for their
improvement to be successful,
and so their focus early on is
much lighter (indicated by a
space below the level at which
focus becomes plausible).

We might view each ITIL

process area as one of these
diamonds, or, if we wish, we
can express a more granular
approach, by selecting specific
activities within ITIL best
practice areas for review. The
choice is up to the organization
undertaking a service
improvement initiative.

The movement towards the top, right quadrant (ie. continual improvement through quantitative
analysis) is accompanied by a shift in the organization's cultural domain from reacting to events,
to proactively managing events and finally to predicting events and removing their cause before it
happens. In this migration the organization will exhibit the following characteristics:

Reactive Organizations
Complex distributed IT environments are typically the result of an evolutionary process.
Simple management solutions target specific components of the overall IT enterprise and
therefore most often involve point process and tool solutions in a narrow enclave of the IT
environment. Repeating this framework throughout the IT organization results in a
assemblage of processes and tools that are meshed together to provide service to particular
business lines. This model is common to large distributed IT environments and its evolution
closely parallels how distributed systems made their way into the IT enterprise in the first
 place. Over time, systems were released into the live infrastructure, supported by different
teams and imbuing to different technology standards and IT directions.

Likewise, networks, systems, databases and applications migrated into the production
business environment, with their own sets of standards, support and operational
characteristics, and this further confounds the multiplicity of unintegrated components. In this
state, when IT service is disrupted or degraded it is problematic to predict business impact.
Instead, the IT organization can only react when a failure or deterioration in service occurs.

Proactive Organizations
The proactive organization takes steps to eliminate failures and outage before they occur.
Proactive organizations will spend more time in analysis and invest in integrated tool sets to
provide the necessary information. Proactive organizations are more likely to have a robust
CMDB to provide robust information on the state of the infrastructure and to compile
availability and capacity data in associated databases. They will have a technical architecture
defining the management tools and technical integration points to enable efficient execution of
an integrated process structure.

Reaching this state requires a focus on workforce practices. There are likely to be
organizational changes that need to occur to align the people needed to execute the more
robust processes. Also, their is a need for more integrated management tools such as data
warehouses, analytical engines and simulation modeling.

In its initial implementation, the proactive organization will involve significant expenditure
because of the size of the investments required and the time lag between collecting
information and achieving a critical mass to make it useful. For example, the historical use of
incident data to identify problems requires a dedicated effort in properly recording symptoms,
actions and resolutions according to a coding scheme (such as Category, Type and Item) and
over a sufficient time interval to identify patterns. The organization seeking to be more
proactive will often be called upon to stay the course in the face of rising expenditures with
little initial return on the investment. While this may seem to be a complex task, a
methodology can be employed to provide a structured approach. This will typically be piloted
in trial areas so that benefits can be identified and quantified for further roll-out.

Predictive Organizations
Predictive organizations acquire the capability to predict the occurrence of events within the
infrastructure. The data warehouses provide the information necessary to utilize data mining
techniques to undertake simulation modeling of the environment. These models discover
interrelationships amongst events comprising the components of the infrastructure. Once
known, automated systems can monitor the enterprise and either resolve faults before they
impact business operations or provide alerts to that mitigating actions can be initiated.

Capability Maturity Models Today

Software Capability Maturity Model (CMM)
The original formulation of
the maturity framework
adopted Crosby’s approach
of evolving each process
through these five stages.
However, Humphrey
realized organizations were
not succeeding in long-term
adoption of improved
software development
practices when they applied
this maturity framework to
individual practices or
technologies.

Humphrey identified
serious impediments to
long-term adoption that had
to be eliminated if improved
practices were to thrive in
an organization. Since
many of these problems
were deeply ingrained in an
organization’s culture,
Humphrey realized that he
had to formulate an
approach that addressed
the organization, not just its
individual processes. The
success of software CMM
is demonstrated by the
following finding of the
Software Engineering
Institute.
Today, the SW-CMM is widely used for guiding software process
improvement programs both in the U.S. and abroad. Although originally
adopted by aerospace firms, the SW-CMM is now used in commercial
software and information systems organizations. After reviewing
improvement results from 14 companies, the SEI found that software
process improvement programs guided by the CMM achieved an average
return on investment of $5.70 saved for every $1 invested on SW-CMM-
based improvement.

People CMM - Section 2, p. 12

CMM Integrated (CMMI)

Many organizations wanted began to see that the methodology underscoring CMM had a much wider
applicability and began to devise CMM-like maturity outlines in other fields. Eventually, the differences
among discipline-specific models, including their architecture, content, and approach, limited the
ability to successfully focus improvements efforts,and, furthermore, applying multiple models which
lacked integration within and across an organization proved costly in terms of training, appraisals, and
improvement activities. Thus, an integrated model that addressed multiple disciplines proved highly
useful.

The aim of CMM Integrated, CMMI, was to provide guidance for improving an organization’s
processes and an ability to manage the development, acquisition, and maintenance of products or
services. CMMI places different approaches into a structure that assists an organization in assessing
it's organizational maturity or process area capability, establish priorities for improvement, and
implement these improvements.

The theoretical marriage involved in integrating the theory in different disciples led to the creation of
two 'streams' or representations. The Continuous representation allows an organization greater
flexibility in implementing CMMI methods. It suggests that an organization can select different
orderings of improvement initiatives. These orders will uniquely reflect the needs of the organization.

The Staged representation requires that certain improvements must occur first as necessary

conditions for subsequent improvements. This staged representation provides a sequence of
improvements, beginning with basic management practices and progressing through a pre-defined
and proven path of successive levels, each serving as a foundation for the next stage or maturity
level.

The CMMI disciple with the

greatest similarity to IT Service
Management processes
is Product and Process
Development (IPPD). This area
portrays systematic approach that
seeks a collaboration of relevant
stakeholders throughout the life
of the product to better satisfy
customer needs, expectations,
and requirements. The staged
representation organizes process
areas into five maturity levels
(with the same descriptors as for
Software CMM) to support and
guide process improvement. The
staged representation groups
process areas by maturity level,
indicating which process areas to
implement to achieve each
maturity level. Maturity levels
represent a process-improvement
path illustrating improvement
evolution for the entire
organization pursuing process
improvement.

The CMMI model describes

general and specific goals which
must be achieved to successfully
operate at a particular maturity
level. The features common to
the general functions are:

 the
organization's commitm
 ent to perform - ie.
management and staff
alignment and focus on
the goal and its'
fulfillment
 the
organization's ability to
perform - the existence
of particular tools and
skill sets necessary to
fulfill goals and
objectives
 the organization's
ability to direct and
complete
implementation on the
basis of a plan
 verification of when the
goal has been reached

The staged representation identifies the maturity levels through which an organization should evolve
to establish a culture of excellence. Because each maturity level forms a necessary foundation on
which to build the next level, trying to skip maturity levels is usually counter-productive However, it
should be recognized that process improvement efforts should focus on the needs of the organization
in the context of its business environment and that process areas at higher maturity levels may
address the current needs of an organization or project. For example, organizations seeking to move
from maturity level 1 to maturity level 2 are frequently told to establish a process group, which is
addressed by the Organizational Process Focus process area that resides at maturity level 3. While a
process group is not a necessary characteristic of a maturity level 2 organization, it can be a useful
part of the organization’s approach to achieving maturity level 2.

Each maturity level in CMMI is characterized by defined processes.

Maturity Description Processes

Level

Incomplete A process that is either non No articulated description(s)

existent or only partially
performed. It fails to meet the
criteria established for a
Performed process.

Performed A performed process supports and Practices are informal.

enables the work needed to
produce identified output work
products using identified input
work products. Practices can be
informal - ie., without following a
documented process description
or plan. The rigor with which
these practices are performed
depends on the individuals
managing and performing the
 work and may vary considerably.
Note
Process meets expectations of
deliverables - ie. it is performed..
ManagedN A performed process that is
planned and executed in
accordance with policy, employs
skilled people having adequate
resources to produce controlled
outputs, involves relevant
stakeholders; is monitored,
controlled, and reviewed; and is
evaluated for adherence to its
process description. The process
may be instantiated by an
individual project, group, or
organizational function.
Management of the process is
concerned with the
institutionalization of the process
area and the achievement of other
specific objectives established for
the process, such as cost,
schedule, and quality objectives.
A managed process is planned and
the performance of the process is
managed against the plan.
Corrective actions are taken when
the actual results and performance
deviate significantly from the
plan. The objectives for the
process are determined based on
an understanding of the project’s Generic Practices
or organization’s particular needs.
Objectives may be quantitative or
qualitative and may be unique to
the individual process or defined
for a broader set of processes with
each individual processes
contributing to achieving the
objectives for the set.
The control provided by a
managed process helps ensure
process stability in times of crisis.
The delivery of IT services are
made aware to management at
pre-defined milestones and
Engineering
 Requirements Management - manage the
requirements of project products and product
components and identify inconsistencies between
requirements and project plans and work products.
Project Management
 Project Planning - establish and maintain plans
that define project activities.
 Project Monitoring & Control - maintain
awareness and understanding of project progress so
that corrections can be taken when project
performance deviates significantly from plan.
 Supplier Agreement Management - acquire
products from suppliers through formalized
agreements.
Support
 Measurement & Analysis - develop and sustain a
measurement capability that is used to support
management information needs.
 Process & Product Quality Control - provide
staff and management with objective insight into
processes and associated work products.
 Configuration Management - establish and
maintain the integrity of work products.
 Establish an Organizational Policy - Establish
and maintain an organizational policy for planning
and performing the process.
 Plan the Process - Establish and maintain the plan
for performing the process.
 Provide Resources - Provide adequate resources
for performing the process, developing the work
products, and providing the services of the process.
 Assign Responsibility - Assign responsibility and
authority for performing the process, developing
the work products, and providing the services of
the process.

commitments are established
among those performing the work
and relevant stakeholders. process
outputs are reviewed with
stakeholders.
Note
Development of basic
management and project
management capabilities in order
to implement initiatives properly.
Establishment of 1 engineering, 3
project management, 3 support
processes and 10 generic
practices.
Defined A managed process that is tailored Engineering
from the organization's set of
standard processes according to
the organization’s tailoring
guidelines, and contributes
outputs, measures, and other
process -improvement information
to the organizational process
assets.
The set of standard processes,
which are the basis of the defined
process, are established and
improved over time. Standard
processes document fundamental
process elements and describe
relationships (e.g., the ordering
and interfaces) amongst the
process elements. The corporate
infrastructure to support current
and future use of the set of
standard processes is established
and improved over time.
Process assets are artifacts that
relate to describing,
implementing, and improving
processes. They
are assets because they facilitate
meeting the business objectives,
and represent investments that are
expected to provide current and
 Train People - Train the people performing or
supporting the process as needed.
 Manage Configurations - Place designated work
products of the process under appropriate levels of
configuration management
 Identify and Involve Relevant Stakeholders -
Identify and involve the relevant stakeholders as
planned.
 Monitor and Control the Process - Monitor and
control the process against the plan for performing
the process and take appropriate corrective action.
 Objectively Evaluate Adherence - Objectively
evaluate adherence of the process against its
process description, standards, and procedures, and
address noncompliance.
 Review Status with Higher Level Management -
Review the activities, status, and results of the
process with higher level management and resolve
issues.
 Requirements Development - produce and
analyze customer, product, and product-component
requirements.
 Technical Solution - design, develop, and
implement solutions to requirements. Solutions,
designs, and implementations encompass products,
product components, and product-related lifecycle
processes either singly or in combinations as
appropriate.
 Product Integration - assemble the product from
the product components, ensure that the product, as
integrated, functions properly, and deliver the
product.
 Verification - ensure that selected work products
meet their specified requirements.
 Validation - demonstrate that a product or product
component fulfills its intended use when placed in
its intended environment.
Process Management
 Organizational Process Focus - plan and
implement organizational process improvement
based on a thorough understanding of the current
strengths and weaknesses of the processes and
process assets.
 Organizational Process Definition - establish and
maintain a usable set of organizational process
assets.

future business value.
Note
The establishment of 14 processes
at this maturity level imply an
emphasis within CMMI on
attainment of this maturity level.
The process breakdown (5 in
engineering, 4 in project
management and 2 in support
process areas) reflect an ordering
suggesting the the immediate
infusion of additional capabilities
in these areas to achieve this level
of capability. This is accompanied
by basic introduction of 3 "basic"
process management process
areas. Two additional generic
practices augment the biggest and
most comprehensive stage of
maturity in CMMI.
Quantitatively A defined process that is
Managed controlled using statistical and
other quantitative techniques.
Quantitative objectives for quality
and process performance are
established and used as criteria in
managing the process. The quality
and process performance are
understood in statistical terms and
are managed throughout the life of Project Management
the process.
 Organizational Training - establish and to
develop the skills and knowledge of people so they
can perform their roles effectively and efficiently.
Project Management
 Integrated Project Management for IPPD -
establish and manage the project and the
involvement of the relevant stakeholders according
to an integrated and defined process that is tailored
from the organization's set of standard processes.
 Risk Management - identify potential problems
before they occur, so that risk-handling activities
may be planned and invoked as needed across the
life of the product or project to mitigate adverse
impacts on achieving objectives.
 Integrated Teaming - form and sustain an
integrated team for the development of work
products.
 Integrated Supplier Management - proactively
identify sources of products that may be used to
satisfy the project’s requirements and to manage
selected suppliers while maintaining a cooperative
project-supplier relationship.
Support
 Decision Analysis & Resolution - analyze
possible decisions using a formal evaluation
process that evaluates identified alternatives
against established criteria.
 Organizational Environment for Integration -
provide an Integrated Product and Process
Development (IPPD) infrastructure and manage
people for integration.
Generic Practices
 Establish a Defined Process - establish and
maintain a description of the process that is tailored
from the organization's set of standard processes to
address the needs of a specific instantiation.
 Collect Improvement Data - collect information
and artifacts derived from planning and performing
the process.
Process Management
 Organizational Process Performance - establish
and maintain a quantitative understanding of the
performance of the set of standard processes in
support of quality and process-performance
objectives, and to provide the process performance
data, baselines, and models to quantitatively
manage the organization’s projects.
 The quantitative objectives are
based on the capability of the set
of standard processes, the
business objectives, and the needs
of the customer, end users,
organization, and process
implementers, subject to resource
availability.
Note
This maturity level augments
process and project management
capabilities to reflect quantitative
emphasis.
Optimizing An optimizing process is a
quantitatively managed process
that is changed and adapted to
meet relevant current and
projected business objectives. An
optimizing process focuses on
continually improving the process
performance through both
incremental and innovative
technological improvements.
Process improvements that would
address root causes of process
variation and measurably improve
the organization’s processes are
identified, evaluated, and
deployed as appropriate. These
improvements are selected based
on a quantitative understanding of  Ensure Continuous Process Improvement -
their expected contribution to
achieving process-improvement
objectives versus the cost and
impact to the organization.
Selected incremental and
innovative technological process
improvements are systematically
managed and deployed and the
effects of the deployed process
improvements are measured and
evaluated against the quantitative
process-improvement objectives.
Note
 Quantitative Project Management -
quantitatively manage the project’s defined process
to achieve the project’s established quality and
process-performance objectives.
Generic Practices
 Establish Quantitative Objectives for the
Process - determine and obtain agreement from
relevant stakeholders about specific quantitative
objectives for the process. These quantitative
objectives can be expressed in terms of product
quality, service quality, and process performance.
 Stabilize Sub-process Performance - stabilize the
performance of one or more sub-processes of the
defined (capability level 3) process that are critical
contributors to the overall performance using
appropriate statistical and other quantitative
techniques.
Process Management
 Innovation & Deployment - select and deploy
incremental and innovative improvements that
measurably improve the organization's processes
and technologies. The improvements support the
organization's quality and process performance
objectives as derived from the organization's
business objectives.
Support
 Causal Analysis & Resolution - identify causes of
defects and other problems and take action to
prevent them from occurring in the future.
Generic Practices
select and systematically deploy process and
technology improvements that contribute to
meeting established quality and process-
performance objectives.
 Correct Root Causes of Problems - analyze
defects and other problems that were encountered,
to correct the root causes of these types of defects
and problems, and to prevent these defects and
problems from occurring in the future.
 This maturity level emphasizes
root cause identification and the
removal of process variances.
Completion of Process and
Support processes to reflect this
and 2 generic practices to
institutionalize the developed
processes.

CMMI Version 3, Continuous Representation, Chapter 4

Visit Terraquest web site for a comprehensive description of CMMI Practice Areas

People Capability Maturity Model (P-CMM) R

The People Capability Maturity Model (People CMM) is a road map for implementing workforce
practices that continuously improve the capability of an organization’s workforce. It is vitally important
for process improvement because it enables the defined organization. Many organizations
undertake extensive process mapping of current and envisioned processes only to find they either
cannot achieve the conceived process or fail to maintain the desired improvements if they are
momentarily achieved. One frequent reason for this "backsliding" is that the achievement
of Organizational Process Definition capability must be accompanied by realization
of Organizational Process Focus; - ie., the continuing ability to utilize the process descriptions.

The People CMM's primary objective is to improve the capability of the

workforce. Workforce capability can be defined as the level of knowledge,
skills, and process abilities available for performing an organization's
business activities. Workforce capability indicates an organization's:

 readiness for performing its critical business activities,

 likely results from performing these business activities, and
 potential for benefiting from investments in process improvement
or advanced technology.

Part One. The People Capability Maturity Model: Background, Concepts, Structure, and Usage, p. 4

P-CMM place in establishing the necessary foundation for successfully implementing service
improvement initiatives like ITIL or CobIT is evident in the following quotation from P-CMM.

Changing an organization’s culture through staged improvements to its

operating processes is a unique approach to organizational development.
These cultural changes provide much of the CMM’s power
for implementing lasting improvements and distinguish it from other quality
and process improvement standards. Although many process standards can
transform an organization’s culture, few include a road map for
implementation. Consequently, organizations often fail to implement the
standard effectively because they attempt to implement too much too soon
and do not lay the right initial foundation of practices.
 People CMM - Section 2, p. 16

The overall goal of P-CMM is embodied in the following excerpt.

As an organization adopts the practices that satisfy the goals of the

People CMM’s process areas, it establishes the shared patterns of
behavior that underlie a culture of professionalism dedicated to
continuous improvement.

People CMM - Section 2, p. 16

Since an organization cannot implement all of the best workforce practices in an afternoon, the
People CMM introduces them in stages. Each progressive level of the People CMM produces a
unique transformation in the organization's culture by equipping it with more powerful practices for
attracting, developing, organizing, motivating, and retaining its workforce. Thus, the People CMM
establishes an integrated system of workforce practices that matures through increasing alignment
with the organization's business objectives, performance, and changing needs.

Workforce capability can be defined as the level of knowledge, skills, and process abilities available
for performing an organization's business activities. Workforce capability indicates an organization's:

 readiness for performing its critical business activities,

 likely results from performing these business activities, and
 potential for benefiting from investments in process improvement or advanced technology.
People CMM
describes an
evolutionary
improvement
path from ad
hoc,
inconsistently
performed
workforce
practices, to a
mature
infrastructure of
practices for
continuously
elevating
workforce
capability. The
philosophy
underlying People CMM can be summarized in ten principles.

1. In mature organizations, workforce capability is directly related to business performance.

2. Workforce capability is a competitive issue and a source of strategic advantage.
3. Workforce capability must be defined in relation to the organization's strategic business
objectives.
4. Knowledge-intense work shifts the focus from job elements to workforce competencies.
5. Capability can be measured and improved at multiple levels, including individuals,
workgroups, workforce competencies, and the organization.
 6. An organization should invest in improving the capability of those workforce competencies
that are critical to its core competency as a business.
7. Operational management is responsible for the capability of the workforce.
8. The improvement of workforce capability can be pursued as a process composed from
proven practices and procedures.
9. The organization is responsible for providing improvement opportunities, while individuals are
responsible for taking advantage of them.
10. Since technologies and organizational forms evolve rapidly, organizations must continually
evolve their workforce practices and develop new workforce competencies.

Like all Maturity models, each maturity level in P-CMMM has specific process requirements which
must be adequately performed to achieve that maturity level.

Maturity Description Processes

Level

Managed Process Areas focus on establishing
a foundation of basic workforce
practices that can be continuously
improved to develop the capability
of the workforce. This foundation
of practices is initially built within
units to instill a discipline for
managing people and to provide a
supportive work environment with
adequate work resources. The unit
balances work commitments with
available resources. Qualified
people are recruited, selected, and
transitioned into assignments within
the unit. Performance objectives are
established for the committed work,
and performance is periodically
discussed to identify actions that
can improve it. Individuals develop
interpersonal communication skills
to ensure that work dependencies
are coordinated effectively. The
knowledge and skills required for
performing assignments are
identified and appropriate training
and development opportunities are
provided. The compensation is
based on an articulated strategy and
is periodically adjusted to ensure
equity.
 Staffing - establish a formal process by which
committed work is matched to unit resources and
qualified individuals are recruited, selected, and
transitioned into assignments.
 Communication and Coordination - establish
timely communication across the organization and to
ensure that the workforce has the skills to share
information and coordinate their activities
efficiently.
 Work Environment - establish and maintain
physical working conditions and to provide
resources that allow individuals and workgroups to
perform their tasks efficiently and without
unnecessary distractions.
 Performance Management - establish objectives
related to committed work against which unit and
individual performance can be measured, to discuss
performance against these objectives, and to
continuously enhance performance.
 Training and Development - ensure that all
individuals have the skills required to perform their
assignments and are provided relevant development
opportunities.
 Compensation - provide all individuals with
remuneration and benefits based on their
contribution and value to the organization.

Defined Process Areas focus on establishing
an organizational framework for
developing the workforce. The
organization identifies the
knowledge, skills, and process
abilities that underlie the workforce
 Competency Analysis - identify the knowledge,
skills, and process abilities required to perform the
organization’s business activities so that they may be
developed and used as a basis for workforce
practices.
 Workforce Planning - coordinate workforce
activities with current and future business needs at
 competencies needed to perform its
business activities. The
organization develops strategic
plans for the workforce needed to
accomplish current and future
business objectives. Development
opportunities are established for
assisting individuals in improving
their capability in these workforce
competencies. Graduated career
opportunities are developed around
growth in one or more workforce
competencies. The workforce
practices implemented at Level 2
are adjusted to motivate and
support development in the
organization’s workforce
competencies. The process abilities
defined for each workforce
competency are used for tailoring
defined processes and establishing
roles that provide the next step in
workgroup development. A
participatory culture is established
that enables the most effective use
of the organization’s talent for
making decisions and executing
work.
Predictable Process Areas focus on exploiting
the knowledge and experience of
the workforce framework
developed at Level 3. The
competency-based processes used
by different workforce
competencies are interwoven to
create integrated, multi disciplinary
processes. Workgroups are
empowered to manage their own
work processes and conduct some
of their internal workforce
activities. The artifacts produced
through the performance of
competency-based processes are
captured and developed for reuse.
Individuals and workgroups
quantitatively manage the
competency-based processes that
are important for achieving their
performance objectives. The
organization manages the capability
of its workforce and of the
competency-based processes they
perform. The effect of workforce
both the organizational and unit levels.
 Competency Development - constantly enhance the
capability of the workforce to perform their assigned
tasks and responsibilities.
 Career Development - ensure that individuals are
provided opportunities to develop workforce
competencies that enable them to achieve career
objectives.
 Competency-Based Practices - ensure that all
workforce practices are based in part on developing
the competencies of the workforce.
 Workgroup Development - organize work around
competency-based process abilities.
 Participatory Culture - allows the organization to
exploit the full capability of the workforce for
making decisions that affect the performance of
business activities.
 Competency Integration - improve the efficiency
and agility of interdependent work by integrating the
process abilities of different workforce
competencies.
 Empowered Workgroups - invest workgroups with
the responsibility and authority for determining how
to conduct their business activities most effectively.
 Competency-Based Assets - capture the knowledge,
experience, and artifacts developed in performing
competency-based processes for use in enhancing
capability and performance.
 Quantitative Performance Management - predict
and manage the capability of competency-based
processes for achieving measurable performance
objectives.
 Organizational Capability Management - quantify
and manage the capability of the workforce and of
the critical competency-based processes they
perform.
 Mentoring - transfer the lessons of greater
experience in a workforce competency to improve
the capability of other individuals or workgroups.
 practices on these capabilities is
evaluated and corrective actions
taken if necessary. Mentors use
infrastructure provided by the
organization’s workforce
competencies to assist individuals
and workgroups in developing their
capability.

Optimizing Process Areas focus on continually  Continuous Capability Improvement - provide a

improving the organization’s foundation for individuals and workgroups to
capability and workforce practices. continuously improve their capability for performing
Individuals continually improve the competency-based processes.
personal work processes they use in  Organizational Performance Alignment - enhance
performing competency based the alignment of performance results across
processes. Workgroups individuals, workgroups, and units with
continuously improve their organizational performance and business objectives.
operating processes through  Continuous Workforce Innovation - identify and
improved integration of the evaluate improved or innovative workforce practices
personal work processes of their and technologies, and implement the most promising
members. The organization ones throughout the organization.
evaluates and improves the
alignment of performance among
its individuals, workgroups, and
units both with each other and with
the organization’s business
objectives. The organization
continually evaluates opportunities
for improving its workforce
practices through incremental
adjustments or by adopting
innovative workforce practices and
technologies.

People CMM

Project Management Maturity Models

The Project Management area in CMMI provided the theoretical impetus for a more exacting scrutiny
by the large project management practitioners in the United states and Britain. The Project
Management Institute (PMI) has maintained the standard for project management - the Project
Management Book of Knowledge (PMBOK)N. PMBOK divides project management into 8 primary
"knowledge areas"N

Organizational Project Management Maturity Model (OPM3) R

In 1998 and based upon CMM initiatives as described aboveN, the project Management Institute (PMI)
Standards Committee commenced a project to develop its' own maturity model. While PMI's "A Guide
to the Project Management Body of Knowledge" or PMBOK® Guide was widely used at that time as
the standard for managing single projects, no standards existed for improving project management in
organizations.
OPM3 provides a framework for advancing project management improvement within an organization.
It is roughly based on the Software Engineering Institute's (SEI) Capability Maturity Model's (CMM®)
five evolutionary maturity levels, and examines maturity development across nine knowledge areas in
PMBOK R. OPM3 integrates standards for project and process management, the PMBOK Guide and
CMM, respectively, to provide a plan for advancing organizational project management maturity.

Within OPM3, best practices are obtained by

demonstrating mastery of a series of Capabilities that
incrementally indicate the achievement of
progressively higher levels of maturity.
A Capability is demonstrated by the existence of
corresponding Outcome(s) as demonstrated on the left.
An Outcome is the tangible or intangible result of
demonstrating or applying a Capability. Every
Outcome should have a Key Performance Indicator
(KPI), which represents the means to measure an
Outcome.

The OPM3 standard goes further by outlining the

dependencies among the best practices. This
complexity allows organizations trying to improve
project management services to understand all of the
Capabilities that may impact the achievement of a
specific project management area.

An OPM3 assessment element provides a means to

navigate these components and compare an
organization against industry averages according to the
PMBOK Guide Process Groups N. This initial high-
level assessment provides a macro look at an
organization's organizational project management
maturity.

The identification of dependencies between the

Capabilities, the use of multiple categorizations for
both Best Practices and Capabilities, and the provision
to conduct both high level and detailed assessments
collectively provide organizations with flexibility in
analyzing the results of their assessment and
developing a detailed improvement plan.
Project Management Maturity Model (PMMM)
In Britain, the CCTA (to become the OGC) promoted Projects in Controlled Environments PRINCE2
as a tailored version of Project Management processes. It remains a widely accepted and utilized
standard by the UK Government and is widely recognized and used in the private sector, both in the
UK and internationally. N.

Consistent with an evolving recognition of maturity modeling the Office of Government Commerce in

Great Britain
introduced a government standard Project Management Maturity Model (PMMM), designed to
measure
project management maturity across the wider organization and the effectiveness of the project output
s and outcomes. Like, OPM3, it was based upon PMBOK..

PM Maturity Levels N
Levels of PMMM Level 1 Level 2 Level 3 Level 4 Level 5
 Initial Structured Organizational Managed Optimized
Process & Standards &
Standards Institutionalize
d Process

IntegrationN No established Basic, Project Processes/ Project

practices, documented integration standards utilized integration
standards, or processes efforts by all projects and improvement
Project Office. for project institutionalize integrated with procedures
Work planning and d with other corporate utilized.
performed in reporting. procedures processes/systems Lessons
ad hoc Management and standards. . Decisions based learned
fashion. only involved Project Office on performance regularly
on high beginning to metrics. examined and
visibility integrate used to
projects. project data. improve
documented
processes.

ScopeN General Basic scope Full project Project Effectiveness

statement of management management management and efficiency
business process in process processes used on metrics drive
requirements. place. Scope documented all projects. project scope
Little/no scope management and utilized by Projects managed decisions by
management techniques most projects. and evaluated in appropriate
or regularly Stakeholders light of other levels of
documentation applied on actively projects. management.
. Management larger, more participating in Focus on high
aware of key visible scope utilization of
milestones projects. decisions. value.
only.

TimeN No established Basic Time Time management Improvement

planning or processes management utilizes historical procedures
scheduling exist but not processes data to forecast utilized for
standards. required for documented future time
Lack of planning and and utilized by performance. management
documentation scheduling. most projects. Management processes.
makes it Standard Organization decisions based on Lessons
difficult to scheduling wide efficiency and learned are
achieve approaches integration effectiveness examined and
repeatable utilized for includes inter- metrics. used to
project large, visible project improve
success. projects. dependencies. documented
processes.

CostN No established Processes Cost Cost planning and Lessons

practices or exist for cost processes are tracking integrated learned
standards. estimating, organizational with Project Office, improve
Cost process reporting, standard and financial, and documented
documentation and utilized by human resources processes.
is ad hoc and performance most projects. systems. Management
individual measuremen Costs are fully Standards tied to actively uses
project teams t. Cost integrated into corporate efficiency and
follow informal management project office processes. effectiveness
 practices. processes resource metrics for
are used for library. decision-
large, visible making.
projects.

QualityN No established Basic Quality All projects The quality

project quality organization process is well required to use process
practices or al project documented quality planning includes
standards. quality policy and an standard guidelines for
Management has been organizational processes. The feeding
is considering adopted. standard. Project Office improvements
how they Management Management coordinates quality back into the
should define encourages involved in standards and process.
“quality.” quality policy quality assurance. Metrics are
application oversight for key to product
on large, most projects. quality
visible decisions.
projects.

HRN No repeatable Repeatable Most projects Resource Process

process process in follow forecasts used for engages
applied to place that established project planning teams to
planning and defines how resource and prioritization. document
staffing to plan and management Project team project
projects. manage the process. performance lessons
Project teams human Professional measured and learned.
are ad hoc. resources. development integrated with Improvements
Human Resource program career are
resource time tracking for establishes development. incorporated
and cost is not highly visible project into human
measured. projects only. management resources
career path. management
process.

CommunicationsN There is an ad Basic Active Communications An

hoc process is involvement management plan improvement
communicatio established. by is required for all process is in
ns process in Large, highly management projects. place to
place whereby visible for project Communications continuously
projects are projects performance plans are improve
expected to follow the reviews. Most integrated into project
provide process and projects are corporate communicatio
informal status provide executing a communications ns
to progress formal project structure. management.
management. reporting for communicatio Lessons
triple ns plan. learned are
constraints. captured and
incorporated.

RiskN No established Processes Risk Management is Improvement

practices or are management actively engaged in processes are
standards in documented processes are organization-wide utilized to
place. and utilized utilized for risk management. ensure
Documentatio for large most projects. Risk systems are projects are
n is minimal projects. Metrics are fully integrated with continually
 and results are Management used to time, cost, and measured and
not shared. consistently support risk resource systems. managed
Risk response involved with decisions at against value-
is reactive. risks on the project and based
large, visible the program performance
projects. levels. metrics.

Procurement/ No project Basic Process an Make/buy Procurement

VendorN procurement process organizational decisions are process
process in documented standard and made with an reviewed
place. for used by most organizational periodically.
Methods are procurement projects. perspective. On-going
ad hoc. of goods and Project team Vendor is process
Contracts services. and integrated into the improvements
managed at a Procurement purchasing organization’s focus on
final delivery process department project procurement
level. mostly integrated in management efficiency and
utilized by the mechanisms. effective
large or procurement metrics.
highly visible process.
projects.

View PMMM vs 5.0 from CCTA OGC

Architecture Maturity Model R

The success of maturity models is demonstrated by the policy in the United States Government that
all US Federal Agencies were to provide Maturity Models and ratings as part of their IT investment
management and audit requirements. In particular, the US Department of Commerce (DoC)
developed an IT Architecture Capability Maturity Model (ACMM) to aid in conducting internal
assessments. The ACMM provides a framework that represents the key components of a productive
IT Architecture process. The goal is to enhance the overall odds for success of IT Architecture by
identifying weak areas and providing a defined evolutionary path to improving the overall Architecture
process.
The Department of
Commerce IT Architecture
Capability Maturity Model
consists of six levels and
nine architecture
characteristics. The six
levels are highlighted on
the left. The nine IT
Architecture
Characteristics are:

 IT Architecture
Process
 IT Architecture
Development
 Business Linkage
 Senior
Management
Involvement
 Operating Unit
Participation
 Architecture
Communication
 IT Security
 Architecture
Governance
 IT Investment
and Acquisition
Strategy
Architecture 1 Initial 2 Under 3 Defined 4 Managed 5 Optimizing
Characteristics Development

Architecture Process Exists in ad- Being actively well defined IT Architecture optimize and
hoc or localized developed. and process is part continuously
form or early Basic IT communicated of the culture, improve
draft form may Architecture to IT staff and with strong architecture
exist. Some IT Process business linkages to process.
Architecture program is management other core IT
processes are documented with Operating and business
defined. There based on OMB Unit IT processes.
is no unified Circular A-130 responsibilities. Quality metrics
architecture and Department The process is associated with
process across of Commerce largely the architecture
technologies or IT Architecture followed. process are
business Guidance. The captured. These
processes. architecture metrics include
Success process has the cycle times
depends on developed clear necessary to
individual roles and generate IT
efforts. responsibilities. Architecture
revisions,
technical
environment
 stability, and
time to
implement a
new or
upgraded
application or
system.

Architecture Development IT Architecture IT Vision, Gap Analysis documentation Defined and

processes, Principles, and Migration is updated on a documented IT
documentation Business Plan are regular cycle to Architecture
and standards Linkages, completed. reflect the metrics are
are established Baseline, and Architecture updated IT used to drive
by a variety of Target standards Architecture. continuous
ad hoc means Architecture are linked to Business, process
and are identified. Business Information, improvements.
localized or Architecture Drivers via Application and A standards
informal. standards exist, Best Practices, Technical and waivers
but not IT Principles Architectures process is used
necessarily and Target defined by to improve
linked to Target Architecture. appropriate de- architecture
Architecture. Fully jure and de- development
Technical developed facto standards. process
Reference Technical The improvements.
Model and Reference architecture
Standards Model and continues
Profile Standards alignment with
framework Profile. The the DoC and
established. architecture Federal
aligns with the Enterprise
DoC and Architectures.
Federal An automated
Enterprise tool is used to
Architectures. improve the
usability of the
architecture.

Business Linkage Minimal, or Explicit linkage integrated with Capital Architecture

implicit linkage to business capital planning planning and process metrics
to business strategies. and investment investment are used to
strategies or control and control are optimize and
business supports e- adjusted based drive business
drivers. government. on the feedback linkages.
Explicit linkage received and Business
to business lessons learned involved in the
drivers and from updated continuous
information IT process
requirements. Architecture. improvements
Periodic re- of IT
examination of Architecture.
business
drivers.

Senior-Management What is Management Senior- Senior Senior-

Involvement Architecture? awareness of management management management
 Why do we Architecture team aware of reviews team directly
need it? effort. Much and supportive architecture and involved in the
Limited nodding of of the variances. optimization of
management heads. enterprise-wide the enterprise-
team awareness Occasional/ architecture wide
or involvement selective process. architecture
in the management Management development
architecture team actively process and
process. involvement in supports governance.
the architecture architectural
process with standards.
various degrees
of commitment/
resistance.

Operating Unit Limited IT Architecture Most elements The entire Feedback on

Participation Operating Unit responsibilities of Operating Operating Unit architecture
acceptance of are assigned Unit show accepts and process from
the IT and work is acceptance of actively all Operating
Architecture underway. or are actively participates in Unit elements
process. We There is a clear participate in the IT is used to drive
support the understanding the IT Architecture architecture
architecture of where the Architecture process. process
process as long organization=s process. improvements.
as it represents architecture is Recognition
the standards at present time. that
we have Recognition architectural
already chosen. that it is painful standards can
Standards will supporting too reduce
only inhibit our many kinds of integration
ability to technologies. complexity and
deliver business Perhaps tired of enhance overall
value. distributing ability to
Anot fully- Operating Unit
developed or IT to achieve
tested business goals.
applications@
to Operating
Unit IT
operations and
support.

Architecture Little The Operating Architecture Architecture Architecture

Communication communication Unit documents documents are documents are
exists about the Architecture updated and updated used by every
IT Architecture Home Page, expanded regularly, and decision maker
process and which can be regularly on frequently in the
possible accessed from DoC IT reviewed for organization for
process the DoC IT Architecture latest every IT-
improvements. Architecture Web Page. architecture related business
The DoC IT Web Page is Tools are used developments/ decision.
Architecture updated to support standards.
Web Page periodically and maintaining Regular
contains the is used to architecture presentations to
latest version of document documentation. IT staff on
 the Operating architecture Periodic Architecture
Unit=s IT deliverables. presentations to content.
Architecture Few tools (e.g., IT staff on Organizational
documentation. office suite, Architecture personnel
graphics content. understand the
packages) are architecture and
used to its uses.
document
architecture.
Communication
about
architecture
process via
meetings, etc.,
may happen,
but sporadic.
May have been
handed out to
IT staff.

IT Security considerations IT Security IT Security Performance Feedback from

are ad hoc and Architecture has Architecture metrics IT Security
localized. defined clear Standards associated with Architecture
roles and Profile is fully IT Security metrics are
responsibilities. developed and Architecture used to drive
is integrated are captured. architecture
with IT process
Architecture. improvements.

Governance No explicit Governance of Explicit Explicit Explicit

governance of a few documented governance of governance of
architectural architectural governance of all IT all IT
standards. standards (e. g. majority IT investments. investments. A
Limited desktops, investments. Formal standards and
agreement with database Formal processes for waivers process
governance management processes for managing is used to
structure. systems) and managing variances feed improve
some adherence variances. back into IT architecture
to existing Senior Architecture. development
Standards management Senior- and governance
Profile. team is management - process
Variances may supportive of team takes improvements.
go undetected enterprise-wide ownership of
in the design architecture enterprise-wide
and standards and architecture
implementation subsequent standards and
phases. Various required governance
degrees of compliance. structure.
understanding
of the proposed
governance
structure.

IT Investment and strategic Little or no IT acquisition All planned IT Operating Unit

Acquisition Strategy planning and formal strategy exists acquisitions are has no
 acquisition governance of and includes guided and unplanned IT
personnel in IT Investment compliance governed by investment or
enterprise and Acquisition measures to IT the IT acquisition
architecture Strategy. Enterprise Architecture. activity.
process. Little Operating Unit Architecture. RFI and RFP
or no adherence demonstrates Operating Unit evaluations are
to existing some adherence adheres to integrated into
Standards to existing existing the IT
Profile. Standards Standards Architecture
Profile. Profile. RFQ, planning
RFI and RFP activities.
content is
influenced by
the IT
Architecture.
Acquisition
personnel are
actively
involved in IT
Architecture
governance
structure. Cost-
benefits are
considered in
identifying
projects.

IT Service Capability R
Between 1995 and 1999, two research projects were carried out in the Netherlands by three Dutch
companies and three Dutch universities. Both projects were sponsored by the Dutch Ministry of
Economic Affairs and had the goal of developing methods and techniques for improving IT services. A
number methods and techniques were researched leading to an observation of significant variability in
an organization's ability to enact service management practices. This led us to the hypothesis that
some IT service providers were more mature than other IT service providers.

Termed the Kwintes project, it led to efforts to describe the maturity of IT service providers. A group of
experts on IT service management and on the Software CMM developed a first sketch of the IT
Service CMM and a detailed specification of the level two key process areas. In September 2000, a
follow-up project was started, aimed at further specifying level three of the IT Service CMM.

The IT Service CMM is a maturity growth model, consisting of five maturity levels. Each maturity level
describes a stage in the maturity of an IT service provider:

1. Organizations at level one are characterized by working in an ad hoc manner and by

unpredictable performance. If IT services are delivered successfully, it is because of individual
heroism.
2. Organizations at level two, the repeatable level, deliver services with a repeatable quality.
That is, they can repeat earlier successful performances in similar circumstances.
3. The Defined level, is aimed at standardization of services. Organizations at level three employ
standard processes to deliver standard services and have implemented organization-wide
processes to train employees and manage resources and problems.
 4. The Managed level, is aimed at attaining quantitative control over the IT service processes.
5. The optimizing level, is aimed at continuous process improvement.
Key Practices
Each maturity level (except for level one) contains a number of key process areas. To reach a certain
maturity level, each of the key process areas of that level and lower levels has to be working
properlyN. A key process area consists of goals and activities, called key practices. An organization
that implements all activities from a certain key process area is expected to also reach the goals of
that key process area. The IT Service CMM distinguishes between five kinds of practicesN.

IT Service Management Processes By Maturity level

Maturity Description Processes
Level

Repeatable A Repeatable Service is aimed at  Service Commitment Management - to ensure

implementing a number of basic
capabilities that every IT service
providers needs, and that are needed
for every IT service. There are two
primary kinds of processes that an
organization has to implement at
this level:
 Service Management: the
planning, specification,
tracking and evaluation of
services. The service provider
and the customer draw up an
agreement about the services to
be delivered, the quality of the
services – specified in terms of
service levels – and the costs
of the services (Service
Commitment Management).
To ensure that the service
levels are realistic, the service
provider draws up a service
plan that shows the feasibility
of the service levels (Service
Delivery Planning). During
service delivery, the service
provider tracks the realized
service levels and reports these
to the customer on a regular
basis to demonstrate that the
provider has indeed delivered
the services against the
promised service levels
(Service Tracking and
Oversight). After a period of
service provision, the customer
and the service provider review
the service level agreement to
see whether it still conforms to
the IT needs of the customer
(Service Commitment
Management). Just like the
that service commitments are based on the
current and future IT service needs of the
customer.
 Service Delivery Planning - ensures that the
service delivery planning is developed in
accordance with the service commitments and
that internal commitments are secured.
 Service Tracking and Oversight - During
service delivery, performance is monitored to
enable corrective actions before the service
commitments are breached. In addition, the
tracking forms the basis for service reports to the
customer.
 Service Sub-contract Management - Parts of
the service that are sub-contracted to third
parties are managed and controlled.
 Configuration Management - The information
technology subject to the IT service is identified
and controlled.
 Event Management - This key process area is
aimed at managing events that occur during
service delivery. Events can be incidents, such as
unavailable servers, or service requests from
end-users. Both types of events need to be
handled in time in order to meet the service
commitments.
 Service Quality Assurance - An independent
quality assurance group provides insight for
senior management into the processes used and
work products produced.
 organization draws up a
service level agreement with
its customer, the organization
should also use service level
agreements when it delegates
parts of the service delivery to
third parties (Sub-contract
Management).
 Service Support: processes
that support the activities that
actually deliver the services.
Almost all IT services concern
the management, operation or
maintenance of hardware and
software components. These
components should be placed
under configuration control.
This ensures that at all times
the status and history of these
components is known, and that
changes are controlled
(Configuration Management).
However, during the period
that the services are delivered,
events can occur that need to
be resolved by the service
providerN. To handle the
service request and to resolve
incidents, changes to the
configuration may be
necessary. The change requests
are evaluated by the
configuration control board
with respect to the service
level agreement and risk for
the integrity of the
configuration. Only after a
change request has been
approved by the configuration
control board, will the
configuration be changed
(Configuration Management).
Finally, to ensure the quality of
the services, the service
provider deploys quality
assurance techniques, such as
reviews and audits (Service
Quality Assurance).

Standardized After the organization has  Organization Service Definition - a service

established these capabilities it can
progress to
implementing Standardized
services and service processes. By
describing the services in a service
catalogue and by developing
standard processes for those
catalogue is developed that describes the
services, in terms of customer benefits, that the
service provider can deliver.
 Organization Process Definition - the
organization describes the processes used to
deliver the services, described in the service
catalogue. Service catalogue and standard
standard services, the organization service processes undergo improvement as a
can standardize and unify its result of practical experience.
performance. Standardized Services  Organization Process Focus - this key process
fall into one of three categories. area is aimed at implementing the standard
processes and assessing the performance of the
 Service Management – is processes in practice.
concerned with the tailoring of  Integrated Service Management - this key
the standard service processes process area is aimed at tailoring the standard
to the customer and the service service processes to specific service
level agreement at hand. Also, commitments for a specific customer so that the
the actual service processes tailored process can be used to manage and
need to be integrated with each deliver services to the customer.
other and with third party
 Service Delivery - the tailored service processes
service processes (Integrated
are performed to deliver the services.
Service Management).
 Training Program - based on the standard
 Enabling – making standard
processes, a training program is developed.
processes available and usable.
Employees are trained to fulfill their roles in the
The organization develops a
standard process.
set of standard services and
describes these services in the  Intergroup Coordination - delivering services
service catalogue requires different groups and disciplines to
(Organization Service coordinate their work. This key process area
Definition). The organization makes sure communication between different
develops and maintains groups is facilitated.
standard processes for each of  Problem Management - incidents and service
these standard services. requests that are registered as part of the Event
Usually, organizations will Management key process area are analyzed to
provide several services to one identify and solve underlying problems in the
customer at the same time. information technology.
Hence, not only the service
processes themselves, but also  Resource Management - required resources for
the integration of these delivering different services to different
processes has to be customers are coordinated across the
standardized as much as is organization.
feasible (Organization Process
Definition). To coordinate
process efforts across services
and organizational units and
over time, organizational
support is institutionalized
(Organization Process Focus).
To teach people how to
perform their roles and how to
work with the standards, a
training program needs to be
put in place (Training
Program). Furthermore, means
are established for the different
groups involved in the service
delivery to communicate
efficiently and effectively
(Intergroup Coordination).
Underlying problems of events
occurring during different
service deliveries are analyzed
(Problem Management) and
resources are negotiated before
making service commitments,
 and monitored during the
service delivery (Resource
Management).
 Service Delivery – concerns
the actual delivery of the
services to the customer using
a tailored version of the
services’ defined service
processesN. Because the
service activities depend on the
particular services being
provided, there is no fixed list
of activities to be performed,
but, all services should
perform the activities as
defined in the level two key
process areas.

Managed On level four, the standard  Quantitative Process Management - aimed at

processes are managed quantitative control of the performance and costs
quantitatively to reduce process of the service delivery.
variance. Organizations gain a  Service Quality Management - aimed at
quantitative understanding of their gaining qualitative insight in the quality of the
standard processes by taking service delivery and reaching specific quality
detailed measures of service goals.
performance and service quality
(Quantitative Process Management)
and by using these quantitative data
to control the quality of the
delivered services (Service Quality
Management). This results in more
predictable performance and
increases the ability of the
organization to draw up realistic
service level agreements.

Continuous Level five finally, is aimed at  Process Change Management - this key

Improvement changing and improving processes
and technology in a controlled
manner. Service providers learn to
change their processes to increase
service quality and service process
performance (Process Change
Management). Changes in the
processes are triggered by
improvement goals, new
technologies or problems that need
to be resolved. New technologies are
evaluated and introduced into the
organization when feasible
(Technology Change Management).
Problems that occur are prevented
from recurring by changing the
processes (Problem Prevention).
process area is focused on improving and
changing processes in the organization to
improve service quality and productivity.
 Technology Change Management - this key
process area is focused on Technology Change
Management: new technologies are identified,
assessed, and implemented in the organization in
a controlled manner.
 Problem Prevention - the root-cause of
problems is identified and removed to prevent
problems from happening again
ITIL Implementation
ITIL doesn't
totally
ignore the
constraint
of

organizational maturity. Appendix C of the Implementing ITIL Booklets presents simplistic variant on
the maturity model. The stated purpose is to assist in devising a readiness assessment for the
introduction of ITIL processes. The approach measures the IT organization's influence and alignment
with business goals and objectives against six elements:

1. Vision and Strategy

2. Steering
3. Processes
4. People
5. Technology
6. Culture

The organization's maturity level is determined by the IT organization's primary focus which migrates
as it matures through the following stages:

1. Technology focused
2. Product/Services focused
3. Customer focused
4. Business focused
5. Value-chain focused

The following grid compares these elements against the primary foci:

Stage Vision and Steering Processes People Technology Culture

strategy

Technology Business Principally Focus on Technology Systems and 'We are IT

views role of driven by cost. Systems and excellence. Network experts'. There
IT as Stability, Network Management is little
Infrastructure availability Management, tools are interaction or
provider of and IT design and independently understanding
hardware, performance implementation purchased and of providing
software and of IT used to manage 'services' to
 network platforms and technology the business
provider). No networks are subsets.
clear vision the main focus
statement on and implicit
role of IT. steering
parameters.

Product/Service The IT Services are Strong focus on Clearer More product Team and
Organization defined in ITIL Service definition of standardization. product
recognizes technology Support IT functions. Design of orientation.
that it delivers terms such as processes and Recognition architectures Customer
a portfolio of bandwidth, the more of first and and integration awareness and
products and processing operational second-line into promotion
services to the performance, aspects of the expertise. management towards
business. disc capacity. ITIL Service tools and Customers.
Evidence of Reporting and Delivery systems.
IT strategic steering on IT processes, such
planning, little defined as performance
input from parameters. measurement
business. and tuning,
availability
measurement
and building
resilience.
Reporting
mechanisms are
used to improve
product and
service
performance.

Customer Focus IT seen as IT Service Level Service Level Service Integrated Customer
service Agreements Management, Management systems and satisfaction.
provider IT steer IT. formalized training and Service
strategy Change Account defined Management
linked to Management Management. activities and platforms,
business integrated into More focus on roles. manageability
strategy. project planning Evidence of built into
structure for aspects in process technology
ensuring delivery ownership, designs and
smooth hand processes. Formalized solutions.
over from new Support Account Operational
IT processes Management requirements
development. deliver clear and Service defined for
service and Management hand-over into
Customer roles in place. production
related environment
performance.
Process
reporting under
pins service
level
agreements.

Business Focus IT is seen as a IT strategic Business and Business R and D and The IT
partner to the goals, IT IT-alignment intelligence technology Organization
 business. IT proposals processes. and business pilots. An provides help
demonstrates made and Strong competencies. enterprise-wide and advice to
strategy discussed at Integration CIO role and management the business.
realization for board level. between CTO role. framework
the business. Business Systems Equal roles in exists defining
IT strategy priority and development business and integrated
input to risk and IT Service IT. service and
business assessments of Management systems
strategy investing and processes. management
making not investing Processes tool sets.
process in IT. Service deliver
levels are 'dashboard
defined more steering
in business information'.
terms, such as Service
'business delivery and
transactions support
processed', processes
'availability of integrated.
business Delivery
functionality' processes
deliver sound
planning and
advice to the
business.

Value chain IT is seen as IT is steered Business and IT Strategy Technology The IT

business on added strategy making, interaction Organization
enabler. IT value to the making. The IT business between enables the
helps shape business. Organization planning, suppliers. business.
and drive Business ensures managing Solutions
business improvements seamless partners and integration.
Change and is through use of integration with suppliers.
seen as a IT. systems Infrastructure
value-added development Integrators.
partner that and all other IT
helps suppliers in the
determine value chain to
business manage real
strategy. end-to-end
services for the
business.

CCTA CMM
Pink Elephant, HP, Ultracomp (now Fox), Quint and CEC have all creating implementation models
which recognize the importance of Capability Maturity Model. They all concluded that business and IT
needed to become more closely aligned and that simply creating SLA(s) (the original OCG implied
answer to alignment) was not sufficient. Service Management became focused on aligning business
needs with IT capabilities. The SLA should be considered in the context of an alignment program.

In 1997, the CCTA reacted to

this need and introduced a
five-level process maturity
model, based on similar
models that had been
developed for software production units, e.g. the Software Engineering Institute’s Capability Maturity
Model (CMM) and ISO’s Software Process Improvement and Capability determination (SPICE). This
was revised to include intermediate stages with the result being a nine stage ITIL implementation
measure. The CCTA developed a series of questions for each stage. The total score in any ITIL area
would determine the organization's maturity with regard to that process.

This treatment acknowledges maturity as a key concept but by modifying the definitions at each level
abandons much of the CMM maturity framework at each of those levels. CMM Integrated describes a
key set of activities at each of those levels. These activities are replaced in this treatment with another
broad (though related) set of descriptors deemed more reflective of processes such as ITIL.

This does, of course, follow directly from the intent of this scale which is to devise a set of questions
which permits the assignment of a scale reflective of the maturity of that process area in order for the
consulting firm to recommend and implement improvements. Once must, however, be careful in
interpreting the scales...

 while the devised questions will reflect concerns at each of the levels the importance (ie.
weighting) attached to each area will differ according to the area. Therefore, comparing a
score in one ITIL process with another process area may be misleading
 the treatment fails to acknowledge that different processes as described in the ITIL manuals
require more mature organizations than other processes.
 there is little debate on the validity and reliability of the assessments since the results will be
considered the proprietary property of the client and administering consulting firm

IT Governance Maturity Framework (COBIT)

The COBIT framework utilizes a maturity model to provide benchmarks for the 34 processes (many of
which are the same as ITIL).

MATURITY MODELS for control over IT processes consist of developing

a method of scoring so that an organization can grade itself from non-
existent to optimized (from 0 to 5). This approach has been derived from the
Maturity Model that the Software Engineering Institute defined for the
maturity of the software development capability. Against these levels,
developed for each of COBIT’s 34 IT processes, management can map:

 The current status of the organization — where the organization is

today
 The current status of (best-in-class in) the industry — the
comparison
 The current status of international standards — additional
comparison
 The organization’s strategy for improvement — where the
organization wants to be

COBIT - Management Guidelines, Executive Summary, p.4

The COBIT scale is based
upon the Software Institute
CMM scale. Each maturity
has a general description
which is subsequently adapted
for meaning with each of the
34 governance process areas.

The Maturity Models are built

up starting from the generic
qualitative model to which
practices and principles from
each of the following domains
are added in increasing
manner through the levels:

 Understanding and
awareness of risks
and control issues
 Training and
communication
applied on the issues
 Process and practices
that are implemented
 Techniques and
automation to make
processes more
effective and
efficient
 Degree of
compliance to
internal policy, laws
and regulations
 Type and extent of
expertise employed.

The following table describes this increasing application of practices over the levels for the different
topics. COBIT suggest that together with the qualitative model, it constitutes a generic maturity model
applicable to most IT processes.

Level Initial Repeatable Defined Managed Optimized

Understanding & Recognition Awareness Understanding Understand full Advanced,

Awareness of need to act requirements forward-looking
understanding

Training & Sporadic Communication Informal Formal training Training and

Communications communication on the overall training supports a communications
on issues issue and needs supports managed support external
individual program best practices
initiatives and use leading
edge concepts

Processes & Practices Ad hoc Similar/common, Practices are Process Best external
approach to but intuitive defined, ownership and practices are
 process and process emerges standardized responsibilities applied
practice and are set; process
documented; is sound and
sharing of complete;
better practices internal best
begins practices are
applied

Techniques &   Common tools Tool set is Mature Sophisticated

Automation are appearing standardized; techniques are techniques are
currently used; standard deployed;
available tools are extensive
practices are enforced; optimized use of
used and limited tactical technology
enforced use of
technology

Compliance   Inconsistent Inconsistent Balanced Balanced

monitoring on monitoring; scorecards are scorecard is
isolated issues measurement used in some globally applied;
emerges; areas; exceptions are
balanced score exceptions are consistently
card adopted noted; root noted and acted
occasionally; cause analysis upon; root cause
root cause is standardized analysis is
analysis is always applied
intuitive

Expertise     Involvement of Involvement of Use of external

IT specialists all internal experts and
in business domain experts industry leaders
processes for guidance

CobIT Maturity Descriptions

The following table describes each of the 34 CobIT process areas by maturity characteristics. The
CobIT processes outlined against a dark brown background are considered to be core processesN.

CobIT Process Area Maturity Level Description

1 2 3 4 5

PLANNING AND ORGANIZATION

Strategic Planning

Architectural Planning

Technology Direction
IT Organization and
Relationships

IT Investment
Management

Communicate Mgmt
Aims & Directions

Manage HR

Ensure Compliance w.
External Requirements

Assess Risks

Manage Projects

Quality Management

ACQUISITION AND IMPLEMENTATION

Solutions Development

App SW Acquisition &

Maintenance

Tech. Acquisition &

Maintenance

Tech. Procedures
Documentation

Implementation &
Accreditation

Change Management

DELIVERY AND SUPPORT

Service Level
Management

External Provider
Management

Performance/Capacity
Management

Service Continuity
Management
Security Access
Management

Cost Accounting

User Education and

Training

Service Desk

Configuration
Management

Incident/Problem
Management

Data Management

Facilities Management

Operations Management

MONITORING
Process Monitoring

Controls Assessment

Assurance Reviews

IT Audit

Executive Maturity
Of course, improving the maturity of the organization's processes will not happen overnight at least
one author has suggested that a pre-requisite to any gains must include a management focus.
Consider the following slide.
The achievement of higher levels of maturity must be preceded by an increasing involvement and
participation of management. As sponsors of the movement they cannot simply "start the ball rolling"
and hope that the momentum will be maintained. Instead, support must be continuous and include:

 a project plan which demonstrates continuing benefits from the effort in order to sustain
momentum and provide them with evidence to their senior management peers.
 continuing and sustained championing reflected in identified ownership of the initiative as well
as individual processes
 continued financial support and the provision of highly qualified and trained project teams

Sustaining Gains
Both CMMI and People make a distinction between practices designed to implement a habit and
practices designed to institutionalize it. Without the later, all too often newly embedded practices will
revert to previous, well-entrenched behaviors. The four institutional practices are displayed below.
Institutionalization practices are practices that help to institutionalize the implementation practices in
the organization’s culture so that they are effective, repeatable, and lasting. These institutionalization
practices, taken as a whole, form the basis by which an organization can institutionalize the
implementation practices (described in the Practices Performed section of the process area).
Institutionalization practices are equally important, however, for they address what must be done to
support and institutionalize the process areas.

Commitment to Perform
Commitment to Perform describes the actions the organization must take to ensure that the
activities constituting a process area are established and will endure. Commitment to Perform
typically involves establishing organizational policies, executive management sponsorship,
and organization-wide roles to support practices to develop workforce capability.

Level 2 Sub-Processes

 Establish and maintain an organizational policy for planning and performing the
process.
Ability to Perform
Ability to Perform describes the preconditions that must exist in the unit or organization to
implement practices competently. Ability to Perform typically involves resources,
organizational structures, and preparation to perform the practices of the process area.

Level 2 Sub-Processes
  Establish and maintain the plan for performing the process.
 Provide adequate resources for performing the process, developing the work
products, and providing the services of the process.
 Assign responsibility and authority for performing the process, developing the work
products, and providing the services of the process.
 Train the people performing or supporting the process as needed.

Level 3 Sub-Processes

 Establish and maintain the description of a defined process.

Measurement and Analysis
Measurement and Analysis describes measures of the practices and analysis of these
measurements. Measurement and Analysis typically includes examples of measurements that
could be taken to determine the status and effectiveness with which the Practices Performed
have been implemented.

Level 2 Sub-Processes

 Place designated work products of the process under appropriate levels of

configuration management.
 Identify and involve the relevant stakeholders as planned.
 Monitor and control the process against the plan for performing the process and take
appropriate corrective action.
Verifying Implementation
Verifying Implementation describes the steps to ensure that the activities are performed in
compliance with the policies and procedures that have been established. Verification typically
encompasses objective reviews and audits by executive management and other responsible
individuals.

Level 2 Sub-Processes

 Establish and maintain an organizational policy for planning and performing the
process.

Level 3 Sub-Processes

 Collect work products, measures, measurement results, and improvement information

derived from planning and performing the process to support the future use and
improvement of the organization’s processes and process assets.

Best Practices
Best practices permit an organization to supplement corporate knowledge by leveraging the
experiences of others; with lower costs and time than will occur in gaining comparable experiences
through uncoordinated project initiatives. However,... adopting and embedding best practices into a
corporate culture may not be easy --- often precisely because staff circumvent the lessons associated
with discovering the best practice, for it is these "lessons" that often provide the base rationales for
justifying improvement initiatives. Determining return on investment for an initiative is far more
problematic without evaluation of the costs associated with inefficiencies. Best practice descriptions
seldom provide this detailed financial information. While many enterprises may claim successful
implementations of ITIL best practices, few will see the benefits still accruing several years later.
Fewer still can boast of continual improvement of the practices.
Best practices should be integrated into a methodology by the IT service division. This provides a
more meaningful context for improvement and outlines how initiatives inter-relate in a more strategic
setting. ITIL, CMMI, CobIT and other frameworks can provide a solid base for this but they must be
'tailored' for the unique characteristics of the organization.

Topics in this Section

Corporate Knoweldge &Organizational Learning Adopting Best Practices Creating a Methodology

Corporate Knowledge & Organizational Learning

Knowledge is information within the context of relevant events, decisions, scenarios and
experiencesR.

"Information" encompasses the meaning given to data or information obtained according to certain

conventions - this is known as "Explicit Knowledge".

On the one hand, "culture" is the total amount of standards, values, views, principles and attitudes of
people that underscore their behavior and functioning.

"Skills" are related to the capability, ability, and personal experience of people - they relate to what
people can do, know and understand.

The knowledge components which culture and skills represent is "implict" or tacit" knowledge, which
depends on the individual and is stored in the minds of people - ie. it is embodied. This concept is
more difficult to describe, is based on experience, is practical in nature and finds its source, among
other things, in associations and intuitions.

On the other hand, Explicit Knowledge, is not dependent on the individual, is theoretical in nature
and is specified as procedures, theories, equations, manuals, drawings etc. This knowledge is mainly
stored in management information and technical systems, and organizational routines. An
organizational challenge is to turn the sum of individual explicit knowledge sources into a base of
corporate knowledge. According to BurltonR, it matures in three stages:

1. Recognition

Recognition is the shallowest level of knowledge. Unless you can identify a problem, the
application of knowledge won't occur because no action will ever be taken. Recognizing a
problem with a customer relationship is a critical first step to resolving the problem or avoiding
further problems. However, recognition by itself not sufficient. Many people will claim they
"know," about a problem area, but what they know remains shallow compared to those who
are knowledgeable in other dimensions.

2. Guidance

Guidance, or referencable knowledge that tells you what to do, is the next dimension of
knowledge. Guidance requires rich and deep sources with specific relevance so that an
appropriate action can be taken. Without it, people might recognize a need or know how to do
something but they would lack the specific context needed to do the right things correctly.
Once a problem with a customer relationship is noted, it's imperative to find out more details,
which then guides the appropriate response.

3. Ability
 The third dimension of knowledge is the ability to accomplish some result that is of value to
someone who cares. This know-how is obviously essential to the smooth functioning of an
enterprise. Having this deepest form of knowledge often differentiates the enterprise from its
competitors. Clearly, someone must be able to do what it takes to resolve a customer
relationship problem, after it is recognized, and appropriate guidance is gained. Applying the
three levels of knowledge enables a business to do the right things in the right way.

Burlton compares these stages (a kind of maturity treatment) to the two types of knowledge. The
result is his Burlton Six Pack.

Knowledge Knowledge Stage  

Recognition Guidance Ability

Tacit Awareness Understanding Capability Embodied

Explicit Pointers Documents Products, Embedded

Processes,
Rules,
Tools

  Who & Why, What How  

Where & When

Mature organizations strive to achieve the ability to retain explicit knowledge. This
becomes Corporate Knowledge...

Corporate Knowledge
The collective body of experience and understanding of an organization's
processes for managing both planned and unplanned situations.

The Knowledge Management Forum

Burlton concludes by summing up the key role process plays in corporate knowledge retention:

"With today's emphasis on knowledge and intellectual capital, many

questions are being asked about the value of such capital and how we can
measure it. Again, process plays the key role. If we see knowledge as a
guide embedded in an enabler to the processes we conduct, we can measure
the value that the knowledge provides only in terms of the difference it
makes in the process. Typically, this is done by examining process quality or
the cost of nonconformance - that is, the cost of lost opportunity to do better
due to better knowledge. This can appear as the total downstream cost of not
having that knowledge available, costs of extra work, customer
dissatisfaction, repairs or corrections, lost staff, and so on."

Roger Burlton, Business Process Management, SAMS, 2001, ISBN: 0-672-32063-0, p. 76')">

Corporate knowledge must be continually refreshed. The organization must continually update its'
skills and methods or run the risk of being overtaken by 'more nimble' competition. The employees of
more successful organizations learn quicker, and implement and commercialize knowledge faster. An
organization that does not learn continuously and is not able to continuously list, develop, share,
mobilize, cultivate, put into practice, review, and spread knowledge will not be able to compete
effectively. That is why the ability of an organization to improve existing skills and acquire new ones
forms its most tenable competitive advantage. R. It is incumbent upon the organization to
systematically collect and use this knowledge.

"Knowledge should be collected from all existing sources including people,

systems data stores, files cabinets and desktops. All knowledge of value
should then be stored in the organizational knowledge repository. For virtual
teams, this knowledge would be immediately conveyed to the people and
systems that could use it. The right knowledge would go to the right person
or system at the right time. Current knowledge could be retrieved form the
system at any time in the future. As knowledge becomes obsolete or expires,
that knowledge could be automatically be removed from the system."

A Best Practice Assessment, Tim Finneran, CIBER Inc at The data Administration
Newsletter, www.tdan.com

But how does one distinguish "relevant" knowledge? This can be a daunting task. But there are
certain principles which can be adopted to facilitate the quest. The organization must shift its' focus
from learning facts to learning  process. Why? Because increasingly organizations will be defined by
their processes -- they accept a mixture of inputs from their environment and weave a set of
"products" and "services" as outputs. Using a systems approach it becomes easier to see the value of
process learning -- and how R&D is uniquely equipped to lead the rest of the organization in
"exploring" systemic connections between processes and products and services.

"As an organization climbs the process improvement ladder, it will usually

include an increasing number of projects under the process improvement
umbrella. Projects benefit from the experiences and lessons learned by
others by collecting those lessons learned in an organization process asset
library and database.... This transition from "individual learning" to "local
learning" to "organizational learning" is one of the great concepts in
process improvement."

Boris Mutafelija, Harvey Stromberg, Systematic Process Improvement Using ISO 9001:2000 and
CMMI, Artech House, 2003, ISBN: 1-58053-487-2, p. 133

Burlton goes on to suggest that knowledge has a lifecycle consisting of the following stages:
 1. Create: Knowledge must be
created either within or outside the
organization. Ideas evolve in
iterative tacit and explicit loops
until the knowledge is ready for
distribution to those outside the
creating group.
2. Store: Knowledge can then be
stored somewhere, either tacitly or
explicitly, so that it's accessible for
others to find and use.
3. Find: Those who need the specific
knowledge must find out where it
is by searching in the right places
and/or by asking the right people.
4. Acquire: Once the knowledge
source is found, the user will then
go through the act of actually
acquiring it-that is, gaining
personal knowledge from other
humans or documented sources.
5. Use: Once acquired, the
knowledge can be put to use
toward some productive purpose.
6. Learn: As a result of having
applied the knowledge, perhaps
repeatedly, the user will learn what
worked well and what didn't. This
learning can then be significant
input into further iterations of the
knowledge creation and
distribution process.

"The objective of knowledge management processes is to make this cycle

more effective as well as more efficient. This implies that corporate
knowledge must be made available in readily accessible forms, such as
documents, processes, and rules."

Roger Burlton, Business Process Management, SAMS, 2001, ISBN: 0-672-32063-0, p. 78">

Developing and continually improving internal processes can be a time consuming and exacting
process, particularly in organizations and sectors where the turn-over of staff often means that much
of the knowledge leaves the organization at key momentsN. All too often the sum total of the
organization's attempt to keep and codify this knowledge is in conducting 'exit interviews' or ensure
that documentation is placed in a shared drive or available to the next incumbent. Knowledge
Management attempts to better manage that knowledge through improved tools and techniques.
InCMMI this is encompassed by the concept of institutionalization wherein key knowledge is captured
by ensuring that key processes accompanying any new project or process.

Burlton offers ten fundamental principles of process management:

Business change must All the things we do, we should do for a reason, and measurement allows us to know if
be performance we are acting consistently with the reason. A popular response to this has been the
driven. "balanced scorecard" approach, which tries to put in place a set of measures that aren’t
oriented just to the financial bottom line. All organizations, regardless of business
mission, can find their own set of performance metrics from which all decisions
 regarding processes can be derived and linked to each other.

This concept is normally referred to as traceability - everything we do, and every

decision we make under ideal circumstances, relates through a set of linked performance
measures to the organization’s scorecard.

Business change must Who cares about what we are doing and how well we are doing it? Stakeholder needs
be stakeholder based. and expectations are the prime drivers of the balanced scorecard and also help determine
what that scorecard should be.

Business change Though perhaps self-evident this principle is often ignored or abused. Personal and
decisions must be political agendas will often form the basis for proposals, recommendations, and
traceable to the approvals of courses of actions.
stakeholder criteria.

The business must be As business cycles of products and services shrink timewise, management structures
segmented along with overly rigid organizational boundaries and planning mechanisms are too slow to
business process lines respond. They don’t anticipate changes well enough to lead the market. Seamless cross-
to synchronize change. functional integration is mandatory, and, only process can stake the claim of achieving
enterprise-wide integration. The "event/outcome" pairing, inherent in the process
approach, defines the value proposition. All other structures are subservient and should
be put into place solely to serve it, and in so doing deliver added value to customers and
stakeholders.

Business processes One traditional pitfall associated with business change is an inability to deliver and
must be managed sustain benefits. In process-oriented change, the problem can be exacerbated if the
holistically. proponents of change cannot locate and maintain appropriate champions. These sponsors
must take a full-process perspective - that is, one that delivers on behalf of external
stakeholders.

Process renewal As the organizational focus grows, a business requires more formal approaches to
initiatives must inspire identify, connect, and share what’s known as well as to realize the identities and
shared insight. trustworthiness of its knowers. It is impractical to learn everything required first hand in
the timeframes required by modern change. Hence, accessible knowledge artifacts, often
in the form of explicit documents, hold great importance to help bridge the knowledge
chasm between "knower" and "solution stakeholder."

Process renewal Everything should be understood and validated at its own level, starting at the top box
initiatives must be and then working down. At each level, the objects we analyze must be looked at only
conducted from the with regard to their own context before any decomposition occurs.
outside in.

Process renewal Continuous learning - learn, create something, review it, and plan the next cycle of the
initiatives must be process. This principle assumes that we will get it wrong before we get it right and that
conducted in an we will know the result of a change only when you try it. Time boxing dictates that the
iterative, time-boxed activity schedule is preset and the amount of work performed varies according to what
approach. can be done within the timeframe.

Business change is all Appropriate roles and responsibilities, organizational structures, empowerment within
about people. accountability, aligned performance incentives, recognition and personal growth
opportunities must be recognized. During transition, the staff must feel that an
appropriate level of trustworthy communication is happening.

Business change is a Stakeholders will have a set of requirements that are in flux. The balance among these
journey, not a requirements will change as each of the stakeholders’ contributions change.
destination.

Burlton, "Business Process Management, SAMS, 2001, Chapter

Adopting Best Practices

A better way may be available. Researching and adopting best practices allow organizations to utilize
the skills and learnings of others. In many cases, business processes may be carefully guarded since
they often define a competitive advantage for the organization. However, in areas where there is little
differentiation between businesses or where international standards' organizations have established
codifications, best practices may be available.

Here are a few definitions of best practices....

The processes, practices, and systems identified in public and private

organizations that performed exceptionally well and are widely recognized
as improving an organization's performance and efficiency in specific areas.
Successfully identifying and applying best practices can reduce business
expenses and improve organizational efficiency.

BPR Glossary of Terms

Planning and/or operational practices that have proven successful in

particular circumstances. Best practices are used to demonstrate what works
and what does not and to accumulate and apply knowledge about how and
why they work in different situations and contexts.

United Nations Development Programme

The most effective methods of accomplishing various tasks in a particular

industry, often discovered through benchmarking.

Online Learning Centre

"the currently recognized best way to fulfill a task, complete an activity or

achieve a stated goal. Best Practice is not static because, by its very nature,
those who seek to implement it also consistently look for further, continuous
improvements.

And Best Practice does not have a single ingredient – a silver bullet – that
 produces miracles. Rather it is a combination of essential elements that,
when brought together, provide a strong underpinning for success.

These key elements are:

 THE ORGANIZATION – the structures, governance and support

systems within the organization itself, which ensure that decision-
making, resources, skills and processes are aligned for success.
 THE PROCESSES – that have been tried and tested in a wide variety
of contexts and have proved to be effective.
 THE PEOPLE – with the appropriate skills, knowledge and
experience for the task in hand."

APM Group - UK

The itSMF (IT Service Management Forum, the ITIL global user organization) defines “best practice”
as an industry-accepted way of doing something...

 it is the best-identified approach to a situation based upon observation

from effective organizations in similar business circumstances
 it means seeking out ideas and experiences from those who have
undertaken similar activities in the past, determining which of these
practices are relevant to your situation and testing them out to see if
they work, before incorporating the proven practices in your own
documented processes
 it is all about not re-inventing the wheel, but learning from others and
implementing what has been shown to work.

What is: ITIL?, Ofer Reshef, Principal Consultant, Optimation, New Zealand, Auckland

Inherent in the realization that IT must operate like any organizational business line, are the
following drivers promoting the adoption of best practices:

 Business managers and boards are demanding better returns from IT

investments, i.e., that IT delivers what the business needs to enhance
stakeholder value;
 Concern over the generally increasing level of IT expenditure;
 The need to meet regulatory requirements for IT controls in areas such
as privacy and financial reporting (e.g., the US Sarbanes-Oxley Act)
and in specific sectors such as finance, pharmaceutical and health care;
 The selection of service providers and the management of service
outsourcing and acquisition;
 Increasingly complex IT-related risks, such as network security;
 IT governance initiatives that include adoption of control frameworks
and best practices to help monitor and improve critical IT activities to
increase business value and reduce business risk;
 The need to optimize costs by following, standardized, rather than
specially developed, approaches;
 The growing maturity and consequent acceptance of well-regarded
frameworks, such as ITIL, COBIT, ISO 17799, ISO 9002, Capability
Maturity Model (CMM), Project in Controlled Environments
 (PRINCE), Managing >Successful Programmes (MSP), Management
of Risk (M_o_R) and Project Management Body of Knowledge
(PMBOK);
 The need for organizations to assess how they are performing against
generally accepted standards and against their peers (benchmarking);
 Statements by analysts recommending the adoption of best practices N.

Aligning COBIT, ITIL and ISO 17799 for Business Benefit, ISAAC

Or, consider Tim Finneran's explanation for using best practicesN

Why Best Practices
We seek to follow Best Practices for the simple reason that doing things
right satisfies customer requirements while utilizing resources in the most
resource-efficient way.

Some specific reasons for following Best Practices:

 Reduces the cost of the lack of quality.

 Reduces the cost of weak Data Administration and Stewardship
 Consistent, higher quality answers to business user questions - Better
access to detailed operational data and to informational data processed
to answer their specific business analysis questions.
 Consistent, higher quality control of the various business processes and
their underlying business rules resulting in:
o An increase in the productivity of information system users
o A common "look and feel"
o Common business rules enforcement, and common business
terminology.
 Provides an entree into Business Process Improvement (Re-
engineering and/or TQM)
 Provides a method to relate architecture components to business goals
and objectives
 Encourages the use of metrics to measure the quality and quantity of
both business process and supporting Information Technology
productivity.
 Increases productivity accruing from the use of a common Information
Management development methodology and a commonly used suite of
development tools.
 Facilitates the ability to move to new and improved methods and tools,
for example, Component Architecture, Rapid Application
Development, and the Data Warehouse.
 Increases project sponsor confidence in Information Management
Project results
 Encourages completeness of the user requirements specifications.
 Ensures that
o All requirement elements have been accounted for
o Business Rules are defined relating all development components,
o The best source of requirements and data are utilized.
o The best source of Information about data availability is
determined and documented in an Information Meta data
Repository.
 Provides a methodology for setting priorities, by ensuring that all
components and component relationships are well defined.
 Furnishes a method for determining the impact of an Information
Management system change request.
 Makes available a ready source of user based requirements
documentation, that will facilitate understanding of the actual user's
requirements.
 Enable approaches able to do things "Quick but less dirty"
  Achieves increased productivity without sacrificing creativity by using
better tools
 Encourages more standard methods, and more useful meta data.
 Provides metrics for recognizing and rewarding success. Developers
will gain satisfaction from "doing things right."
 Facilitates the definition, development, and management of Reusable
Components.

A Best Practice Assessment, Tim Finneran, CIBER Inc

at The data Administration Newsletter, www.tdan.com

With best practices in place, companies are better positioned to apply rational thinking and metrics
when assessing Return on Investment (ROI) and the Total Cost of Ownership (TCO) of IT
investments. Additionally, they are better positioned to meet IT governance expectations. Best
practices take on strategic significance as companies recognize the value that these disciplines
contribute to the overall landscape of IT Service Management (ITSM)R. Best practices permit an
organization to avoid making mistakes during the learning process - in essence learning from others.

However, best practices may also be problematic for an organization to implement because...

 the organization has not made the mistake - thus, not clearly understanding the reasoning
behind the adopted practice. N;
 best practices are, by necessity, subject to statistical interpretation. They reflect
the "best" amongst a discrete number (and not an unbiased sample) of organizations
reviewed - as opposed to a random sample of all organizationsR;
 the organization may not have adapted its' internal support processes sufficiently to
implement the processes - ie., not sufficiently mature in CMMI terms. The successful
implementation of best practices are contingent upon key capabilities (the maturity level of
which may be contingent upon yet other key capabilities) - "to achieve a best practice, one
must develop the constituent capabilities of the best practice." R;
 the implementation of one process area may have interdependencies with other areas. These
interrelationships can be complex and differ with the characteristics of the organization
implementing process improvement. Results can vary in unpredictable ways in the absence of
a defining framework underscoring the best practices;
 different process areas (eg., the ten areas cited in the ITIL service management and delivery
books) will have implementation requirements, which will be aligned to different levels of
organizational maturity.

New advances in IT service management may resolve some of these shortcomings by ..

 distinguishing processes and practices according to the scale of an implementation.

 focused acknowledgement of the underlying organizational processes necessary for an IT
service management discipline to be implemented at a prescribed level of maturity.
 describing (as COBIT does in rudimentary form) process variations at different levels of
organizational maturity
 selective descriptions of ITIL implementation suggestions to better highlight
implementation packages (including associated supporting process requirements) dependent
on the maturity level attained by the organization.

Integrating Best Practices - A Model

A model can provide a guidepost for decisions of what industry and corporate knowledge should be
embedded within the organization. A "business model", according to FinnernanR, describes the ways
in which providers and customers interact to do business; such a model includes roles,
responsibilities, facilities, products, and process.

Organization
The Organization Best Practices component would include an "organizing concept". For example, one
organization required enterprise-wide standards and guidelines to be enforced throughout the
corporate entity. The entity was distributed not only geographically, but also with varying lines of
business and channels of trade.

This organization would be assessed according to the following organizing concept:

 Agreement at highest level of management as to Principles, Best Practices & Methodologies,

Standards and Guidelines.
 A central function that facilitates compliance while allowing business flexibility.
 Distributed professionals committed to these policies and principles and supported by local as
well as central management.

The organizational structure based upon this organizing concept would facilitate:

 A central policy and practices developed by a centralized organization but including

distributed organization input and support,
 Distributed execution organizations based upon enterprise policies and practices with
personnel, belonging to the centralized organizations, who are integral, co-located members
of each project team. Project teams may also be supported by central specialists that act as
SWAT Team members, as needed.
 A Management Steering Committee for major projects that ensures that central standards and
guidelines are followed consistently while making sure that resources are efficiently utilized.
Principles and Best Practices
The Principles and Best Practices components of the Best Practices Business Model are statements
of a preferred architectural direction or practice. As will be discussed below, these principles will be
defined by means of a description statement, a rationale, implications, and a measure of success.

Architecture Model
There is not a single Enterprise Architecture Model. When we discuss architecture, we recognize that
architecture is the representation of the underlying set of inter-related frameworks that define and
describe the solution domain required by the business entity to attain its objectives and achieve its
business vision. Architecture is an amalgam of engineering art and engineering science.

The Architecture Model components of the Best Practices Business Model include the following
Architecture Models:

 Information Architecture Models - Enables the enterprise to develop a common, shared,

distributed, accurate, and consistent data resource.
 Business Architecture Models - Models the business enterprise to show how business is to
be done
 Application Architecture Models - Links the data and business architecture to reflect
applications and how they are used and distributed.
 Technology Architecture Models - Links up with the Application, Business, and Data
Architectures to provide inter-operable technology platforms that meet the needs of the
various user roles (Actors) at identified work locations.
Methodology
The Methodology components of the Best Practices Business Model include:

 Information Architecture Modeling

o Conceptual and Logical Data Modeling
o Database Design & Administration
 Business Process Architecture Modeling
o Use Case Analysis
o Event/Process Modeling
 Application Development
o Rapid Application Development and Prototyping
o Informational Data Access Development (including Data Warehouse)
 Application Architecture Definition/Inventory
 Technology Architecture Evaluation/Development
Quality Administration and Stewardship
The Quality Administration and Stewardship components of the Best Practices Business Model
include maintaining information/knowledge quality, by means of:

 Information/Knowledge Stewardship (Editorial Board)

o Appropriate Content
o Appropriate Presentation
o Aesthetics
o Vehicle (e.g., Would Video be better?)
 Information/Knowledge Content Administration
o Receiving
o Organizing
 o Posting
o Archiving
 Information/Knowledge Management Tool Administration

Integrating IT Service Best Practices - A Methodology

Within this overall model context our point of interest is in "Business Process Architecture Modeling"
and specifically in "Event/Process Modeling". At this point we can define the underlying relationships
amongst best practices through the use of a methodological framework..

"Organizations wishing to adopt IT best practices need an effective

management framework that provides an overall consistent approach and is
likely to ensure successful outcomes when using IT to support the
enterprise’s strategy."

Aligning COBIT®, ITIL® and ISO 17799 for Business Benefit, A Management Briefing from ITGI
and OGC, p.10

The collection of these best practices and the manner in which they are tailored to the unique
characteristics, goals and objectives of an organization is sometime referred to as a Methodology.

"A methodology is not a best practice in and of itself. It is the collected sum

of best practices that, when carefully orchestrated, create synergistic,
tangible value to an organization. Methodology is also a business process
that an organization executes. The process is a collection of best practices
(call them methods or tasks if you wish) that are organized to produce value
at one or more points along the process path, or if you’ve been reading the
latest management texts, the value chain."

Myths of Methodology, Dan Drislane, Beggs-Heidt, August 2002

The following schematic was developed with reference to software development, but, I think it is
equally relevant in a discussion of IT service management.
In the end, it doesn't matter where the best practices originate from - ITIL, CobIT, CMM, MOF. The
challenge is in integrating them into a coherent service methodology for the organization. The
development of the methodology will take into account the organization's distinctive requirements in
terms of the nature of the work, the size of the organization, it's dependency upon technology, the
formality or informality of the hierarchical structures, etc. This tailoring implies that the organization
must strive to achieve at least the level of organizational maturity sufficient to initiate an improvement
exercise. Many organizations lack sufficiently robust and documented processes from which to
undertake this kind of action. Therefore, it is essential to devise strategies and plans to achieve this as
depicted in "People, Method and Tool Enablers" in the above schematic.

The aforementioned article offers some recommendations for embedding these best practices into the
organization.
They recommend building your methodology one best practice at a time. As a best practice proves
itself through actual project use, you then implement a business process to “graduate” the practice
into your methodology. Hence, processes are like software releases, themselves subject to gating
processes in which they are thoroughly tested before being released into the organization's operating
methodology. The authors offer four tips to achieve this:

1. Break down your [operations] into more manageable best practices.

2. Master best practices first, then graduate and integrate them into the
larger methodology.
3. Evolve your methodology by enhancing existing best practices,
introducing new best practices.
4. Appoint stakeholders that can shepherd and maintain each best
practice. Don’t overburden one person with more best practices
than they can handle; encourage organizational participation and
skills development by recruiting staff to adopt a best practice.

Myths of Methodology, Dan Drislane, Beggs-Heidt, August 2002, p. 6

However, they also caution against excessive reliance on a prescriptive set of best practices. In this
endevour, the "tailoring" criteria is important because these guidelines focus ingenuity and creativity
into fruitful areas. Note this recommendation by IBM --

Service management solutions should tailor ITIL concepts and best

practices information to suit the needs of each individual client, and
incorporate the following elements to help ensure success:

 Specific measurements for the processes and services, to promote

achievement of return on investments
 Techniques to plan and manage process deployment, to take
 advantage of quick wins and to plan for integrating services
delivery into organizations
 Facilitation of organizational change, to ensure understanding and
acceptance of the solutions by staff
 Analysis and planning of essential skills required for performing
the improved service management practices
 Definition of the required reporting requirements for the solution,
to be able to communicate successes and analyze opportunities for
improvements
 Assignment of governance roles and elements to promote clarity of
responsibilities and understanding of the contribution of service
management solutions to the business
 Definition of interfaces and hand-offs to other processes to reduce
duplication of efforts
 Development of a service culture in which employees exhibit
appropriate behaviors and attitudes in their dealings with customers
 Involvement of service delivery partners in creating product and
services solutions to the benefits of your business.

IBM and the IT Infrastructure Library. IBM Global Services, January 2002, p. 12

These "guidelines" are being advanced as generally prescriptive - that is widely applicable. As such,
they can be considered implementation  Nprinciples. They are the tailoring principles. Tailoring is akin
to alignment - that is, it channels the organization towards projects and activities aligned with
corporate goals and objectives. Consider the following:

Methodology exists to make software development a repeatable process.

Repeatability has some obvious benefits: reduced time to delivery; lower
maintenance costs; faster adoption of new best practice; and faster training
ramp-up of new employees. However, one additional benefit is that it also
aligns the IT organization with the business of the company. This is
important because it helps stem IT innovation that adds only marginal value,
what I term commodity creativity, and instead focuses IT professionals on
what will truly benefit the core business of the company. Project team
members should no longer be flustered that best practices such as
Architecture Conformance Validation or Unified Change Management
check their freedom and imagination. What such best practices do —
particularly these two — is remove some of the tedious decisions that
managers, designers and developers have to make when they’re engaged in a
development project. Project contributors are then left to focus more
intently on solutions that add more business value and less behind-the-
scenes structure.

Myths of Methodology, Dan Drislane, Beggs-Heidt, August 2002, p. 14

Best practices evolve and are managed to a 'practice lifecycle' similar to many other elements of a
service management framework. The lifecycle suggested by the USMBOK has four main stages:
common, best, good, next, described thusR:

 Common - generally known and consistently defined, specific use undefined, accessible and
in the 'public domain', yet unproven
 Best - generally recognized or at least proposed by the industry as being a reasonable and
theoretically sound, unproven, an industry 'standard', minimum
  Good - transformed by use from theory to application, proven, statistical evidence of benefit
as applied within a specific organization and scenarios, not transportable to another
organization without a return to Best
 Next - Good practices that are stable, foundational, and candidates for innovative thinking
and another cycle of improvement

Process Modeling
This section is intended to demonstrate the importance of process modeling capabilities as a pre-
requisite for implementing service improvement projects based upon ITIL and CobIT best practices. I
demonstrate the extend of agreement on this need through reference to CMMI, CobIT and other
sources. I finish by describing the key elements which go into a process description - essentially the
material required to Institutionalize the process within the organization.

What's in this Section

Organizational Structure Organizational Process Capabilities Process Modeling

Organizational Structure
ITSM is about the delivery of services. The delivery of a service differs from the delivery of a
commodity in the following ways:

 Services are intangible,

 The customer may participate in the service delivery process,
 Part of the service consists of interactions between customers and technicians,
 The production and consumption of a service are inseparable and can occur at the same
time,
 Services are delivered through multiple processes using a chain of partnerships,
 Services may not be mutually exclusive; that is one service may form part of another service.

Most enterprises are not organized along service lines. Traditional organization structures allowed
companies to achieve three interrelated goals which have little connection to the service requirements
of a customer:

1. define lines of responsibility and authority

2. channel the flow of information
3. help achieve coordination of work activities.N

All three, but most certainly the last, of these goals have implications for how a service division should
be organized. Traditionally, the division may adopt one or more of four primary organizational models
(variants and mixes are common):

 Functional - employees are grouped together on the basis of the primary skill (or business
function) they need to do their job
 Divisional - employees are grouped together according to (1) the products on which they
work, (2) geographic location or (3) sets of customers they serve.
 Lateral Relations - a structural devise to encourage coordination amongst individuals and
groups in different work units.
  Matrix structures - employees report to multiple supervisors creating multiple chains of
command

Most IT services will involve several divisions and/or functional lines which contribute participants in a
"service chain". Companies develop and maintain systems and applications according to IT groups
or Line Of Business (LOB) - rather than according to business process or service - resulting in a
hodgepodge of packaged, custom and legacy applications.

This diagram
illustrates how
various processes
involve multiple
units within the IT
division itself. This
matrix of
organization unit and
functions is further
complicated when
LOBs maintain
Graphic 1: Organization complexity in IT service provision exclusive or
predominant
influence over their
major applications.
With their
intrinsically narrow
views of the
enterprise, these
"silos" add to the
complexity of
managing enterprise
applications and
create a number of
management
problems. The lack
of visibility across
the enterprise hinders
the ability to
measure service
levels and the
business impact of
problems, obstructs
managing
availability and
performance, and
limits the ability to
isolate and resolve
problems. Since each
LOB addresses
similar management
concerns - often in
different ways
- management efforts
are duplicated,
economies of scale
are lost, and any
 prospect of a "big
picture" view of the
business is wasted by
the lack of
information sharingR.
In large
organizations with
multiple mission-
critical applications
, the respective
businesses may be
reluctant to
relinquish any
control over the
application to a
central IT Provider
(ie. Application
Support) thereby
creating complexity
and inefficient
management. The
need for cooperation
can lead to friction
because units need to
acknowledge process
hand-offs.

This need for cooperation is inherent throughout ITIL best practices and requires attention and
ongoing scrutiny by the organization wishing to implement, sustain and build upon service
improvements:

"When ITIL is implemented, the support and delivery of IT services is

performed via cross-functional processes rather than functional groups. It is
up to the organization to determine how those processes will map to the
existing organizational structure. In some cases, that structure is changed. In
other cases, organizations decide to formulate cross-functional committees
to oversee and steer processes. In either case, people are ultimately forced to
change how they perform their daily tasks and that is not always met with
enthusiasm. These changes can include simple procedural changes, entire
process reform, changing the tools that are used, individual job title changes,
and changing reporting lines."

Problem Management: The Key to Leveraging an ITIL Implementation, Chorus White Paper, March,
2005

Friction occurs at the point where activities, operations, functions,

disciplines, departments, or business units interact. Metrics should be placed
at these touch points to meaure the amount of friction that occurs.

Mark D Lutcheon, managing IT as a business, Son Wiley & Sons, 2004, ISBN: -0147-14706-6, p.
168.

The introduction of better workforce practices is a key enabler for implementing new process
initiatives and needs to be closely coordinated with better governance models including a review of
the organizational structure of the IT service provider.
 Organizational Process Capabilities
People Maturity Modeling suggests that this "friction" and the workforce practices engendered by
rigid organizational structures are endemic in less mature organizations. At a minimum the enterprise
must ensure a stable work environment. Without this stability introducing new work practices
associated with revised or new processes will be problematic...

At the second level of maturity, organizations must establish a foundation on

which they can deploy common processes across the organization. Before
being able to successfully implement many advanced practices, management
must first establish a stable environment in which to perform professional
work. They must ensure that people are not constantly rushing about
pellmell, cutting corners, making mistakes from hasty work, and fighting the
fires that characterize over-committed organizations. Until basic
management control is established over daily work, no organization-wide
practices have any chance of being deployed successfully since no one has
the time to master them. The primary objective of a level 2 environment is to
enable people to repeat practices they have used successfully in the past. To
enable this repeatability, managers must get control of commitments and
baselines. The effort to establish a repeatable capability is the effort to
establish basic management practices locally within each unit or
project. Only when this management discipline is established will the
organization have a foundation on which it can deploy common processes.

http://www.sei.cmu.edu/cmm-p/version2/

Defining standard processes is crucial in achieving level 3 process capabilities. In devising its'

criteria for assessing the maturity of IT governance process, the Information Systems Audit and
Control Association suggest that best practices such as ITIL are targeted to the achievement of a
point between maturity levels 2 and 3.

Graphic 2: COBIT Executive Summary

Most organizations are currently at level 2 - offering Repeatable services. ISO standards reside
about half way between levels 2 and 3 while currently described best practices such as ITIL are
focused at organizations striving (but not attaining) a defined maturity level. The ultimate goal for
all enterprises should be attainment of an " optimizing" maturity level. The reasons for this are aptly
described in the following passage from CMMI.

The organization's set of standard processes, which is the basis for maturity

level 3, is established and improved over time. These standard processes are
used to establish consistency across the organization. Projects establish their
defined processes by tailoring the organization's set of standard processes
according to tailoring guidelines.

The organization’s management establishes process objectives based on the

organization’s set of standard processes and ensures that these objectives are
appropriately addressed.

A critical distinction between maturity level 2 and maturity level 3 is the

scope of standards, process descriptions, and procedures. At maturity level
2, the standards, process descriptions, and procedures may be quite different
in each specific instance of the process (for example, on a particular project).
At maturity level 3, the standards, process descriptions, and procedures for a
project are tailored from the organization’s set of standard processes to suit a
particular project or organizational unit. The organization’s set of standard
processes includes the processes addressed at maturity level 2 and maturity
level 3. As a result, the processes that are performed across the
organization are consistent except for the differences allowed by the
tailoring guidelines.

CMMI

In the Netherlands, the Kwintes Project applied CMM to the achievement of level 3 service

management maturityN. It cited the following key processes for obtaining a Standardized level of IT
service management:

 Organization Service Definition - a service catalogue is developed that describes the

services, in terms of customer benefits, that the service provider can deliver.
 Organization Process Definition - the organization describes the processes used to deliver
the services, described in the service catalogue. Service catalogue and standard service
processes undergo improvement as a result of practical experience.
 Organization Process Focus - this key process area is aimed at implementing the standard
processes and assessing the performance of the processes in practice.
 Integrated Service Management - this key process area is aimed at tailoring the standard
service processes to specific service commitments for a specific customer so that the tailored
process can be used to manage and deliver services to the customer.
 Service Delivery - the tailored service processes are performed to deliver the services.
 Training Program - based on the standard processes, a training program is developed.
Employees are trained to fulfill their roles in the standard process.
 Intergroup Coordination - delivering services requires different groups and disciplines to
coordinate their work. This key process area makes sure communication between different
groups is facilitated.
 Problem Management - incidents and service requests that are registered as part of the
Event Management key process area are analyzed to identify and solve underlying problems
in the information technology.
  Resource Management - required resources for delivering different services to different
customers are coordinated across the organization.

Kwintes emphasizes the development of process descriptions and suggests that these process assets
should be developed in close parallel with a service catalogue. And, many of the Kwintes
recommendations can be found in COBIT (CobIT describes how an organization would work at
different maturity levels for 34 essential processes, many of which are further elaborated within ITIL
best practice areasN).

To achieve this requires specific capabilitiesN. Most prominent amongst these are Organizational
Process Definition, necessary for the organization to retain the accumulated experience of
knowledge workers in a structured context. Otherwise, the organization has difficulty institutionalizing
and benefiting from shared knowledge - "Organizational process assets enable consistent process
performance across the organization and provide a basis for cumulative, long-term benefits".

Process Modeling
Definition of Process
"A naturally occurring or designed sequence of operations or events,
possibly taking up time, space, expertise or other resource, which produces
some outcome. A process may be identified by the changes it creates in the
properties of one or more objects under its influence."

Wikpedia

Definition of Process
"a connected series of actions, activities, changes etc., performed by agents
with the intent of satisfying a purpose or achieving a goal. "

ITIL, Planning to Implement Service Management, Appendix B 1, Process Theory

Underscoring the concept of process is a theoretical premise - process theory which holds that if an
outcome is to be duplicated, so too must the process which originally created it. There are certain
constant necessary conditions for the outcome to be reached. This simple relationship can be
extended to include additional relationships. Inputs determine (or, in statistical systems establish
tendencies), which when followed by certain activities produce specific Outcomes.

A Process Model can be used to describe activities and their relationships. Process Models are
graphical representations of existing or planned processes and can be used to understand what
functions are performed and how those functions interact. A process represents an action or task that
requires some amount of time to accomplish its objectives. A completed Process Model graphically
depicts the specific steps, operations, and information needed to perform a process. Data enters the
process, is processed, data comes out, the outcome is measured and reviewed. This very basic
expression underlies any process description. The process model may represent as broad or as
narrow a viewpoint as is required and may be refined further and into more detail. If several
viewpoints are desired, separate models can be developed for each. Some characteristics of a
process include:

 A process is always organized around a goal. The main output of that process should be the
result of that goal.
 A process model will also describe the activities that exist within a business process.
 A scope statement should set out, in broad terms, the content of the business process and
the process model that exposes it.
  The process model will define the required activities and set them into a logical sequence.
This sequence is driven by the dependency of one process on the information that is provided
to it by one or more other processes.

A process model can be developed to a very fine or very coarse degree of detail. The more precise
the model, the more specific it becomes to a particular process as practised in one place. If it is less
precise, it can be used with a high degree of generality.

Often information or materials produced in one process are used

in others processes. The term "ICOM" is the acronym for the
four possible roles relative to a process:

1. Input - data or material used to produce the output of a

process.
2. Control - data that constrain a process. Controls
regulate the transformation of inputs into outputs.
3. Output - data or materials produced by or resulting
from the process.
4. Mechanism - people, machines, or existing systems
that perform functions or provide energy to the
process.
In Planning to Implement
Service Management, ITIL
presents a somewhat more
elaborate description of the
ICOM approach. In their
description Controls are
specifically identified as
either Goals and Objectives,
values and characteristics
associated with a champion or
designated process owner and
quality parameters including
Key Goal and Performanc
e Indicators. Mechanisms are
defined as Resources and
Roles.

Elements of Good Process

It should be evident that there is general consensus around the importance of developing,
documenting and maintaining process artifacts for IT service improvement. Without this capability it
becomes exceedingly difficult to implement and then institutionalize IT service management gains.
In addition to process flow charting, a good process description should contain the elements needed
to sustain and improve. These have been described in CMMI as generic or institutionalization
processesR.

The following is a fairly exhaustive list of attributes that characterize the robustness of a process. In
this sense, robustness refers to the resiliency and durability of a process to withstand abuse, enforce
compliance, and be able to measure its effectiveness. The robustness of a process comes in degrees
- the absence of a few of these characteristics doesn't mean that a process is weakly designed or
poorly executed; however, in general, the more of these attributes that are present, the more robust a
process is. Many of these are included in the following list of process elements.

 The objective is identified. An early step in creating a robust process

is to state its overall objective, document it, share it with all appropriate
parties, and ensure that all process-design participants agree to it and
clearly understand it. The objective should answer the questions of
what problem the process solves, which issues it addresses, and how
the process adds value and quality to the environment.
 The executive sponsor is identified and involved. Each process needs
to have an executive sponsor who is passionate about the successful
design and ongoing execution of the process. This person provides
support, resources, insight, and executive leadership. The executive
sponsor arranges for any required participation or communication with
other groups, either inside or outside the infrastructure. This individual
is often the manager of the process owner.
 The process owner is identified and given responsibility for and
authority over the process. This person leads the team that designs
the process, identifies its key customers and suppliers, and documents
its use. The process owner executes, communicates, and measures the
effectiveness of the process on an ongoing basis.
 Key customers are identified and involved. Key customers are those
individuals who are the immediate users and direct beneficiaries of the
process. For example, suppose you're designing processes to request
the restoration of a file or the resetting of a password. Key customers
for these processes may be users who are most likely to request these
services on a regular basis. Their involvement in developing the
process is important to ensure practical design and ease of use.
 Secondary customers are identified and consulted. Secondary
customers are those that may use a process less frequently than primary
customers or who may be the eventual rather than immediate
beneficiaries of the process. Using the example in item 4 above, if
administrative assistants are making the original requests for file
restorations, then their managers are likely to be the secondary
customers of the process. Their consultation can be helpful because
they may be the ultimate users of the process.
 Process outputs are identified. These are the specific deliverables or
services that the process provides to the primary and secondary
customers. Service metrics usually measure the quality of the delivery
and the content of these outputs.
 Process inputs are identified. These are the specific input entities that
the process requires. They may take the form of soft inputs such as
data, information, or requests, or they may be hard inputs such as
floppy disks, tapes, or other physical entities.
  Process suppliers are identified and involved. Process suppliers are
the individuals who provide the specific inputs to a process. These
suppliers may be:
o internal to an IT infrastructure (for example, data entry
departments)
o external to an IT infrastructure but internal to IT (such as a
development group entering change requests)
o external to IT but internal to a company (for instance, an
outside user group supplying report modification
information)
o external to a company (such as hardware and software
vendors who may provide details about how an upgrade is
to be performed)
 The process is described by a sound business model. In simple
terms, a robust process should make common business sense. The
benefits of using the process should exceed the cost and efforts
expended to design, execute, and maintain the process. The business
side of a robust process sometimes involves leasing agreements,
maintenance agreements, and service-level agreements.
 Process hierarchy is understood. Some processes have secondary
processes or sub-processes underneath them. Individuals who are
developing well-designed robust processes know and understand the
relationships between the primary and secondary processes.
 Execution is enforceable. Almost any process, regardless of design,
needs to be enforceable to be effective. Whenever possible and
practical, software techniques such as passwords, authorizations, audit
trails, or locks should enforce compliance with a process. When
technical enforcement is not practical, management support, review
boards, metrics, or other procedural techniques should ensure
enforcement.
 The process is designed to provide service metrics. Most processes
measure something associated with their output. Often this involves a
quantitative measure such as transaction processes per second or jobs
completed per hour. In addition, a robust process focuses on qualitative
measures that are oriented toward the end user. These metrics show the
relative quality of the service being provided. N

Developing Robust Processes, Lightpointe, Nov 19, 2004

Process orientation is often a big change and demands commitment from the management. Without
this commitment process orientation initiatives often fail to deliver the expected results. By centering
ones attention on processes the focus is also transferred from the finished result to the activities
forming them. Since the processes create the result, they are also the first things that have to be
controlled and developed. By focusing on core elements, the process view can be applied on an all-
embracing level in the organization, seeing the whole organization as one system. Looking at the
organization as a system of integrated and interrelated processes is vital for this kind of thinking.R.

I believe that process developing and maintenance is as important a process as any of the ITIL best
practices areas. Therefore, I describe the underlying sub-processes which make it up under HCI
processes. Access this process for further detail on implementing and sustaining process artifacts.
Service Improvement Issues
For many companies, implementing ITIL best practices has proven enigmatic. In this section I discuss
industry difficulties in implementing ITIL best practices. Information on post-implementation failures is
hard to find (organizations are reluctant to publicly expound upon such failures even if they are
sophisticated enough to produce conclusions on performance based upon empirical findings),
however, I postulate upon both operational and optimizing issues.

Identifying the barriers to implementation within organizations, whether real or perceived, can lead to
refinement of service improvement scope and specification statements. It will permit a better
identification of contingency and/or strategies for removing or neutralizing/mitigating the impediment's
effects. Some of these barriers may be beyond the organization's control (eg. regulatory and statutory
requirements), but others may reside within the organization's culture - deep-rooted, even intractable
but not unmanageable. This section addresses these impediments and possibilities for their removal
or management.

The discussion is conducted by grouping issues into four categories reflective of the kinds
of gaps which organizations will typically encounter between existing and desired states. Any one of
the four types can be a major impediment to proper implementation, operational or improvement
undertakings. The types often interact in ways which reinforce tendencies to back-slide to
previous, more comfortable methods and procedures.

What's in this Section

Industry Implementation Service Expectations Awareness Design Delivery
Success Rate Gaps --> Gap Gap Gap Gap

Industry Implementation Success Rate

As experience with ITIL implementations grew throughout the 1990s it was inevitable that some
disillusionment would offset the sometimes excessive claims of benefits. After all, those benefits, as
originally expounded in the ITIL best practice areas, described fully implemented processes, fully
integrated with other ITIL process areas. Moreover, they were based upon a sample of European
industries (mostly large) with successful IT service management practices - few if
any struggling organizations were asked to provide comment.

In January 2005, IT Republic published an article on the results of research into over 200 ITIL
implementationN. It's findings were:

 ITIL adoption is gaining momentum but is still in the early stages of

implementation for most enterprises in North America: Only 19% of
respondent organizations in North America have reached the most
mature practice levels (control, integration, and optimization). The
majority of respondents (81%) report their adoption of the ITIL
framework (guidelines, principles, and concepts) is either absent or is
still being established and is not yet fully implemented.
 Organizations prefer integrated suite-based approaches to ITIL
adoption: Over 75 percent of respondents employ a solution that relies
on an integrated suite — either alone or in combination with home-
grown or point solutions. In contrast, less than 25 percent rely on
home-grown or point solutions alone or in combination to implement
ITIL best practices.
  Organizations approach ITIL Service Support and Service Delivery
processes stepwise resulting in maturity gaps. For each of the Service
Support processes, about 50 to 60 percent indicate absent or initiated
processes (not yet fully implemented). Service Delivery processes are
moving slower along the maturity curve, with less than 40 percent of
organizations reporting mature practice levels for most delivery
processes.
 Impediments to successful ITIL adoption revolve principally around
management factors that are under the control of CXO: CXO
sponsorship is the dominant critical success factor in the adoption of
ITIL. Survey participants report the major barriers to ITIL adoption are
a lack of awareness (61 percent), an inability to attain buy-in (60
percent), and a lack of committed process owners (59 percent).
Technical issues are of secondary importance to adoption decisions.
 Many organizations are using ITIL processes as a part of their strategic
planning: Over 40 percent of respondents indicate that their enterprise
currently considers IT service management a strategic part of their
design and planning processes, and others (40 percent) will do so in the
near term.

Note: that the definition of maturity being referenced here is that used by the
CCTA which would appear by the categories to be easier to score on that the
definition within CMMIN.

The Adoption of ITIL in Large Enterprises, techRepublic, January, 2005, p. 3

The preamble to the article concludes by stating - 'One immediate challenge for IT professionals is to
convince key decision-makers of the value of ITIL adoption for their enterprise by increasing
awareness, buy-in, and process ownership within the enterprise."R.

The original hype has been subjected to greater internal scrutiny as organizations have been
increasingly asked to verify performance improvements. The ability to properly engage in this kind of
verification requires an organization with some level 4 CMMI capabilities - ie. quantitatively managed -
often presenting the organization with the sobering realization that there are many other management
practices (ie. enablers) that need to be improved as either pre-requisites or co-requisite to ITIL best
practices.

Moreover, organization will also come to the realization that implementing the best practices of other
organizations has its' own unique set of problems. Every enterprise has a unique combination of
competition, regulations and culture which requires the "tailoring" of practices to individual
characteristics.

Consider the following commentaries:

"The ITIL methodology has proven to be notoriously time-consuming and

difficult to implement. Although ITIL promises cost-saving and process
improvements, there is no guaranteed return on investment (ROI), making
the ITIL proposition a not very attractive one for corporate IT departments,
where the situation in 2003 is characterized by intense cost-cutting
initiatives coupled with a quest for quick ROI. Anecdotal evidence of costly
ITIL implementation failures has further deepened concerns of companies
interested in the general ITIL approach."

"Vendors have oversold the ITIL methodology as a means of mapping

business processes to IT processes, which is indeed a big concern for many
 IT departments these days. Unfortunately, ITIL is unsuitable for this task. It
is merely a way of structuring the internal IT service delivery and once fully
implemented will increase the efficiency of the IT department. Once clients
started to familiarize themselves with the ITIL concept, this mismatch
between promise and reality became obvious, effectively diminishing the
ITIL value proposition even further.

Both from Thomas Mendel, Beyond ITIL: Despite Hype Full Implementations Are the Exception,
GIGA Research, October 23, 2003

Gap Analysis - What Prevents Service Improvement

Performance gaps exist in organizations when current process, technology and resource capabilities
do not meet the needs of its 'customers' or the overall organization's business objectives. Gap
analysis is the comparison of the current capabilities of an organizational process with a future vision
of for that process (often, though not always, equivalent to customer expectations). The current
position is identified by baselining the process - the AS-IS description. The future position is projected
by describing how the process should operate to meet organizational objectives - the TO-BE process.
Gap analysis describes strategies and tactics for the organization to achieve the desired state; - ie.,
move from the AS-IS to the TO-BE state.

Best Practices such as ITIL allow the organization to describe the TO-BE process by adopting or
adapting processes, principles and practices used by what are considered to be "successful"
enterprises. The key to a successful grafting lies in the distinction between "adopting" and "adapting".
The former implies a largely wholesale use of described principles and practices while the latter
implies a "tailoring" of the processes to organizational size, capabilities and cultural influences.
Successful "adapting" challenges the organization to thoroughly understand the state of its' internal
processes and the constraints they place upon the organization. They can lead to one or more of four
fundamental service "gaps" which the organization should either remove or mitigate their adverse
impacts.

The Expectations Gap

One of the most frequent results of poor requirements analysis is that customers and stakeholders are
not properly considered. The development of requirements includes:

 Elicitation, analysis, validation, and communication of customer needs, expectations, and

constraints to obtain customer requirements that constitute an understanding of what will
satisfy stakeholders;
 Collection and coordination of stakeholder needs;
 Development of the life-cycle requirements of the product;
 Establishment of the customer requirements;
 Establishment of initial product and product-component requirements consistent with
customer requirements.
 The service improvement
initiative must acknowledge
these these needs or
an Expectations Gap can
arise. This gap reflects the
difference between the service
expected by customers and
lines of business and the
service vision of the Service
Provider.

This situation isn't necessarily

the result of any disconnect
between the Provider and
Client groups. IT Service
providers are constantly under
pressure to provide service to
additional customers as the
organization assumes new
systems and services. These
service extensions often occur
without sufficient additional
resources. The result is often
capacity pressures - a
decreasing ability to maintain
service levels in the face of
mounting capacity pressures.
The Provider experiences
increasing difficulties in
maintaining levels of
performance. Customers
continue to expect the same
service but the organization
cannot deliver it without
additional resources.

The problem is most acute when it comes to support costs. The introduction of new systems is usually
accompanied by analyses of new server and equipment requirements. Estimates of these can usually
be determined during stress testing of an application. More problematic are the support requirements
- the resources needed to maintain high availability or the resources required to restore the
application when something goes awry. These are either ignored, downplayed or the IT organization
is instructed to absorb the costs. The continual absorption of these costs can quickly place the IT
department in an untenable position. Reginald Tomas Yu-Lee comments on the organization's
inability to adequately conceptualize capacity.

"Historically, organizations have not effectively managed their total

capacity, quite simply because traditional definition of capacity limit the
understanding of what constitutes capacity. Definitions that only focus on IT
capacity, for instance, fail to acknowledge space, labor, equipment, and
materials. "

Essentials of Capacity management, Reginald Tomas Yu-Lee, 2002, ISBN: 0-471-20746-2, p. 21

ITIL recognizes the need for the IT organization to acknowledge customer expectations.

"it is wise to try and manage Customers' expectations. This means setting
 proper expectations in the first place, and putting a systematic process in
place to manage expectations going forward, as satisfaction = expectation -
perception."

ITIL Service Delivery, Section 4.4.2

In the ITIL framework, customer expectations are addressed through Service Level Management.

"An ancillary benefit of service level management is that it makes it possible

to avoid so-called expectations creep - that is, the ever rising levels of users'
undocumented expectations"

Sturm, Morris, Jander, Foundations of Service Level Management, SAMS, 2000, ISBN: 0672317435,
p. 16.

The Service Level Agreement is the negotiated document wherein performance is described and
tracked. It establishes a direct relationship between performance metrics and the resources
necessary to achieve those levels - Service Level Management allows the IT department to meet
business expectations and opens a dialog to confirm these expectations R. Service Level Management
is, thus, an important element in mitigating or avoiding and Expectations Gap.

"Without SLAs in place, you are effectively telling your customers that you
will provide support to them any time, under any conditions, without any
limitations to the systems and services they have."

HDI - Implementing Service & Support Processes, Chapter 8

The Awareness Gap

The organization needs to realize when it has
succeeded - and this includes customers and
stakeholders. Well implemented processes
may not achieve their objectives if their
existence and operation is not properly
communicated to the consumers of the
services.

Although the vision is a powerful

tool in helping guide and
coordinate Change, the real
power is unleashed when the
vision is effectively
communicated to
the stakeholders. ... Typically,
their interest stems from the fact
that they are investing time,
energy, attention, money, and/or
other resources with the
expectation that they will achieve
some form of return on their
investment.
 The sense of urgency ('What if
we do nothing?') and the vision
('What's in it for me?') should
form the basis of all
communication to the
stakeholders involved in or
impacted by the CSIP. These
messages should be aimed at
motivating, inspiring and
creating the necessary energy
and commitment to buy-in to the
Change Programmed. The
question 'What's in it for me?'
can be answered by the vision
statement ... for various
stakeholders.

CCTA - Planning to Implement Service

Management

An Awareness Gap often exists around IT services that have low day-to-day visibility with the
customer and stakeholders. Typically, service continuity and capacity management issues are "low"
on the horizon with line of business customers. Service Improvements in these areas often go
unnoticed by business customers. The IT Provider may establish initial communications channels but
fail to maintain them with fresh material over the life of the implementation effort. The result is the
initial enthusiasm is soon replaced with complacency, and, generalized message content may not
address the specific needs and wants of a target group.

Service Design Gap

A service must be designed. CMMI cites six fundamental engineering capabilities needed to properly
design a service:

 Manage requirements so as to identify inconsistencies between them and work products;

 Produce and analyze customer, product, and product-component requirements;
 Design, develop, and implement solutions to requirements;
 Assemble the product from the product components, ensure that the product, as integrated,
functions properly, and deliver the product;
 Ensure that selected work products meet their specified requirements; and,
 Demonstrate that a product or product component fulfills its intended use when placed in its
intended environment.
 If these practices are not
done well there will be
gaps between the
requirements of the
customer for a service and
the manner in which the
service is envisioned.

In ITIL the definition of

services is defined through
the establishment of
"Service Level
Requirements". ITIL
comments on the
difficulties which can be
encountered in doing this.

"It can be difficult to draw

out requirements, as the
business may not know
what they want - especially
if not asked before and they
may need help in
understanding and defining
their needs. Be aware that
the requirements initially
expressed may not be those
ultimately agreed - they are
more likely to change
where charging is in place.
Several iterations of
negotiations may be
required before an
affordable balance is struck
between what is sought and
what is achievable and
affordable"

ITIL Service Management, Service

Level Management, Chapter 4.4.4

Most organizations don't devote sufficient time to requirements definition. The Standish Group cited
"incomplete requirements" as the prime reason why projects failed.R. This lack of rigor in original
definition becomes increasingly manifest in IT-Business misalignment as the goals and objectives
inherent in ongoing service and system support fail to align perfectly with business goals and
objectives.

Ralph Young echoes the findings of the Standish Group in Effective Requirements PracticesR. He
suggests that "Poor requirements are a major, though not exclusive, contributor to poor technical
solutions" - ie., the service design. A poor design can also result from:

 Incomplete review and analysis of alternative designs so that the selected design may not be
the best one
 The design is imperfect in one or more phases of the product lifecycle
  There are distinctions between the environment wherein the design was selected (eg., test or
QAT environments) and its' intended (ie. live) environment.

Mr. Young provides some recommendations to "facilitate getting to the real  requirements":

1. "Invest 8% to 14% of total program costs on, the requirements

process. Spend additional time and effort near the beginning of a
project to work to identify the real requirements. Ensure joint user
and supplier responsibility for requirements. Facilitate clarification
of the real requirements. Control changes to requirements.
2. Train program and project managers (PMs) to pay more attention to
the requirements process.
3. Identify a project champion. A project champion is
an advocate for the effort, is very familiar with the set of real
customer needs for a system, and provides an active role in the
development activities, facilitating the tasks of the development
team.
4. Develop a definition of the project vision and scope.
5. Identify a requirements engineer and utilize domain experts to
perform requirements engineering tasks.
6. Train developers not to make requirements decisions and not to
gold plate.
7. Utilize a variety of techniques to elicit user requirements and
expectations. Use a common set of techniques and tools among all
parties involved in a particular project.
8. Train requirements engineers to write good requirements.
9. Document the rationale for each requirement.
10. Utilize methods and automated tools to analyze, prioritize, and
track requirements.
11. Utilize peer reviews and inspections.
12. Consider the use of formal methods when appropriate."

Ralph Young, Effective Requirements Practices, 2001, ISBN: 0-201-70912-0, pp 59-60

Best Practices as Representing "TO-BE" Descriptions

Best Practices allow an organization to establish service design specifications based upon generally
accepted standards and methods. But, the "logic" behind these standards and methods often requires
the organization to take a "leap of faith" because they have not experienced the pain pointsN.

The organization must "adapt" rather than "adopt" best practices. The former implies "tailoring" of the
best practices to the unique characteristics of the organization and to the current situation. The
"adaption" requires...

 an understanding of what distinguishes an organization undertaking IT service improvement

from those organizations used to collect and describe "best" practices. Note that ITIL, as an
open, widely available description of techniques, differs from offerings such as Gartner's TCO
studies. The latter provide more extensive breakdowns (including an organization's type -
financial, government, etc) of the factors influencing the cost of IT services.
 an internal culture conducive to implementing change. Adopting new procedures without
experiencing the pain associated with poor or failed processes will often result in lack of
internal support for the so called "best practices". Bernard Boar comments on this aspect of
change:
 "It should be borne in mind that there is nothing more difficult to handle or
more doubtful of success, and more dangerous to carry through than
initiating change. The innovator makes enemies of all those who prospered
under the old order, and only lukewarm support is forthcoming from those
who would prosper under the new. Their support is lukewarm partly from
fear of their adversaries; who have the existing laws on their side, and
partly because men are incredulous, never really trusting new things unless
they have tested them by experience."

Bernard Boar, The Art of Strategic Planning for Information Technology,

Wiley, 1993, ISBN: 0-471-59918-2, p. 332.N

 the sophistication of internal strategic planning processes - what COBIT refers to under the
general heading of "Planning and Organization" and cites the following supporting activities:
o Information Technology as Part of the Organization's Long- and Short-Range Plan
o Information Technology Long-Range Plan
o Information Technology Long Range Plan Changes
o Short Range Planning for the Information Services Function
o Assessment of Existing Systems. N

The intent of these strategic activities is to align IT with the business goals and objectives of
the organization so that it makes a direct contribution to their fulfillment.

The difference between where we are (current status) and where we want to be (vision and goals) is
what we do (target objectives and action plans). Each improvement project must have objectives
which explain this alignment. The objectives for the project must cascade to other business objectives
which further the organization's goals, mandate and vision. Goals are simply a clearer statement of
the visions, specifying the accomplishments to be achieved if the vision is to become real. The target
objectives are clearer statements of the specific activities required to achieve the goals, starting from
the current status.

Service Delivery Gap

Even if the organization gets its' target (the TO-BE model) right it may not be able to achieve it. It may
have a Delivery Gap. This represents the distance between the established delivery standards and
actual service delivered by the IT department. For example, IT management may set a target that
telephone calls should be answered within thirty seconds. If it regularly takes more than thirty seconds
for calls to be answered, regardless of the cause, there is a delivery gap.
 When requirements expand
(as depicted in the graphic by
the demands upon the
previous solution - the bridge)
new capacity and
performance is expected.
Achieving the benefits of
ITIL service delivery
processes such as Availability
and Capacity Management
assume a recognition of a
shift in organizational focus
from technology-based
organizational units (eg.
network, application, desktop)
to a more goal-direct focus
(eg. availability, capacity).
This shift implies that there
are greater benefits in
considering network and
database availability together
(eg., in an availability plan or
in incident procedures) than
considering each of network
restoration, availability,
capacity as independent
entities. There is, of course,
no correct exclusive view, but
ITIL suggests that a re-
focusing to a more functional
perspective (including
amassing needed subject
matter skill-sets) will usually
produce efficiencies. This
shift from a product to
functional focus will
challenge organizations
lacking experience and
support structures in inter-unit
cooperation.

The organization may not be able to bridge the gap between AS-IS and TO-BE processes for a
several broad reasons:

1. Immature Workforce Practices

People Capability Management suggests that an organization must achieve work-force practices in
stages so as to have the necessary underlying practices to implement sophisticated processes.
Consider the following conditions cited by People's CMM

"Many of the firms beginning to investigate process innovation are

constrained by some aspect of their structures or cultures, which makes it
difficult for them to pursue their interest to the point of concerted action.
Structural and cultural constraints to process innovation include strict
 hierarchical structures, cultures unreceptive to innovation, and general
organizational rigidity or inability to accommodate change."

Thomas H Davenport, Process Innovation, Harvard Business School Press, 1993, ISBN: 0-87584-366-
2, p. 106

At the second level of maturity, organizations must establish a foundation on

which they can deploy common processes across the organization. Before
being able to successfully implement many advanced practices, management
must first establish a stable environment in which to perform professional
work. They must ensure that people are not constantly rushing about
pellmell, cutting corners, making mistakes from hasty work, and fighting the
fires that characterize over-committed organizations. Until basic
management control is established over daily work, no organization-wide
practices have any chance of being deployed successfully since no one has
the time to master them. The primary objective of a level 2 environment is to
enable people to repeat practices they have used successfully in the past. To
enable this repeatability, managers must get control of commitments and
baselines. The effort to establish a repeatable capability is the effort to
establish basic management practices locally within each unit or
project. Only when this management discipline is established will the
organization have a foundation on which it can deploy common processes.

At the third level of maturity, the organization identifies its best practices
and integrates them into a common process. Once people are able to perform
their work at the Repeatable Level using practices they have found to work,
the organization has the ability to identify which practices work best in its
unique environment. These practices are documented and integrated into a
common process that is then trained to the entire organization. Measures of
the critical practices in this process are defined and collected into repository
for analysis. When the organization defines a standard process for
performing its business activities, it has laid the foundation for a
professional culture. Most organizations report the emergence of a common
culture as they achieve Level 3. This culture is based on common
professional practices and common beliefs about the effectiveness of these
practices.

People's CMM

2. Ineffective Governance
"The differences between success and failure in today’s high technology
environment, for many organizations, are based on the IT governance
framework they adopt."

IT Governance: Maximizing the Business Investment, Neil Stolovitsky - December 13,

2005, Technology Evaluation Centers

"Silos" result from introducing governance mechanisms piecemeal in order to address specific needs
(for example, architecture problems or overspending or duplication). Patching up these problems as
they arise limits opportunities for the IT provider to make a more strategic impact on business.
Instead, management should actively design IT governance around the enterprise's objectives and
performance goals. Actively designing governance involves senior executives taking the lead and
allocating resources, attention, and support to the process. For some enterprises, this will be the first
time IT governance is explicitly designed. Often there are mature business governance processes to
use as a starting point.R.
Governance determines who make what decisions. This has vertical implications for most appropriate
organizational structure to promote the desired service improvement goals and horizontal significance
for placing decisions at the right level in the organizations. Two key elements in designing a
governance framework are:

 Clarify the exception-handling process - exceptions challenge the status quo, particularly
the IT architecture and infrastructure. Some requests for exceptions are frivolous, but most
come from a true desire to meet business needs
 Provide the right incentives - a common problem is the misalignment of incentive and
reward systems with the behaviors the IT governance arrangements were designed to
encourage
 Assign ownership and accountability for IT governance - Like any major organizational
initiatives, IT governance must have an owner and accountabilities. Ultimately, the board is
responsible for all governance, but the board will expect or delegate an individual (probably
the CEO or CIO) or group to be accountable for IT governance design, implementation, and
performance

3. IT Department Scale
ITIL best practices assume implementation by organization with enough IT activity to justify the
processes as described. While there is literature describing ITIL implementations in small
organizations, R the benefits as stated apply to implementations within relatively large organizations.
Consolidation of described roles by individuals can only go so far before the benefits will be
outweighed by the costs of the training needed and the costs of the disruptions encountered in the
implementation.

4. Support Sustainability
People CMM notes that organizations with low level of workforce competencies have higher levels of
turn-over accentuating the problem. Teams assembled to implement an ITIL initiative may be
dissolved without proper thought for how the momentum for the initiative can be maintained. At low
organizational maturities few supports for continuous improvement are in place so that ongoing
support is systemic.

The result is that the organization will slip back into the old ways of doing things (the "natural" way)
and the ITIL initiatives will become "another management flavour of the day". In truth, organizations
reliant upon "champions" (ie., individuals) for the continuing support of projects will have archives full
of unfulfilled efforts and the organization may approach the next one with an air of defeatism. Such
histories provide a challenging hurdle for generating team and stakeholder enthusiasm for new
projects.

Even if the organization achieves some tentative gains it may not be able to sustain them because it
has not internalized the necessary administrative and management supports. Without the supporting
processes the organization will slip into the old ways of doing things (largely because they are
"natural") and ultimately view the recent gains as "just another management initiative". Reversion to
previous methods often have one of two primary root causes...

1. the preparatory work outlining the financial benefits and costs to implement ITIL were not
adequately done so that there is no compelling rationale which can withstand the absence of
initial ITIL champions (eg. original sponsors assume other roles in the organization)
2. There are practically no "big-bang" ITIL implementations (ie. all processes implemented
simultaneously). The "natural" state of ITIL implementation is continuous. It must continue to
evolve and momentum must be maintained. The transition must be accompanied by a shift in
organizational values...

Old Attitude New Attitude

 Clients are Users Clients are Customers

Inward looking Outward looking

Technology focus Process focus

Ad hoc processes Streamlined, focused processes

Best Efforts Measured, accountable processes

Entirely in-house balanced in-house and outsourced

Organization is fragmented with Integrated end-to-end

silos

Reactive Proactive

Operations Management Service Management

System skills Listening skills

The HP Service Management Reference Model White paper

These gains will most likely require the organization to achieve greater maturity in it's supporting
personnel, administrative and management approaches. A continuous improvement program will
challenge the organization to continually monitor and report upon process results. Organizations
which approach results reporting as ad hoc, periodic activities are not likely to inculcate the result-
oriented perspective necessary to achieve sustained momentum.

Project Improvement Options

Many organizations have found the tenN ITIL best practices areas may be too broad, encompassing
and interdependent to be successfully isolated as service improvement initiatives. Projects will have a
much better chance of success if they can be "Scoped" properly and have manageable
interdependencies with other processes and procedures that are either controlled or managed as
related initiatives in a more encompassing project.

In this section, I provide a basic introduction for each of the ITIL best practice categories and offer
more granular outlines of possible service improvement initiatives. Many of the suggestions are
derived from the proposal selection criteria advanced in the previous section.

What's in this Section - ITIL Best Practice Areas

Inciden Servic Chang Proble Configuratio Releas Servic Availabilit Capacit Financia Continuit
t e Desk e m n e e y y l y
Level
Incident Management
Incident Management (sometimes referred to as Event
Management) will be one of the first processes an organization will
implement. Indeed, all organizations will have some capability to
handle Incidents. One of the major insights that ITIL offers is its'
pre-occupation with restoring service as an exercise separate and
distinct from identifying and solving the underlying root cause of the
incident. The logic inherent in this is simple and sublime, but one
that requires a consistent and dedicated application by the
organization because there will be a natural tendency to seek out
root cause during the investigation of the incident. Unfortunately, all
too often doing so lengthens the time to restore services.
Documented, easily available "workarounds" which can be
implemented quickly to restore service as quickly as possible are the
stock and trade of good Incident Management.

At the same time that Incident Management is seeking to restore a

service to defined operating parameters, Availability and Problem
Management are working to ensure that problems and "Known
Errors" are removed from the infrastructure - so they do not re-
occur. Proactive measures by the organizations responsible for these
areas will reduce the workload on Incident Management teams.
Mature organizations seek to re-direct activity from addressing
incidents to removing their existence in the first place. Ensuring
quality control in recording information on Incident Tickets provides
the data needed to undertake this kind of analysis. Accurate and
complete information is, therefore, an important quality of service
(QoS) consideration which pays dividends to organizations capable
of effectively translating this data into concrete service improvement
initiatives.

Incident Management Process

Possible Incident Management Improvement Initiatives

 Establish Incident Database - At the most basic level an organization needs the ability to
record an incident in order to manage the recovery of any service degradation and to avoid
duplication of effort around the reporting of separate instances of the same incident. More
mature organizations might improve their documentation and categorization of incidents in
order to expedite subsequent restorations due to recurring common cause(s) (ie. identify
Known Errors). When the primary purpose of the incident database is only "recording"
incidents to manage the immediate service issue the database does not need to be
particularly sophisticated and might be developed in using inexpensive software such as MS
Access or MS Outlook (leveraging existing investments in these products)N.
 Establish restoration service targets - Establish service performance targets based upon
the assessed severity of the Incident. Severities are assigned based upon relative perceived
importance of infrastructure component and urgency for restoration at time of outage (eg.,
peak service time vs off-hours)
 Create Knowledge Bases - Record recovery methods on the Incident Ticket for restorations.
Follow this up with recording diagnostics, Known Errors, restoration methods, etc in an
accessible location (eg., web address).
 Establish Major Incident Process - Develop a dedicated and consistent process for
handling major incidentsN. Initially, this function might be performed by an Incident Analyst or
Restoration Officer. In larger operations, however, this may be the responsibility of Availability
Management who have overall responsibility for the availability of systems throughout the
enterprise.
  Implement Incident Ticket Quality Assurance - Review Incident Tickets for completeness
and accuracy. This provides insurance that the incident has been RESOLVED properly and
has a positive affect on Customer satisfaction. The Incident database becomes a reliable tool
for analysis rather than only an archive of past incidents. This enhances the ability of
Availability Management to review stages of the Incident lifecycle for bottlenecks in an
attempt to increase overall infrastructure availability
 Evaluate Incident Lifecycle - Decompose the Incident Management process
into lifecycle stages. Ensure that the Incident Ticket logs entry and exit from each stage of the
lifecycle. The provision of operational data permits operational analysis of the process to
identify consistent bottlenecks and problems in order to decrease recovery time and enhance
overall availability. This provides additional information for analysis and review of Problems
thereby increasing the effectiveness and efficiency of Root Cause Analysis by Problem
Management
 CMDB - Incident Linkage - Link incidents consistently with Configuration Items thereby
facilitating improved identification of impact and permitting better prioritization amongst
competing restoration tasks. This produces improved quality in the Incident database for
Problem Management (identification of problem devices), Availability Management
(extrapolations to assess potential failures) and Capacity (extrapolations for capacity issues).
 Incident resolution governed by SLO - Negotiate and publish service restoration objectives.
The timeframe for resolution of incidents is governed strictly by Service Level Objectives
(SLO) negotiated between lines of business and the IT Provider. Incidents are classified by
severity and priority with established levels dictating their priority consideration as set out in
service level objectives for that classification. As well, alerts are issued when resolution
activity is approaching the established deadlines. This triggers escalation procedures
designed to provide additional resources to the restoration effort so that the organization can
be more successful in honouring service commitments to client groups.
 Review Incident Lifecycle - It is important to recognize that every Incident passes through a
number of stages. This 'lifecycle' view provides an important framework in determining
requirements for incident detection, management reporting, diagnostic data capture and for
securing needed tools for diagnosis and verification that IT Service has been restored.

Service Desk
In small organization the distinction between Incident Management,
the Service Desk and Problem Management may be less pronounced
that in larger enterprises. In small organization a single person might
perform all three roles.

The Service Desk should be the first line of contact for daily user
interaction with the IT Department. They specialize in a quick turn-
around of the most frequent interactions. Typically these will include
service requests, requests for information and recurring incidents
which have known parameters and solutions. These functions are
subject to automation by way of online request systems, online
knowledge bases and bulletin boards to keep user informed of
outages. However, if the organization chooses to rely heavily upon
automated service desk functionality care must be taken to ensure
that the important roles of communication traffic controller and
initial Ticket Owner are re-assigned accordingly within the Incident
Management System.

Service Desk Process

Possible Service Desk Management Improvement Initiatives

 Creation of SPOC - Initiate Incident reporting through a single point of contact. The source
may be physically distributed and may be composed of multiple Help Desks constituted to
form a single 'virtual' help desk.
 Customer Communications - Establish communication policies and procedures designed to
ensure customers and stakeholders are kept continually informed of service requests and
outages - pending, in-progress and completed. This allows Users to plan activities around a
service disruption on the basis of best estimate of a restoration time and allows them to
mitigate the worst effects of an outage. It might also help ensure needed resources are on
alert in the event the incident needs additional resources.
 Service Request process description - Develop processes for fulfilling repetitive service
requestsN. Typical service requests include:
o new employee technology setup
o request for information - HOWTO
o password setup
o hardware / software Move, Add or Change (MAC)

Doing this will permit the organization to become more efficient over a range of repetitive
tasks.

 Monitor customer satisfaction - Aligning customer perception and satisfaction is paramount

to the success of any support operation. It is the customer's perception, rather than
availability statistics or transaction rates, that, in the end, defines whether the Service Desk is
fulfilling its' vital roles of first point of contact and communications conduit. Satisfaction
surveys are an excellent method of monitoring customer perception and expectation and can
be used a powerful marketing tool. The Service Desk should conduct regular surveys of
customer satisfaction, and, in addition to reporting the results, develop recommendations for
improvement based upon the survey data.
 Service Request Reference to Service Catalogue - Develop an online service
catalogue which the Customer can use to order services. The catalogue should include items
on HOW TO ACCESS a service with reference to the Service Desk as the point of initiation.
 Self-Help SR Initiation - Every company would like to reduce the cost of customer service.
Migrating service-oriented calls and emails to self-service channels is a low-cost, high-impact
way to achieve this goal
 Online KB Access - Access to online Knowledge Base information describing common
issues, workarounds, existing known errors and problems within local environment
Change Management
Poorly executed releases and changes are a primary cause of
incidents. Therefore, improvements in change management
processes can result in a quick return on investment for the
organization.

The evidence linking infrastructure changes to user incidents is large

and conclusive R. Many organizations< however, are reluctant to
undertake basic changes in this area. Doing so requires the many
distinct platforms (eg., mainframe, desktop, operating environments,
major business applications) to relinquish elements of control to a
central body. The organizational "silo" in this case loses some
control over the timing and manner in which they make changes,
while many of the benefits are realized in other areas of the
enterprise. Whenever gains accrue to a different organizational unit
from the one incurring the costs, senior management must be
involved to approve and direct any financial re-alignment or to
enforce the change in responsibility on behalf of the overall
organization.

In many organizations separate and distinct Change Management

forums proliferate in subject areas (eg., servers, desktop, application
areas, etc.). There may even be separate Help Desks to record and
initiate activity - each doing their own thing, unmindful of the
cascading affects that a change to their area may have on other
infrastructure elements or other business areas. Consolidation of
Change Schedules is one of the first change management procedures
which should be implemented. This should be quickly followed by
either consolidating Change Advisory forums or ensuring proper
communications amongst them.

A Configuration Management Database will enhance Change

Management's ability to analyze the effect of changes by quickly
displaying the potential impact of a change - including other forums
and areas affected. Any information which improves the
organization's ability to review the risks associated with a change
will have a positive affects.

Change Management Process

Possible Change Management Improvement Initiatives

 Consolidated Change Schedule - Consolidate all Change calendars used throughout the

organization into a single event calendar. This ensures that Changes are coordinated across
the enterprise and that scheduling will take into account other changes. It provides more
complete information on pending changes and reduces any risks resulting from scheduling
conflicts (CI interdependencies, time and resource availabilities, overall structural complexity
in the infrastructure). The Calendar can also provide an important data source for assessing
past change events and their interrelationships.
 Develop RfC and CAB structures - Develop a standard Request for Change template to be
submitted and appropriate change approval procedures. These procedures may vary with the
size and complexity of the organization and the deemed importance to the organization of
changes. Procedures might include:
o peer review of changes
o manager sign-off of changes
o local and corporate change Advisory Board (CAB)review
 o executive management review and sign-off

Combination of different boards might be used depending upon the assigned importance and
risk associated with the change.

 Qualitative risk assessment process - Risks are primarily assessed by reviewing their

assessment of risks as described on the RfC. The ability to properly assess risks associated
with changes is determined by:
o the accuracy and completeness of the information recorded on the RfC
o the breadth of infrastructure representation involved in the review
o the inclusiveness and description of the upcoming change schedule (review of
change inter-dependencies)
o the quality of the review process
 CMDB Reference - The ability to assess the risks of a change is enhanced with the existence
of a CMDB which describes the interdependencies of CIs in the infrastructure. With a CMDB
reference, Change Management is able to determine with increased precision, what and how
CIs are affected. Change Management will be responsible for ensuring that successfully
implemented Changes have their associated CIs recorded or modified in the CMDBN.
 CM documentation libraries - Policies and procedures designed to integrate process
repository into Change Management. These would include:
o rules for checking out documentation - including versioning
o an RfC (or derivative form outlining need for document revision)
o rules governing review of revised documentation
o acceptance criteria
o rules governing checking in of new documentation containing revisions
 Pre-approvals Library - Recurrent low risk changes are pre-approved through an initial
presentation of procedures to the followed for its' fulfillmentN. These procedures are kept in
the documentation repository (part of CMDB) and, as long as the prescribed procedures are
adhered to, the change needs only to be recorded and considered in the Change Calendar.
Any deviations or abnormalities associated with following the procedures will require
clearance through Change Management (which, because of their continuing classification as
low risk can usually be cleared by a Corporate or Local Change Manager).

Problem Management
An important insight advanced by ITIL is the distinction to be drawn
between Incident and Problem Management and the recognition of
the distinct goals, governance, processes and procedures separating
the two services. Problem Management engages more analytic,
quantitative procedures which are often found in more mature
organizationsN. Initiating Problem Management practices will
challenge organizations unwilling or incapable of assuming a more
proactive or predictive view of the infrastructure. Sometimes an
organization will embrace Problem Management, but lack the
necessary management commitment or resources to devote to the
effort. In these situations attention will almost always be redirected
to fire-fighting (ie, urgent, immediate) activities the moment any
resourcing pressures arise.

Nonetheless, there is strong evidence that efforts spent in identifying

 and removing infrastructure faults will produce significant benefit to
the infrastructure's overall stability and have a positive rate of return
on the investment. Yet, like Change Management, issues can arise
with regard to the distribution of the rewards. It is in the nature of
process re-engineering undertakings that the realization of benefits
will often accrue to a different part of the organization than where
the costs are incurred. Without supporting benefit-cost data and in
the absence of senior management support (above the organizations
incurring the costs and benefits) the promise of benefits may not be
sufficient to overcome bureaucratic hurdles.

Problem Management Process

Possible Problem Management Improvement Initiatives

 Incident Referral - Incidents which are restored using a workaround will be referred to
Problem Management for offline consideration. Problem Management undertakes to
determine the root cause of the incident in an attempt to achieve a permanent resolution for
the incident so that it will not re-occur. The benefits of a separation of Problem analysis from
system restoration will result to an improvement to overall availability by achieving speedier
(though temporary) restoration of high impact services. It also provides the ability to attend to
the Problem using structured techniques and without interference or pressures resulting from
the pressure of restoring service. These techniques include specialized skills in RCA. In
organizations with many unresolved errors in the infrastructure, procedures may be required
to prioritize Problems in a manner which best ensures that the highest-impact of them get
early considered.
 Problem Management database - Selection, creation, population of Problem Management
database identifying Known problems and errors in the infrastructure
 Error Control - With the availability of a reliable data source on the existence of Known
Errors and Problems in the infrastructure, PM can begin to proactively investigate, analysis
and systematically control their adverse affects.
 Predictive PM - Predictive PM activities focus on identifying and resolving Problems and
Known Errors before Incidents occur. Problem prevention ranges from prevention of individual
problems, such as repeated difficulties with a particular feature of a system, through to
strategic decisions (eg., review of MTBF of infrastructure components and a strategic
replacement or mirroring strategy to reduce the chance and/or impact of a failure). The latter
may require major cost to implement, such as investment in a better network. Problem
prevention also includes information being given to Customers that obviates the need to ask
for assistance in the future. Analysis focuses on providing recommendations on
improvements for the Problem solvers. Problem analysis reports provide information for
improving service quality. The objective is to identify potentially 'unstable' components of an
IT infrastructure and investigate the reasons for the instabilities.
Configuration Management
Because there is a shared corporate obligation to monitor the assets
of an organization, most corporations will have developed an Asset
Management system and have an Asset database describing the
financial attributes of items. This asset, while highly useful for
tracking software licensing and machine movement does not
describe the inter-relationships of IT devices within the
infrastructure. These dependencies are important for developing
incident containment strategies and assessing the impact of releases
and changes. The Asset database must either be amended to include
additional fields (due to the nature of inter-relationships most
financial databases are ill-suited for this extension) or
a CMDB purchased or developed. Ideally, asset data can be migrated
from the Asset system into the CMDB, or, alternatively both systems
may continue to operate with bridges built between them - a logical
CMDB.

Many organization have purchased or built a CMDB and populated

it only to find that these task are easy compared to keeping the data
accurate and current. Doing this requires a concerted organization
commitment.

Discovery Tools can be used to search and discover infrastructure

components (ie. Configuration Items). Using these tools to perform
monthly updates of the CMDB is a low cost way to keep the CMDB
accurate. It may not, however, be easy to update other important
fields so that items pertaining to any individual Configuration Item
may be in varying states of currency.

An important consideration in establishing a CMDB is the level of

granularity for which Configuration Items should be described. The
fewer the number the easier the maintenance - but, the less useful the
database will be. A good rule of thumb is to get control of the
organization's major application areas (where the business impact of
service outage is the most severe). This data can then be used to
support Incident and Change Management processes. The
organization can then continue to enhance the CMDB's inclusiveness
until a point of diminishing returns occurs where further
infrastructure elements (coverage) and/or details on each item
(granularity) fail to be worth the additional effort in maintaining
them.

Configuration Management Process

Possible Configuration Management Improvement Initiatives

 Tool Selection - Unlike other process areas, tool selection will have a significant impact upon
the operation of Configuration Management. Obtaining a database to record configuration
items can be a significant expenditure. Additionally, the CMDB is central to a mature ITSM
implementation because it represents the heart of the information view of the organization.
Reloading into another system and adding field and functionality at a later time are significant
undertakings and will lead to service disruptions during the process. To a large extent it will
determine who and how configuration items are loaded, modified over their lifecycle and
retired. For these reasons, you need to get it right the first time. Consequently, the selection
of a Configuration tool should be decided upon early.
 This does not mean that all the tools features need be implemented immediately. Populating
the CMDB may be difficult, but it is a minor problem compared to keeping the information
current and accurate. The logic is to start small and build upon your experience.

 Load Asset Information - Most organizations will have some Asset information retained by
Finance or retained in individual spreadsheets by lines of business. The information from
these source should be consolidated into the selected CMDB. At a minimum, loading asset
information extents the use of this information to the Service Desk. For organizations lacking
this information it permits new capabilities in terms of licence rationalization and warranty
provisioning.
 Load Basic CMDB for Change Mgmt - Loading Asset information allows the organization to
deliver an existing service in new, more useful ways. Augment this information with additional
fields geared to the Change Management process (ie. the relationships between
a Configuration Item such as a server and other CI's such as applications). The initial
information should encompass major application attributes of vital importance to business
operations. A rule of thumb would be to find the 20% of items which would result in 80% of
the major outages. This provides basic experience with Configuration Management and
provides important information to the Change Management.
 Operate CMDB - At this point is important to have a period of stability for the operation of
Configuration and Change Management processes in order to assess the successes and
improvements needed in the processes.
 CMDB Expansion - Populate the CMDB with the configuration information for the remaining
assets not configured as part of the previous stage. This extends the benefits and completes
the information of how one item relates to another. Since the Service Desk is the usual point
of entry for changes in Configuration Items it should be charged with updating CIs resultant
from service request fulfillment.

Note the following caution.

"the jury's out on whether CMDBs can be made to work, at least in their
holistic, 'framework' sense. Most successful CMDB implementations to date
are targeted at a subset of possible functions and specific management
processes and applications."

Dennis Drogseth, Vice President, Enterprise Management Associates, quoted in The Fastest Payback
for Your ITIL Investment, Integrien, White Paper, October, 2005

 Validate CMDB using discovery tools - Use discovery tools to validate the accuracy of the
CMDB.

Discovery Tools might also be employed to update the CMDB. At a minimum all anomalies
identified should be investigated since they might indicate improperly implemented Changes
(which are reported to Change Management - an important metric for them).
Release Management
Many organizations will confuse Release and Change Management.
Both processes are concerned with introducing changes to the
"known and trusted environment" and often Release Boards are
established to manage changes associated with specific applications.

Change Management should be the final arbitrator of what gets

introduced into the infrastructure. Release Management is like a
furniture mover. Their prime task is to ensure a smooth migration of
furniture (ie. code and machinery) from one location to another (ie.,
test environments into the production environment). Their tools are
project management and migration tools (such as Microsoft Solution
Framework). Their jobs are frequently large, typically involving
multiple milestones and interactions with Change Management.

Release Management Process

Possible Release Management Improvement Initiatives

 Establish Release Policy - A Release policy document for an organization should be

produced to clarify the roles and responsibilities for Release Management. There may be one
document per organization, or an umbrella set of guidelines and specific details for each
supported system or IT service. The Release Policy may be part of the organization's overall
Change Management plan.

A Release Policy is revised or extended when an organization adopts a new technical

infrastructure. Piloting of new Release Management procedures should form part of a project
to implement a new infrastructure. For example, a new approach to releasing software may
need to be developed when an organization decides to adopt a new hardware or software
platform. This may be something as small as a new programming language or as major as a
completely new hardware platform with its own operating system, or a network management
system.

 Develop Definitive Software Library - The 'Definitive Software Library (DSL) is the term
used to describe a secure compound in which the definitive authorized versions of all
software CIs are stored and protected. In reality, this single storage area may consist of one
or more software libraries or file-storage areas. It contains the master copy of all controlled
software in the organization. The DSL should include definitive copies of purchased software
(along with licence documents or information), as well as software developed on site. Master
copies of controlled documentation for a system will also be stored in the DSL in electronic
form.

The exact configuration of the DSL that is required for Release Management should be
defined before development commences. The DSL forms part of the Release Policy or
Change and Configuration Management plan for the organization.

 Roll-out Planning - Procedures, templates and guidance should be planned to enable the
central Release Management staff to take products from application groups and projects, and
then to release the software and hardware efficiently and effectively.
 User Acceptance Procedures - Rigorous assurance that User is satisfied with the amount of
testing done before a release is made into the infrastructure. These assurances should be an
item in any SLA with the Customer. The possible levels of testing required in a User
Acceptance Test Plan are:
o New System Test: where the application to be tested is entirely new (is not an
enhancement or system upgrade).
 o Regression Test: where the amount of change in an existing application requires a
full system retest.
o Limited Test: where the amount of change in an existing application requires only
change specific testing.
 Defect List Mgmt - Institute procedures to ensure that defects are rigorously measured and
tracked during development phases and all defects not fixed at the time of the release are re-
constituted as Known Problems or Known Errors (root cause known but solution not yet
implemented). Wherever possible, additional information on workarounds should accompany
the list as a contingency action for the occurrence of an incident. The Defect List is made
known to the service desk (potential source of incidents) and responsibility is transferred to
Problem Management who have responsible for tracking Errors in the infrastructure. The
movement of defects should be explicitly mentioned in the Release Policy.

Service Level Management

The quality of a Service Level Management process will determine
how well the IT Service provider promotes its' client's interests. The
definitive document in this process is the SLA. It replaces anecdote
with fact, and in doing so, provides a more solid basis for discussion
and negotiation between service provider and service customer(s). It
positions the IT Department as a seller of services at defined costs,
therein promoting a more business-focused relationship.

Many organizations have developed SLAs which have failed to

deliver on their promise because the organization lacks the ability to
monitor and report consistently on the performance of the included
services. Quickly, the SLA documents get ignored - just another
piece of paper.

The approach advocated here recognizes the inherent difficulties

associated with negotiating the multi-varied relationships involved.
Much internal discussion within the IT division (ie. getting the house
in order) should precede negotiating service parameters and levels
with business units. This can be accomplished through the
publication of a Service Catalogue by the IT provider - listing
available services, service options and costs.

Unlike many other ITIL areas which can be targeted for a

generalized implementation in concert with the achievement of a
specific level of organizational maturity, there are aspects of Service
Level Management at all maturity levels. Few organizations will
achieve a Level 5 implementation - optimized service provision
through continuous adjustment based upon the provision of real-time
information of performance. Many, however, can put in place key
elements, reflective of the organization's level of maturity at any
point in time. These elements will establish and promote
improvements in the relationship between IT provider and customer
and establish key enablers to implement other service improvement
initiatives.

Service Level Management Process

Possible Service Level Management Improvement Initiatives

 Establish Basic Service CatalogueR - A basic catalogue develops the service hierarchy
based upon a logical framework (eg., existing org structure, Utility metaphor, COBIT
governance model). For each serviceN the following elements are described:
o a description of the service offering
o a description of to whom the service is offered and how it is accessed
o activities associated with the service (note: activities can themselves become
services depending upon the level of granularity desired - the acid test will always be
whether or not the offering has a distinct recognition by the Customer base)
o Offered variations in the service provided
o service participants involved in the delivery of the service (the service chain)
o contact information
 Develop & Pilot Prototype Operational Level Agreement - A good example is the NEW
EMPLOYEE SERVICE - that suite of services provided when a new employee joins the
company. This is an excellent example because...
o it involves a known and easily identifiable service chain (since it has been
institutionalized through the Service Request process)
o is usually initiated through the Service Desk (though it may be automated)
o requires coordination and "hand-off" to fulfill the service
o involves existing and well articulated participants

Based on the service chain associated with the NEW Employee service develop an
Operational Level Agreement between the participants and the Senior Leadership Team of
the Division offering the service.

 Develop SLA OLA - UC Architecture - Choose on basic SLA structure (architecture):

o service based - an SLA for a particular service written to pertain to the entire client
base
o customer based - an SLA targeting a specific line of business and covering all
services provided
o multi-level SLA - a mixture of the above two

The third type is often the most efficient. It can outline a broad spectrum of services offered to
the entire customer base for generalized services (including level variations - ie. silver, gold,
platinum). Then more specialized or targeted services such as specific application
ideosyncratic factors can be offered as addenda or side deals to affected clientsN.

 Pilot Memorandum of Understanding (MOU) - Develop Memorandum of Understanding for

service delivery. The MOU would itemize roles and responsibilities and describe services
which are delivered but would not contain financial or performance data. This can provide a
quick win by and can "institutionalize" the documentation of relationships while skirting more
difficult questions of performance and financing that may prove challenging for many
organizations.
 Describe participant obligations in the delivery of services - Develop Operational Level
Objectives for all participants in the service chain as described by their service chains
maintained in the service catalogue. This requires that many of the service parameters be
negotiated, particularly around "hand-offs" (eg. length of time - elapsed and latent involved in
the hand-off between participants).

The exercise may be coordinated by a Service Manager who, based upon the collected
OLOs, develops a composite Service Level Objectives. This measure is often contrasted with
 industry benchmarks. Discrepancies require explanation. The objective is to advance SLOs
which describe expected (and perhaps stretch) service performances.

All current contracts with third party providers should be reviewed for their internal
consistency with the OLOs and SLOs. Performance requirement deficiencies should be noted
and remedied at the earliest contract renewal opportunity.

 Establish OLAs & UCs - OLOs should set out serialized, specific back-to-back targets for
support groups that underpin the targets included in SLAs. For example, if the SLA includes
overall time to respond and fix targets for Incidents (per priority level), then the OLAs should
include targets for the each of the elements in the support chain (target for the Service Desk
to answer calls, escalate etc, targets for Network Support to start to investigate and to resolve
network related errors assigned to them). In addition, overall support hours should be
stipulated for all groups that support the required service Availability times in the SLA. If
special procedures exist for contacted staff (e.g. after hours telephone support) these must
also be documented.

It should be understood that the Incident resolution targets included in SLAs will typically not
mirror targets included in contracts or OLAs. SLA targets will include performance specs for
all process steps in the support cycle (e.g. detection time, Service Desk logging time,
escalation time, referral time between groups etc, Service Desk review and closure time - as
well as the actual time fixing the failure). Each OLO target will have achievement parameters
(eg., achieved 95% of the time over the course of a month). The sum of the achievement
parameters for all process stages are not multiplicative (ie., 95% times 95% times 95%). This
simply implies that over the course of an entire service chain it is not expected that a service
delay will exist at each stage. Rather, one might expect that a service deficiency may occur at
one of the stages 5% of the time - but we don't necessarily know at which stage the delay will
be experienced.

Before committing to SLAs, it is therefore important that existing contractual arrangements

are investigated and where necessary, upgraded. This is likely to incur additional costs, which
must either be absorbed by IT, or passed on to the Customer. In the latter case the Customer
must agree to this, or the more relaxed targets in existing contracts should be agreed for
inclusion in SLAs.

OLAs should be monitored against these targets and feedback given to the Managers of the
support groups. This highlights potential problem areas, which may need to be addressed
internally or by a further review of the SLA.

 Develop Service Level Objectives - Develop the Service Level Objectives based upon the
composite of OLO defined in the respective service chains. This exercise involves more than
just adding the response times associated with each stage in the service chain. Doing this
would likely provide response targets out of line with industry best practices. Each stage of
the process must be reviewed in the context of its' distribution (ie. earliest possible, mean and
medium time, latest possible) and then statistically analyzed against the entire service chain
to derive overall earliest, mean and latest response times. These times are then reviewed
against industry standards and major deviations explained.
 Evaluate Memoranda of Understanding (MOU) - Evaluate success of MOU as a devise to
establish written obligations of participants.
 Service Catalogue Upgrade - Extend functionality of Service Catalogue to include:
o Financial service information - Establish the models for accurate internal pricing.
Systematically gather both tangible and intangible costs incurred to deliver a service.
Provide pricing in advance, but resist the temptation to over-simplify the structure.
Indicate any charges for services performed outside of normal parameters or
durations.
o Service Level Objectives - cite performance objectives including assumptions
implicit in their usage
 o Service Chain Descriptions - Outline participants in the delivery of the service and
their obligations to each other (and the overall corporate entity which collectively
might represent those obligations.
o Performance Reporting - real-time reporting of actual performance against
Objective targetsN.
 Collect Service Level Requirements - Once the SLA structure has been agreed upon, a first
SLA can be drafted. It is advisable to involve business clients from the outset, but to start
discussions a first outline draft can be advanced to build upon. Be careful though not to go too
far and appear to be presenting the Client with mandated services - they should have some
input into the kind and quality of the service to be offered.

It can be difficult to draw out requirements, as the business may not know what they want -
especially if this is their initial introduction to the concept of negotiated service. They may
need help in understanding and defining their needs. Be aware that the requirements initially
expressed may not be those ultimately agreed - they are more likely to change where
charging is in place (since the Business Customer may have to make compromises based
upon the costs of delivering the service). Several iterations of negotiations may be required
before an affordable balance is struck between what is desired and what is achievable and
affordable.

Many organizations have found it valuable to produce a pro-forma that can be used as a
starting point for all SLAs. The pro-forma can often be developed alongside the pilot SLA.

 Develop Service Level Agreements - With the existence of a Service Catalogue

the SLA becomes an expression of the agreement between parties as to the levels of service
to be offered as described in the catalogue. This has the effect of focusing negotiation and
removing repetition from the documentation. The SLA becomes the expression of that
negotiation. The wording of SLAs should be clear and concise and leave no room for
ambiguity.

Using the draft agreement as a basis, negotiations must be held with the Customer(s), or
Customer representatives to finalize the contents of the SLA and the initial service level
targets, and with the service providers to ensure that these are achievable.

 Manage Customer Relationship - Whether charged for IT services or not, the customer's
impression of the quality and quantity of services is a barometer of success. IT must
recognize that the process of setting customer expectations is multi-dimensional. To begin
with, the customer expects to be more productive through the utilization of the services that IT
provides. This sets expectations by IT staff for reliability, availability, cost effectiveness, and
so on. The second set of customer expectations, and one that is frequently overlooked, is the
customer's responsibility in the process. The customer should be aware that they are
responsible for effectively utilizing the technology at their disposal by becoming more
proficient through education and experience. They also are obligated to report performance
issues appropriately as specified in SLAs and be a proactive advocate and participant within
the overall SLM process. They must understand and accept the agreed-to guidelines,
timeframes, and limitations of the offered services.

Where charges are being made for the services provided, customer demands can be
expected to be more reasonable than in environments where there is no charge mechanism
in place. Where direct charges are not made, the support of senior business managers must
be enlisted to ensure that excessive or unrealistic demands are not placed upon the IT
provider by any individual customer group.

 SLM Basic Reporting - Nothing should be included in an SLA unless it can be effectively
monitored and measured at an agreed point. Inclusion of items that cannot be effectively
monitored almost always result in disputes and eventual loss of faith in the SLM process.
 Existing monitoring capabilities should be reviewed and upgraded as necessary. Ideally this
should be done ahead of, or in parallel with, the drafting of SLAs, so that monitoring can be in
place to assist with the validation of proposed targets. It is essential that monitoring matches
the Customer's true perception of the service - in practice achieving this is often elusive.

Reporting can be broadly divided into two categories: real-time and periodic. Reviewing and
improving services is the validation of Service Level ManagementN. Because it implies
performance (and, hence, internal compensation and rewards) performance reporting is
sensitive and may imply major cultural and organizational shifts. It should, therefore, be
approached cautiously and in stages corresponding to increasing
organizational maturity capabilities. This usually implies a movement from ad hoc, to regular,
to automated to real-time reportingN.

Real-time reporting should be the ultimate goal for service-level reporting. On a real-time
basis, clients need to know the status (i.e., health) of the service. A simple, positive
confirmation that the service is believed to be functioning normally is often sufficient. Some
companies with SLM tools denote this status check with an icon similar to a stop light, with
red, amber and green lights, with the obvious meanings.

 Review Service Level Management Process - Review SLM process in conjunction with
other ITIL processes for internal consistency and general harmony. The results of the review
should include specific recommendations for improvement. A basic objective of the review is
assess the organization's readiness to proceed towards Level 4 maturity processes.
 Quantitative SLM - Few organization will seek (or even need) to establish this kind of
sophisticated reporting. In most organizations, Key Goal and Performance Indicators are used
to measure the overall performance of the organization - the provisioning of IT
services contribute to but are not always considered central to those the realization of
business strategic goals and objectives. However, for organizations whose business is IT
provision KGI and KPI may be critical. Such organizations must have IT processes greater
levels of maturity since their survival is determined by them. To these organizations, the
provision of IT services is the primary revenue generating vehicle (and not a supporting
function). These practices reflect Level 4 and or 5 maturities - the performance of processes
is controlled using statistical and other quantitative techniques, and is quantitatively
predictable. At maturity level 3, processes are only qualitatively predictable.

The expected process performance can be used in establishing the project's quality and
process-performance objectives and can be used as a baseline against which actual project
performance can be compared. This information is used to quantitatively manage the project.
Each quantitatively managed project, in turn, provides actual performance results that
become a part of the baseline data for the organizational process assets. The associated
process performance models are used to represent past and current process performance
and to predict future results of the process. For example, the latent defects in the delivered
product can be predicted using Six Sigma techniques of defects identified during service
verification activities.

When the organization has measures, data, and analytic techniques for critical services and
service characteristics, it is able to do the following:

o Determine whether services are repeatedly achieving their SLOs and have stable
trends (i.e., are predictable)
o Identify bottlenecks where the performance is within natural bounds that are
consistent across service chain boundaries
o Establish criteria for identifying whether a service or service activity should be
statistically managed, and determine pertinent measures and analytic techniques to
be used in such management
o Identify service activities that show unusual (e.g., sporadic or unpredictable) behavior
 o Identify any activities and processes that can be improved in the organization's set of
standard processes
o Identify the implementation of a defined process which performs best and
recommend other arenas for its' adoption in the organization (ie. building on success)

A key to proliferating organizational successes is the establishment and maintenance of

baselines and models which characterize the expected process performance of the
organization's set of standard processes.

To undertake quantitative SLM requires an enhanced ability to measure Availability in real-

time, so there is a pre-requisite on Availability Management's ability to achieve Level 4
maturity.

Maturity level 5 focuses on continually improving services through both incremental and
innovative technological improvements. Quantitative service-improvement objectives for the
organization are established, continually revised to reflect changing business objectives, and
used as criteria in managing service improvement projects (SIPs). The effects of deployed
service improvements are measured and evaluated against the quantitative SLOs. Both
defined processes and the organization's set of standard processes are targets of
measurable improvement activities.

Process improvements to address common causes of process variation and measurably

improve the organization's processes are identified, evaluated, and deployed. Improvements
are selected based on a quantitative understanding of their expected contribution to achieving
the organization's process-improvement objectives versus the cost and impact to the
organization. The performance of the organization's processes and services are continually
improved.

Optimizing processes that are agile and innovative depends on the participation of an
empowered workforce aligned with the business values and objectives of the organization.
The organization's ability to rapidly respond to changes and opportunities is enhanced by
finding ways to accelerate and share learning. Improvement of the processes is inherently
part of everybody's role, resulting in a cycle of continual improvement. Ref

Availability Management
All organizations, regardless of their maturity level, must undertake
some availability management. Organizations who ignore
Availability Management experience chronic outages with severe
and persistent business impacts. Like the other service delivery
elementsN, Availability Management must be acknowledged within
the organization even if actions are haphazard, uncoordinated and
unfocused. ITIL's contribution is the recognition of these elements as
identified tasks common across technology platforms.

Creating identified responsibilities for these functions (whether by

creating identifiable organizational units or through cooperative
venues in which individuals resident in subject areas which
commiserate on common processes and documents such an
Availability Plan) may benefit organizations of a size large enough
and mature enough to entertain this kind of functional specialization.
 Availability Management Process

Possible Availability Management Improvement Initiatives

 Formalize Application Sizing undertakings - A system development project will normally

include an assessment of the hardware, network bandwidth and support requirements of new
applications. Formalizing the requirement as IT policy will ensure that the requirements of
new applications are better acknowledged over their forseeable lifespan.
 Consolidate Availability Requirements - Most organizations will have some process for
assessing minimum application availability requirements and the rationales supporting system
redundancies, backup procedures, clustering and mirroring technologies. Collecting and
storing this information in a central place facilitates the regular review of the requirements in a
consolidated context. This review should consider new technological initiatives, leveraging
economies of scale amongst applications as they surface during review.
 Create the Availability Plan - This plan represents the culmination of much of the planning
activities associated with Availability Management. It should form an integral part of the
annual operational review, and, will relate availability needs to available revenue and
expenditure forecasts. It contains summaries and rationales for the availability strategy,
feasibility assessments and design activities. The plan should encompass:
o Summary of IT funding and investment policies and how they affect availability
requirements
o Detailed recommendations for optimizing availability and reducing downtime costs
o Identification of key areas for improvement and specific actions and services to
consider
o Benefits and costs for each recommendation, so implementation decisions can be
confidently supported
o Listing of all assumptions made and infrastructure changes implemented to increase
availability
o availability performance over the previous year in terms of variances from availability
targets set in SLAs
 Establish AMDB - The source of availability information collected in the preceding tasks can
be retained in a data repository supporting Availability data analysis. This might form a
physical or logical division of a CMDB. In addition, there can be vast amounts of availability
data extracted from monitoring devices. This data should be maintained in a source easily
accessible to Availability Management. Availability Management could also design key
summary statistics and maintain this in lieu of the raw data.
 Define CI Targets for Availability, Reliability and Maintainability - Availability
Management can maintain records of the availability, reliability and
maintainability/serviceability of Configuration Items (CIs). The best place to do this is in a
CMDB. Comparing the targets for component availability with actual failure rates would
provide Availability Management with valuable information for Availability improvement
initiatives. It would also allow them to compare the MTBF rates amongst competing devices
thereby permitting the gradual infusion of more reliable devices into the infrastructure.

These infrastructure components can be analyzed for evolving trends which will provide
information and insights into potential availability issues and suggest opportunities to
strengthen overall availability.

 Initiate Systems Management - System management involves toolsets, policies and

procedures to keep mission-critical systems up and running. It includes the monitoring,
diagnostic and automated error recovery to enable fast detection and resolution of potential
and actual IT failure. It makes performance adjustments based on dynamic circumstances by
…
 o Monitoring the amount of disk space required providing early warning of potential
space issues
o Checking that backups have been performed and that they are viable input into the
recovery procedures
o Performing analysis on index usage; tuning indexes to maximize index usage;
creating, dropping and altering indexes as required for performance improvement
o Monitoring internal database space for fragmentation that can lead to excessive page
chaining resulting in poor performance; schedules database reorganizations to
correct excessive fragmentation
o Recording resource shortages in the area of CPU and memory making
recommendations on need-to-acquire resources
o Constantly checking error log file for warnings or errors reported by the database
management system and taking appropriate measures to resolve root cause
o Determining timing of updating internal database statistics to improve optimizer
performance
o Verifying structure integrity of database schema and takes corrective actions as
required
o Providing reports on performance and resource trends for proactive environment
management.
 Automate Availability Toolsets - The provision of Systems Management tools positively
influences the levels of availability that can be delivered. Implementation and exploitation
should have strong focus on achieving high Availability and enhanced recovery objectives. In
the context of recovery, such tools should be exploited to provide automated failure detection,
assist failure diagnosis and support automated error recovery.

Collection techniques fall into one of two primary categories:

o Event-driven Measurement - the times at which certain event happen are recorded
and then desired statistics are compared by analyzing the data
o Sampling-based Measurement - taking a scheduled, periodic look at certain counters
or information access points

Capacity Management
Capacity Management, like Availability Management, will be done
within the IT organization. ITIL main contribution to service
management in this regard is the recognition of the elements as
identified tasks common to many technology areas. Grouping these
functions together, whether by creating identifiable organizational
units or through cooperative venues in which individuals resident in
subject areas commiserate on common processes, documents (ie., a
Capacity Plan) will benefit the organization.

The timing and nature of Capacity Management processes is

different from those of Availability management by virtue of a
heavy reliance upon common technologies and toolsets. Because
there are economies to be achieved in purchasing bandwidth and
software licensing there is a great need to consider overall capacity
requirements for the IT Department. On the other hand, Availability
requirements will be specific to individual application areas. Thus
Capacity Management requires much greater activity coordination
 than availability and this need is frequently reflected in units charged
with consideration of overall capacity issues.

Capacity Management Process

Possible Capacity Management Improvement Initiatives

 Establish Capacity Requirements - develop the initial baseline of the organization's

capacity needs based upon current levels of service (documented or implicitly recognized). To
do this the infrastructure resources encompassed by those needs must be recognized so that
their utilizations or performance can be measured. This determination is made based on
current knowledge about which resources are most critical to meeting future capacity needs.
In many shops these resources will revolve around network bandwidth, the number and
speed of server processors, or the number, size, or density of disk volumes comprising
centralized secondary storage. The resources identified should be measured as to their
utilizations or performance. These measurements provide two key pieces of information:
1. a utilization baseline from which future trends can be predicted and analyzed
2. the quantity of excess capacity available for each component [Note].

Current utilizations should then be compared to maximum capacities. The intent here is to
determine how much excess capacity is available for selected components. The utilization or
performance of each component measured should be compared to the maximum usable
capacity. N

Then collect meaningful workload forecasts from representative users. User workload
forecast worksheets should be customized and used as much as possible to meet the unique
requirements of your particular environment. These forecasts are then re-stated as resource
requirements. Measurement tools or a senior analyst's expertise can help in changing
projected transaction loads, for example, into increased capacity of server processors. The
worksheets also allow you to project the estimated time frames during which workload
increases will occur. [Note]

 Create Capacity Plan - The Capacity plan is the formal description of the organization's
Capacity requirements. It needs to show what capacity is needed in the future and at what
cost and should permit prediction of what hardware upgrades or additional equipment would
be needed to meet future service level objectives. It will include information on sizing of any
new systems proposed and needs to reflect cost constraints and availability or reliability
requirements.

The capacity plan should document the current levels of resource utilization and service
performance, take into account business strategy and plan in its forecast of future
requirements for resource in support of IT services delivered or new services planned. Any
recommendations made in the plan should include quantified details of necessary resource,
any relevant impact, associated cost and benefits.

The production and update of a capacity plan needs to occur at pre-defined intervals,
preferably yearly in line with the business or budget cycle. A quarterly re-issue of the updated
plan may be necessary to take into account changes in business plans, to report on the
accuracy of forecasts, and to make or refine recommendations.

 Establish CDB - The CDB holds information about workload, and performance, for example,
of how heavily a customer relationship management database is being used, and data
allowing trends for future forecasted growth of storage requirements. It provides information
for producing reports, the capacity plan, monitoring performance, managing resources, and
demand.
 Inputs to consider for the CDB are:

o Financial data – costs

o Hardware data
o Development data
o Service data - problem/change
o Contingency data - hardware, and so on
o Technical data - availability data, and so on
o Business data - future direction and strategy

Other detail input for the CDB includes:

o Capacity plan - current in place; DTP software

o Model generators - parameters for sizing and modeling
o Sizing software results
o Modeling software results
o Resource utilization monitors - threshold exceptions
o Service level management - threshold exceptions
o Other performance/surveillance software
o Workload performance monitors

Capacity management issues can dramatically affect the business if they cause unplanned
downtime of a vital business function. This requires considerations for capacity and
availability management to be intertwined and solution designs consistent. Service continuity
management is weighing risk versus cost for scenarios outside the normal availability design.
Its contingency planning relies on capacity forecast and recommendations to move forward in
documenting a chosen contingency measure. It follows, that the clear and distinct
requirements of each process have correlated capacity and performance data identified and
properly recorded in the CDB. It is important capacity detail data in the CDB relates to OLA
and associated OLA and/or SLA information is tracked in the configuration management
database (CMDB). Because there is an implied dependency of availability management
information on the proper integration of performance and capacity measurement data,
capacity and availability staff often shares common monitoring tools and management
solutions.

 Establish Monitoring, Analysis & Tuning - Monitoring should be specific to particular

operating systems, hardware configurations, applications, etc. Some of the monitors should
be free utilities within a hardware or software product, while others form part of a larger
systems management tool set and need to be purchased independently. It is important that
the monitors can collect all the data required by the Capacity Management process, for a
specific component or service.

In considering the data that needs to be included, a distinction needs to be drawn between
the data collected to monitor Capacity (e.g. throughput), and the data to monitor performance
(e.g. response times). Data of both types is required by the Service and Resource Capacity
Management sub-processes. The data should be gathered at total resource utilization level
and at a more detailed profile for the load that each service places on each particular
resource. This needs to be carried out across the whole Infrastructure, host or server, the
network, local server and client or workstation.

Part of the monitoring activity should be of thresholds and baselines or profiles of the normal
operating levels. If these are exceeded, alarms should be raised and exception reports
produced. These thresholds and baselines should have been determined from the analysis of
previously recorded data, and can be set on:

o Individual components, for example monitor that the utilization of a CPU does not
exceed 80% for a sustained period of one hour.
o Specific services, for example monitor that the response time in an on-line service
does not exceed 2 seconds and that the transaction rate does not exceed 10,000
transactions per hour.
o All thresholds should be set below the level at which the resource is over-utilized, or
below the targets in the SLAs. When the threshold is reached, there is still an
opportunity to take corrective action before the SLA has been breached, or the
resource has become over-utilized and there has been a period of poor performance.
o Often it is more difficult to get the data on the current business volumes as required
by the Business Capacity Management sub-process. These statistics may need to be
derived from the data available to the Service and Resource Capacity Management
sub-processes.

The data collected from the monitoring should be analyzed to identify trends from which the
normal utilization and service level, or baseline, can be established. By regular monitoring
and comparison with this baseline, exception conditions in the utilization of individual
components or service thresholds can be defined, and breaches or near misses in the SLAs
can be reported upon. Also, the data can be used to predict future resource usage, or to
monitor actual business growth against predicted growth.

The use of each resource and service needs to be considered over the short, medium and
long term, and the minimum, maximum and average utilization for these periods recorded.
Typically, the short term pattern covers the utilization over a 24-hour period, while the medium
term may cover a one-week to four-week period, and the long term, a year-long period. Over
time the trend in the use of the resource by the various IT Services will become apparent.

It is important to understand the utilization in each of these periods, so that Changes in the
use of any service can be related to predicted Changes in the level of utilization of individual
resources. The ability to identify the specific hardware or software resource - on which a
particular IT Service depends -is improved greatly by an accurate, up-to-date and
comprehensive CMDB.

When the utilization of a particular resource is considered, it is important to understand both

the total level of utilization and the utilization by individual services of the resource.

The analysis of the monitored data may identify areas of the configuration that could be tuned
to better utilize the system resource or improve the performance of the particular service.

The implementation of any Changes arising from these activities must be undertaken through
a formal Change Management process. The impact of system tuning changes can have major
implications on the Customers of the service. The impact and risk associated with these types
of changes are likely to be greater than that of other different type of changes. Implementing
the tuning changes under formal Change Management procedures results in Less adverse
impact on the Users of the service. Increased User productivity, increased productivity of IT
personnel, a reduction in the number of Changes that need to be backed-out (including the
ability to do so more easily) and greater management and control of business critical
application services.

It is important that further monitoring takes place, so that the effect of the Change can be
assessed. It may be necessary to make further Changes or to regress some of the original
Changes.
 Implement Demand Management - In the short-term Demand Management should be
aware of the business priority of each of the services, know the resource requirements of
each service and then be able to identify which services can be run while there is a limited
amount of memory available. In the longer term, Demand Management may be required
when it is difficult to cost-justify an expensive upgrade.

Demand Management can be carried out as part of any one of the sub-processes of Capacity
Management. However, Demand Management must be carried out sensitively, without
causing damage to the relationship with the business Customers or to the reputation of the IT
organization. It is necessary to understand fully the requirements of the business and the
demands on the IT Services, and to ensure that the Customers are kept informed of all the
actions being taken.

 Implement Capacity Modeling - Modeling is associated with level 4 or higher maturity

organizations.

Baseline Modeling is the first stage in modeling is to create a baseline model that reflects
accurately the performance that is being achieved. When this baseline model has been
created, predictive modeling can be done (i.e. ask the 'what if?’ questions that reflect planned
Changes to the hardware and/or the volume/variety of workloads). If the baseline model is
accurate, then the accuracy of the result of the predicted Changes can be trusted.

Analytical Modeling involves representations of the behavior of computer systems using

mathematical techniques, (e.g. multi-class network queuing theory). Typically, a model is
built, using a PC-based software package, by specifying within the package the components
and structure of the configuration that needs to be modeled, and the utilization of the
components, e.g. CPU, memory and disks, by the various workloads or applications. When
the model is run, the queuing theory is used to calculate the response times in the computer
system. If the response times predicted by the model are sufficiently close to the response
times recorded in real life, the model can be regarded as an accurate representation of the
computer system.

Simulation Modeling is even more sophisticated and involves the modeling of discrete events,
e.g. transaction arrival rates, against & given hardware configuration. This type of modeling
can be very accurate in sizing new applications or predicting the effects of Changes on
existing applications, but can also be very time-consuming and therefore costly.

When simulating transaction arrival rates, have a number of staff enter a series of
transactions from prepared scripts, or use software to input the same scripted transactions
with a random arrival rate. Either of these approaches takes time and effort to prepare and
run. However, it can be cost-justified for organizations with very large systems where the cost
(millions of dollars) and the associated performance implications assume great importance.

Effective Service and Resource Capacity Management together with modeling techniques
enable Capacity Management to answer the 'What if' questions. 'What if the throughput of
Service A doubles? "What if Service B is moved from the current processor onto a new
processor - how will the response times in the two services be altered?'
Financial Management
As an IT management tool, budgeting is ignored or under-used.
Budgeting provides a starting point for cost cutting, as it forces one
to think about how to provide the same service with less money. In
an IT environment budgeting is notoriously difficult, because while
logic demands an IT budget follow the business budget, reality
mandates a simultaneous budgeting process. An IT budget should be
made after the goals for the business are set, after the budgets for all
other supporting departments are set, and after it is known what the
actual business needs are.

IT budgeting is made more difficult when the Capacity Management

process is incomplete or does not function properly. IT groups
typically are organized in highly politicized functional silos, and
planning for the needed capacity often is pure guesswork or - even
worse - a result of carefully crafted political compromises.

Accounting practices in many IT organizations can also be chaotic

and misunderstood. Changes in the IT department and lack of
control over these changes provide headaches to most IT accounting
people as most uncontrolled change creates chaos. Reporting, in
conjunction with Service Level Management, is non-existent in most
companies and "fire fighting" considerations determine where the
dollars go.

Internal billing practices often are considered "funny money" and a

burdensome bureaucratic control. As a result, the potential benefit of
billing and thus influencing end-users' behavior often is ignored or
unknown. Even in companies where sophisticated service level
monitoring is being practiced, it is normal for the end-user to face a
lack of transparency around charging practices. The end-user seldom
has a clue what the service is actually costing or what his or her
department is being charged for the use of any IT service.

Financial Management Process

Possible Financial Management Improvement Initiatives

 Service costing definition - It is desirable to determine the cost of services to customers,

taking into account the external specification of design of the service (the design that comes
from the process of Service Planning that specifies the "what" of the service). While the IT
Division may not actually charge business the full cost of IT Services (some may be consider
"corporate" services, a form of "notational" budgeting permits the IT Division to identify and
track service costs. The IT Division should also consider the costs projected for the capacity
and availability requirements.
 Analyze the revenues projected according to the charging and pricing policies to the
customer - For each service, it is necessary to review the projected revenues for each level
of service described in the external specification of the design (Service Planning). Evaluate
the feasibility of these projections compared against the market and the charges that the
customer is willing to accept. Then analyze the revenues against the delivery of the service
through the time that the service will be available to the customer.
 Determine Service Costs - Service level management and the resulting IT services that it
enables come at a substantial cost to the enterprise measured by both monetary and human
resource requirements. In order to make an intelligent decision relative to service
provisioning, IT must accurately identify all costs of the services being evaluated, perform a
ROI analysis and engage the customer to fund the service. This is true for existing services
 being provided and new services being considered. In order to identify costs, all components
of the IT infrastructure that combine to enable a service need to be considered. In all areas,
these costs can be significant. It is necessary that a comprehensive ROI analysis be
performed on each activity to determine if the expected return to the organization, both
directly financial (cost vs. benefit) and indirect effort (cost vs. increased or maintained
customer productivity levels) is worthwhile. In cases where the ROI process indicates that the
service does add enough value to the enterprise to be worthwhile, the service will not be
implemented. In instances where the ROI process has established that the service is of value
to the organization, the service will be implemented. In some cases, the service requested
may be simple in nature. It does not significantly impact the areas of service provisioning that
the cost analysis is designed to evaluate. The service level manager makes a "judgment call"
in these cases and may elect to establish the new service without formally executing the
financial analysis process.
 Provide Customer Detail - Calculate the true costs to the customer by use of the service.
Determine the usage of each specific service in order to generate the corresponding charges.
 Establish charging policies - Determine margins affecting the rates and the prices relative
to recovery of the costs. Determine whether charging will be informational, notional, or actual
to the customer. Four factors govern the requirements of charging policies:
o Complete recovery of all cost (direct, indirect);
o Influence the service usage by the customer;
o Recovery of costs according to the usage of the services;
o The service is aligned to the market in terms of availability, capacity and cost;

Determine how the costs of service delivery to customers will be allocated and accounted.
The cost structures must consider any economies of scale that are related to the delivery of
several combined services or increases in volume.

 Financial Activity tracking - Track and analyze for each service by customer:
o Asset usage including the Return on Assets (ROA);
o Purchasing actuals and trends;
o Changes to inventory.
 Benchmark TCO - Determine like-industry averages and cost breakdowns as a benchmark
against which the organization can be compared.
 Determine Services TCOs - Given a specific service (for all the customers and based on the
standard costs) determine the total cost of assets which the customer uses throughout the life
of the service.
 Market Service Catalogue - To communicate and promote the effective use of services in
relation to their costs and to educate customers as to the value of the services as based on
their cost to deliver and the economies of scale related to maintenance of the IT system for
Service provisioning. Gain the trust and commitment of the customer. Gain consensus on
policies that balance load and capacities, for example:
o Increased prices for older technology and" discounts" or advantages in terms of
charges for newer and more supportable technologies;
o Increased charge for services during peak operations and discounts during times of
lower demand for the service.
 Introduce Cost reporting in Catalogue - Report actual costs either directly into the calendar
or through a monthly feed. Variances represent FM's ability to properly flow and manage
costs.

In reality, linking any IT initiative into the total existing IT environment

involves a cost. the amount of that cost depends not only on the size and
complexity of the initiative being undertaken, but also on the state of the
current IT environment.
 Mark D Lutcheon, managing IT as a business, John Wiley & Sons, 2004,
ISBN: 0-471-47104-6, p. 137

Service Continuity Management

Almost all large organizations have Disaster Recovery Plans for
their major, business-critical applications. There is an abundance of
evidence about the pitfalls of organizations which have tried to save
money by cutting corners on these plans. Efforts to maintain and
update the plans, however, often suffer due to the absence of a
highly visible and permanent responsibility for their maintenance.
Consequently, efforts in this area are often sporadic and in
consistent.

Theoretically, Service Continuity Management is an adjunct of

Availability Management. The two areas share a common goal.
However, because this area represents such a severe threat to
business interests, most business units will wish to maintain tight
control over plans and recovery strategies.

Because of this pre-occupation Service Continuity is frequently not

considered during ITSM improvement projects. It is considered
tangential to or outside the sphere if the iT Division. IT service
managements efforts devoted to Availability Management are seen
as the most appropriate vehicle for the provider to exercise some
influence and direction over continuity plans.

Service Continuity Management Process

Possible Service Continuity Management Improvement Initiatives

 Business Risk Assessment - Before planning to protect the environment and recover from
potential outages, the organization must ensure the appropriate disaster avoidance measures
are in place. A review of the current environment is conducted to ensure processes and
practices are in place to deter or prevent a disaster from happening.

In addition to disaster avoidance, a risk assessment or analysis is performed to identify and

define potential risks to the organization. Based upon the risks, preventative measures are
implemented to mitigate the affect of the risk or threat.

 Complete Business Impact Analyses - A key driver in determining ITSCM requirements is

how much the organization stands to lose as a result of a disaster or other service disruption
and the speed of escalation of these losses. The purpose of a Business Impact Analysis (BIA)
is to assess this through identifying:
o critical business processes
o the potential damage or loss that may be caused to the organization as a result of a
disruption to critical business processes.
 Develop Recovery Strategies - Systems Recovery Procedures for Survival Critical
applications should be maintained by Services Continuity Management. These procedures
should be readily available to Availability Management in the event of the need for quick
service restoration. In addition, Availability Management may maintain sets of generic
restoration procedures for such things are file servers, back-up servers, routers, etc which
 can be referenced to ensure speedy restoration of these devices. Availability Management
should undertake to have recovery procedures created for all Survival and Mission Critical
applications and for services for which recovery is sufficiently complex that documenting and
implementing standard processes for recovery will provide greater assurance of success and
less chance of creating further incidents. These procedures should be controlled through
Change Management methods including testing them in a pre-production environment.
 Develop Disaster Recovery Scenarios - A Disaster Recovery Strategy is developed for
each major application taking into account the estimates of risks and the type of recoveries
which should be implemented.

These strategies are placed under Change Management and will form part of SLAs
negotiated with lines of business.

 Maintain Disaster Recovery Processes - Disaster Recovery should be identified as a

service and recorded in the service catalogue so the costs and benefits of maintaining it (with
annual testing) are accounted for.

Enabling IT Service Improvement

In the previous section service improvement initiative were presented for consideration. It was
usggestion that these proposals be assessed against some selection previously proposed. However,
as discussed in the section on Improvement Issues the organization's ability to successfully
implement them will be affected by many existing management and operational factors. This section
proposes a number of key areas which should be addressed in order to facilitate the service
improvement initiatives. Properly addressed and implemented these areas will result in a more
proactive and "mature" organization.

What's in this Section

Standardiza Justificat Governa Polici Awaren Fault Risk CMD Project Service Do Measurem
tion ion nce es ess Approa Mg B Capabil Catalog cs ent
ch mt ity ue

Focus on Standardization
Objective
Balance local requirements with enterprise standards in order to reduce
the total costs associated with developing and maintaining a highly
reliable infrastructure.

Put simply, IT must support business goals and objectives. It does this by either improving operational
effectiveness or by containing costs (efficiency). Therefore, a simple answer of where to start
implementing ITIL is in those areas where the highest Return on Investment can be realized. But, of
course, it is not that neat.

To begin with, few organizations are starting from scratch. Most organizations have some IT
infrastructure in place and the sophistication of the operations is probably determined by the strength
of the personnel and technology in respective departments within the IT and business units. The fact
that different departments will have different capabilities will be reflected in inconsistent service
provision particularly in such areas as capacity and availability management - ie. service delivery
components. Managed workforce practices wherein the communications channels are open may help
mitigate disparities. Overall, the implementation of various ITIL best practice areas should tend to
mirror the organizational maturity required for their implementation.

"The maturity of the Service Management processes is heavily dependent

upon the stage of growth of the IT organization as a whole. It is difficult, if
not impossible, to develop the maturity of the Service Management
processes beyond the maturity and capability of the overall IT organization"

Planning to Implement Service Management, Appendix J

Implementing all but the most basic ITIL practices (defined as those practices which address a
"reactive" organization (ie., firefighting). This would include Incident Management and reactive
versions of Change, Release and Problem (eg. Major Situation Root Cause Analysis).

To get beyond these kinds of approaches requires the organization to address its' overall
management and organizational capabilities and Capability Maturity Modeling provides valuable
insights into how to increase this capacity to implement best practices. CMMI suggests the
establishment of maturity goals through target staging of capabilities.

"Target staging is a sequence of target profiles that describe the path of

process improvement to be followed by the organization. When building
target profiles, the organization should pay attention to the dependencies
between generic practices and process areas. When a generic practice is
dependent upon a certain process area, either to carry out the generic
practice or to provide a prerequisite product, the generic practice will be
ineffective when the process area is not implemented. When a target profile
is chosen with these dependencies accounted for, the target profile is
admissible."

CMMI - Version 1.1, Continuous Representation, p.34

Target a Standardized (Defined) Level of Maturity

The vast majority of organizations are struggling to achieve level 3 (Defined) maturity. This level is
generally agreed-upon as being 90% congruent with ISO9001 certificationR (see Reference Models
section). So, achieving those procedures, processes and enabling practices associated with level 2
and 3 are key starting points for an organization.

This requires a pre-occupation with standards. The following chart is taken from an assessment of
organizational "business intelligence" maturity but the discussion is more widely relevantN.
In the early stages, business units purchase their own toolsets and develop many of their own
processes and procedures to employ them. For business intelligence applications these are often
spreadsheets or personnel databases used to access information at relatively low costs. Once these
business units become reliant on the tools (because of sunk costs on licenses, training, embedded
knowledge and expertise), they are highly resistant to any centrally-directed attempts to standardize,
particularly when the selected tool is not the one they are using (or even a different version). As the
approach becomes more widely used in different business units, the enterprise needs to standardize
the tools and approaches to control its' spiralling costs of owning and maintaining the tools and
processes. As the graph illustrates, however, the costs of redundancy and uncoordinated actions are
not immediately felt - it is "only in the mature stages that standardization delivers sufficient benefits to
offset the loss of local control".

"This occurs when there is a robust BIN infrastructure in place and most of

the information that users need exists in the data warehousing environment,
so the hard, time-consuming work of preparing data for query and analysis is
completed. "

Enterprise Business Intelligence, Strategies and Technologies for Deploying BI on an Enterprise

Scale, Wayne Eckerson and Cindi Howson, August, 2005 available at Bitpipe

Once an organization balances local requirements with enterprise standards, it reaps a multiplicity of
benefits that enhance individual performance and boost corporate productivityD.

This discussion is presented as a backdrop against the establishment of

ITIL initiation activities. The following items should be implemented
early because they provide key elements which facilitate other service
improvement efforts. They establish pre-requisites for bridging service
gaps between existing and desired processes, and, they address the key
need to institutionalize gains so that, not only can the organization begin
the process, but it will establish procedures and support mechanisms to
prevent reversals.
Support Case for Service Improvement Project (SIP)
Objective
To ensure ongoing defence of the SIP by demonstrating return on
investment.

Not so long ago, IT Divisions were exempt from demonstrating Return on Investment to the company.
Today, IT plays in the same arena as other enterprise functions - sales, service, finance, marketing:
all are expected to project their returns, then deliver with control and predictability. The CIO’s spot at
the board room table comes with this level of business results expectation.

ITIL has inherited much of this mystique. It has developed such a following that companies will enter
into service management improvement programs based on ITIL best practices without describing the
benefits to be expected. The organization gets caught up in the initial euphoria, but most often will pay
when the first wave of criticisms threatens the improvement program. The difficulty in expressing
these benefits in financial terms has been commented on by Rich Schiesser in IT Systems
management.

"Dollar costs and dollar savings are common denominators used by business
professionals in making technology decisions. Yet they are the measures
least offered by IT professionals in presenting the benefits of a process
improvement. "

Rich Schiesser, IT Systems Management, Enterprise Computing Institute, 2002, ISBN: 0-13-087678-
X, p.47.

The creation of the good business case is a critical element/stage in good project management and a
service improvement initiative should be undertaken using Project Management methodology. Much
of the justification should be included in a business case and ultimately find its' way into the Project
Charter. However, the information is often so fundamental in its' description of the state of the
infrastructure as to transcend project initiatives. This information not only serves to justify service
initiatives but to describe how associated processes will be implemented. The information will be re-
used many times and should be periodically revisited to ensure ongoing accuracy. The following are
examples of key information which the organization should use to justify service improvement
initiatives:

Information Use

Determine Vital Business Functions (VBFs)
 Mapping IS services to business value chain
functions allows IS to clearly identify vital
business functions and their relationships to
Information Services. By mapping these
dependencies, IS can more effectively prioritize
activities that support vital business functions
(eg. incident recovery severity designations,
change prioritizations, etc), and focus on adding
value to what is most important to the business.
IS can also improve its role in the business value
chain by being directly involved in the
development of new solutions that support vital
business functions. In this way, IS can move
beyond simply responding to the needs of the
business, and delivering IS services per agreed
service levels. IS can move to a higher value-add
 function of jointly planning competitive business
initiatives that rely on IS service and support.R

Business costs from service outages for major
applications
 Prioritize applications for incident treatment
 Assess which applications require Business
Continuity and Disaster Recovery Plans
 Determine application availability/recovery
strategies
 Assign priorities for change and release
management treatment

Number of incidents resulting from poor changes
 Determine importance of Change Management
as a "pain point" to the organization
 in conjunction with business costs, ensure
appropriate risk mitigation strategies associated
with application changes

Cost per user supported by the organization  Determine baseline reference to like-industry
averages
 Establish baseline for trending

Determine Customer satisfaction with IT services  determine extent of business support

provided  Establish "pain points"
 Determine baseline satisfaction level for trending

These base characteristics of the IT organization provide the initial justification and outline for a
service improvement initiative. A developed "Business Case", a key deliverable of the Concept Phase
of Project Management, will cite service deficiencies which need attention. These will be expanded
upon in the Project Charter, the major deliverable of the Project Definition phase.

The Project Charter establishes the primary repository for updating this kind of information and the re-
usability of this document for further initiatives will further the maturity of the organization with
reference to its' project management capabilities.

Establish Governance Framework

Objective
To ensure appropriate roles and responsibilities are established and
maintained and the appropriate focus for decisions identified to
facilitate Service Improvement Program.

It is important to establish who makes what kinds of decisions with regard to service delivery because
it determines who needs to be involved in the project and in what capacity - decision-maker,
participant, advisor or informant. In CMMI, assigning responsibility is key
to institutionalizing a Managed Process. Without a sound governance model there is little assurance
that decisions in other areas of an improvement endeavor are being made correctly and by the
appropriate people.

"To avoid costly and unfocused implementations of standards and best

 practices, organizations need to prioritize where and how to use standards
and practices. The organization needs an effective action plan that suits its
particular circumstances and needs. First, it is important for the board to
take ownership of IT governance and set the direction management should
follow. Making sure that the board operates with IT governance in mind
does this best. The board should:

 Make sure IT is on the board agenda

 Challenge management's activities with regard to IT to make sure
IT issues are uncovered
 Guide management by helping align IT initiatives with real
business needs and ensure that it appreciates the potential impact on
the business of IT-related risks
 Insist that IT performance be measured and reported to the board
 Establish an IT steering group or IT governing council with
responsibility for communicating IT issues between the board and
management
 Insist that there be a management framework for IT governance
based on a common approach (e.g., COBIT) and a best practice
framework for IT service management based on a global de facto
standard (e.g., ITIL) ".

Aligning COBIT®, ITIL® and ISO 17799 for Business Benefit, A Management Briefing from ITGI
and OGC, p.18

The best way to approach Governance is as a shared activity. Assemble some sort of council or IT
strategy committee when coming up with a governance model. Then, have the committee take a look
at each policy it would like to enact and matrix each by priority, by degree of benefit, and by rank. The
starting point to define governance is to define the role and responsibilities of the IT area. Some key
considerations are:

 People & Structure - At a department level within IT, there should be a definition of what
each area is responsible for. When this structure is rolled up it should cover the
responsibilities of the IT area as a whole. By defining R&Rs, then rolling them up as part of a
structure, it will become clear where gaps exist, or activities outside the scope of IT are being
performed. It also shows the poor fits in the organizationN. Many non-IT areas of the
organization can be part of governanceN. This includes communication processes and implies
the establishment of formal communication forums where interaction can take placeN.
 Process - establishing the rules under which IT operates. Setting standard processes and
methodologies which the organization will useN. An organizational decision to utilize ITIL
or CobIT or CMMI as single or conjoint reference models would be an illustration of this kind
of policy. All these should be visible in the roles and responsibilities of the area, and need to
be documented at some level (more in Process Management). If a proper business process
model has been created, the governance can refer to that model. If not, governance may
have to refer to some high level criteriaN.

"Once IS is aligned with itself, the organization can focus on aligning with
business objectives. This includes making sure that IS shares information
with the business and understands its requirements. When this type of
communication exchange doesn’t take place, the results can cause
problems."

Ken Turbitt, ITIL -The Business Perspective Approach, August 28, 2005, ITSMWatch
  Projects - Governance should also cover the evaluation of ideas, justification, approval and
prioritization of projects. From project start, there are areas that should be included in the
governanceN.
 Compliance - There needs to be a mechanism in place to monitor compliance. This can be
as formal as an IT Audit function, to as informal as periodic reviews.
 Clarify Exception Handling Methods - Exceptions are how enterprises learn. They
challenge the status quo, particularly the IT architecture and infrastructure. Some requests for
exceptions are frivolous, but most come from a true desire to meet business needs. If the
exception proposed by a business unit has value, a change to the IT architecture could
benefit the entire enterprise. Exceptions also serve as a release valve, relieving the enterprise
of built-up pressure. Managers become frustrated if they are told they can't do something they
are sure is good for business. Pressure increases and the exceptions process provides a
transparent vehicle to release the frustration without threatening the governance processR.

Like any major organizational initiatives, IT governance must have an owner and accountabilities. In
most organizations, the CIO will be accountable for IT governance performance with some clear
measures of success. Most CIOs will then create a group of senior business and IT managers to help
design and implement IT governance. The action of the board or CEO to appoint and announce the
CIO as accountable for IT governance performance is an essential first step in raising the stakes for
IT governance. Without that action, some CIOs cannot engage their senior management colleagues in
IT governance.R

Establish Policy FrameworkR

Objective
To establish basic compliance framework to ensure implemented
processes and new practices are followed.

Policies are established to reduce risk and maximize efficiency. The benefits of standardization will
only materialize from effective enforcement of the policy governing work processes. Many policies
focus on how work is performed, others dictate when the work is performed, while others mandate
what technologies will be employed. By designing and enforcing the appropriate policies, service
providers increase quality and enhance agility while minimizing their costs.

Most organizations have no shortage of policies, but, their enforcement is another matter. Many
policies are unknown to IT staff so marketing and accessibility are important considerationsN. Without
some measure of policy enforcement, standardization is nearly impossible to achieve. Technology
selection will be fragmented; economies of scale will be elusive, if not impossible, and learning curves
will never be surmounted. Carefully planned, actively enforced policies are a necessary ingredient for
the successful transition to a service provider model.

However, not every activity needs a policy. Excessive policy-making can stifle innovation and create
an oppressive work environment. There is a balance between the enforcement of policy and the
encouragement of workplace creativityR.

When it comes to building and implementing IT policies, there is no magic bullet. Every business is
different, and the approach taken to meet objectives and/or ensure compliance will vary from one
environment to another, even in the same industries. However, there are certain best practices which
increase the odds of crafting and implementing a policy that employees will support and that will help
protect organizational integrity.
A uniform format will make the policy easier to read, understand, implement, and enforce. The scope
of a policy should be manageable. Separate, smaller polices that address specific needs will usually
be better. A typical policy should include:

 a statement of purpose,
 description of the users affected,
 history of revisions (if applicable),
 definitions of any special terms, and
 specific policy instructions from management.

Policies should be reviewed by legal counsel to ensure that they comply with governing laws, and,
they should be reviewed on a regular basis to ensure that they continue to comply with applicable law
and the needs of your organization. New laws, regulations, and court cases can affect both the
language of your policies and how you implement them. A thorough review of policies at least once a
year is desirable and a dedicated notification system/service to keep employees informed of changes
should be developed. When revised policies are introduced, they should be formally distributed and
thoroughly explained.R

Establishing Awareness of Best Practices

Objective
To develop and maintain ongoing support for Service Improvement
using best practices as advocated through ITIL

Few organizations can direct new change through fiat, particularly if those changes involve cultural
shifts or the re-alignment of established work habits. Mature organizations will have established work
habits which facilitate "change". These organizations are often referred to as "agileN" in that they can
change directions quickly. Flexible alignment of IT with business goals and objectives will preclude
any reluctant acceptance of best practices by embedding practices which seek out the lessons
learned by others.

While individuals may be aware of good practices within their own job speciality they will often lack the
wider perspective associated with other's endeavors and their potential impact on their area. They
often fail to understand the trade-offs between their and other units concerns and initiatives. More
importantly, this may be reflected in a failure of cooperation in administering functions as a participant
within a more encompassing service chain. The result is less than optimal performance and
disgruntled customers.

A basic presentation on IT service management best practices throughout the organization (such as
an ITIL Essentials introduction) will be useful in sponsoring involvement and creating support for
initiatives.
Define Risk Management Approach
Objective
To increase the success rate of service improvement implementations
and subsequent operations caused by a poor identification of risks
associated with the implementation plan and/or operationalization of
the practices.

RiskN management allows IT management to balance operational and economic costs of protective

measures and achieve gains in mission capability by protecting the IT systems and data that support
the organization. Minimizing negative impacts on an organization are the fundamental reasons
organizations implement a risk management process for their IT processes and systems. Effective
risk management must be totally integrated into all service management best practices - particularly
service restoration, change and release processesR. The organization should establish (preferably in
conjunction with developing a policy framework) a general risk assessment approach which defines
the scope and boundaries, the methodology to be adopted for risk assessments, the responsibilities
and the required skills. The approach should ...

 assess the risk acceptance capacity of the organization

 focus on examining essential elements of risk such as assets, threats, vulnerabilities,
safeguards, consequences, and likelihood of threat
 provide for the definition of a risk action plan to ensure that cost-effective controls and
security measures mitigate exposure to risks on a continuing basis
 ensure a formal acceptance of the residual risk, depending on risk identification and
measurement, organizational policy, uncertainty incorporated in the risk assessment
approach itself and the cost effectiveness of implementing safeguards and controls.

Choose a Structural Fault Management Approach

Objective
To identify a strategy for the removal of structural faults from the
infrastructure so as to focus attention on a single or set of identified
approaches.

A primary goal implicit in ITIL is the removal of structural faults (which cause the cessation of business
operations). The time it takes to recover from incidents will often impact the profit line of an
organization, so that the organization should consider its' recovery. This will usually be accomplished
through one of four generic approaches:

1. Place reliance on restoration - Ensure that once an incident occurs that recovery will be as
fast as possible with priority treatment being based upon the impact of the outage to business
operations. The first order of business is to restore service through the implementation of
a workaround with the root cause of the incident taken offline for subsequent investigation.
2. Find and remove root cause - The ITIL practices of directing initial response to the
implementation of a workaround has its' critics...

"Some might question: "why start at problem management and ignore

incident management?" Incident management, while important because it
focuses on the fastest way to help people resolve an immediate issue (email
your file to me and I'll print it; meanwhile, we'll create a trouble ticket to
 figure out why the printer near you isn't working) can actually be a negative
drag on productivity. Workarounds are, after all, work that doesn't really
solve the problem and with repetition can quickly add up to many times the
work required to resolve the underlying problem."

The Fastest Payback for Your ITIL Investment, Integrien White Paper, October, 2005, p.3

3.
"A successful Problem Management implementation will free up IT
resources required to perform daily support activities, which allows for
resources to be directed towards an overall ITIL implementation. Traditional
human-based Problem Management has significant limitations that preclude
it from being effective at freeing up IT resources."

Problem Management: The Key to Leveraging an ITIL Implementation, Chorus System Inc
Whitepaper, March 2005

4. These authors (usually associated with Knowledge-based products) contend that Problem
Management analysis and decision making activities are overly labour intensive.
Consequently, Incident data consists of vague symptoms as reported by users and high level
status information from monitoring systems and monitoring tools constrain the amount of
information to be analyzed to that which a human is capable of absorbing. Thus key data
required to properly diagnose a problem seldom exists. In addition, when the root cause of a
problem is determined and a workaround or solution is identified, the characteristics of the
error and the associated solution are seldom recorded in a known error database (knowledge
base) N. Because of poor incident data and ineffective knowledge bases, many organizations
are forced to increase human resources within Problem Management. In some organizations,
Problem Management is actually a functional group of people rather than a process. In reality,
most organizations are so busy being reactive that there is little time to be proactive.
5. Contain the impact of faults - Infrastructure redundancy, fault-tolerant, effective back-up
strategies, etc will allow the fault to occur without it resulting in an outage to the business. In
the past, this strategy was too expensive to employ for all but the most important of the
enterprise's applications. Today, however, with the advent of blade computing and self-help
mechanisms and their diminishing costs (at least relative to business losses experienced
through the outage) their use is becoming widespread.
6. Problem prevention - Management of the processes in which structural faults enter the
infrastructure through improved Change and Release Management processes. This is the
premise behind the Visible OPS approach R. Their approach starts by Stabilizing the Patient -
that is reducing the number of new faults being introduced to the infrastructure by freezing
change outside of scheduled maintenance windowsN. they then direct attention to effective
Release Management processes by reducing the risks associated with release through the
use of known and trusted "build processes.

The highest return on investment comes from implementing effective release

management processes. This step creates repeatable builds for the most
critical assets and services to make it "cheaper to rebuild than to repair." We
take the priceless paintings identified in the previous step and work to create
equally functional prints that can be mass-produced

The Visible OPS Handbook, Starting ITIL in 4 Practical Steps, Kevin Behr, Gene Kim and George
Stafford, ISBN: 0-9755686-0-4
Identify Configuration Items
Objective
To establish a focal point and organizational culture which recognizes
the importance of maintaining information on the inter-relationship of
component parts of the infrastructure.

Some ITIL process areas are harder to implement than others. A 2002 study of 10 ITIL assessments
in the UK found that "in the area of Configuration Management organizations consistently under
achieve"R. Though central to the control and management of IT resources, an exhaustive CMDB is
difficult to establish and even more problematic to maintain. In the end, this requires automation
through auto-discovery tools - "Dynamic, current, accurate, service-relevant, adaptive and scalable -
auto-discovery is one of the holy grails surrounding the CMDB R. Control comes at a cost.

"A standalone CMDB project, often couched as a Business Services

Management project with an "ITIL-compliant" CMDB (although no such
designation exists), cannot help but be a large, all-encompassing project. It
must define relationships for all lines of business and millions of IT
components. A project so complex tends to last for years and generally leads
to disillusionment and failure."

The Fastest Payback for Your ITIL Investment, Integrien White Paper, October, 2005, p.2

BMC Software Solutions, a major provider of ITSM toolsets, has contended that the "hands-off"
approach by ITIL has resulted in a great deal of confusion about what a CMDB is and what it is notR.
They note, that "One thing, however, that ITIL is explicit about is the fact that configuration
management is focused on the relationships among infrastructure hardware and software
components".

In both CMMI and Service Management Maturity, Configuration Management is cited as a key sub-

process for the achievement of Level 2 (ie. Managed) maturity. Therefore, achieving some capability
in this area is key to realizing basic management capabilities. CMMI identifies key Configuration
activities:

 Identifying the configuration of selected work products that compose the baselines at given
points in time
 Controlling changes to configuration items
 Building or providing specifications to build work products from the configuration management
system
 Maintaining the integrity of baselineN
 Providing accurate status and current configuration

The highlighted item above indicates that CMMI treats Change Management as a sub-process of
Configuration Management - ie., Track and Control Changes.N. Change Management is seen as the
means of controlling modifications to the Configuration data system. Therefore, even though the
CMDB may be difficult to develop, populate and maintain, it is nonetheless a critical to properly
defining the impact of incidents and prioritizing competing demands for resources to devote to
recovery activities. Additionally, it is key to any improvement efforts directed at refining the risks
associated with changes to the infrastructure.

Fortunately, the population of the CMDB can be done in stages - both from the perspective of the
granularity of a recordN and the scope of the coverageN - "Very often, due to the large number of CIs
involved, a phased approached will be adopted to implement this process"R.
 "A number of criteria can be used to aid in the prioritization of CIs and their
associations for CMDB population. The criteria could be based on criticality
of the systems/services to the business, outsourcing or insourcing projects,
systems/services causing the most difficulties to support due to lack of CI
information, projects that require CI information such as technology
refreshment, total cost of ownership etc. Depending on the chosen criteria,
historical statistics and management information captured by the Service
Desk, Incident Management, Change Management, Problem Management,
Release Management and Availability Management processes can provide
further data for decision making."

Implementing Service and Support Management Processes - A Practical Guide, Section 3.2.5. p. 54

"It is necessary that the organization collect and assess current

information on the Configuration Items comprising the infrastructure.
This will typically comprise spreadsheets, datasets and may include an
Asset Management system. The organization should identify and
separate the information pertaining to its' most important and high risk
applications. The relationships amongst these items should be itemized
into an accessible form and made available to service Desk and Change
Management personnel."

Develop Project Management Capability

Objective
Ensure capability to undertake successful service improvement
initiatives

Service Improvement Programs should be implemented using project management approaches and
practices. The organization's capabilities with respect to project management, will, to a large degree,
determine how successful it is in undertaking a service improvement initiative.

In addition, infrastructure rollouts and major releases should be controlled using project management
methodologies. The capabilities of the organization in re-using and perfecting project plans will affect
their success rates and lead to reductions in changes which need to be backed out and fewer
structural faults and incidents in the infrastructure.

"Deployment involves a high degree of logistics management of all the new

infrastructure components, and requires good medium term tactical planning
skills, including Change Management, and Project Management
competencies."

ITIL, ICT Infrastructure Management, section 3.1

Project Management is a key control in the CobIT framework, and the existence and review of the
framework is a key control area - establish and periodically review a general project management
framework which defines the scope and boundaries of managing projects, as well as the project
management methodology to be adopted and applied to each project undertaken.R. The publication
describes the attributes for Project Management in organizations at different maturity levels.
Similarly, Project Management is one of four process areas in CMMIN. Note that basic Project
Management capabilities are associated with a level 2 (Managed) organization while Process
Management proficiencies require level 3 (Defined) maturity.

Level 2 - Managed

 Project Planning - establish and maintain plans that define project activities
 Project Monitoring & Control - provide an understanding of the project's progress so that
appropriate corrective actions can be taken when the project's performance deviates
significantly from the plan.
 Supplier Agreement Management - Manage the acquisition of products from suppliers for
which there exists a formal agreement.
Level 3 - Defined

 Integrated Project Management for IPPD - establish and manage the project and the
involvement of the relevant stakeholder's according to an integrated and defined process that
is tailored from the organization's set of standard processes.
 Risk Management - identify potential problems before they occur, so that risk-handling
activities may be planned and invoked as needed across the life of the product or project to
mitigate adverse impacts on achieving objectives.
 Integrated Teaming - form and sustain an integrated team for the development of work
products.
 Integrated Supplier Management - proactively identify sources of products that may be
used to satisfy the project's requirements and to manage selected suppliers while maintaining
a cooperative project-supplier relationship.
Level 4 - Quantitatively Managed

 Quantitative Project Management - quantitatively manage the project's defined process to

achieve the project's established quality and process-performance objectives.

Identify IT Services
Objective
Provide focus and direction to service improvement activities so that
resources can be better utilized to achieve corporate information goals
and objectives.

Service Level Management was one of the first areas addressed in the second version of the ITIL
books. It's primary focus is on distinguishing types of agreements and emphasizing the need for
written agreements to replace verbal accords. Much discussion centres on the contents of the
agreements and the need to report against performance commitments contained within the
agreement. Service Catalogues are mentioned in passing but the relationship between them and
SLAs is not expounded upon.
More recently, SLM has been advanced as a key method in
ensuring IT-business alignment. As the Cheshire cat replied to
Alice - "If you don't know where you're going, any road will
get you there".. So, many organizations are discovering that
operational effectiveness means that money must
be directed to activities and processes which have returns
realizable in the achievement of business goals and objectives
- operational efficiency is just wasted dollars if it doesn't add
business value.

The three main concerns facing executive management today

are compliance with government regulations, cost reduction
and increased revenue generation:

 The first of these, compliance with government

regulations, is a major issue for IT. It may be a key
drivers in defining the service management (eg.
Sarbannes-Oxley), requiring close cooperation with
corporation financial and business leaders. At the
very least, it will require periodic compliance reports.
 Cost reduction is always a concern for both IT and
the business. Streamlining processes and offering
self-service capabilities through a service catalogue
and knowledge bases can reduce costs while
empowering users.
 Lastly, streamlining and automating processes for
initiating requests and streamlining the authorization
process can reduce time to service, freeing
technicians to work on higher-priority issues like
increasing efficiencies or providing additional
revenue-generating capabilities
Indeed, increasing attention has been directed to the
production and dissemination of a Service CatalogueR as a
means of better achieving this alignment.
"Central to these and other ITIL
processes, is the IT Service Catalog,
which provides a compelling venue for
communicating service options in terms
of content, costs, service level agreements
(SLAs) and other characteristics to IT
customers. The IT Service Catalog can
also empower IT operations and planning
with an effective model of business
services and their end-components, which
can support and enhance a large number
of ITIL processes, as well as most
management disciplines."

The Service Catalog: an Essential Building Block For

ITIL, White Paper Prepared for Centrata, December
2004, p. 1

"The Service Catalog is a critical first

step in ensuring that IT services align
with the business unit’s needs. By
establishing a standard set of service
 offerings, with associated service levels
and costs – and then publishing that
information to the internal customers of
IT – the IT organization can leverage
market forces to manage demand for
services. IT can become more demand-
driven, based on informed customer
requests for pre-defined service offerings,
and thus improve alignment."

How to Produce an Actionable IT Service Catalog,

newScale Whitepaper, February, 2005,
www.newscale.com

"Many experts agree that one of the first steps in running IT like a service-
oriented business is to implement an effective service catalog. Adopting an
IT catalog of services in alignment with an ITIL based service level
management process can optimize service provision to the business while
reducing the overall costs of IT service support and delivery.......

The initial baseline should be refined to include only those initial services to
be included in the pilot or first iteration of the IT service catalog."

Ready to Create Your IT Service Catalog?, ITILworx, Kevin LeBlanc, June, 2005, p.1

"By mapping IT services more explicitly to business needs, the IT

organization can better understand how to add even more value. This aspect
of the Service Catalog helps address three of the most emotional words in
the IT vocabulary; "IT-Business Alignment.""

IT Service Catalog - Common Pitfalls, Rodrigo Fernando Flores, September 12, 2005, ITSMWatch

"IT Service Catalogs, which define the services that an IT organization is

delivering to the business users, have emerged as the central element of IT
Governance models. Service Catalogs serve to align the business
requirements with IT capabilities, communicate IT services to the business
community, plan demand for these services, and orchestrate the delivery of
these services across the functionally distributed (and, oftentimes, multi-
sourced) IT organization."

IT Service Catalogue - The Central Component Of IT Governance, Boris Pevzne, September 19,
2005, ITSMWatch

A Service Catalogue offers the organization a method to establish a relationship between costs and
the provision of IT services.

"The existence of a true price that is charged to a business unit's controllable

expense lines encourages efficient resource use. When the enterprise fails to
pay a price for the services it consumes, it wastes resources through
artificially inflated demand. It also tends to develop the impression the
services are free, undermining their perceived value."

"Running IS Like a Business: Introducing the ISCo Model", Gartner, January 16, 2003, page 21.

Many organizations avoid internal pricing of time and resources. While unpopular it will promote a
tangible shift in a service provider's orientation. Both internal and external prices are fundamentally
based on a calculation of the cost of delivering a service to a customer. The accuracy of the cost
analysis will determine the financial viability of the service. No service assessment can be adequately
undertaken without such figures. All relevant costs should be captured, categorized and assigned to a
service. Cost modeling must be both systematic and repeatable. Once gathered, the costs must be
incorporated into an internal pricing model for analysis along two dimensions.

Establish Documentation Repository

Objective
Establish ability to obtain, store and utilize process and policy
documentation.

"Undocumented or overly manual processes are not sustainable; human

nature virtually guarantees that shortcuts will be taken, judgment will lapse
and mistakes will be made."

The New Business of IT, OPSWare Whitepaper, available at Bitpipe

Process management is a way in which an individual, a group, a project, or an organization thinks

about, and manages, its work activities. It is based on the premise that the quality of the product is
governed primarily by the quality of the process used.  . IT is being forced to pay far greater attention
to process for three primary reasons:

 regulatory mandates requiring IT organizations to prove that they have taken reasonable care
in controlling their IT processes.
 the push for efficiency. One area that has been largely untouched in this effort to maximize IT
efficiencies is the process area. There is a wealth of efficiencies that can be reaped from
focusing on processes.
 the push toward automation and responsive infrastructures that can adapt rapidly as business
needs change. Automation is not a silver bullet for processes. In reality, automation should
not be undertaken unless there are established processes that are already stable and
effectiveN.

The ability to utilize known, trusted and re-usable processes is an important organizational attribute.
Without defined and enforced processes encompassing best practices wherever practical the
organization is doomed to repeat its' mistakes because there are few formalized methods to capture
learning.

Process Management is one of four key primary areas in CMMIN which defines an organization's
capabilities and overall maturity. Each of these four areas can be defined by the maturity of sub-
processes within that area.

However, Process Management requires key process capabilities by an organization which are
associated with higher levels of maturity:

Level 3 - Defined

 Process Focus - plan and implement organizational process improvement based on a

thorough understanding of the current strengths and weaknesses of the processes and
process assets.
 Process Definition  - establish and maintain a usable set of organizational process assets.
This is a key practice area. It is instructive to note the sub-processes CMMI advances for
implementing this Practice Area. It represents a practical plan for implementing process
definition capabilities.

o Establish Standard Processes

 Decompose each standard process into constituent process elements to the detail
needed to understand and describe the process
 Specify the critical attributes of each process element
 Specify the relationships of the process elements
 Ensure that the set of standard processes adheres to applicable policies; process
standards and models; and product standards
 Ensure that the set of standard processes satisfies the process needs and
objectives of the organization.
 Ensure that there is appropriate integration among the processes that are included
in the set of standard processes.
 Document the organization's set of standard processes.
 Conduct peer reviews on the organization's set of standard processes.
 Revise the set of standard processes as necessary
o Establish Lifecycle Model Descriptions
 Select life-cycle models based on the needs of projects and the organization
 Document the descriptions of the life-cycle models.
 Conduct peer reviews on the life-cycle models.
 Revise the descriptions of the life-cycle models as necessary
o Establish Tailoring Criteria and Guidelines
 Specify the selection criteria and procedures for tailoring the set of standard
processes
 Specify the standards for documenting the defined processes
 Specify the procedures for submitting and obtaining approval of waivers from
the requirements of the organization's set of standard processes
 Document the tailoring guidelines for the organization's set of standard
processes.
 Conduct peer reviews on the tailoring guidelines
 Revise the tailoring guidelines as necessary
o Establish the Organization’s Measurement Repository
 Determine the organization's needs for storing, retrieving, and analyzing
measurements
 Define a common set of process and product measures for the set of standard
processes
 Design and implement the measurement repository
 Specify the procedures for storing, updating, and retrieving measures.
 Conduct peer reviews on the definitions of the common set of measures and the
procedures for storing and retrieving measures
 Enter the specified measures into the repository
 Make the contents of the measurement repository available for use by the
organization and projects as appropriate.
 Revise the measurement repository, common set of measures, and procedures as
the needs change
o Establish the Organization's Process Asset Library
 Design and implement the process asset library, including the library structure
and support environment
  Specify the criteria for including items in the library. The items are selected
based primarily on their relationship to the set of standard processes
 Specify the procedures for storing and retrieving items
 Enter the selected items into the library and catalog them for easy reference and
retrieval.
 Make the items available for use by the projects
 Periodically review the use of each item and use the results to maintain the
library contents.
 Revise the process asset library as necessary

 Organizational Training - establish and to develop the skills and knowledge of people so
they can perform their roles effectively and efficiently
Level 4 - Quantitatively Managed

 Process Performance - establish and maintain a quantitative understanding of the

performance of the set of standard processes in support of quality and process-performance
objectives, and to provide the process performance data, baselines, and models to
quantitatively manage the organization's projects.
Level 5 - Optimizing

 Innovation & Deployment - select and deploy incremental and innovative improvements that
measurably improve the organization's processes and technologies. The improvements
support the organization's quality and process performance objectives as derived from the
organization's business objectives.

Organizational process assets enable consistent process performance across the organization and
provide a basis for cumulative, long-term benefits to the organization. A Process Catalogue provides a
single source of the definition of IT operations processes. It is invaluable in the management and
continuous improvement of these processesR. This collection of items should include descriptions of
processes and process elements, descriptions of life-cycle models, process tailoring guidelines,
process-related documentation, and data. The catalogue supports organizational learning and
process improvement by allowing the sharing of best practices and lessons learned across the
organization.

For the catalogue to properly work it should meet the CMMI criteria for institutionalizing a Process
Definition at the defined level

 Establish Policy - Establish and maintain an organizational policy for planning and
performing the organizational process definition processN.
 Provide Resources - A process group typically manages the organizational process
definition activities. This group is typically staffed by a core of professionals whose primary
responsibility is coordinating organizational process improvement. This group is supported by
process owners and people with expertise in various disciplines.
 Assign Responsibility - Assign responsibility and authority for performing the process,
developing the work products, and providing the services of the organizational process
definition process.
 Train People - Examples of training topics include (1) planning, managing, and monitoring
processes (2) Process modeling and definition, (3) Developing a tailorable standard process
 Manage Configurations - Examples of work products placed under configuration
management include (1) set of standard processes, (2) descriptions of the life-cycle models,
(3) tailoring guidelines for the set of standard processes, (4) definitions of the common set of
product and process measures, (5) measurement data
  Identify and Involve Relevant Stakeholder's - Examples of activities for stakeholder
involvement include (1) reviewing the set of standard processes, (2) reviewing life-cycle
models, (3) resolving issues on the tailoring guidelines, (4) assessing the definitions of the
common set of process and product measures
 Monitor and Control the Process - Examples of measures used in monitoring and
controlling include (1) percentage of projects using the process architectures and process
elements of the set of standard processes, (2) defect density of each process element of the
set of standard processes
 Objectively Evaluate Adherence - Examples of activities reviewed include Establishing
organizational process assets.
 Review Status with Higher Level Management - Review the activities, status, and results of
the organizational process definition process with higher level management and resolve
issues.

Much of this material exists in the organization in various uncollated (and hence, less accessible)
forms. The collection and retention of these process artifacts is an exercise which can be undertaken
early in preparation for their inclusion in process modeling and storage in a process repository.

Establish Base Measurement Capability and Culture

Objective
Establish capability to continuously improve the collection and analysis
of objective data on performance.

Many organizations rely upon a tool to provide the process. This most often occurs because the
underlying IT discipline's processes and activities and their associated value are not properly
understood. Most IT managers understand the technology tools that are used to oversee the
environment and deliver the required products and services to its constituency, but not the underlying
processes or relating measurements. IT organizations may do a good job of measuring and/or
tracking certain aspects of the IT environment, such as database transactions, network uptime,
trouble tickets, change requests, and so on but falter in providing the end-to-end measurement and
reporting of the IT organization's transformational processes.

One of the most popular characterizations of indicators is the one known as SMART R meaning that a
good indicator has to be Specific, that is, identified with a relevant variable and representing it
accurately; Measurable, that it not only may be measured but that there are also the mechanisms
necessary to generate the corresponding information in order to quantify them; Action-oriented in
relation to critical processes of the organization; Relevant (R:Relevant) in general terms has to do
with the differentiation between lots of trivial ones and the few vital ones; Timely which has to do with
the availability of information at the right moment for the decision making.

"The KPIs for each ITIL process can be leveraged to determine the maturity
and completeness; at the same time using 6-sigma concepts around
variability will provide a more tangible goals to set and achieve. There needs
to be a targeted, pre-determined goal, which will be a direct function of the
degree of consistent intensity driving the momentum of the efforts"

Service Centric Model For NOCs And Data Centers, Suparno Biswas, October 30, 2005, ITSMWatch

"[Customers want] Measurement and metrics for SLM. Today, business

decision-makers demand a more consistent delivery of IT services - which
means IT needs service-level management (SLM). To maintain the service
levels that business users expect, IT departments have to implement more
mature and stringent processes in conjunction with better IT performance
measurement systems."

Raising the Bar for ITIL and CMDB Implementation, Thomas mendel, Jean-Pierre Garbani, June 22,
2005, available at Bitepipe