Lee Marshall, ITSM Consultant, read the blog I made last week (click here for the post). The following entry outlines the second half of the conversation that ensued (click here for part I)…

What’s Missing from the Client Side?

Lee: Of course, the blame is not just with the rigid ITIL practitioners. Organizations should have clear goals and outcomes for their ITSM program before engaging the services of an ITIL consultant. But often they don’t, and this is where the services of an ITSM consultant who is a true business consultant become invaluable.

MJ: Can you expand on what you mean by, “…having clear goals and outcomes” before engaging with a Consultant? Can you give an example of a clear goal/outcome?

Lee: An example of a clear goal is: Develop an enhanced service level agreement for information and technology services, including service standards and performance targets that are meaningful and relevant to clients. With this management directive, ITIL can be leveraged to implement a Service Level Management process that meets the business goal. A goal like “Implement Service Level Management” or “Build an IT Service Catalogue” means nothing to the business.

Another example could be: Complete a business impact assessment to identify and confirm service continuity requirements for all information and technology applications and services. With this goal, ITIL’s guidance in the areas of IT Service Continuity, Availability and Capacity Management can all be leveraged. But ITIL doesn’t exist in a vacuum.

Best practices in fields of disaster recovery and business continuity would also shape this organizational goal.

COBIT provides an excellent framework for linking IT processes to IT goals to business goals. I would recommend that organizations leverage COBIT when doing an assessment of their IT and identifying areas that need improving. To ensure independence, a consultant with COBIT expertise can be used, but the project should be sponsored by an internal group within the organization. Usually this would be senior management, the CIO or internal audit.

What to look for in a True ITSM Consultant

MJ: Ok good. So let’s say that we have an organization that doesn’t have clear goals and outcomes for their ITSM program. You mentioned that this is where a, “…true business consultant becomes invaluable.” What does this person look like?

Lee: A “true” ITSM management consultant or firm can provide the following:

An assessment of the current maturity level of information technology at the organization, using ITIL and COBIT as guides

• Identify areas that require attention enabling IT to focus its efforts
• Work with executives and senior management to build a roadmap
• Work with process and service owners to implement ITIL processes
• Once the areas to focus on have been identified during the assessment and roadmap building phase, then the ITSM consultant can build a team to implement the processes. And that is when an expert in ITIL process documentation will come in handy.

MJ: I love that you said, “Work with process/service owners to implement ITIL processes.” You didn’t say that the consultant him/herself implements the processes. ITIL implementations fail when the consultant becomes the process/service owner and therefore when they leave, the organization reverts back to their old behaviors. I’ve said it before and I’ll say it again: improving ITSM involves changing the attitudes and behaviors of the staff in an organization.

Lee: So, in conclusion, if your organization has clearly defined the goals and objectives of your ITSM program, and the areas to focus on along with the processes that need improving, then hire yourself an ITIL consultant who can document and rigidly implement processes according to your specifications. Otherwise, find yourself an experienced ITSM business consultant. You will save money in the long run and you will be closer to the ultimate goal: aligning IT with the business.“

Lee Marshall (ITIL v2/v3, COBIT 4.1) is an IT service management professional with over 10 years experience leveraging industry best practices to align IT with the business requirements of organizations. To contact him, visit his website and blog at www.leemarshall-itsm.com or e-mail him at leemarshall.itsm@gmail.com

Michael Jagdeo (SCM, ITIL v2/v3) has an extensive background as a Recruitment Consultant and ITSM/ITIL enthusiast. He has worked on placements in Singapore, Dubai, London, and across North America. As Director of Recruitment Services at B Wyze Solutions, he manages relationships with clients like Johnson & Johnson, Toyota, Maple Leaf Foods, and the Government of Ontario.

Lee Marshall, ITSM Consultant, read the blog I made last week (click here for the post).  The following entry outlines the conversation that ensued…

I’m Upset

Lee:  Over the past fifteen years as an IT service management practitioner and consultant, I have found that ITSM consultants, generally, fall into two categories:

• Those who use ITIL as gospel and are excellent at rigid process documentation, but fail to understand the needs of the business. Hence, their excellent documentation sits on a shelf or network drive and no one looks at it or uses it.
• True management consultants who use ITIL, and other Best Practices, as a guide in achieving the goal of IT service management: aligning IT with the business objectives of the organization.

Unfortunately, the latter tend to be in short supply and the former are what the majority of organizations are getting when they engage the services of an ITIL “consultant”. And it upsets me that ITIL may be getting a bad name because of this. Too many failed ITSM implementations are causing organizations to reconsider ITIL when they need it more than ever to compete in these difficult economic times.

For example, I was once engaged by an organization to implement an IT Service Catalogue. Naturally, I wanted to see what other ITIL processes were in place, as these processes would complement the services and service levels defined in the service catalogue.  The ITIL practitioner at this organization proudly showed me the Incident Management process binder complete with colour Visio diagrams that went on for pages, RACI charts, definitions, etc. And they had produced dozens of these ITIL manuals that sat on various shelves across the organization. However, when I interviewed the lead service desk analyst, who had been there for years and dealt with IT’s customers every day, they were not even aware that the process or the binder existed!

MJ:  It upsets me to no end, too.  Imagine if companies stopped considering implementing six sigma best practices for TQM because of failed implementations!  It’s funny, because when I first heard that they were coming out with ITIL v3, I said, “I hope this doesn’t confuse the industry!  Most organizations don’t have v2 up and running yet!”  I held back on doing my ITIL v3 certification for 3-4 months for this very reason.  It turned out that when I did break down and take the ITIL v3 eLearning course we built, there was a lot of valuable information, i.e.:

·         The Lifecycle of SSàSTàSDàSOàCSI

·         New topics like Demand Management

·         More ITSM-relevant treatments of areas like Security Management

Individuals shouldn’t necessarily look at failed projects and say things can’t be done.  That said, I completely understand why failed implementations can skew the perception of the ITIL value proposition.

Lee:  Absolutely! The fundamentals of service management and ITIL are based on the collective experience of practitioners worldwide, backed up by solid research and science.  The Service Strategy book in v3 attempts to cover some of the science behind service management, such as utility vs. warranty, and I’ve found this has confused many people. But project management and the PMBOK are analogous to service management and ITIL.  Just because some organizations have failed to implement project management doesn’t mean the principles behind the PMBOK are not sound.

Stay tuned for Part II!

Lee Marshall (ITIL v2/v3, COBIT 4.1) is an IT service management professional with over 10 years experience leveraging industry best practices to align IT with the business requirements of organizations.  To contact him, visit his website and blog at www.leemarshall-itsm.com or e-mail him at leemarshall.itsm@gmail.com

Michael Jagdeo (SCM, ITIL v2/v3) has an extensive background as a Recruitment Consultant and ITSM/ITIL enthusiast.  He has worked on placements in Singapore, Dubai, London, and across North America.  As Director of Recruitment Services at B Wyze Solutions, he manages relationships with clients like Johnson & Johnson, Toyota, Maple Leaf Foods, and the Government of Ontario.

Christine Whittle is a seasoned Manager of Service Delivery with a background from PWC and Brookfield Asset Management.  She weighs in on Cindy Allingham’s column, ITIL Misunderstood…

Wow, great topic of discussion.  While I hear and agree with much of what is being said, I see things a little differently…

ITIL by any other name

ITIL has existed since pretty much the beginning of IT, though was introduced to North America a little later then UK and Europe. A lot of IT departments follow ITIL generally but don’t call it, “ITIL.”  What IT department doesn’t recognize that when they have a lot of issues about the same thing that there might be 1 culprit out there?!  These IT departments are performing Problem Management whether they realize it or not.

MJ:  Correct!  Anyone that worked in operations in the ‘80s practiced strong change management because, heck, it just made SENSE.  Did they call it change management, create RFC’s, etc. per se?   Probably not.  But they were operating using best practices.  The ITIL best practices were published back in ’86!

Best Practices, Not a ‘Solution’

And while we all tend to talk of ITIL as a solution, it is only a set of best practice ideas which require consideration and planning based on your business.  It is not the answer to any IT problem.  Rather, it helps guide us to making good choices for running IT as a Business in full support of the Company we are there to support.

MJ:  GREAT point.  I think somewhere down the road people started thinking ITIL was like implementing SAP.

Can ITIL Save You Money?

Yes! And it does so by:

1.    Ensuring that IT develops and follows standards and processes that reduce the down time of end users through Incident Management.

2.    Reducing the number of incidents by identifying and resolving root cause problems through Problem Management.

3.    Reducing incidents and problems by formalizing the process to gain approval for Infrastructure and Application changes to reduce business impact.  (for an article that discusses the nuances of Problem Management, click here)

4.    Reducing incidents through monitoring of systems for capacity and availability management. Fast resolution to actual/potential service outages it facilitated when IT can anticipate threats in the environment.

MJ:  All strong points.  It’s important to keep in mind that, in the initial term, there are costs that have to be incurred in order to carry out the ITIL best practices (i.e. hiring a Problem Manager, Process Designer, etc.). 

That said, while the initial ROI given the costs involved may not be immediate, as we move ourselves away from firefighting by building relationships between the Problem Management group with Infrastructure and Application Management, we now start adding value to the business because we can help enable their strategy.  Keeping an application up 80% of the time is not considered a value-added offering by the business.

So, I should implement ITIL, right?

Wait a minute.  If your IT department develops their own best practices that makes sense to them and allows them to delivery service in a cost effective manner, why choose ITIL? Why waste a lot of time and energy developing something that is already available and has taken all sorts of businesses and requires into consideration to develop a great framework for us to use?

I think the most important thing we all need to remember is that IT is here to support the business. We must find ways to reduce business downtime and increase resolution times, because in doing so we prove our worth to the business. The business also must determine what downtime they can accept and therefore how much they are willing to pay to ensure that level . . . Hence SLAs!

MJ:  While a company, without knowing anything about ITIL, can become good at providing IT services without ITIL based on hard work and common sense, they will never become great without consulting with a best practices body of knowledge, whatever it’s called.  I’m not saying create a project to implement ITIL. But at the very least, one should consider the information contained in a relevant best practices BOK and evaluate whether certain aspects could enhance service delivery.

At B Wyze, we believe that there is one huge process that is missing from most ITIL implementations.  It’s a process that your consulting firm doesn’t talk about.  It’s a process that requires negotiation, facilitation, and team-building between the IT silos.  It’s a difficult process.  It’s a process that nobody wants talk about it because it requires uncomfortable conversations with uncomfortable people.

Rick Beaudry, Co-CEO at B Wyze, will weigh in on this process very soon…

Christine Whittle (ITIL) is a Senior Service Delivery Manager with over 10 years experience in IT.  She specializes in Operations and Service Delivery improvement using her experience in ITIL processes, best practices, and focus on business requirements to help IT departments mature.  To contact her, please leave a message at 1.888.418.4230 ext. 222.

Michael Jagdeo is Director Recruitment Services for B Wyze Solutions.

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

Cindy:  … 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:  Ailing Processes are addressed by layering more processes on top

After a few years of implementation and operation of an ITIL process, IT management often concludes that the process is not working. Either there isn’t enough compliance, the data kept isn’t accurate, or there is lack of customer confidence in it. These are not really problems with the process itself, but in many companies it is easier to identify the problem as such. Instead of taking the process apart and modifying it, often additional new processes are added to “fix” the existing problem. New resources and new functions are added, to take precedence over the old process, in the hope that it will fix the problem. The only thing this will do is result in confusion and a growing need to simplify the process. It is better to take the process apart and examine why it isn’t working, or whether the real reason has to do with other conditions in IT.

MJ:  It sounds like process myopia (to the extent of glaucoma) ensues over the years.  You get process-focused professionals trying to fix/optimize/add to processes without taking into consideration the business that they’re trying to support.

Cindy:  Documentation isn’t maintained regularly because there is too much of it

This has been a perpetual problem in IT, but in the past few years ITIL has elevated documentation agony to a new level. Part of the problem is that people don’t read these days. But the information explosion has resulted in ‘way too much material to ever be easily consulted. Think of your ITIL documentation as the handbook for how to run your IT department. It’s critical, but it could easily get out of control and include all kinds of useless or obscure information. If your ITIL document focuses on how processes and tools work, change it to emphasize only those pieces of information that are organization-specific and that change most often.

MJ:  Right on!  How many ITIL implementations consist of a phonebook of documentation in lieu of detailed negotiations and mentoring with IT and business groups!?  Additional documentation does not a measurable improvement make.

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 Director Recruitment Services for B Wyze Solutions. 

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.