This advice addresses two key element:

1. adopt a vision (understand where you're going) based upon organizational need
2. develop projects which are manageable within the context or organizational capabilities
3. projects need to be tailored to organizational characteristics

Michael Marks expands upon the project scope theme and adds two additional "tips" for a successful ITIL implementation.

ITIL

Therefore, we may conclude that when implementing ITIL best practices...

1. Change Management must precede Configuration Management in order to determine what CIs are most important
2. Service Level Management establishes the services which Financial Management will use
3. Incident Management provides the data which Problem Management uses

Further, ITIL identifies eight primary elements of a good implementation plan:

• Create a sense of urgency - Creating a sense of urgency is concerned with answering the question 'What if we do nothing?' Answering this question at all organizational levels will help gain commitment and provide input to a business justification for investing in service management practices
• Form a guiding coalition - assembling and empowering a group to lead the Change effort. The team should have shared understanding of the urgency and what it wants to achieve. A guiding coalition should ensure that the organization is motivated and inspired to participate. The Team should endevour to gain full support from the stakeholders, including the business managers, IT staff and the User community. The team must be prepared to spend time and effort convincing and motivating others to participate.
• Establish Vision(s). The guiding coalition is the custodian of the service management vision. A good vision statement can serve four important purposes:
  • Clarify the direction of the program,
  • motivate people to take action in the right direction,
  • coordinate the actions of many different people,
  • outline the aims of senior management

  Without a sensible and easily understood vision, a Service Management implementation program can deteriorate into a list of confusing, incompatible projects that can take the organization in the wrong direction, or even nowhere at all. Remember, as the Cheshire Cat quoted to Alice - If you don't know where you're headed then any road will get you there.

• Communicate the Vision(s). The vision should be understandable by every stakeholder. The way it is communicated should be aimed at specific target groups. For example, communication to senior management will require a different approach to communication to IT staff.
• Empower staff to act on the Vision - In the empowering phase two important aspects need to be stressed, i.e. 'enabling' and 'removing barriers'. There needs to be new, changed or added facilities so that people are really able to make the Change happen.
• Create Quick Wins. Nothing breads success like success. Staging the implementation plan to achieve a Return on Investment from initial ventures will go a long way in creating new and solidifying current support.
• Consolidate Improvements - Initial changes can easily be undone if not carefully nurtured. This is because, unless improvement and Change is thoroughly embued in the organizational culture there is a tendency to revert to previous ways.

  The success of quick wins keeps the momentum going and creates more Change. In a CSIP it is important to recognize short, middle and longer term wins. Changes should sink deeply into the new culture or the new approaches will be fragile and subject to regression: quick wins have the characteristics of 'convincing',' motivating' and showing immediate benefits and gains medium-term wins have the characteristics of 'confidence' and 'capability' - and having a set of working processes in place longer-term goals have the characteristics of 'self-learning' and 'expertise' and fully integrated processes that have self-learning and improvement built into them; reaching this stage requires a baseline of confident, capable delivery and real understanding - trying to reach this level before having gone through the other levels is like trying to win an Olympic medal before training has commenced. Implementing ITSM, Section 5.3.7

• Institutionalize the Change(s). Many Changes fail because they are not ingrained into everyday practice. To institutionalize a Change means showing how new working practices have produced real gain and benefits, and ensuring that the improvements are embedded in all organizational practices.

  Some ways of institutionalizing Changes: new recruitment and selection criteria (looking to hire people with ITIL experience or proven Customer or service focused experience) new employee (business and IT) induction includes IT Service Management familiarization: 'This is the way we do things.' employee training plans and offerings include ITIL or Service Management focused training process goals and management reporting is matched to changing requirements, showing that they are used and requests are made for new sets of steering information clear actions defined in minutes of meetings based upon reports produced new IT solutions and development projects are integrated into existing processes. Signs that the Changes have been institutionalized include: people defend the procedures and declare, 'This is the way we work', rather than, 'This is the way I've been told to do it' people make suggestions for improving procedures and work instructions to make them more effective or efficient process owners are proud of their achievements and offer to give presentations and write articles people come back from ITIL conferences and seminars and declare, 'I didn't learn much that we haven't already done or thought of'. Implementing ITSM, Section 5.3.8

ITIL does suggest that the usual order of implementation is to establish the Service Support functions first together with the other first-line control functions of Network Management and Computer Operations Management. This has the advantage of focusing on the day-to-day relationship between customers and the IT service provider so that the customer will see immediate benefit. There are some obvious dependencies. For example, Configuration Management relies on Change Management to provide control processes and should be implemented at the same time, or after, Change Management is established. Similarly, Problem Management cannot function effectively without the Service Desk and Incident Management.

META Group

Adopting this clustering framework they suggested a phased implementation of ITIL processes:

Microsoft

Quick Wins

Best Practices Area	Quick Win
Service Desk	Merge multifunctional service desk into one central point of contact, either virtually or physically.
Incident Management	Establish consistent definitions of incident severities to ensure proper response by support staff to logged incidents.
Problem Management	Ensure that changes are correctly referenced to problems so that the root cause is only resolved once
Change Management	Establish a standard Request for Change (RFC) form.
Release Management	Ensure that Operations Acceptance Testing (OAT) is carried out as a separate exercise to User Acceptance Testing (UAT).
Configuration Management	Produce a "logical" CMDB from existing system data (for example, inventory, human resources, purchasing) rather than a "physical" CMDB.
Availability Management	Use historical analysis on hardware mean time before failure (MTBF) in order to proactively replace equipment before it fails.
Capacity Management	Input threshold figures for CPU, memory, and disk to Service Monitoring and Control.
Service Level Management	Summarize service level agreements into two pages or less so that they are easier to read.
Service Monitoring and Control	Identify system baselines to establish accurate thresholds for monitoring and alerting on normal and abnormal system utilization.
Financial Management	Charge on service management issues (service desk calls, problems/changes raised) rather then CPU, memory I/O, etc...
IT Service Continuity Management	Ensure that documentation copies are stored at an off-site location either electronically or physically.

InterProm Caveats

Proactive

Proactive recommends the following guiding principles for ITIL implementation.

"Once the Service Support and other control functions have been established, the service provider is in a position to implement the Service Delivery processes. Again, there is no rigid order of implementation and, in practice, a significant amount of parallel activity can occur. For example: The development of a service catalogue is a necessary stage in the implementation of both Service Level Management and IT Service Continuity Management. Business impact analysis and risk analysis & management are relevant to both Availability Management and IT Service Continuity Management."

Many organizations will want to implement Service Level Management as a priority and the ITIL recognizes this. However, it does recommend that at least some elements of Availability Management (reporting) and Capacity Management (performance management & application sizing) are established at the same time so that realistic targets can be agreed in SLAs, monitored and consistently achieved. It may also be necessary to produce cost estimates for different levels of service in order to select the most appropriate one. This will require some Financial Management capability. The remaining elements of Availability and Capacity Management can be implemented at a later stage, as can more detailed Financial Management and IT Service Continuity Management.

Art of Service

Visible Ops Handbook

They suggest that ITIL should be implemented within an organization in four distinct phases:

Implementation Methodology

The classic implementation strategy is depicted on the right. The organization develops a Vision for the IT Organization based upon high level business objectives. This is accomplished by ensuring proper alignment between IT and business strategic objectives. No organizationN manages information technology for its' enjoyment. Rather, IT is an enabler of business goalsNR. This alignment is traditionally supported by Service Level Management wherein IT operations are expressed as services which seek to be aligned to business objectives. Baseline assessments provide information on where the IT organization is currently located relative to those goals. Baselining or benchmarking moves the yardstick for the organization allowing it to refine its' targets, short-term goals and tactics to be used in achieving its' strategic objectives. The goals should ideally be expressed as Key Goal and Performance Indicators. KPI's have some broad characteristics which distinguish them from other measures: they are measured frequently e.g. daily or 24/7 (KPIs are not measured monthly) they are acted upon by the CEO and the senior management team on a daily or 24/7 basis all staff understand the measure and what corrective action is required responsibility can be tied down to the individual or team they have a significant impact on the organization e.g. it impacts most of the core critical success factors and balanced scorecard perspectives positive movement affects all other performance measures in a positive way Service Improvement Programs (SIP) are managed projects to bridge the gap between the current baseline and the desired service.

Lastly, what are the measures for success? How does the organization know when it has achieved its' targets^DR. These are monitored using a balanced scorecard approach highlighting KGI and KPI and explaining significant variances ^N.

It is, however, never this simple. Complicating this are:

• defining measurable targets for an organization presents a "moment of truth". Adopting industry averages must recognize the capabilities of the organization to undertake the exercise. This is reflected in the sophistication (ie., maturity) of supporting processes such as Project Management and Process Management.
• Despite all the processes mentioned in ITIL, as a comprehensive framework it is incomplete. A 2004 study of firms in the United Kingdom concluded that "Adopting companies found a need to add other processes beyond those described in the ITIL" ^R.
• the need to stage implementations in accordance with maturity level horizons in order to solidify gains within the organization's cultural mix so that back-sliding doesn't occur in the absence of dedicated resources and changed champions

Implementation Enablers

Determine Organizational Abilities to Change

Determine the Cost of Downtime for Major Applications

The overall costs of an IT Service are influenced by the levels of Availability required and the investments required in technology and services provided by the IT support organization to meet this requirement. Availability costs and those costs increase exponentially as requirements approach continuous operations.

However, it is important to reflect that the UnAvailability of IT also has a cost - UnAvailability isn't for free either. For highly critical business systems it is necessary to consider not only the cost of providing the service but also the costs that are incurred from failure. The optimum balance to strike being the cost of the Availability solution weighed against the costs of UnAvailability.

The cost of an IT failure could simply be expressed as the number of business or IT transactions impacted, based on either an actual figure (derived from instrumentation) or an estimate. When measured against the vital business functions that support the business operation this can provide an indication of the consequence of failure. The advantage of this approach is the relative ease of obtaining the impact data and the lack of any complex calculations. It also becomes a 'value' that is understood by both the business and IT organization. This can be the stimulus for identifying improvement opportunities and can become a key Metric in monitoring the Availability of the IT Service. The major disadvantage of this approach is that it offers no obvious monetary value that would be needed to justify any significant financial investment decisions for improving Availability.

Where significant financial investment decisions are required it is better to express the cost of failure arising from System, application or function loss to the business as a monetary 'value'. The monetary value can be calculated as a combination of the tangible costs associated with failure, but can also include a number of intangible costs. The monetary value should also reflect the cost impact to the whole organization, i.e. the business and IT organization.

Assigning costs of Unavailability allow the organization to establish what is acceptable risk. Once established then highly reliable analyses of the optimal level of availability are possible and a correct assessment of the availability-recoverability trade-off is possible.

Develop a Vision for the Implementation

A Vision of what you want to accomplish is a mandatory condition for implementing ITSM. "A vision, simply put, is an objective that lies outside the range of planning. As such, a vision includes both a description of the organization's most desirable future state and a declaration of what the organization needs to care about most to reach that future state." Michelle L. Bechtell, Untangling Organizational Gridlock, Quality Press, 193, ISBN: 0-8144-0203-8, p 182 This Vision should include both long-term and short-term milestone for accomplishment. These milestone should acknowledge the accomplishment of specific capability maturity characteristics. For many organizations achieving a Defined maturity will be either the primary goal or a milestone towards reaching even more mature ITSM processes and activities. The Vision needs to be translated into specific Key Performance Goals and Indicators which define the goal. The depiction on the right is Thomas Davenport's. Davenport suggests that Visions should include a "stretch goals - which is primarily behavioural. This lets process designers and customers know that innovation and creativity are welcome and that the organization is serious about process improvement. To target low levels of improvement, or what can be realistically achieved with modest increases in resources and effort is to invite only marginal improvement at best. However, even stretch goals must be attainable, if it is impossible to achieve the target then staff become disillusioned.

Develop Process Repository

One of the key elements in developing a process repository is the maintenance of process modularity. In this respect, think of processes as application code. Develop sub-routines (modules) which represent the a generic process and describe process variations as conditions within the description. This treatment ultimately pays dividends to the organization by highlighting common functions and activities which may be candidates for consolidation (or some other common treatment). This is what is referred to in CMMI as "tailoring the process" from a common process repository - a key element in improving overall organizational capabilities.

In sophisticated process implementations, the organization may wish to invest in process tools such as Proactivity, FoxPrism, or Prosim. These tools maintain process assets in structured databases at a defined level of granularity. maintaining processes in this way facilitated access and re-use in other process descriptions.

Driving this movement is Business Process Management (BPM). BPM is more than process mapping. Where process mapping tends to be a static, two-dimensional representation of the process, BPM permits the process data that goes with the flow to be used for analysis using powerful analytical engines. The data, the process flow and the analysis are often the combination that allows for clear identification of bottlenecks, waste in the operation, root cause determination and prioritization of breakthrough opportunities. While BPM has been targeted at high-level business process, its' implications for IT service management are dramatic and will continue to be felt over the next decade. It is " The Third Wave" according to Howard Smith and Peter Fingar.

Assess the State of Current IT Service Management

Choose a Framework

Select Assessment Criteria

These self assessment questions are rudimentary at best and measure whether an organization has a function in name. They provide little insight into how well a function, activity or toolset may be meeting its' intended purposes. Considerable work needs to be directed in this area to better integrate CMM concepts within an assessment framework. In my opinion, twenty questions in each area fails to accurately assess the organization's capability. An assessment which more accurately assesses the employment of various activities and tools in each area at different maturity levels would be a vast improvement. Unfortunately, it is unlikely to come soon because consulting firms gain significant contracts from assessing these capabilities. The recommendations are often disappointing in terms of the recommendations. More often than not, the primary value gained from the assessment is the source itself - "recommendations from an independent, big name consulting firm" which all too often are required to progress further through the company's management layers. And, also far too often, the "independence" proves to be illusionary as the consulting firm has its' own or another company with whom it has formed an alliance, products to flog. BE WARY.

Identify Executive Sponsorship

The executive sponsor must be a champion of the process, particularly if the shop has gone many years with no structured turnover procedure in place. He or she needs to be able to persuade other executives both inside and outside of IT to follow the lead. This individual is responsible for providing executive leadership, direction, and support for the process. The executive sponsor is also responsible for selecting the process owner, for addressing conflicts that the process owner cannot resolve, and for providing marketing assistance.

Determine AS-IS (Benchmark)

In tangible terms, this means that an assessment of the AS-IS situation should be top-down. That is the description should start will a high level description of the current process without fleshing out process detail. It may be that entire sub-processes and activities can be eliminated or need substantial revision to achieve desired operational gains. Describing them in detail service no purpose since the description will become an archival document only once the new processes are initiated.

More time should be devoted to uncovering the Policies, Guidelines and assumptions which underpin the current processes and subjecting them to substantial scrutiny. It may be that many assumptions are no longer valid and that new technological tools have opened up new, previously unseen opportunities.

Refine TO-BE Process Descriptions

• Process Level 1 describes a 'mega-process'. In practices this level strives to give readers a broad, high-level understanding of the organization functions. At this level of abstraction the entire operation should be displayed on a single page. The next process levels provide increasingly level of detail.
• Process Level 2 translates a Level 1 process into major process functions. the organizations' activities are subsequently de-composed into processing areas. Process Level 2 process documentation depicts the inputs, outputs, controls, mechanisms and major activities for each process function.
• Process Level 3 defines and sequences the main events within each major process. At this level of decomposition.
• Process Level 4 continues the decent into greater activity granularity
• Process Level 5 defines the supplemental procedures and reference material used to guide, clarify or instruct how tasks are performed.

Responsibility for subsequent de-compositions will reside with the units both directly involved in the processes - though some decisions will be required for processes which span organizational units.

Many processes may be described as service requests - ie. a process is invoked upon the request for a new or change to an existing process. For example, a request to set up the IT services associated with a new employee will be maintained as a class 4 or 5 process - tailored from a higher level process (and, consistent with) a process to launch a service request (so that there is consistency in how service requests are initiated and fulfilled regardless of the service).

Identify Risks to Implementation of TO-BE processes. Establish risk management strategies

Risk	Mitigation Action
Initial Support disappears	conduct solid research to express implementation in terms of return of Investment achieve multiple sources of champions so that if one leaves another can assume the sponsorship role
Organizational culture unreceptive to ITIL practices	Undertake organization training in ITIL practices identify cultural impediments embed ITIL practices in job descriptions provide other financial incentives for compliance
Organization lacks the organizational maturity to maintain the gains - ie. it back-slides to its' "natural" operational methods.	manage ITIL implementation as an organization Change project emphasize transition to performance-based processes (so that individual performance is aligned) ensure sufficient "quick-win" to sustain momentum Market ITIL implementation successes
unrealistic or poorly expressed objectives - the organization has no idea what success will look like	emphasize visioning exercises

The method used to implement service initiatives is project management. Project Management, according to the Project Management Institute's Project Management Book of Knowledge, is the application of knowledge, skills, tools and techniques to project activities in order to meet or exceed stakeholder needs and expectations. Project management knowledge and practices are best described in terms of their component processes. These processes can be placed into five process groups: (initiating, planning, executing, controlling and closing) and nine knowledge areas (integration management, scope management, time management, cost management, quality management, human resource management, communications management, risk management and procurement management).

There are many project management methodologies. The standard used by the CCTA - the creator of ITIL, is PRINCE2 - Projects in Controlled Environments. PRINCE2 is a process-based approach for project management providing a method for the management of all types of projects. Each process is defined with its key inputs and outputs together with the specific objectives to be achieved and activities to be carried out. PRINCE2 is a written description of how to manage a project in a logical, organized way, following defined steps. It is not a tool or a technique, but a structured project management process.

Projects can be one day, one year or many years. It must be recognized that, although the creation of a small deliverable is a project, it does not need the structure and discipline of a much larger project. For a one day project, you 'just do it'. Any planning analysis and design is all done in your head. For a twenty day project, you mostly 'just do it'. However, now you may need to plan a little bit, maybe communicate a little bit, maybe deal with problems a little bit. A three month project probably has too much work to plan and manage it all in your head. For instance, you need to start defining the work and building a simple workplan. A six month project needs full project management discipline. On the other extreme, a multi year project probably has too much to get our heads around it all. Now you start to break the larger project up into smaller, but related, projects to get the entire piece of work done.

What constitutes an ITIL improvement project? There are two essential approaches which, in all likelihood will culminate in very similar activities. They differ in the breadth and scope of the project management undertaking - the underlying techniques and control points:

• major ITIL/CobIT processes are the defined project with specific sub-processes being elements of the Work Breakdown Structure, or
• ITIL/CobIT sub-activities (eg. service catalogue, escalation management) being the primary focus within a framework established by the major categories.

There are a number of problems with very large projects:

• The work is less clear the farther out in the future it is
• Since the future work is less clear, it is harder to make any kind of accurate estimates for effort, duration and cost
• Business and technical conditions will change over time, making planning assumptions in the future very uncertain
• You risk losing organization support if there is a long delay before delivering tangible results
• It is very difficult to predict resource requirements and availability far into the future

In general, very large efforts are much too difficult and complex to manage as a single project. The better technique is to break the work down into more manageable chunks, each of which is considered its own project, with its own Project Charter. For instance, a long effort can be broken into separate sequential projects based on the life cycle. A project is set up for the analysis work. Toward the end of that project a new project is established, based on what you know then, to do the design work. Then a construct/test project is initiated, and finally a project for implementation. Other large initiatives might be broken up into smaller projects that might run in parallel. On the other hand, an effort to implement a large package solution may be broken into smaller projects, some of which must be done sequentially, but others that can be done in parallel. Each team will work to complete its smaller project, but all the work would be coordinated so that the entire effort is successful.

This is my preferred approach for IT service management. The spider-web of inter-dependencies between the major ITIL/CobIT categories make project identification through ITIL disciplines too gross a division to start from. Treating the ITIL area (eg. Change Management) as the primary unit of analysis for project improvement purposes has the tendency to compartmentalize the effort without proper recognition of the relationships to defect management, release management, configuration management, etc.

Select Improvement Projects

• Operational Necessities

  The organization may need to attend immediately to some prominent service gaps. Examples, might be to remove service shortcomings identified in an IT audit, or legislative gaps such as Sarbannes-Oxley or to ensure that a Disaster Recovery Plan can be initiated).

• Removing Pain Points

  The organization will want to remove the most prominent sources of poor service management. These may be:
  • sources of customer-expressed dissatisfaction,
  • services deemed excessively expensive for the value received,
  • processes that are clearly not working correctly

• Process Inter-dependencies

  Processes frequently have inter-relationships which must be considered. Improving service in one area may be expedited my first considering improvements in a related process. As a general rule, some measure of process control needs to be evident in enabling areas for a service management initiative to be fully successful - otherwise, the gains will be short-lived as the organization is back-slides into previous habits and processes. This is what is referred in CMM as the "ability to commit" - or the institutionalization of the process gains.

  In other instances, the implementation of an improvement may be expedited by a successful associated process. This will usually mean than elements of the process under consideration need not be as rigorous or "mature" because there are other venues through which key activities (and their associated performance objectives) may be obtained. F0r example, consider the following quote from the recent Help Desk Institute (HDI) publication.

  "Before attempting to implement any of the Configuration management activities, the organization must ensure, that the Change Management process has been implemented and operated at a mature level. Without a well-established Change Managament process, the integrity of the CMDB cannot be maintained." Implementing Service and Support Management Processes: A Practical Guide, ISBN: 90-77212-43-4

• Achieving Meaningful Returns on Investment

  The greater the return on investment from the service improvement initiative the more likely management is to be supportive. This return will usually be expressed over a multiple year period and will include project aimed at augmenting key process enablers in order that gains will be sustainable and implemented within the context of the organization's operational capabilities. When determining ROI it is important that the costs of implementing enabling processes be included, or the gains expressed in terms of the ROI indicators will be overstated and unattainable.

• Gaining Momentum - The Importance of Quick Wins

  When discussing the OPM3 maturity modeling as a project management improvement methodology a PMI publication states "Organizations may want to look for Capabilities that are easy to achieve. This consideration can help the organization demonstrate early success and gain valuable momentum to sustain the improvement initiative"^R.

  This is equally relevant with regard to IT service management improvements - it will often be necessary to achieve some quick return on investment in order to sustain management support of the larger service improvement initiative. Most service improvement initiatives should include a mixture of larger, longer projects with bigger ROIs and more immediate, controllable projects with gains than may not be as reliant on the implementation of key enabling processes. often, this means the measures can be implemented quickly, perhaps because they build upon existing strengths, or processes which require tuning to fully realize their potential.

• Stay Within Organizational Capabilities

  CMMI-staged clearly suggests the importance of implementing enabling process capabilities in stages. The staged representation...

  “Provide a proven sequence of improvements, beginning with basic management practices and progressing through a predefined and proven path of successive levels, each serving as a foundation for the next" CMM-Integrated, Version 1.1, p. 2

  CMMI distinguishes key from advanced support processes. The latter (Organizational Environment for Integration, Decision Analysis and Resolution, Causal Analysis and Resolution) require an advanced maturity level (certainly beyond a defined level).

• Leverage Existing Toolsets

  IT departments will often "throw" technology at a problem. This often results in untapped technical potential which can be exploited by modest improvement in process or the exercise of quality control measures to ensure that the data and process achieve the same quality standards as the technology available.

  “All households make good use of just a few basic tools: a hammer, a set of screwdrivers, a pair of pliers. A minor "splurge" of a few dollars can get you a couple of productivity-enhancing gadgets such as a power drill or an electric screwdriver. Unless you are building furniture, however, a US$4,000 lathe will be a waste of money. It is important to understand your existing tool inventory. Ask yourself these questions: Are you using your existing tools to your best advantage? Are you missing basic tools and toolsets but have expensive, complex tools? Are you having problems for which your current toolset can't provide insight? If you answered yes to any of these questions, you probably have the wrong set of tools for the maturity of your organization. Often, it is to your detriment to purchase a sophisticated solution if you do not have the staff or expertise to make full use of the tool. A tool left idle is more damaging to your company than no tool at all.” Nell Cote, How To Choose Application Performance Management Tools, www.EcommerceTimes.com, 02/25/05

Implementation Issues

Project Options