This three day course provides the groundwork for the ITIL® Foundation certificate in IT Service Management. Certification validates that the student has gained the knowledge of the ITIL® terms, structure and basic concepts and has comprehended the core principles of ITIL® best practices.

Course Objectives

Includes all the processes, terms and concepts from ITIL® V2 and V3 with a focus on the functions and processes in each stage of the Service Lifecycle. At the end of the course the student will be able to understand:

• Service Management as a practice
• The Service Lifecycle stages
• The key principles and models of IT Service Management
• Key terms and definitions
• How the Service Management process contributes to the Services Lifecycle
• The role, objectives and organizational structures of functional areas
• The relationships of the processes

Modules

• Service Strategy
• Service Design
• Service Transition
• Service Operations
• Continual Service Improvement

Course Includes

• 3 days in-class consultant-led instruction
• Course Manual, ITIL® Reference Handbook, mock exam
• 1-hour proctored ITIL® Foundations Certification exam
• 30 Days complimentary access to B Wyze ITIL Lite on-line eLearning ITIL® primer

Location:

B Wyze
20 Valleywood Drive
Suite 100
Markham, ON
L3R 6G1

My conversation regarding why ITIL implementations fail continues with Cindy Allingham, Sr. Consultant…

 Cindy:  In recent years, many organizations bought the proposition that ITIL process implementation would solve most IT problems. They realized that proper assessment, expert process design, and organized implementation projects were necessary in order to address the shortcomings evident in IT. Along with these efforts came boosts in staffing of ITIL process functions, and a corresponding boost in functions related to gathering metrics to measure and prove performance. IT leaders promised their business counterparts that ITIL spending would result in visible IT performance improvements, and possibly even cost reductions.

Why haven’t ITIL implementations realized their lofty goals?  ITIL processes, like many processes shaped by high-level guidelines, lend themselves to continuous improvement. That is a good thing and a bad thing. There is always room for improvement, of course, but there is a danger in getting caught up in the improvements and losing sight of the actual operation. I call that ITIL Overload; it occurs when more effort is expended on the process than on the results.

How can we identify ITIL Overload?  Here are some symptoms:

Cindy:  Significantly more IT resources are devoted to ITIL process than basic operational support

IT organizations may have thought that they would be able to temporarily expand to implement ITIL processes, and then shrink down again. This is not realistic. Operations staff have full workloads maintaining and supporting their technology. They can be trained to follow different processes to an extent, but they cannot absorb additional responsibilities assessing, designing, implementing and maintaining processes. ITIL processes will solve a lot of problems but require additional resources with unique skills. These will be permanent requirements. Companies often try to skimp on these, or they eliminate operational positions in favour of process resources. Additional process never reduces workload. Look closely at whether there is too much process.

MJ:  Wouldn’t problem management, done correctly, significantly reduce the volume of incidents and therefore reduce workload?

Cindy:  A healthy and well-designed Problem Management process should reduce the number of recurring incidents. However, since you add both process and a new function (Problem Management) you aren’t actually reducing workload.  You will definitely improve the quality of error-handling, but you will require additional resources to handle the added process and operational activities.

MJ:  You’re right!  Even if one problem is resolved, it’s not a discrete cost saving:

i.e. Savings of Resolved Problem – Cost of Process Development – Cost of Problem Manager – Additional ramp-up costs = Investment rather than Discrete cost saving at the time that the problem is resolved and the incidents that were associated with the problems are eliminated.  That said, once IT is saved from firefighting these incidents, it will allow them to focus on eliminating more problems.  Once a certain amount of problems are eliminated from the environment, IT can stop firefighting and start…drumroll please…strategically supporting the business!

Cindy:  Lack of data for various functions (i.e. Configuration Management)

I have often seen companies who start out very positively, implementing functions one by one and integrating them as they go. However, at some point, when an assessment is done, they realize they have no resources to populate data repositories that are critical. An obvious example is a Configuration Management database. In many companies it is a mammoth effort to populate and maintain this data, but without it ITIL process is toothless. Populating data repositories is boring, thankless work, and even when it is automated it is perceived as a waste of resources. Processes must be simplified to make the best use of the data available, and to make it easy to maintain the data.

MJ:  The dreaded CMDB!  For additional information about CMDB’s and their intended results, click here.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222.

Michael Jagdeo is the Director Recruitment Services for B Wyze Solutions. 

[Note:  This is Part 2 of an ongoing conversation that I’m having with a former VP of IT of a national bank in Canada.  We started talking about why ITIL initiatives have such a low rate of success, and I was truly amazed at the perspective she had to offer.  Click here for Part 1.]

Michael Jagdeo:[In response to Cindy’s email] What I find interesting is that the core ITIL processes of Incident, Problem, and Change Management aren’t practiced very well at many organizations.  Some organizations go through ITIL consultants in various forms and still don’t have these processes down.  

In frustration, I wrote a blog on it, actually.  http://www.bwyze.com/blog/implementing-incident-management-like-a-marketing-guru/.  I’d love to hear your thoughts on where ITIL consultants/IT departments have missed the mark.  What are they doing wrong? 

Cindy Allingham –

Your blog, specifically the article on Implementing Incident Management, touched on an idea that I want to expand on, to answer your question:  Why Doesn’t ITIL Work?

To begin with, keep in mind that ITIL is a library of process guidelines. Everyone knows there are no hard-and-fast rules about how to organize, or what jobs need to be done. Implementation of one process, such as Incident Management, can be relatively easily and cheaply done. And that’s where most organizations get into trouble. They view each process as a stand-alone function that can be built on existing functional foundations.

This is understandable, given that most organizations want to start small and simple, and that’s good. However, true process maturity will only happen with ALL the processes in place and integrated, and that is very difficult.

Take tools, for example. A good incident management reporting tool includes a database and an easy way of entering data uniformly, and it is pretty difficult to get IM going without it. Many organizations purchase and implement a tool for one process without thinking how they will furnish and integrate the other processes. Change Management, Problem Management, Release Management, Config Management, and almost all the other ITIL processes need to be linked by such a tool. To do that up front, however, is extremely costly and requires a lot of planning. Most organizations cannot justify that cost and effort all at once, so they start piecemeal.

Functional flow in the organization is critical, but is probably the most poorly understood area when putting in ITIL processes. However, if you get it wrong you will get situations like this: Incident Management and Help Desk analysts are viewed as incompetent, lazy and uneducated because they cannot seem to stop the rising tide of incidents. No matter what they seem to try, the numbers just keep going up. Project and development teams have no relationship with IM and HD, and just keep developing new great stuff, but the old stuff just never gets fixed. This is all blamed on the Service areas.

However, the development areas do not include impact assessments on their projects, to verify that the new products and services aren’t going to introduce new problems, and to make sure that the Service areas know how to fix the things that break. This is so common, many IT managers are aware of it, but getting it to change is tough. I suggest that, if the blame for rising incidents were placed on developers they would be quickly reduced, but most of the time development functions reject any involvement in service.

It may be, also, that consultants and vendors have encouraged organizations to place very high expectations on ITIL. Many think that, provided ITIL is “installed” properly, all the IT service problems will disappear. But remember, ITIL is merely a collection of process guidelines, so it is still necessary to choose appropriate tools, provide appropriate levels of resourcing, put the effort in to integrate all the processes, fine tune each process in accordance with your organization, and make sure the right groups are accountable.

Senior IT management should, perhaps, also consider whether they have given process owners the right level of authority. For instance, the Incident Manager is usually a first-line manager in the service-side of IT, but has no authority to stop or delay projects, reject new product implementations, or challenge strategic plans that might result in increased incidents. Unless they can do this, they really don’t have the authority they need to be accountable for Incident Management. A way needs to be found to have that in place.

ITIL material and consultants know all of this, and try to convince their customers to do it properly, but more often than not, IT senior management derails or truncates processes to fit the organization. Cutting costs, holding the line on staff numbers, and keeping authority centralized are usually on the agenda, but these are all counter to what ITIL needs to work. Organizations who find their ITIL processes aren’t delivering the value expected will need to get some expertise to re-assess, possibly streamline or re-implement, and shift the ownership and accountability for the key functions. Should you hear an IT exec insisting that they know ITIL well enough to do it themselves without outside help, you need to ask yourself again, Why Isn’t IT Working?

MJ is a Director at B Wyze Solutions.

Cindy Allingham (ITIL, PMP, CGEIT) is a Senior Consultant with over 25 years’ experience in all aspects of IT. With several years at the IT executive level, she has an extensive portfolio of experiences in the financial services and government sectors. She specializes in ITIL consulting, project management, and operations improvement.  To reach her, please leave a message at 1.888.418.4230 ext. 222

Often times when things aren’t going quite right in IT, people are quick to blame technology rather than the people or the existing process. In my experience, most mid to top tier ITSM tools can be modified to meet business requirements, rather than investing in new technology.This brings me back to the original question which comes first, the tool or process? In order for an ITSM tool to function effectively, it must enable a robust process. ITIL, Cobit, Six Sigma…..it doesn’t matter, it just needs to follow a best practice framework that is applicable to the organization.

Once the process is defined, then start planning the tool implementation or upgrade (rip and replace isn’t always the answer). Remember to start with reporting requirements first. Often times, if the data isn’t going to be diplayed in a management report, it doesn’t need to be captured in the tool.

Last but not least, in the spirit of continual service improvement, process always needs to be reexamined for improvements. When process is updated, don’t forget the tool!

What gets measured gets done is a phrase I learned in my Service Marketing fourth year university course. This phrase can be applied to improve processes in the IT industry. If a process does not get measured, it cannot be managed. If the process cannot be managed than nothing can be done to improve the process.

Once a process has matured, it is fairly easy to just leave it as is.

Instead, IT services should always be looking at making continual service improvements to their processes which will better align IT with the goals of the business. ITIL Best Practices suggests using the continuous Deming Cycle process to improve processes. This Deming Cycle consists of - Planning (Planning for improvement initiatives), Doing (Implementation of the improvement initiative), Checking (monitor, measure, review services and processes), and Acting (continual service and service management improvement).

Some of our clients have recently implemented a change management team and they follow the deming cycle process weekly. The change management team is responsible for meeting bi-weekly to measure their success rate from the past weeks change. By measuring improvements the team can plan ahead and make new changes to make the process even better.