Category: ITIL and ITSM

1. IT cost transparency. Something has still got to give in terms of what IT costs — IT is and will continue to be a sizable expense to the business. The IT organization is spending the business’ money, and so the business wants to know whether it is being spent wisely (and who can blame them). How many IT shops know if they are investing the business’ money wisely outside of projects?
2. Value demonstration. Is IT still just a cost center or has your IT organization been able to translate IT investment into demonstrable business success? I still rather somewhat cheekily say that “if we could demonstrate the business value derived from IT, surely we would be being asked to spend more rather than having to respond to corporately mandated, quick fix, end-of-year budget cuts.”
3. Agility. The speed of business change continues to dictate a rapid response from IT that many struggle with — as a simple example, yesterday my nephew told me of his five-week wait for a laptop at the bank he recently joined. Not only is it speed and flexibility, it is also “agility of mind.” A change in I&O mindset that asks “why not?” rather than “why?”
4. Availability. Nothing new here (again). The business needs high quality, highly available IT (or business) services. The difference is in business expectations and available alternatives. For a number of reasons, the business continues to be less forgiving of IT failure and, again, who can blame them.
5. “Personal hardware.”  End user devices will continue to be a big challenge for IT in 2013. Whether it is the fact that our “internal customers” are unhappy with their “outdated” corporate laptops or the fact that they can’t have corporate iPads or the whole “can of worms” that is BYOD (bring your own device), personal productivity hardware will again be a battleground of business discontent in 2013.
6. Support and customer service. For me, support is one thing and customer service is another; ideally IT delivers both. That it is ultimately about supporting the consumption of IT services by people rather than just supporting the technology that delivers the IT services. And that service-centricity by frontline IT staff is not enough; it needs to be all IT staff. The same is true for customer-centricity.
7. Cloud. As cloud adoption continues, are we looking at cloud as a technical or business solution, or both? Do we know enough about the status quo to make informed decisions about moving IT services to the cloud? Probably not; yet for many, cloud is the answer. But I still can’t help think that we haven’t really taken the time to fully understand the question.
8. Mobility. BYOD comes into play here again, but I think that a bigger issue is at hand — that we are still technology-centric. We all hear talk about MDM (mobile device management) as “THE big issue.” IMO, however, this is old-skool-IT with the device a red herring and of little interest to the customer (unless IT is providing outdated devices). Your customers want (or at least we hope that they continue to want) to access your services any which way they can and need to. Mobility is about people.
9. Compliance. Whether it’s internal or external regulatory compliance (or governance), most of the above will potentially have a negative knock on to compliance whether it be SOX, software compliance, or meeting internal requirements for “transparency and robustness.” With everything going on elsewhere, it is easy for me to imagine degradation in internal control, not reacting to new risks as a minimum.

The first point to make here, is that ITIL is, and will continue to be, an IT Service Management toolkit.

That means that you don’t have to be using ALL of ITIL, ALL of the time – the methodology can be adapted to suit the needs of organisations – the key thing is to put your organisational requirements first, and not follow bureaucracy for the sake of it.

Second, ITIL has been formed on IT Service Management best practice and will continue to evolve to reflect the needs of IT departments the world over.

Public vs Private Clouds:

Well run IT service Management systems have always had to apply different models to different systems – they will continue to evolve, The focus if IT teams will have to move away from operational aspects of infrastructure to managing the diverse environments that public, private and hybrid Cloud environments will bring.

Configuration Management Database:

Anyone who uses ITIL will know the importance of the CMDB – however doesn’t necessarily mean inflexibility. A well implemented CMDB can make things more agile in fact.

No doubt, the way organisations use the configuration management database will need to be tweaked for Cloud – however the message is the same – use ITIL as part of a sensible and flexible IT Service Management infrastructure and you will be able to account for any changes that new technology brings.

 

Some of the problems that ITIL will face with Cloud Computing include:

• Because Cloud and SaaS apps are based on a pay-as-you-go model, they have the potential to operate under the radar of ‘traditional’ IT service management infrastructure – particularly with relation to procurement
• Dealing with Private and Public cloud services will require different approaches. Public clouds are great in terms of their cost savings but cab be less reliable, especially when you look at security, compliance and service level agreements. These problems are not there with Private cloud services – but they don’t come cheap. As a result, many organisations use hybrid services.
• ITIL’s configuration management database (CMDB) – is designed to hold information about  assets and resources that exist in an IT environment – what happens when those resources don’t physically exist any more?!

ITIL implementation is no cakewalk. ITIL impacts your entire organization — your business, your IT department and your in-flight projects. The most common implementation challenges include:

1. Management Commitment

The biggest problem ITIL implementations face is when executive management approve the ITIL program but then fail to follow through with strong sponsorship support.

2. Resistance to ITIL

ITIL represents a broad organizational change that is always resisted. Departments, teams and individuals tend to defend the status quo.

3. Project Culture

ITIL isn’t a project with a completion date. It’s a set of processes that must be continually improved. There are plenty of organizations who “do” ITIL and then move on to something else. This approach always fails.

4. ITIL for the sake of ITIL

Organizations that seek a rubber stamp from ITIL (e.g. ISO 20000 certification). Such organizations see little business value in ITIL and seek to minimize implementation costs at the expense of true ITIL success.

5. Business Acceptance

ITIL isn’t transparent to the business. For example, it may change the way that business submits change requests or opens support tickets.

It’s important that business be a strong supporter of ITIL from the start (program initiation). Otherwise, ITIL may be viewed as bureaucratic nonsense. ITIL implementations are rarely successful without business buy-in.

6. Big Bang

ITIL has numerous processes. Each ITIL process has a large organizational footprint. Full implementation of ITIL is best done in phases. A big bang ITIL implementation has the potential to disrupt IT and business operations.

7. Naive Implementation

Throwing ITIL over the wall and hoping it takes hold.

8. Tools

ITIL isn’t a technology. However, it’s nearly impossible to implement ITIL processes without technology. Technology implementation is often amongst the greatest ITIL challenges.

9. The Moving Target

Many organizations that were in the middle of ITIL V2 implementation were thrown off track by the considerable changes in ITIL V3.

1. You treated it as an implementation.
ITIL is not something you implement, it is not a standard. It is a set of best practices that you can integrate into the unique properties of your IT organization.

2. You hadn’t already evaluated your existing processes.
ITIL isn’t simply going to solve all your problems. There are two key components of any organizational improvement, and that is process improvement and the ability of people to change or adapt to change.

3. You didn’t spend enough time getting people on board.
This could be hit or miss, but it is more likely to miss if you simply sent a team out to make the changes, and did not directly include the people affected by the changes. Work done on bringing people over to the new initiative, especially those passive resistors, early and throughout the process, will pay handsomely in a projects success.

4. You picked areas of ITIL that didn’t demonstrate ROI immediately.
Some areas of IT Service Management are more reactive to change from best practices like ITIL. For Example, looking at Service Desk, Change Management, or Self Service improvements, will tend to have immediate results, and are highly influenced by automation. If you are looking to get buy-in for longer-term projects, start with these areas and then move outward. Once an organization can see impact from ITIL, future projects will be easier to get everyone on board.

5. You approached ITIL and its various components subjectively.
Whatever emotions and previous experiences (failures or successes) you take with you into applying ITIL concepts and best practices will cause pain. Like everything else, look at the big picture, and be as objective as possible.

6. You placed too little importance on your ITSM solution.
Your ITSM solution is the CPU of your IT organization. If it’s bogged down, or unable to change and move at the speed of the new processes, ITIL may not help. Again, take a step back and see how your goals line up with the abilities of your tool. Of course, we’d love for you to take a look at ChangeGear, built with ITIL best practices in mind, out of the box.

7. You focused on ITIL as a goal that has a finish line.
ITIL tends to work best as an iterative process with continuous service improvement. So, in a manner of speaking, you will never be finished with ITIL, that is if you plan on it being a successful part of your IT organizational philosophy.

8. You compartmentalized the benefits to IT and/or technology.
The entire organization, not just IT should see benefits, and thus should understand that changes will be occurring and will likely impact the business as a whole. Besides, with the modern metamorphosis of the IT department, ITIL can fit nicely into the other technology initiatives already happening around the organization.

9. You tried to improve too many areas at once.
There are no rules to adopting ITIL best practices. This is your organization. You can do as little or as much as you want. Stephen’s blog highlights some of the best and most common places to start, which is probably a good idea. Just stick with the idea that boiling the ocean tends to lead to failure, or at least a lot of unhappy beach goers.

10. You ignored the influence of, and impact to, culture.
Your organization is unique. Before implementing anything, take a step back and look at how it approaches change, and how it may be affected by change. Understanding the culture you will be working within, might just change a failure to a success.

Complete ITIL implementation will bring around 40 new roles to organizations but it is not practical to do so even for a big organizations. The reason is that some processes are not best suited for the existing structure, and that the cost of change will perhaps exceed the selective process selection and unnecessary increase the cost of implementation without adding any value.

While larger enterprises boast of a good chunk of ITIL roles manned by dedicated resources, smaller organizations (if they end up implementing processes in service design, transition and operation), might choose to go in for the full array of roles, with resources handling multiple roles concurrently. Having dedicated resources requires deep pockets, and a bottomless pit of budget reserves, which is unusual these days.

ITIL publications do not explicitly talk about people holding either a single role or multiple roles. But the implication is that a person will take over one role, and not multiple ones.

There are three different categories for the combination of role: conflicting roles, roles with synergy and roles which does not care about conflicts or synergy.

In ITIL, if the outcome of one role is influenced negatively by the other, it qualifies as a conflict. Or, if the objective of one role has elements that tend to alter the thinking of the other – now that’s a conflict. 

The combination of two or more roles which ends up benefiting one or multiple processes. A producer, who also directs the movie, is more likely to optimize spending and sweat over all directorial details to ensure box office success. Whether it succeeds or tanks is different topic to discuss another day.

There are a number of role combinations which falls under don’t-cares. They neither conflict, nor add synergy. 

ITIL roles that conflict

Incident and Problem Manager

This is a classic role conflict in ITIL. Many organizations identify the same person to do both the roles without realizing what is at stake.

An incident manager’s objective is to drive toward resolution at the earliest–either through a temporary workaround, or a permanent solution if available. A problem manager is hell-bent on getting to the root of the problem. He’s interested in the source of the problem, and unless and until a permanent solution is not in sight, he doesn’t care about any temporary fixes.

In theory, and in practice, it’s pretty obvious that both the roles require people who are oriented quite differently. Yet it’s a common practice to club these two conflicting roles.

Release Manager and Service Test Manager

A release manager has an objective to release software or implement hardware equipment as per customer requirements/architecture. In PMI methodology, he would be called a project manager, as the activities involved are similar, i.e., initiation, planning, execution, control and closure.

One of the sub-activities of release management is testing the release package before it’s deployed. A service test manager is appointed to oversee the test activities and report on the observations found.

It’s not uncommon to see a release manager being given the responsibilities to manage build, test and deploy activities. I have a problem when a release manager works as a test manager as well.

The test manager’s job profile includes testing the built package, verifying if the functionalities are as per design and whether the release meets customer expectations. Whereas a release manager wants to complete the project on time–and within budget as always.

If the two roles are combined, there is every chance that the test manager’s role can be compromised. Suppose the release is running on a tight schedule, and a minor flaw is identified which may not impact anything directly. A test manager who is also a release manager might overlook it for the benefit of the other role he’s playing.

In all activities, a tester must be a different person. In ITIL, another popular conflict on the same lines is the process manager playing the role of a lead auditor. This should not be allowed, for the organization’s own good.

Process and Service Owner

A process owner owns the process (like incident management), and is responsible for ensuring that it’s fit for purpose intended. A service owner likewise owns the service but is responsible for the delivery.

This conflict is rather indirect. A process owner, who owns the service as well, is adapted involuntarily to the service he owns, and to a certain extent, starts looking at services through the lens of the service he owns.

Being a process owner, his scope extends to other services that he may not own. So, when he tries to apply the process to another service whose genetics are quite different, it may feel like tailoring a suit for Kevin James, and asking Johnny Depp to don it.

 

ITIL roles that synergize

As I mentioned earlier, the combination of two or more synergistic roles benefits the other.

Risk and IT Service Continuity Manager

A risk manager is tasked with identifying, assessing and controlling risks. An IT service continuity manager ensures the service is able to perform at minimum service levels if a disaster happens.

Both the roles are aligned, in the sense that they are proactive, but they also look toward the future, getting ready to minimize the unintended effects.

Each would help the other in contributing with specific intel that helps both the process overall.

Configuration and Knowledge Manager

A configuration manager identifies, records, controls and verifies records of configuration items. A knowledge manager does a similar set of activities with available information, and knowledge.

Knowledge management is relatively new to many organizations, but configuration management has existed for a while. However, a knowledge manager need not re-invent the wheel to plan the management of information and knowledge.

In this case, configuration management can lend a hand, and synergize knowledge management activities for the better.

There is one certain way that leads to fiasco – to start implementation of the entire ITIL framework. It sounds funny, but there are 26 processes and 4 functions in ITIL. To start implementing all (or most) of them… is not at all a good idea.

There are many things you need to consider before deciding which part(s) of ITIL you are going to implement. Here are some generic issues which are very important to consider.

Business Process Management – IT processes have to be aligned with business processes; i.e., IT services have to underpin business services. That means that there is no point in implementing an IT service if the business does not have a need for it. I remember a situation where IT implemented an internal employee portal, which was supposed to integrate all employee-related information and services (e.g., salary data, presence/absence from work, education records and training management, traveling service…etc.), but other departments inside the organization (HR, Finance…) were not properly involved in the project and, consequently, were not motivated to be a part of the service.

Standpoint – It’s very seldom that you are starting from scratch, i.e., that you don’t have any process in place. Maybe they are in chaos, but more than likely you have some processes in place and you need to do something to get them under control, improve them or introduce some additional processes. Before you finish your To-Do list, perform the gap analysis and see how far (or near) to the ITIL recommendations you are. If you have an ITSM tool in place – your “maneuvering space” is usually limited. The reason for that is that tools are customizable to a certain extent (from my experience, level of customization is proportional to the cost of the tool). Don’t forget to consider “pain points” (e.g., those processes which are causing most of the problems, delays, errors…) and “quick-wins” (something that you can implement in a short period of time and show immediate benefit).

Drivers – are you clear on what the drivers are for the implementation? Is it poor customer support emphasized by customer complaints? Or your company is growing and IT (and the services) are gaining in complexity, so you need a “tool” to manage them? Maybe you need better coordination of daily activities in a multi-team environment (and you want to manage the work and not vice-versa)? Whatever the reason is, it’s important that you are clear about it. Namely, it will define your goals, project, resources… etc.

Resources and Management support – when you gain your management’s approval, doors to your resources are open. That’s important because you are, probably, not the only resource in the story. You need some financial resources, other people (either to help you during implementation or as process owners once when you finish), external parties, tools… etc. I had a customer that wanted to consolidate two existing Service Desks and implement several ITIL processes. The idea was excellent, and preparation was done well, but the approach to management was wrong. The implementation project did not take place.

Depending on your organization – think about your issues before you approach management to get approval (e.g., if you are part of an international organization, most probably many things are already pre-defined).

First step: you must create an opinion about the implementation project. Negative feelings about the project will decrease support and acceptance.

Waste of resources – starting in the wrong direction usually causes a loss of money. Take, for example, human resources that you use for implementation – you can always express them in monetary value, particularly for external ones (e.g., consultants that are hired on the project)

Credibility – your results build your credibility in both ways, positive as well as negative. Here, I mean both your credibility inside your organization as well as inside your own team.

It’s very important to start in the right way. You can find a lot of resources about ITIL implementation. But, you are the most critical factor. Why? It’s simple. You know your situation (i.e., motivation and trigger for implementation), your organization, your people, etc. Namely, the ITIL framework is wide and covers many aspects of IT. Therefore, you should find what is most important for you and your organization, and the issues you are trying to solve.

How to start?

Although every situation is its own story, there are a few points that are advisable to most of the implementation projects.

Efficient start of the implementation is essential.

Start smart – You created a list of the processes and functions that need to be implemented, and you start to implement them in sequence according to your own preference. Such implementations usually never end. Take the opposite approach. For example, create a To-do list with the complete scope of the implementation (all processes, i.e., functions). Assign priority to each one. Consider carefully which ones can be combined and implemented together (e.g., if you need to implement both, Change Management (CM) as well as Service Asset and Configuration Management (SACM), there is no point in implementing CM and then few month later SACM). But, be cautious. You can’t expect to be able to implement all (or many) of the processes, i.e., functions in the scope in parallel. Go step by step and combine when it is necessary

Quick wins – these are the goals that can be achieved quickly and “easily.” Detect quick wins and do them first. In such a way you will gain credibility and your project will defend the reasoning for implementation. In this way you will get much more “space” for the rest of the implementation. Pressure will be lower and, since it will be obvious that you deliver results, you won’t be under a magnifying glass. When providing quick wins, it usually happens that you are left to do your work, meaning that you can completely focus on the project. For example, your organization pays penalties because incidents are not resolved in the time defined by Service Level Agreement (SLA). By implementing Incident Management, you will gain control of your incidents and save money.

Project approach –ITIL implementations have all the features of a project (time, resources, goals, deliverables, costs, etc.) and there is no reason not to treat it that way. Quite the contrary, compared to ITIL, Project Management is much “older”; i.e., there are enough reliable project management methodologies that can be your powerful tool to bring the implementation to success.

Control and steer – Independent of scope, ITIL implementation is tricky. It goes deep into operating processes and influences the way people do their jobs, i.e., the way the organization works. Therefore, you have to be very careful and keep your steering wheel firmly in your hands. One of the tools you can use is measurement. Measure before you start the implementation and afterwards. Compare the results and you will know whether you are on the right track. Return on Investment (ROI) is another one. When you succeed in Incident Management implementation and achieve incident resolution within the target time, it will be easy to calculate ROI for that process (direct benefits are savings in penalties that are not paid, an intangible benefit is organization’s reputation in the eye of their customer, etc.).

Keep it Simple and Straightforward

Size of the organization, organization’s culture and setup, management, your own team, complexity of business and processes… there are many parameters that can influence and increase complexity of the implementation. On the other side, those parameters are quite often taken as an excuse.

There is a principle that can be used to explain approach to the ITIL implementation: KISS – Keep It Simple and Straightforward. Business life is complicated already, it shouldn’t get worse and topics which implementation covers should be addressed directly. There is enough know-how about ITIL and implementation. Use that know-how, take what is relevant to you and avoid unnecessary complexity. And, get started.

Step 1: ITIL Project Preparation

Step 2: Definition of the IT Service Structure

Step 3: Selection of ITIL Roles and Role Owners

Step 4: Analysis of As-Is Processes: ITIL-Assessment

Step 5: Definition of the To-Be Process Structure

Step 6: Definition of Process Interfaces

Step 7: Establishing Process Control

Step 8: Designing the Processes in Detail

Step 9: Selection and Implementation of Application Systems

Step 10: ITIL Process Implementation and Training

The IT service management framework for ITIL® is logically divided into five phases based on what a provider offers, and the IT service that the customer enjoys and values. The other four phases in ITIL® are service design, service transition, service operations and continual service improvement.

The first of the five phases is the service strategy. In this phase, the strategy to implement a service into an IT organization is closely tied to the management approach for that service.

Let’s say a cell phone provider wants to introduce a new service, such as high-speed internet. In the service strategy phase the stakeholders develop the strategy for what to introduce, how to launch, where to source, how to meet demands and manage operations.

Overview of the service strategy phase

In the service strategy phase, the service provider and the customer define the terms of what the service entails, how will it be of value to the customer, and what type of customers (age groups, genders, geography, etc.) are likely to opt for the service.

In this phase, the high-level strategy is laid out and the feasible services will pass to the service design phase where the conceptual services would be given definite form, figure and dimensions. A number of conceptual services get filtered through the sieve as well.

With a good strategic advisory team in place, organizations can hope to meet a number of goals. Some common ones for organizations include branding with innovative and customer-focused services, annulling the competition and showing ROI on their IT investments.

Processes in the service strategy phase

To achieve all that I have mentioned under the strategic management, ITIL® has developed a few processes to aid the aims of a service strategy.

Process 1: Service portfolio management

Service portfolio management ensures that the organization has the right set of services to offer to its customers. It also ensures that customers perceive the offered services as valuable so the organization makes a balanced return on investment.

The service portfolio management process involves researching and identifying the services that can be offered to customer. Here, the riders are the return on investment and the risk appetite. Once a list is drawn up, they track how the service performs, how it’s perceived and check whether the service fits into the overall scheme of things. The service portfolio also consists of the services that once existed but have been retired and/or replaced.

The output of the service portfolio management process is the service portfolio itself, which consists of three components:

• Existing services
• Services in pipeline
• Retired services

The existing services consist of all that is being offered to customers, similar to a menu card that you find in a restaurant. Services in pipeline are those services that are under development. At times, it is important that customers are lured in with the services that they can enjoy in the future. For example, a cell phone service provider can claim that they offer 3G internet service, and within the next 6 months the customer can expect to use the 4G service that’s under testing.

Process 2: Financial Management for IT Services

As the name of the process indicates, the financial management for IT services aids in bringing in the investors, and channeling investments to services that have the most potential.

When a new service is to be introduced, or if an existing service needs an upgrade, this process starts by evaluating the financial impact. This usually involves convincing investors secure the funding for the provision of the services.

Other aspects of finances, such as budgeting for a service, accounting for how money was spent and charges for the customer’s use of services, all fall under the financial management process. Balancing income and outflow and forecasting financial requirements are some of the other activities that are performed in this process.

Process 3: Business Relationship Management

You can own top-notch services, but if you can’t keep your customers loyal to you, then the organization might start looking to close down the shop and consider alternatives. Business relationship management is a new introduction to ITIL® which deals with building customers relationships through value proposition and meeting their business needs.

Many case studies over the years have pointed to the conclusion that it costs a lot more to bring in new customers than to keep existing ones. To keep customers, organizations must hear the pulse of the customer; understand how the customer views your organization and the services you offer. The Business relationship management process looks at all these aspects of retaining customers and more.

The business relationship management process specifically focuses on the customer requirements and working within the organization to meet the customer goals. The process keeps tabs on the customer’s perception towards the IT organization and works to keep it positive.

This process does not deal with the customer at an operational level or on an incident basis, but rather on a level where the governance body is seated. There is a sister process in the service design phase called as service level management, which is responsible for interacting with the customer regularly over the performance of its services and making sure service level agreements are adhered to.

Outflow from Service Strategy

The output from service strategy provides direction to all other phases in the ITIL® framework. People in organizations who form service strategy are generally the board members, CXOs and others with a mature head on their shoulders.

The decisions taken by the board and senior management percolate to various nooks and corners of the organization and bears on how the services are run and what the customers can expect. An organization gifted with a strong strategic team is an organization that focuses on the right credentials to go the distance, and win.

 

 

 

 

 

ITIL is a widely accepted approach to IT service management and provides a set of best practices drawn from the public and private sectors internationally. Here’s how to make it work for you.

Short for IT Infrastructure Library, ITIL is an infrastructure library, initially developed in the U.K. ITIL is a widely accepted approach to IT service management and provides a cohesive set of best practices drawn from the public and private sectors internationally. It’s supported by a comprehensive qualifications scheme, accredited training organizations, and implementation and assessment tools.

The management and control of the IT infrastructure is a critical function and improved service delivery and service support processes will increase the efficiency and effectiveness of operational delivery.  The Information Technology Infrastructure Library (ITIL) is a widely accepted industry framework that adopts a process driven approach to developing operationally excellent IT service support and service delivery processes. The benefits of implementing globally consistent, ITIL-based processes include:

• Improved availability, reliability and security of IT services.
• Increased IT project delivery efficiency.
• Reduced TCO of IT infrastructure assets and IT applications.
• Improved resource utilization including decreased levels of rework and elimination of redundant activities.
• Provisioning of services that meet business, customer and user demands, with justifiable costs of service quality.
• More effective and better third-party relationships and contracts

While ITIL process improvement and standardization promises to greatly upgrade service and yield cost savings, success is not guaranteed. There are, in fact, some common misconceptions or myths that could lead an organization astray.

Since the ITIL framework provides only the necessary guidance on process structure, many CIOs are not seeing the improvements they expected — despite heavy investment in ITIL. ITIL deployment should be set within the context of a business or IT change program and as such, is more than a simple set of processes that can be rolled out and uncompromisingly followed. Any IT change program will encompass organizational, process and technology elements.

Here are ten tips CIOs and program directors can use to approach effective ITIL implementation with confidence:

Organization

1.  Approach ITIL implementation as part of the IT-wide strategy, and use it to guide all other strategic initiatives.
ITIL process implementation has significant IT-wide impacts; it is not an isolated initiative. To avoid both resource and programming constraints, implementation must be aligned with other global and regional programs, IT initiatives and sourcing or supplier initiatives.  A portfolio management approach should be taken to understand the alignment and priorities of all initiatives in addition to the overall benefits to the organization.

2.  Consider the post-ITIL organization before completing the process design.
Introducing ITIL-based processes generates requirements for new functions and roles, which could impact the current service management structure. Prior to completing process design, understand the roles and functions required to support the processes; giving specific consideration to the supplier/internal resource split.  Consideration must also be given to the governance structure needed to guide and support the new IT organization. Establishing a transformation program ensures that the structure from which to hang ITIL is secured and operational prior to process implementation.

3.  Engage, engage, engage. Continuous communication is required at all levels of the organization.
Implementing ITIL impacts the full spectrum of the organization’s employees. Because of this, it is critical to understand the impact at each level within the organization and the value each brings to the program. Subsequently, engagement, communications and training are absolutely key to success; from the initial engagement of senior stakeholders to the manager-level ITIL training of new global process owners.

4.  Set realistic expectations about benefits realization and establish a baseline from which to monitor improvements.
Change within any organization takes time to be accepted and implementing ITIL is no different. Implementation of ITIL focuses on improving customer service and as the processes mature the subsequent ROI will be recognized.

To determine the end result, focus the strategy and focus communications on improving service quality and establishing an early baseline of key performance indicators (KPIs) from which to monitor improvements. The chosen KPIs and their associated benefits should be business-focused and clearly understood so that effort is not wasted on measuring and interpreting superfluous data.

5.  Engage existing suppliers early.
Existing suppliers and any subsequent SLAs will be affected by the implementation of ITIL. The strategy for handling third-party engagement and establishing a robust communications plan must be clearly defined, with priorities focused on the desired supplier landscape.

Early engagement with procurement and legal departments will help to support and address the ripple effect that occurs right through to existing contracts and SLAs upon implementing the new processes. An end-to-end SLA will also be ultimately required to support the operation of the new processes.

Process

6.  Identify and deliver the quick wins.
It’s “old” advice, but it remains fundamentally important to ensure that the organization achieves, communicates (and celebrates) early successes. Such an approach buys time for the process implementation and will help to gain the much-needed stakeholder engagement across the organization. Experience suggests that failure to achieve these successes will typically double the resistance to the change and halve the support within six months.

7.  Maximum benefit can be only achieved if the impact each process has on another is understood.
The ITIL framework is comprised of ten service management processes and one service management function. Every ITIL process supports, interfaces and integrates with at least one other process.

For effective development and deployment the relationship, impact and interdependencies across the ITIL framework must be clearly defined and understood. The close integration and understanding of the processes allows for the continual flow of up-to-date, critical and accurate information that in turn enables management to drill down and identify target areas for service improvement.

8. Prioritize process selection based on current maturity; don’t bite off more than you can chew.
It’s important to take a holistic view to ITIL implementation, however. It’s not imperative to implement all processes concurrently in order to realize operational improvements and a significant ROI.  Implementation of individual processes or the prescribed combination of processes can deliver the desired operational improvements. Processes should be selected based on the benefits sought by the organization and the ones that drive the most business value.

9.  Use success as a springboard for further improvement.
Implementing ITIL is a strategic commitment and will take many months to fully implement. During this time many different parts of the IT organization will be required to change.

In this sort of environment, it’s important to also implement a program of continuous improvement (e.g. a “plan, do, check, react” cycle). First this will ensure that improvement is actually delivered as expected and, second, it will help to build further improvement rather than assuming the job is done and risk slipping back in to old behaviors.

Technology

10. Combine process and tool activities from day one as part of a single solution approach.
Implementing a service management tool will support the streamlined processes, automate tasks and manage and distribute information. Knowledge management (e.g., the re-use and integration of information) is a critical component of the service management tool. Integrating data control processes with the tool will ensure that information is current and continues to add value to the service management processes.

Implementing ITIL is not just about evaluating and revising processes, it’s about change: changing the way people work and are rewarded; changing technology platforms; and changing behaviors across an entire organization.

 

Ref: www.webopedia.com