Roadmap for Successful ITIL Service Support Implementation

Once you have decided to implement ITIL service support processes—namely Change Management, Incident Management, and Problem Management—what do you do? For the best results, start with a small scope and build upon each success—begin with the areas that have the most urgent need for improvement and then go from there.

It often helps to examine how another company has had success with implementing processes. Let's explore the challenges faced by a large multinational organization that are common across many organizations. First consider the following background information about the company that I'll call Generic Manufacturing Company:

  • Multinational organization with more than 100,000 employees
  • Manufacturing industry
  • Offices and facilities in 20 countries
  • Multiple service and product business unit organizations
  • In the process of implementing a new enterprise IT operating environment
  • Historically has experienced major problems with support services; each business unit had its own way of doing things, making it a challenge for the individual area IT environments to communicate with each other
  • Wants to standardize hardware, software, and IT tools throughout the organization to allow better communication and coordination
  • Wants to centralize Change Management, Problem Management, and Incident Management processes to ensure consistent practices are followed

There were processes in place but each business unit had their own unique way of getting their jobs accomplished. There were still old desktop computers and servers being utilized. There was a centralized Help desk, but the IT areas did not use it. In fact, the IT area told their applications and systems customers to contact the IT staff directly if the customers needed help. The only time the Help desk was called was basically for password resets. Okay, so where to start? This sounds like a job for ITIL!

Getting Ready

Organizations of any size can benefit from centralizing IT processes as much as possible. The IT Service Support processes that tend to impact all organizations regardless of size are Change Management, Problem Management, and Incident Management.

The Generic Manufacturing Company can benefit from effective centralization of its many IT processes. They determine they can probably benefit by clearly establishing one process and one area to be ultimately responsible for change, problem, and incident handling processes.

Consider all the possibilities for where and when to begin. This is the initial stage of ITIL implementation. It is important to get the different areas, currently mistrustful and at odds with each other, to understand the improvements that can be made through cooperative implementation of ITIL. The business management was all for implementing a process to make IT management go more smoothly, and in fact improve upon business results. The Generic Manufacturing Company developed the ITIL process implementation roadmap that Figure 5.1 shows. All organizations can take this roadmap and modify it to meet their own enterprise's unique environments.

Figure 5.1: ITIL process implementation roadmap.

It is not practical to implement all aspects of ITIL Service Support at one time! Not all the required process inputs will be available when the first process is initiated. There will be information quality issues where key process input areas are absent. It will be very difficult, and often impossible, to determine the impact of a change on business services availability, capacity, and continuity when supporting processes do not exist. This increases the possibility of problems occurring when deploying the processes.

Be sure that representatives from each of the ITIL Service Support process teams are included in the CAB. These representatives can then be made aware of the impact of the changes on the user community.

Be sure to include information security within your processes. Information security is a critical function within the IT organization. It is critical to include information security in the authorization of all network and information system changes. Doing so ensures that security is accounted for in the development of the change. Information security should also be part of the CAB.

Realizing Improvements Are Needed

The Generic Manufacturing Company performed an assessment to clearly identify and document the problems. Three major trouble areas were discovered:

  • The multiple areas of the company were each following different processes to move applications from test to pilot to production environments. One of the areas didn't even have a pilot (end-user quality assurance) environment and moved the applications directly from the test environment to the production environment!
  • IT problems were handled very differently throughout the enterprise. A couple of the business unit applications support areas told their end users to call them directly to handle problems. Other business units directed end users to call the corporate Help desk. Documentation for the problems was not consistent, was not centralized, and often was not documented. The same problems seemed to occur over and over again.
  • IT-related incidents were recurring with increasing frequency. Many times the same incident occurred in different parts of the enterprise, and different teams handled the same incident differently. The teams handling the incidents did not communicate with each other about what worked well and what didn't work for incident resolution.

Generic Manufacturing Company IT leaders realized these problems were likely having major negative impact on the business. They wanted to look into specifically how much impact, and then determine what could be done to improve upon the situations. These trouble areas are common to most organizations.

Get Executive Support

Executive management must clearly support the implementation of ITIL processes throughout the enterprise. Without this support, the people who must be involved with implementing the necessary changes will not do so and will continue with business as usual. It is human nature to continue doing things as they are currently done; it is not as much work out of an already perceived to be too busy day to continue with the status quo. Unless executive leaders tell personnel that changes must be made, there will not be full cooperation. Lack of cooperation here will lessen effectiveness of ITIL implementation and could result in an unsuccessful project.

The Generic Manufacturing Company CIO explained the three major problems to the corporate executives. The explanation described the ITIL Service Support processes and how they could be good ways to improve or eliminate the problems. The IT staff asked for, and got, executive support to do a project to determine the extent of the problems throughout the enterprise, and then to determine what specifically should be done to address the problems.

Choose Team Members

Another key component for success is obtaining the qualified personnel to perform the implementation and ongoing tasks necessary within the ITIL Service Support processes. There will be a need for some full time employees (FTEs), but there will also be the need to add responsibilities to existing positions. Even with the strong and visible support of executive business leaders, buy-in from all stakeholders, the establishment of the CMDB, the creation of a good process definition, and integration and automation of the processes throughout the enterprise, success will not be accomplished if you do not have personnel performing the necessary activities.

You must also ensure that your internal customers will be actively involved in the ITIL process development, implementation, and maintenance. This will make certain your customers have tested and accepted the components of the ITIL process, ensuring the requirements have been met. Be sure to obtain feedback to guarantee the customer needs are considered and included within the planning process. There will be similar team members for each of the ITIL processes. The key roles for the ITIL Service Support processes include:

  • Change Manager—This position will have authority and accountability to define, validate, and maintain the Change Management process. This position is responsible for oversight of Change Management process monitoring, measuring, reporting, and operations.
  • Support Center Manager—This position should help determine how the Incident Management process can provide data relating to the other processes. This is the central point of contact for customers, so this position should ensure that the information identified and classified within the Support Center will be valuable and useful to other parts of the organization.
  • Project Manager—This position is responsible for assisting with the initiation of the project, creating the project plan, executing the plan, and then closing the project. The Project Manager is also responsible for providing status updates for each project milestone.
  • Human Resources (HR)—A representative from HR should create job descriptions for new positions related to the Change Management process. HR can also identify potential internal candidates for the new positions.
  • Trainer—A position needs to exist to ensure training will be provided to targeted positions as well as providing awareness communications to the entire enterprise.
  • Purchasing Department—Someone from the purchasing department should be enlisted to negotiate the best prices and services possible from the vendors you will use to implement and support the Change Management process.
  • Applications Development—Enlist the experts from your applications development areas to help choose Change Management process software. They can also identify the hardware requirements for the software. They should also discuss the products being considered with the Support Center staff to make sure the integration with the other ITIL processes are facilitated.
  • Business Unit Managers or Representatives—Your internal customers must be represented within the Change Management process planning, implementation, and ongoing management to ensure the needs of the business are appropriately considered. This person must have in-depth knowledge of how the business works and must be able to translate and communicate the process issues and requirements into business terms for the personnel within the business unit.
  • Support Center Staff—These personnel will typically not participate in the implementation of the Change Management process but will provide service delivery through their established communications channels, such as email, telephone, intranet site, and so on. The Support Center owns the Incident Management process. This area is the point of contact for customers and must be able to provide them with good advice and guidance. The Support Center staff must also obtain feedback regarding the problems reported through the Problem Management process. They should also create regular, typically daily, reports of the top-ten most common problems reported each day to allow for addressing reported problems most effectively and lessening the effect of ongoing, repeat problems.
  • Incident Team Members—These personnel will work with the application providers to create Service Level Agreements (SLAs) and Operating Level Agreements. They also will manage the Support Center knowledge base and management reporting.

Create Mission Statements

To achieve success, organizations must first define success. It is necessary to create a mission statement for each of the ITIL processes you are implementing. The following example shows the mission statement Generic Manufacturing Company created. You can use this as an example on which to base your own mission statements. You will need to modify it to fit your own organization's style of writing, along with your industry and environment.

Generic Manufacturing Company Change Management Mission Statement

The mission of the Generic Manufacturing Company Change Management process is to enable technical changes within the production environment in the most efficient and consistent way possible to support business objects and with the least amount of disruptions resulting from making IT changes. The purpose of the Change Management process is to ensure changes made within the IT environments are consistently tracked, reviewed, tested, communicated, implemented, and validated to reduce the negative impacts to the business as much as possible.

Perform a Baseline Assessment

It is important to clearly identify and document the scope for which your ITIL process will apply. For example, if you are going to start the implementation of ITIL by implementing the Change Management process for a specific application, clearly document the application, the persons and positions responsible for each of the changes involved with that particular application, the types of changes possible for that application, and so on.

You must have a complete CMDB in place to be able to successfully manage changes to the infrastructure scope that you have established. An incomplete CMDB will result in Change Management mistakes because of missing or incorrect information.

The Generic Manufacturing Company determined the scope for the ITIL processes they will first implement will be for Change Management, Problem Management, and Incident Management related to the email system used throughout the enterprise.

Identify Stakeholders

You must understand who the stakeholders are; they are necessary to understand how to improve upon the processes as well as determine the success for how the processes were implemented. Define, identify, and map the stakeholders for each of the ITIL processes you are implmenting. Identify the specific needs for each of the types of stakeholders you've identified. This information will be used in assessing the success of the ITIL process for the corresponding stakeholders.

The Generic Manufacturing Company identified the following stakeholders for the email system:

  • Information Technology
  • Information Security
  • Human Resources
  • Legal
  • Management
  • Email Process Owners
  • Email Users

These are similar to the stakeholder other organizations will have for the email system.

Determine Current Situation

Organizations must determine the specific needs for change; the need to improve upon the ways IT processes are currently being performed. This need must be documented to validate to the stakeholders why change is necessary.

As a generic example, if your organization has $1000 per hour revenue coming in every hour of every day each week, and your changes typically cost you 5 hours of lost revenue, that calculates to $5000 of lost revenue per week or $260,000 of lost revenue as a result of changes. Making your Change Management process more efficient and effective could save you many hours of time that computes to many thousands of dollars of additional revenue. To demonstrate this, you will need to keep track of some critical measurements.

Here are some key measurements to make when implementing the Change Management process:

  • How many changes occur within the scope you've identified each month?
  • How must time does it take to implement the changes?
  • How many incidents and outages occur as a result of the changes?
  • How many changes are backed out each month?

The Generic Manufacturing Company identified the following for their email system:

  • Even though the same type of email system was being used throughout the enterprise, Lotus Notes, there were four different email servers being separately maintained by different business units, each located in a different country from the others.
  • Upgrades and patches were applied to each of the four email servers as determined by each maintenance team. This resulted in having different versions of Lotus Notes running on the four servers.
  • End users reported their email problems to many different areas; sometimes to the IT staff administering one of the servers, sometimes to the central Help desk, sometimes to the Information Security area, and sometimes to their own managers.
  • End users also report email incidents, such as spam or phishing messages, to many different areas.
  • A review of each mail server revealed that each server was unavailable because of changes, problems, or incidents anywhere from 1 hour to 8 hours per work week.

Identify Trouble Spots

Where are the trouble spots within your current processes? You must identify the activities and components within your current processes in order to ensure not only that you do not recreate them, but more importantly that you resolve the trouble spots with your implementation. There are many different tools, automated and manual, you can use for identifying your trouble spots— flowcharts, Pareto charts, and fishbone diagrams, just to name a few.

A flowchart is a schematic representation, using well-defined symbols, of an algorithm or a process. A flowchart can be used to identify the flow or sequence of events within a process or service. A Pareto chart, named after Vilfredo Pareto, is a special type of bar chart where the values plotted are arranged in descending order. A Pareto chart can focus efforts on the problems that have the greatest potential for improvement by illustrating their relative frequency or size within a bar graph. A fishbone diagram, also called a "cause and effect" diagram, and an "Ishikawa" diagram after the creator, shows the causes of a certain event. A fishbone diagram can allow team members to identify and graphically display all the possible causes related to a problem or condition to help determine the root causes.

The Generic Manufacturing Company ITIL implementation team decided they would use fishbone diagrams to identify where their trouble spots were for their email system Change Management, Problem Management, and Incident Management processes. Figure 5.2 shows the diagram they created to show the trouble spots within their email system Problem Management process. This provides an example of how you could use a fishbone diagram to help identify the trouble spots when you are planning for your ITIL Service Support processes.

Figure 5.2: An example fishbone diagram for identifying trouble spots.

Perform Benchmarks

After you've identified the problem areas and the need for improvements, you can establish a benchmark. Why create a benchmark? Simple: to be able to determine how much you've improved your process following implementation and to help to continue process improvement. If you do not measure where your organization is at (your benchmark), you will not be able to clearly show how much change has occurred as a result of implementing the ITIL processes. ITIL has a process maturity framework (PMF) that organizations can used to measure, or benchmark, the process within your organization and then to subsequently provide the context for measuring the maturity of the process as time goes on.

The PMF assumes that a Quality Management System (QMS) is in place and that there is a goal to improve one or more aspects of the process' effectiveness, efficiency, economy, or equity. A few of the QMS models ITIL uses include those by Deming, Juran, Baldridge, and Crosby.

Table 5.1 shows the five levels within the ITIL PMF.






Little to no documentation or assigned responsibilities for the process.



The process is documented but there are limited operational processes in place; it is not viewed as having significant importance.



The process is documented and has an owner, objectives, and allocated resources; however, acceptance throughout IT may not exist.



The process is well-documented and implemented throughout all the business units and IT. The process interfaces with other processes.



There is seamless integration of the process throughout IT and business areas. The process has become institutionalized as part of everyday activity.

Table 5.1: The ITIL PMF levels.

The Generic Manufacturing Company's assessment clearly and quickly shows that they are at Level 1 within the PMF.


When you have the trouble spots documented and the benchmark complete, it is time to formally document the plan to address the issues from your findings.

Document the Business Case

The single biggest factor in successfully implementing ITIL Service Support processes will likely be overcoming resistance to change. To overcome the challenge, partner with all your stakeholders to gain their buy-in for the changes as well as using their input for creating the processes you are implementing. Use the information from your assessment and benchmark to build your business case.

As a detailed investment proposal, include within your business case a detailed analysis of all the costs, benefits, and risks associated with the proposed investment of implementing Change Management, Incident Management, and Problem Management. Put the investment decision into the context of strategic business goals. Position the business objectives and goals with the options involved with each of the ITIL processes that impact the decision makers. Use one of the many management tools, automated or manual, to help you demonstrate the improvements that the business can realize by implementing the ITIL processes.

The Generic Manufacturing Company created their report by linking the current situation with the business goals for revenue, and showed how much money they were losing by the time lost from downtime and employee time taken to respond to poorly executed changes, along with inconsistent handling of incidents and ongoing problems. They used Pareto charts to demonstrate their current situations and focused upon the problems and the alternatives that are projected to have the most positive impact upon the business. Figure 5.3 shows the Pareto chart for their problems, current and projected, following Problem Management process implementation. Use this example to inspire your plans to make the business case.

Figure 5.3: Example Pareto chart for Problem Management process implementation.

Set Goals

You must establish documented goals to be able to know whether you are successful in your efforts. Clearly define the goals for your specific organization for implementing ITIL Service Support processes. The following example highlights the goals defined by the Generic Manufacturing Company.

The Generic Manufacturing Company's Goals for Implementing ITIL Service Support Processes

The goal for implementing a formal Incident Management process within the Generic Manufacturing Company is to restore normal service operation as quickly as possible, using consistent practices, and to minimize the negative impact on business operations to ensure the best possible quality and availability of IT service levels as defined within the IT SLA.

The goal for implementing a formal Problem Management process is to minimize the negative impacts of problems and the resulting incidents on the business. The Problem Management process will maximize IT services by correcting problems and preventing recurrences.

The goal for implementing a formal Change Management process is to ensure that standardized and consistent methods and procedures are used to efficiently and promptly handle all IT changes to minimize the impact of change-related problems upon IT service quality, thus improving the day-to-day operations of the organization.

Use the Generic Manufacturing Company Service Support goals as a basis for creating your own customized goals. Communicate the goals within your awareness messages.

Create the Implementation Plan

Carefully develop the implementation plan. Too many organizations spend too little time planning implementations, and then end up spending ten or twenty more times doing the actual implementation than they would have spent if they had just invested more planning time up front. Think through the steps necessary for your own organization. Each business will be different. The Generic Manufacturing Company created detailed implementation plans for their ITIL Service Support processes. Table 5.2 shows a sample from their Incident Management process implementation.



Start Date

Due Date




Identify areas impacted by the Incident Management process


Identify linkages to other processes




Identify existing Incident Management roles


Update roles and responsibilities


Identify personnel to fill roles and assume responsibilities


Identify CAB members


Identify project team roles


Awareness and Training


Identify groups that need targeted training


Identify awareness communications necessary


Decide whether to create training content or bring in from outside


Create awareness communications


Create timeline for sending awareness communications


Identify dates for providing training


Send awareness communications


Deliver training

Table 5.2: Sample from an Incident Management process implementation plan.

Use this plan sample as an example upon which to create your own, customized plan for your business. Remember, this is just a sample; yours will need to be more detailed.

Create Policies

You must document the high-level plans to describe the goals for your organization with regard to the ITIL processes. This documentation is critical for describing management's decisions regarding their commitment, direction, and planned course of action. Create policies for each of the ITIL Service Management processes you decide to implement. The following list shows some of the Change Management policies created by the Generic Manufacturing Company:

  • All changes within the enterprise email systems must follow the established and documented Change Management procedure.
  • Each submitted change must have a detailed script describing the change. The Change Management Project Manager is responsible for reviewing the scripts and approving change requests before the change can be scheduled. Following change request approval, any deviation from the pre-approved script requires Change Management approval.
  • Each change request must include the following information:
  • Activity description
  • Details of change justification
  • Possible impacts to the customer and other production systems
  • Scheduled start and end times
  • Necessary resources
  • Each approved change request must have a documented fallback option.
  • Any vendor contracted to do changes must do the work onsite to enable appropriate oversight of the activities.

Use these Change Management policies as examples to help you get started with your own organization's policy development.

Identify Responsibilities

You will need to assign responsibilities within each of the ITIIL Service Support processes. Most, if not all, of the people filling these roles will be the same as the implementation team members within the corresponding defined roles. However, these responsibilities are different in that, as opposed to implementation activities, these roles will be responsible for ongoing Service Support activities. These are the ITIL Service Support responsibilities the Generic Manufacturing Company defined:

  • 1st Level Support—Register and classify incident report and perform immediate actions and keep users informed about the situation status at specified intervals. If 1st Level Support cannot resolve the situation, it will be transferred to the appropriate 2nd Level Technical Support Group.
  • 2nd Level Support—Take over situations that cannot be solved immediately by 1st Level Support. If necessary, request external support, such as from software or hardware manufacturers. If the situation cannot be resolved, the 2nd Level Support passes the situation on to Problem Management.
  • 3rd Level Support—Resources within the hardware or software manufacturers whose services are requested by 2nd Level Support.
  • Incident Manager—Responsible for the effective implementation of the Service Desk and Incident Management process. Carries out reporting procedures. The first point of contact for incidents.
  • Problem Manager—Researches the root causes of problems and incidents. If possible, makes workarounds to the Incident Management team. Develops final solutions for Known Errors.
  • Change Manager—Authorizes and documents all IT infrastructure and configuration item changes. Determines and communicates the sequence of individual change stages. Involves the CAB when necessary.
  • Release Manager—Responsible for consistently and effectively implementing changes to the IT infrastructure. Plans, monitors, and implements changes in coordination with Change Management.
  • Configuration Manager—Prepares and makes available to the Service Management teams the necessary information about the IT infrastructure and services. Maintains the configuration items and related documentation for the components of the IT infrastructure. Documents changes and checks the updated information regularly. Automates the CMDB update process as much as possible.

Build upon these to fit your organization's requirements and needs.


When the mission statements have been clearly articulated, they must be effectively be

communicated throughout the enterprise. If you do not make your personnel aware of the Service Support processes, they will not follow the processes and/or will not know what the processes require.

The implementation plan and the purpose of each process must be clearly and effectively communicated to each of the key stakeholders. Ask for feedback to ensure that the needs from each of their areas are adequately incorporated into the process as well as to obtain their ongoing support.

Train Personnel

Success cannot be accomplished with a group of implementation folks who have no knowledge about what must be done for each of the ITIL processes. Training the team members for each of your processes is yet another key to success for your process implementation. There must be a clear understanding of the goals for each of the processes. You can provide the team members with this knowledge through a wide variety of methods—assigned reading, classroom training, sending them to industry meetings, taking computer based training (CBT), or bringing in an outside trainer who is an expert in the ITIL process.

When implementing ITIL, it is also a good idea to have at least the leader for each of the ITIL processes invest the time necessary to attain ITIL Foundation Level Certification as well as practitioner level certification in their specific ITIL process.

Implement the Plan

At this point, you should have a very clearly documented, detailed implementation plan. Provide enough time between the development and implementation phase to allow for one of Murphy's Law's—"everything will take twice as long as anticipated"—and to allow for training to effectively occur. Make sure all stakeholders will be provided with advance notice of the upcoming changes. Be sure to clearly communicate to them how they will or may be affected by the changes.

Use a phased rollout approach to avoid a "big bang" type of situation. Small changes are difficult enough for personnel to deal with. If you try to throw many changes at them at once, you are setting yourself up for failure at best and disaster at worst.

Use Tools to Manage Change

It is important that any tools you choose to implement the ITIL processes actually follow or support the ITIL philosophy. Keep the following in mind when choosing your ITIL Service Support tools:

  • Be sure to include the people who will be using the tools for different activities involved with the processes when identifying tool requirements and testing the tools.
  • If you are replacing old tools with new ones, remember that there may be more users for the tools than when you did not have the processes in place. Take into consideration the impact the considered tools will have upon the network and supporting infrastructures. Be sure to obtain enough licenses to cover all possible users.
  • Start defining the requirements you have for supporting tools early in the Service Support planning processes; don't wait until you are planning to implement the processes.
  • Assign a ranking or level of importance to each of the tool requirements you identify.
  • Be sure to evaluate the tool in terms of how well it will meet your defined goals and requirements.
  • Look for tools that are customizable and consider how much effort and cost is involved with that customization.
  • Take into consideration the amount of training and expertise the possible tools will require. Will you be able to obtain that expertise in-house or will you need to go outside your enterprise?
  • Be sure to test the potential tools thoroughly. Clearly define scenarios and choose testers from throughout your stakeholders to ensure you consider the perspective of all the ultimate tool users.

Be sure to choose tools that will offer seamless integration with the other IT tools throughout the enterprise to reduce integration risks.


Chapter 2 and 3 provided key performance indicators (KPIs) to use to measure the success of Change Management, Problem Management, and Incident Management success. Be sure to use them! You must also measure the success of your implementation activities as you go along. Tracking key measurements will help to ensure optimization of your IT investments and will be used to validate to your customers the effectiveness of the processes.

Review Status

Carefully track the status for each of the activities involved with each of the Service Support processes. You first need to know what your current state is for each of the processes you are implementing; your benchmark values. You then need to track how much time the implementation tasks consuming. Once implementation is complete, you need to determine how much time the changes take. How much time does responding to incidents take? How much time does resolving problems take? Be sure to carefully document all these status metrics to not only be able to see your progress but also enable you to answer executive management questions regarding your implementation progress.

Measure Goals

Look at the goals you documented during project planning. How close are you to meeting those goals? Document the goals that have been achieved, along with how close you are to meeting the goals that you have not yet met.

Measure Changes

Document the changes that have occurred not only within IT but also within the entire enterprise as a result of implementing the ITIL Service Support processes. Some of these changes may include:

  • Reduced IT costs
  • Greater business process productivity
  • Improved communications
  • Increased IT reliability

It is important to document the changes not only to ensure that improvements can continually be made within the processes but also to provide documentation to validate the value of the processes within the organization. Many organizations have a tendency to abandon processes once improvements have been made. Your business leaders must understand through your wellwritten documentation that the processes must be preserved, and improved upon as necessary, in order to keep those noticeable and measured improvements in place.

It is also important to be realistic in your efforts. You should not expect to become ITIL certified compliant right away; maybe even never. However, what you should expect with successful implementation is for documented and noticeably improved processes, validated through your measurements.

Document Problems and Vulnerabilities

No ITIL Service Support implementation will occur without snags. And there are always vulnerabilities within the enterprise that will put certain portions of the processes at risk. It is important to identify and document these problems and vulnerabilities so that you can most effectively address them.

Some of the common problems and vulnerabilities experienced by organizations include:

  • Lack of strong and visible commitment from executive management
  • Shortage of resources needed for implementation of one or more of the processes
  • Shortage of resources needed for ongoing maintenance of one or more of the processes
  • Lack of personnel and/or implementation team awareness and understanding of the processes and how they apply to their respective job responsibilities
  • Customer service levels or the processes not clearly defined or inadequately defined
  • Poor integration with other processes
  • Personnel resistance to change
  • Workarounds are not effectively or consistently shared with other support staff
  • Change updates are not communicated
  • Lack of established customer service levels
  • Poor or non-existent tools to support the Service Support processes

Plan for Ongoing Management

As I stated earlier, implementing ITIL Service Support processes is not a one-time activity. To keep the processes effective, organizations need to develop and consistently follow plans for ongoing management and operations activities. These activities can be simplified and made more efficient through automation. The following are some examples for how ongoing management and activities can be automated:

  • Automated auditing tools can be used to compare the documented infrastructure with what the infrastructure actually looks like.
  • Change detection tools can be used to identify changes within the infrastructure and compare them with the approved changes documented within the Change Management database.
  • Detection tools can alert IT staff of intrusions and possible threats and vulnerabilities.
  • Incident tracking software can be used to identify incidents related to specific changes. This will make it easier to report separately from other incidents and will enable incident trends and summary reports to be more easily created.
  • IT service monitoring can show the service impact resulting from changes, incidents, and problems.
  • Network search tools can be used to identify all the devices throughout the enterprise. Some are especially helpful by being able to identify software versions and hardware configurations.
  • Report automation software can standardize, quicken, and make the reporting process and tasks easier.
  • Self-service tools can allow end users to perform ITIL Service Support activities themselves, without involving other personnel, which will allow the other personnel to continue with their other job responsibilities.
  • System infrastructure monitors can be used to monitor device availability during planned outages, changes, incident response, and problem resolution.


IT services are an integral part of all business processes within most organizations. ITIL provides a collection of best practices for performing effective Service Support processes. All ITIL Service Support processes are linked and, theoretically, are dependent upon each other. However, to be most successful with ITIL implementation, organizations must first identify where their most pressing problems exist within the enterprise, then establish a manageable scope for initially introducing and implementing the Service Support processes into the enterprise. The likely processes for most organizations to implement beneficially will be for Change Management, Problem Management, and Incident Management.

Implementation of the chosen ITIL processes within the chosen scope must be strongly and clearly supported by executive management. The implementation plan must be carefully and thoroughly developed. Mistakes within the implementation plan will not only result in a loss of investment cost and personnel time but also likely result in pushback of further implementation of the processes from the stakeholders, and even damage the business disruption of services.

Planning and providing a coordinated approach to IT Service Support design, implementation, and maintenance, otherwise referenced as application life cycle support, will help to ensure IT operations areas deliver services designed to meet business requirements. Coordinating input from the stakeholder and business unit areas will allow the IT organization to better meet service-level requirements and choose new technologies to re-engineer business processes, resulting in greater effectiveness, more efficiency, and positive business impact.