Designing An ITIL Process Is The Easy Part

Up until now, the enablers we have discussed relate primarily to the design, build and test phases of the project; however, by the statement “Ability To Deploy” I am specifically referring to the political will and authority to deploy / impose a new method of working and new tools across the scope of the organization that now must comply with these new ITSM processes.� In our experience and research, this is a primary point of failure for many companies (it all looked great until others were required to change the current behaviors).

While it takes significant effort to design, document and test your ITSM deliverables, it is at the point of actually rolling out changes to the functional groups and departments that many ITSM projects hit the proverbial brick wall.� Whether it comes in the form of open rejection of the new process and tools or it rears its head as a delay tactic, many ITSM projects find themselves mired in the quagmire of inter-company politics and fail at the point of delivery without ever having realized any value to the organization making the investment.

Typical Deployment Challenge Scenarios:

• The Filibuster: One or more of the groups you are deploying to find some urgent reason to put off changing to the new way of working based on a whole series of excuses (either real or imaginary) not related to the project directly, as this would appear as if they were not supportive.
• The Never Ending Pilot: Based on the principle of a pilot rollout to a designated group, the testing of process and tools generates dozens of critical improvement requirements that somehow did not come up during the months of design and review by the very same group.
• The Perfectionist Syndrome: The primary stakeholders responsible for signing off on the design and characteristics of the process and tool requirements refuse to accept that improvement – not perfection – is the goal, and that certain improvements can come later.� This scenario is very typical for an organization that has had difficulty managing changes in scope during the project lifecycle.
• The Tool Development Backlog: For ITSM programs, the process automation tool/suite is often used by several processes that have already been deployed or are being so while other processes are being designed.� The challenge that often arises at this point is the fact that the developers / administrators become the primary bottleneck in that they cannot cope with all of the demands for configuration and customization they are receiving from multiple process groups. This becomes even more of an issue if request for tool enhancements are not approved, prioritized and scheduled through a strict Change Management process.

These are the typical scenarios that come painfully to my mind. I am sure you have your own and I would love to hear them.

Troy’s Thoughts What Are Yours?

“Experience has taught us that men will not adopt and carry into execution measures the best calculated for their own good without the intervention of a coercive power” ~George Washington

When You Are Not Integrated You Are Isolated

It is no secret that to even get close to the process integration that ITIL suggests as good practice, it is critical to consider workflow automation and tool requirements; however, that being said, have you also considered that underpinning these processes is data?� Data is passed back and forth between processes as tasks, workflow records, approvals, SLA time frames, costs and configuration item details.

Invariably, the activities, inputs and outputs of ITSM are represented in a digital form that is shared by many processes at various times and for various reasons.� This digital web of information flow is ultimately represented by an ITSM tool and data architecture that supports the over all vision and strategy of an enterprise IT function, fulfilling the role of a key business partner and service provider.

Underpinning the integrated ITIL process model must be an integrated ITSM tool strategy that is supported by a shared data model.

In the ITSM community we are very comfortable talking about the IT governance and process levels of service management; however, we often fail to consider the tool and data definition that is required to make it real.� In my personal experience it is always the tool element of the ITIL project that takes the longest time – not the process design!

At the heart of this challenge is the silo or domain approach to how we purchase IT management tools.� The fact is that one of the most significant challenges to a service management approach is the cultural and organizational focus on IT silos to the detriment of enterprise IT management issues.

To explore this concept further from a tool perspective, consider your own organization and the following questions:

1. Is there a defined enterprise IT tool strategy and architecture model?
2. Is there any function or group in your organization that has a mandate to create and govern an enterprise tool strategy?
3. Do you have a group in your organization that manages and supports IT tools that are used by IT functions across your organization?
4. Are IT management tools budgeted for and purchased at a domain / departmental level, but are required to fit within a predefined enterprise strategy?

If you are like the majority of companies I have worked with, all of these questions would most probably be answered with a no and the resulting tool landscape would be filled with multiples and duplicates of various types of tools that do not integrate.� It is also very common to find tool decisions for ITSM programs being made in isolation without the consideration of integrated tool requirements.�

Lets face it we love our IT Management tools and each IT group want’s to have its own specialized set which they have exclusive control of and access to. This is true even though half a dozen other IT groups could benefit from its use given the opportunity. But for the most part we treat each other on a need to know basis and guard our departmental resources like misers, after all knowledge is power!

As a former geek I do love my Sci-FI and Star Trek has been part of my life since I was young. There is a famous quote by Spock in the movie “Wrath Of Khan” 1982 that comes to mind. “The needs of the many out weigh the needs of the few or the one.” Wouldn’t it be nice if this philosophy was a guiding principle for buying IT Management tools.

Troy’s Thoughts What Are Yours?

“The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.” ~Bill Gates

A Little Knowledge Can Be A Dangerous Thing

If you understand knowledge to be the collection, absorption and internalization of facts and information, the application of that knowledge takes skill, which is a capability and proficiency based on experience, or better yet, wisdom.�

It all boils down to the concept that your ability to accomplish something worthwhile is typically directly proportional to your knowledge and skill related to your goal. For ITSM projects this means you know about ITIL and have experience in designing, documenting and deploying enterprise processes in a silo based culture.

Even though ITIL is celebrating its 20th birthday in 2009, it was just a few years ago when most people would tell you they had never heard of ITSM or ITIL.� Today, awareness has improved and most IT people you ask will tell you they have heard of ITIL and have a simple understanding of what it is.

That being the case, the people charged with project tasks, deliverables and the ongoing management of the process need to seriously consider more advanced education and learning.� This blog post lists a recommended level of ITSM education by role and involvement in your projects.

General ITIL Overviews

It is highly recommended that each person within the IT organization receive a high-level overview of ITIL as part of the project communication plan and for the ongoing training of new IT employees.� The level and detail of overviews can be customized in accordance with their level of participation in service management processes.

The ITIL overview is designed with the intention of providing an introduction to the ITIL framework, the processes and their goals and is a must for anyone who is even remotely involved in these processes going forward to understand the new and strange language everyone is starting to speak. It’s kind of like the language lessons tourists take before they travel abroad. They may not know any details but at least they can order a beer and ask to use the washroom. “Two very critical skills in any country”

Foundations ITIL Education

It is highly recommended that anyone involved in managing or executing daily ITIL process activities attend an ITIL Foundations class.� This is a prerequisite course for further ITIL study and certification, and should be made a mandatory requirement for those individuals tasked with the coordination, management, ownership or governance of your service management processes.

Key Roles:

• Process Sponsors
• Process Owners
• Process Managers
• Process Staff
• Project Managers
• Process Customers
• ITSM Tool Owners / Administrators
• ITSM Consultants

Intermediate ITIL Education

The Intermediate level courses are intended for individuals tasked with the implementation, ongoing management and continuous improvement of a specific or a collection of closely related processes. In the new ITIL v3 scheme this comes in two separate flavors. 1) Life Cycle Courses: A course based on a the management elements of a specific part of the Service Life cycle. e.g.: Service Strategy, Design, Transition, Operation, Continual Service Improvement.� 2) Service Capabilities Courses: A series of courses based on a logical grouping of processes with a strong connection with each other and a focus on practical execution. e.g.: Release Control and Validation.

For this reason, it is highly recommended that the following roles be identified for intermediate level education and certification.

Key Roles:

• Process Owners
• Process Managers
• Program / Project Managers
• ITSM Tool Owners
• ITSM Consultants

Advanced ITIL Education – “ITIL Expert Designation”

The advanced education courses and certification such as the those that focus on the full Service Life-cycle, e.g.: Managing Across the Lifecycle and the attainment of the “ITIL Expert” designation are intended for those who have overall ownership of a service management improvement program and are responsible for the ongoing governance and improvement of multiple processes. Some have argued that the Expert Certification is now a basic entrance requirement for ITSM consultants.

This level of certification is recommended for the following key roles.

Key Roles:

• Service Managers
• Service Delivery Managers
• ITSM Consultants

So in summary whatever your involvement in the ITSM world some level of education and certification will be a necessity at some point in your IT career. Of course it does not hurt that a recent survey by ZDNet’s Tech Republic listed 2 ITIL certifications as part of the top 15 paying IT Certifications. If knowledge for personal improvement does not get your interest maybe money does.

For more information about ITIL courses you can check out Pink’s website. Yes a bit of a shameless plug but what do you expect, I am Pink and proud to be!

Troy’s Thoughts What Are Yours?

He attacked everything in life with a mix of extraordinary genius and naive incompetence, and it was often difficult to tell which was which.” ~Douglas Adams

Resources Fuel The Fire Of Execution

It was a very wise person who first said that nothing in life is free.� This is of course true for ITSM projects as for anything else.� Sitting down with the right people from across the organization to define new policies, processes and tools takes a significant resource investment (time, people and money).� That being said, one of the most frequent statements I hear from people when I speak to them at conferences or in courses is that they are expected to implement ITSM practices without any formal investment in any of the above other than perhaps their salaries.� They are expected to change organizational behavior and pull the ITIL rabbit out of the hat, so to speak, because they have ITSM somewhere in their title.

While for the purposes of the research we recently conducted I aggregated time, people and money under the single title of “resources”, these are in fact three separate enablers / constraints.

Time

Several respondents in our research said that they had all the leadership and organizational will they could wish for; but, they were swamped with an IT project portfolio that was overwhelming, with half a dozen initiatives being perceived as more urgent than their ITSM projects.� There is only so much time in the day and they are already running at max speed and doing their email at 10:00 pm each night after they feed the kids and put them to bed.� Sadly, the urgent always takes precedence over the good and necessary.� Survival always trumps strategy.

People

If your organization is like many we have worked with, year after year of focusing on cost reduction has reduced your IT operational staff to what feels like a bare minimum to keep the lights on.� What people you do have are very hesitant to commit to what appears to be the latest management fad and set of acronyms floating down from senior management.� The key stakeholders that are critical for you to involve in the ITSM initiative are busy fighting the daily fires (often caused by immature processes) and are too busy to come to your process and tool design meetings.�

This general lack of people is a very crucial issue for ITSM in general.� After years of cost reduction and containment, there really isn’t a lot of bandwidth for people to get involved in the project, let alone manage the ongoing processes once they are deployed.� While you can hire consultants to help alleviate the resource crunch for the project, who gets to run them after the consultants leave?�

Money

A lack of available funding is often a constraint that is shared by many organizations, and while money cannot buy happiness it can get things done!� However, in our research we discovered that there are some organizations that have the money, but lack of time and internal people were their most serious constraints.� One respondent from the Calgary Pink Perspective event stated that that the issue was not money (thanks to the oil boom in western Canada), but skilled people and affordable housing to attract talent to the region.

Meanwhile we still face the challenge of having to change the wheels on the bus as it travels down the highway. This reminds me of that EDS commercial “Building Aircraft In The Air” that came out after the super bowl a few years ago.

Troy’s Thoughts What Are Yours

”Time is an illusion. Lunchtime doubly so.” ~Douglas Adams

”Leadership is not something you do to people, it’s something you do with people.” ~Ken Blanchard

Life seems to come at you in a series of waves. At times you feel like you are surfing the crest balanced between the forces of change and the quiet pools of serenity. However, there are other times when you have the impression the wave is breaking over you or that you have been left stranded and forgotten in a stagnant pool. Wherever you find yourself today the good news is that each phase is transitional and that life really is a series of dependent and connected events that bring you to new horizons and views of reality.

My own life is no different than yours and recent changes in leadership scope have broadened my responsibilities at Pink Elephant and I am learning a whole new definition of busy. It is for these reasons my writing as of late has slowed down a tad. However, I have finished writing the research paper that I promised you a few months ago and I will now provide that to you following these series of articles which expands on the initial concept we discussed earlier this spring.

Last time I wrote on the 7 enablers I presented a model of critical success factors needed to be successful on your ITSM journey.� These past articles set the stage for this model:

7 Enablers & Constraints of ITSM
ITSM Enablers Getting You To Work On Time
Perspectives From The Pink Perspective Tour

The following list represents these 7 Critical Enablers:

1. Leadership: Executive and senior level support and sponsorship
2. Resources: Access to necessary project and ongoing process resources (time, people, funding)
3. Knowledge: Your level of information, knowledge and skill related to ITSM
4. Integrated Tools: Availability of integrated ITSM tools to support process workflow and automation
5. Ability to Deploy: The organizational capability to deploy new polices, processes and tools across silos
6. Ability to Effect Behavioral Change: Changing organizational behavior/culture and ensuring compliance to new practices over the long term
7. ITSM Momentum: Maintaining momentum, priority and funding for the ITSM programs

The basis of this model was substantiated with research we successfully completed with over 300 participants. You can find the research posted on the Pink President blog and it will also be imbedded in the full paper I will share with you following the next series of articles.

The Results Are In!

My intent with this new series on the topic of the 7 enablers is to provide more detail and context for each one.

The first and arguably the most important enablers is:

Leadership & Vision

Many hundreds of books have been written on the subject of leadership and the role a leader plays in providing the vision, direction and the compass that a project needs to be successful.� Without a leader’s blessing, passion and direction, very little is accomplished that has lasting effect.� This is true of all major endeavors, and it is certainly true with ITSM projects.�

We live in a time when the vision of the IT Executive is changing from one traditionally focused on technology optimization and cost reduction to an evolution towards service delivery and value generation; however, many IT shops still struggle with the value of ITSM principles when they are still firmly entrenched in a purely technology mindset.� For an ITSM project to truly succeed, the executive sponsor needs to understand what it means to be a service-focused organization and support the establishment of the processes that make this concept a reality.

However, many organizations are challenged with a CIO and executive IT team that have not bought into the principles of ITSM.� This proves to be very challenging when you consider that ITIL is a Service Management framework that has as its primary goal the delivery of services.

“Service Management is a set of specialized organizational capabilities for providing value to customers in the form of services.” Source:� ITIL® V3

In my experience very few organizations understand the concept of an IT service and even fewer organize themselves around the delivery of IT services.

To be effective, the leadership of an ITSM program must profoundly understand what an IT service is and wish to establish the disciplines that make the delivery of services possible.

What we often see is that the ITSM program sponsor has agreed in principle that the project represents a set of positive goals and has agreed to fund some initial efforts, but is still largely unconvinced of the exercise’s strategic nature.� The green light has been given, they have agreed to stand up at key meetings and say positive things, but little effort is made on ensuring that the remaining six enablers are in place and managed in a proactive manner.

It has been argued that the true skill of a leader is not just the shaping of vision and direction, but also the task of execution.� Larry Bossidy and Ram Charan make a very powerful statement in their book, Execution: The Discipline of Getting Things Done:

“A high proportion of those who actually rise to the top of a business organization have made their mark – their personal brand as high level thinkers. They aren’t interested in “how” of getting things done; that is for somebody else to think about.” Source: Chapter 2 – The Execution Difference

The concept of Execution is a discipline worthy of discussion in and of itself. This is a topic I will be speaking on at our upcoming ITSM Conference in February when I review the principles of Execution in terms of ITSM projects.

Rather that pointing toward the hill and saying “Make It So”, true leaders must take the point and lead the ITSM charge.

Several of you have pointed out in previous comments that without a healthy enabler in Leadership then the rest of the 7 are moot. (Read The Comments)

Troy’s Thoughts What Are Yours?

”It’s hard to lead a cavalry charge if you think you look funny on a horse.” ~Adlai Stevenson

I Call It A Trunk and You Call It A Boot

The strange thing is that neither word does a particularly good job of describing a luggage compartment in a car and yet within our cultural boundaries people know very well what we mean by either one. However, leave the comfort of your current cultural context and you cannot be totally sure that people understand your intent by the vocabulary you use.

Language is a diverse and rich tool by which we express ourselves. However, it can also be a stumbling block and a subject over which we are confused, disagree or at least misunderstand each other. It is bad enough when we use completely different words such as trunk and boot to mean the same thing. However I feel truly sorry for the poor traveler who is caught unaware and is embarrassed by the use of a common word that has a totally different meaning in a different place. For example asking someone if they like your pants has a very different context in North America versus the United Kingdom.

George Bernard Shaw’s quote about the Americans and English: “Two Peoples Separated By A Common Language” is very true.

Don’t get me wrong, living in Canada I admire and respect cultural richness and diversity. However, when it is necessary to work at a common purpose and process across organizational boundaries such as local IT departments, geographical regions and dealing with multiple external suppliers, a common language is a Critical Success Factor.

While the poets and writers such as Shakespeare may disagree there is a time and place for a common language with shared definitions.

“What’s in a name? That which we call a rose by any other word would smell as sweet.” ~From Romeo and Juliet (II, ii, 1-2)

A key benefit the ITIL library provides is a neutral (non partisan) common vocabulary and set of definitions for global IT Service Management. Lets face it, if you put 10 IT professionals in a room from different organizations and ask them what a service is, you will get at least 12 answers. While I value creative flexibility as much as the next person I would prefer to avoid confusion where people cannot understand each other due to an issue of communication. The challenges of implementing IT Service Management are already daunting enough without having to argue over terms and definitions.

Common Terminology and PinkVERIFY

As many of the readers may know Pink Elephant provides a service called PinkVERIFY(TM) to the ITSM community where we will assess tools on request by the vendor for ITIL compatibility. The criteria we use for this assessment comes from a collection of ITIL guidance, vendor, practitioner and Pink experience that you can download for free from our website.

As part of this service we have written a white-paper where we define ITIL-compatible as:

Compatible = The software tool supports the PinkVERIFY criteria and ITIL terminology “out of the box” as part of its standard commercial offering.

ITIL Terminology is referenced from the official ITIL glossary hosted by the OGC’s “Best Management Practice” website.

A recent post on Dovetail Software blog has taken issue with this stand.

While I respect that not all organizations and individuals may share this view and have every right to disagree, I believe a common language is foundational to good and effective communication within the context of a process.

Pink also acknowledges in the PinkVERIFY whitepaper:

”Note: There are many excellent tools available on the market and practitioners should not exclude any tools from their selection process just because they do not have the PinkVERIFY certification;”

Troy’s Thoughts What Are Yours?

Dictionaries are like watches; the worst is better than none, and the best cannot be expected to go quite true. ~Samuel Johnson

A Practical Guide For A Very Relevant Topic

I set myself a goal today to write about the release of the 2nd edition of the very popular Service Catalog book co-written by Bill Fine, Rodrigo Flores and myself last year. I see from my news reader that my co-author and friend Rodrigo Flores from newScale has also provided a great review on his blog site.�

So why the need for a 2nd Edition?

The Service Catalog is the top subject du jour for many organizations adopting IT Service Management!

The popularity of this topic is not surprising for several reasons we discuss frequently on this blog including:
Are you being served?
Service-based costing
The role of the Service Owner
The evolving Service Organization
The nature of the service catalog

The first edition of the book has been on the market for just over 18 months and during that time it has sold out of multiple print runs.� Over the last two years, during which I have been writing content for this site and tracked how people have found their way here, a great percentage of the searches and queries have been related to IT Services and specifically the Service Catalog.�

The book’s first release was a few months prior to the release of ITIL version 3. This second edition has been updated to align language and concepts with the V3 IT Service Lifecycle model and the roles defined in the new ITIL books. We have also added new content around Request Fulfilment, implementation considerations and ITSM tool requirements for the Service Catalog and related processes such as Service Portfolio Management and Financial Management.

Here is a copy of the back cover text for your interest:

Building on the success of the first edition, this new edition is aligned with the latest, vital ITIL version 3 content. At the core of this volume is the fundamental principle that the IT Service Catalog has transformed from its role as being one output in the Service Level Management process to becoming the cornerstone deliverable item of a successful IT Service Management organization.

NEW! Service Catalog Tools chapter! The Service Catalog is the tool through which IT can define its business value by providing clear, easy-to-access services and support for all other business units striving to achieve corporate goals. This edition gives practical guidance on how to setup and develop the structures of the Service Catalog. Readers learn how the Service Catalog plays a critical role in demonstrating real value to the consumers of IT services including:

• Business Customers
• Business Users
• Peer IT Groups

Written by industry experts and using real case studies, this valuable text takes the reader beyond the theoretical to focus on the real business benefits of Service Catalogs and provides the steps for a successful implementation within any organization.

FREE Service Catalog Templates included making this book one of the most valuable additions to your IT library.

Visit www.pinkelephant.com to access these templates.

Apparently many of you who have purchased the first edition of the book have found it to be practical and useful on your IT Service Management journey. The following quotes are based on reviews posted by our readers:

Read what Amazon customers have to say about the first edition!

“Good introduction and advanced info on Service Catalogs. I have only been through the first half of the book, but that has been a great start...”

“This book is a simple and robust approach to move IT in the service direction...”

“I was very pleased with the book on several fronts. I’ve seen too many people hitting the CMDB wall, in part due to a lack of efforts in developing a Service Catalog. Thanks guys, for help folks avoid a savage journey and finding the Right Road.”

“I stumbled upon this book through a Service Catalog webinar I attended recently and I have to say that based on the lack of subject matter available on Service Catalogs I didn’t expect much.”

Visit Amazon to read more!

For those of you who would like to buy a copy of this new edition, the book will be making its debut appearance at the upcoming ITSMF Fusion conference in San Francisco, where I will be speaking on the topic of the Service Catalog.� Pink Elephant will have copies for sale at our booth and the book will also soon be available on our website as well as other online suppliers. At the Fusion event, Rodrigo, Bill and I will be available for book signing opportunities.� If you are at the show stop in at the Pink booth and say hello.

Troy’s thoughts what are yours?

“Disconnecting from change does not recapture the past. It loses the future.” ~Kathleen Norris, O Magazine, January 2004

You may not share the same DNA but you’re an extended family just the same.

The reality of our IT world today is that the business has an ever increasing set of “options” for how, when, where and from whom it buys IT services. In other words there are more and more fish in the sea and the local pond has expanded to now include the possibility of buying services from anywhere in the global economy with a dizzying array of options.� The World Is Flat

In my last article I stated that this external pressure will play a significant role in pushing the internal IT organization from its comfort zone of focusing on technology optimization and cost reduction to a service provider value-oriented mindset. When this occurs in your IT shop - and it will - the reality of the many available options may not point to the most effective solution being an internal IT service.

Today I am speaking at an ISACA Conference on IT Governance in Toronto. I will be presenting at 1:30 on the evolution of the ITIL v3 IT Service Lifecycle Model. This morning I had the opportunity to attend a session titled:“Governance Of Outsourced IT Services” and it has inspired me to sit down between sessions and hammer out this post.

I was personally struck by a question asked by one of the over 150 session attendees of the presenter and the rest of the session audience: “Do you or does anyone in this session know of an IT Outsourcer relationship that has ever gone well? In my 10 years of managing these relationships I have not seen this happen.” The response to this question was utter silence without one positive voice to be heard!

Why is this the case and is this not a major risk based on what I have written so far?

I have my personal opinions which I would like to share with you.

The Rise Of the Managed Service Provider (MSP)

Organizations are increasingly turning to external IT service providers who are in the business of taking responsibility for, and providing to their customers a part if not the entirety of end-to-end IT services in a profitable manner. In this relationship they are often paid to deliver an IT Service where they own the technology assets and provide the human expertise and personnel.� The increased use of MSPs as part of the IT service strategy can be observed across all industries and at all sizes of companies. Even the smallest IT department will have an external supplier for services such as Internet access, hardware repair and perhaps telephony support.

So with this growing reality, it becomes increasingly more important to figure out why most of these relationships with external providers end in tears and how we can do something about improving these relationships.

From my perspective the following list represents the top 4 most common reasons for this tendency for failed relationships with your managed service provider. However, I would invite the readers to add their own perspective as comments on this article.

* Outsourcing Services or Processes That Are Not Defined Or Are Broken: Consider that one of the classic mistakes we make is to attempt to outsource a something which we don’t understand or which currently has problems. The session I attended this morning was called “Governance Of Outsourced IT Services.” The presenters did a great job on their topic but what kept coming to my mind during the session was the fact that in my experience, most IT shops are just beginning to define what they do and expect to deliver from a service perspective. Today many if not most organizations manage their technology as isolated domains and have little knowledge or history about what to expect of a service. So consider what happens when you outsource something that you don’t understand, currently have issues with, don’t understand your requirements for, or don’t understand how to measure. The answer to this question is that you get compounded problems since your contract will typically not reflect what is needed and you have added another level of bureaucracy protected by contract language and legalese. This concept of “I can’t deal with my problems, so I will pay you take them” leads to arguments and broken relationships with perhaps the only benefit being the fact that you have someone else to yell at rather than the improved services or processes you were hoping for.

* Outsourcing Accountability/Governance: Building on the first issue, the second most common mistake we typically make is that we often completely pass the oversight, strategy, delivery and measurement of outsourced services to the MSP. After all the very word outsource means we send it outside our walls right? Sadly this sentiment is not practical, healthy, beneficial and even legal in some countries. A primary reason that many MSP relationships falter and fail is that the organization that has contracted for the service has not retained the strategy and oversight of the service. While it is very possible to outsource the responsibility for the provisioning of the service it is not advisable at any time to outsource accountability. Consider that if an external audit finds a deficiency in the service/process or the controls managed by the outsourcer the risk and legal implication impacts the customer not the MSP.� The organization who has contracted for the services provided by the MSP must have people who’s primary function it is to retain the governance, strategy, oversight and management of the MSP relationship for the services you have purchased externally.

* Beating The MSP Down To the Lowest Possible Price: Many organizations place the negotiation of their MSP contracts solely in the hands of a procurement group who’s primary key performance indicator is to get lowest possible cost for anything. I have seen this process carried as far as the procurement person forbidding the involvement of any of the stakeholders who are actually interested in the service becoming part of the negotiation as they might possibly compromise the goal of lowest cost possible. Consider for a moment what the most probably outcome of this strategy will be. You will beat the MSP down to a level where they are bordering on unprofitability and this will lead them to become rigid, inflexible and surly. Also as a consumer and purchaser of goods ask yourself if you actually fill your home with the cheapest priced goods and hire contractors for important home improvement projects at the lowest priced you can find.� Chances are that you may do so for commodity products but for the goods that need to be relied on and that protect your loved ones the lowest price will not be your primary selection criteria. So it is not surprising that your relationship with your MSP starts on a bad footing when you beat them down to the lowest possible price. No one wins in this scenario.

* Pretending and Acting As If The MSP Is A Stranger Outside The Family Circle: The fourth factor on my list is perhaps the most emotional but emotion is often one the most powerful contributors to failed relationships. In reality the relationship between the internal IT staff towards the MSP is often one of hostility, mistrust and fear. The causes for this negative set of emotions are many and range from the fear of losing their jobs and privileges to the reality of the fact that in some instances the internal IT staff had no involvement in the discussion and contracting of the MSP and feel they have been told to accept an outsider whom they don’t trust at the family table. The analogy of a family is appropriate here in light of the comment I made in the earlier point about the inability to outsource accountability. To extend the family analogy a bit further, when an organization decides to contract out a component of or the majority of its IT services, the MSP is being brought inside the family circle albeit on a contractual and temporary basis. When this occurs the MSP becomes a legally adopted member of the extended family for the term of the contract and as such is part of the organization’s Service Value Network in practice and in the eyes of the law. This means that to be an effective family member the MSP must agree with, participate in and share responsibility for following the organization’s policies, processes and standards. However, even more importantly the internal IT staff must stop treating the MSP as an outsider, stranger or unwelcomed dinner guest but accept the fact that at least for the time being the MSP is an adopted brother or sister and should be treated with courtesy and respect.

Troy’s Thoughts.� What Are Yours?

“You can pick your friends but you are stuck with your family” ~Anon

Sometimes You Have To Dance To A Different Beat

Every road trip offers a potential treasure trove of memories that we will share over and over again with our friends and family.

This experience is no less true of Pink road trips. in this case the recent Pink Perspective series of events.

As many of the readers of this blog may know I speak and write often about the fact that although ITIL is 20 years old, the vast majority of organizations that have begun to implement ITIL processes have never progressed past Change Management.

Most organizations will start with Incident Management, add in some request elements, move on to working on Problem (specifically what is often called an RCA process) and then proceed to Change Management. (And Stop)

At this point the wind dies out of the ITIL sails and the IT organization struggles to build a business case to move forward since they start running into processes such as Service Asset & Configuration Management, Service Catalog Management, Service Level Management and Release & Deployment Management, etc..

Company after company deploys these processes and then hits a proverbial wall and can seem to go no further. Why do companies hit this wall?�

Many might say that these other processes are harder and in some respects, this statement is true. However, in my opinion the reason that the majority of companies go no further than Change Management is because the remaining processes require an IT organization to understand what an IT service is and wish to manage and organize around a service model.

In my personal experience I would estimate that the majority of IT organizations I have worked with are primarily if not solely focused on managing IT technology assets and are not organized around service delivery concepts.

This lack of cultural recognition of IT as a provider of services is a global IT issue.There is no country in the world where IT Service Management principles have been adopted fully by the general IT industry. In short there is no ITIL Shangri-La hidden in the snowy peaks of some far off mountain range.

However, today (2007-2008), the concept of IT services are finally beginning to be understood. The driver for this birth of understanding is not ITIL adoption as some might suggest but is being driven by forces outside the traditional internal IT function.

The pressure to adopt a service model is coming from the business customers of IT who are being approach by Managed Service Providers (IT Outsourcers). These IT outsourcers are educating IT’s business customers about the availability of Software As A Service (SaaS) options for core business functions and the emerging hosted infrastructure options such as Cloud Computing. All of these services can be purchased by the business in units of consumption that vary based on actual use. In short the business can buy IT services without having to own their own assets.

However, while these external sources are pushing many companies to adopt IT Service Management concepts this adoption is still in its infancy as the IT culture slowly changes.�

With that background, on with the fun part of my story.

So going back to the Pink Perspectives, (I think it was the Washington event) I was going on as usual about the fact that most companies stop at Change Management as I have described above.

At which point, my friend George Spalding, who many of you may know is our Vice President of Events and a fellow Pink speaker upstages me. He, of course, has heard my rant often. George gets up on the stage and begins what he calls the Incident, Problem, Change Dance.

Yes, that’s right, a dance.

Picture George doing a quasi Can Can Routine.

Incident, Problem, Change, Stop (Kick)
Incident, Problem, Change, Stop (Kick)
Incident, Problem, Change, Stop (Kick)

Add the beat and the rhythm and you get the picture. Needless to say, it became quite a hit and we had to do it at all the remaining events.

Ok so maybe you had to be there and know George for this to be funny but it is certainly something I will share for years to come with my fellow Pinkers as we down our recreational beverages.

Troy’s Thoughts What Are Yours?

“Never trust a leader who cannot dance.� ~Mr. Miyagi, The Next Karate Kid, 1994

Key ITSM Enablers And Constraints - Establishing Terms and Definitions

The Pink Perspective Tour is now in the past and and I find myself in the possession of over 300 solid survey responses to the seven enablers and constraints. My next task is to write the promised paper fleshing out the model to also include the survey results and case study examples.

As part of this paper I have written the following section to further define what is meant by a Key Enabler. In the earlier posts we have had a very interesting dialog regarding the relative importance of leadership and vision over and above the other enablers. I share this view and will explore it in more detail.

Before we look at each of the enablers in detail it would be helpful to clearly define what is meant by an enabler or constraint. Consider that any objective, goal or project has certain critical elements or success factors that are required to make the objectives and goals of the initiative achievable. We often take those factors for granted and do not give them much consideration until they run out or their lack of quality places the objectives at risk. Making the assumption that these critical factors are present in enough quality and quantity is often a terminal mistake. Understanding these factors and managing their constraints is key to knowing if you have sufficient means to achieving your ends.

To illustrate this concept consider the analogy of you getting to work on a Monday morning. For the purposes of this analogy we will assume that you drove yourself to work from your home.

To get from home to the office parking lot you required several enablers to be in place.

1. Car: A car or some form of transportation is the most obvious enabler. However a car alone will not make the journey possible.
2. Fuel, Money: The car needs fuel and you need money (more and more of it these days) to fill the car with fuel.
3. Directions: You also need direction; a car with a full tank of gas without a vision or goal of where you are headed is not much use.
4. Roads: We often assume that the road will simply be there when we start driving. However in many countries this is not an assumption we can safely make. Even in the countries that have a mature infrastructure the occurrence of unanticipated accidents, road construction and detours can often remove the assumption of a good and quick road from our path.
5. A Drivers License: You may think that a license is not required to drive, but consider that your driver’s license represents governance, policy and rules of the road to which all drivers must adhere.� A lack of adherence would present a chaotic and dangerous environment in which to drive.
6. Knowledge: You need to have the skill to drive your car on the road system and within the context of your local rules. While you take it for granted today there was a time where the knowledge and skill of driving your vehicle was new.� If you were given a transport truck to drive in a country where the rules of the road differed from your previous context the ability to simply jump in your vehicle and drive would not be so quickly assumed.

While most of us don’t think of them on a daily basis each of these enablers is critical to achieving our goal of getting to work on time. If even one of these critical factors is limited in either quantity or quality then the likelihood of succeeding at our or mission of getting to work is at risk.

A common statement that we hear from many organizations that do not succeed in their ITSM objectives is that they were not aware of their constraint until it was too late. To be effective in achieving your goals it is vital to understand and manage all the elements that will either allow you to be successful or diminish your ability to achieve your results.

Key Enabler Versus a Key Constraint

In a simple world each of these enablers would be a standalone requirement that had little to no impact on the other factors and where they all had equal weighting. However, we do not live in a simple world. Another critical element of knowledge is the understanding that certain enablers have an overall positive or negative impact on the others. For example in our previous analogy you can argue that you can still get to work with limited governance and policy policing the use of the roads. There are many countries in the world where this would seem the case. However a profound lack of direction combined with a no formal means of transportation will make the other enablers pale in seeming importance. In our ITSM reality you can equate this example to having limited to no leadership and without the benefit of a formally recognized and funded project. In other words you are being asked to implement ITSM practices on the side of your desk. The lack of these key enablers makes things such as maintaining project momentum pale in comparison.

In light of this concept consider the following definitions:

• A Key Enabler has a significant positive impact on the initiative and compensates to some extent for other factors that may be less positively ranked.
• An Enabler has a positive impact on the initiative and supports the achievement of the goals and objectives.
• A Constraint is a limiting factor for the initiative and restricts the ability of the initiative to realize its goals and objectives.
• A Key Constraint has a significant negative impact on the initiative. It has the very real potential of causing the initiative to fail and can have a negative impact on the other factors.

Now I will get back to writing the paper, coming soon to an ITSM blog near you.

Troy’s Thoughts What are Yours?

“Better to light a candle than to curse the darkness” -Chinese Proverb

Ten Cities in Three Weeks

As I sit in my hotel room in Washington D.C., I have a view of the Capitol Building and the Washington Monument . I am reflecting on the progress of the three week road tour / adventure that has kept me hopping on planes, trains and automobiles and has kept my blogging to a minimum.

This is a quick post to let you know that I am still here and plan to get back to my regular writing schedule starting next week.

In my last post I introduced to the readers of this blog to the concept of the seven critical enablers and constraints of ITSM. As you can see from the comments this concept has already sparked some healthy debate and discussion which I have shared with the attendees at the Pink Perspective events.

In each city we have been introducing this concept as one part of the day’s agenda and have been conducting a survey to understand which of the seven enablers represent the most challenging constraints in the cities and regions through which we are traveling.

You can find copies of the Pink Perspective slides, surveys and the regional results on David Ratcliffe’s President’s Blog.

As promised I intend to analyze the data we are collecting from the many attendees of the roadshow as part of an upcoming paper and conference session I am planning to deliver at our 13th Annual ITSM Conference this coming February in Las Vegas.

The Horse Race So Far:

This list represents the status of the overall results so far. However, keep in mind that we have not yet accounted for the results from Washington, Philadelphia, Dallas and Toronto.� Here are the overall rankings so far as we head into the third and final lap.

From greatest to least challenge:

6. Ability to Effect Behavioral Change: Changing organizational behavior/culture and ensuring compliance to new practices over the long term

2. Resources: Access to necessary project and ongoing process resources (time, people, funding)

7. ITSM Program Momentum: Maintaining momentum, priority and funding for the ITSM programs

5. Ability to Deploy: The organizational capability to deploy new policies, processes and tools across silos

4. Integrated Tools: Availability of integrated ITSM tools to support process workflow and automation

3. Knowledge: Your level of information, knowledge and skill related to ITSM

1. Leadership: Executive and senior level support and sponsorship

Interesting results so far!

It appears that the people issues are ranked as the most challenging with leadership and vision being listed as the least difficult constraint. Without reading too much into this just yet it would seem that many organizations understand and accept the need for change but are struggling with how to make this happen in a politically-charged landscape of IT silos with limited resources.

More to come soon!

Troy’s Thoughts. What Are Yours?

”If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family anatidae on our hands.” ~ Douglas Adams

What Makes You Stronger Can Limit Your Potential When Its Missing!

2008 has been a year of reflection for me as I mark 10 years of ITIL adventure with Pink Elephant. In that time I have had the opportunity to work with many organizations as they began and progressed on their IT Service Management journeys.

I would like to say that every IT group I have worked with has had unquestionable success and is reaping all those benefits you read about in the ITIL travel brochures; however, that would not be a true statement!

The reality is that despite best intentions, many organizations stumble or fail in their initial attempts at implementing ITSM practices. The anecdotal reasons given by these organizations vary, but they are related in the sense that they each represent a failure in a key enabler required to be present at some level to achieve their transformation objectives.

When I consider the conversations I’ve had combined with the battle stories of many ITIL champions and sponsors, 7 themes emerge as a consistent pattern. These 7 themes represent 7 critical enablers that provide the energy and life blood ITIL projects require to kick off and stay alive long enough to make a difference at an enterprise IT level. This is not to say that targeted benefits cannot be realized without all 7 being in place in sufficient quality and quantity but I do believe that they are required to effect “lasting change” across the political boundaries of technology silos that represent reality for most IT groups.

ITSM projects have 7 key enablers that provide the energy and resources to initiate, sustain and realize the promised benefits. Unfortunately for many of the organizations these same 7 enablers when non existent at least at a basic level can quickly turn into limiting constraints and terminal blockages that paralyze; then kill their ITIL programs. Understanding, identifying and eliminating these terminal blockages is a critical success factor for any successful ITSM transformation program.

The following list represents these 7 Critical Enablers:

1. Leadership: Executive and senior level support and sponsorship
2. Resources: Access to necessary project and ongoing process resources (time, people, funding)
3. Knowledge: Your level of information, knowledge and skill related to ITSM
4. Integrated Tools: Availability of integrated ITSM tools to support process workflow and automation
5. Ability to Deploy: The organizational capability to deploy new policies, processes and tools across silos
6. Ability to Effect Behavioral Change: Changing organizational behavior/culture and ensuring compliance to new practices over the long term
7. ITSM Program Momentum: Maintaining momentum, priority and funding for the ITSM programs

Consider the analogy of a heart with 7 key valves that pumps the life blood through a healthy ITIL Program. For full health, each enabler needs to be in place to run the marathon and cross the finish line. If one or more of these valves are blocked or partially constrained the reality of bypass surgery may be required to keep the program alive.

Over the remainder of 2008 Pink will be conducting and publishing research around these 7 enablers / constraints.

We want to hear from you on which of these 7 enablers / constraints represent your biggest challenges.

Starting with a survey being distributed at our upcoming Pink Perspectives, and followed by papers and conference presentations, look for more information on this important topic.

Troy’s Thought’s What Are Yours?

”Of course we all have our limits, but how can you possibly find your boundaries unless you explore as far and as wide as you possibly can? I would rather fail in an attempt at something new and uncharted than safely succeed in a repeat of something I have done.” --A. E. Hotchner

However, in my personal opinion there are four primary reasons you do an ITSM process assessment.� Gaining insight and information for project planning is probably the least compelling.

So here are the top 4 reasons you should strongly consider the need to plan a series (yes I said a series) of process assessments.

Reason 1: As I have already mentioned it is helpful and healthy to obtain an accurate snapshot of your current process maturity, gaps and cultural climate to use for planning purposes. This information is useful for setting project priorities, establishing road maps and looking for quick wins to improve current practices. However, more importantly the information and data you gather before you actually fix anything will be critical for reason #4.

Reason 2: Investment validation (building your business case for project funding) is the next critical reason to conduct an assessment.� I am fond of repeating a wise saying I once heard. “It is not real until it is documented” It is a quirky part of human nature that allows us to deny or at least postpone the reality of things that are not documented. Somehow putting it down on paper and making it official forces us to at least consider the need to act on the things we have put off dealing with.

Reasons 1 & 2 assume you only do an assessment up front prior to beginning your improvement efforts.� The next two reasons require you to consider the need to conduct additional assessments following any improvement actions.

Reason 3: So you have deployed new processes, established policies, documented new roles and implemented improved tools. What makes you think that people are going to change their behavior and not revert to the way they have always done things? One of the critical success factors in achieving employee compliance and changing behavior is creating a sense of personal accountability through measurement and yes audit. Another factor of human nature is that we often take the path of least resistance when under stress (and who is not under stress) when we know we are not being measured or held accountable for our actions. I am sure you have heard the quote, “What gets measured gets done!”. By planning for, executing and publishing the results of a series of self or external assessments you are buying insurance on the increased likelihood of deployment success, not to mention continual service improvement. For more information on the subject of establishing personal accountability and employee compliance take a look at the following article.

Employee Compliance A Key Factor For ITIL Process Implementation

Reason 4: The most compelling reason to conduct at least two process assessments (if not more), is the cold hard fact that you will have shown evidence of the benefits and return on investment promises you sold to your boss as part of your ITSM business case.� An ITIL implementation program is always a journey of many steps and you may or may not have had formal funding for your first improvement projects. (Many organizations start this journey in stealth mode and fund their initial actions through existing budgets.) However, eventually you will need to go to the well so to speak to ask for real resources (time, people, tools and money) to support your next targeted improvements. To do this you will have to show your sponsors and benefactors that you achieved something worthwhile in the first round of improvements by pointing to the evidence provided by an initial assessment report. This, of course, requires you to have conducted an assessment before you started to fix things so that you can compare the improved present against the wild west past.� Without the two separate snapshots it will be very difficult to prove that life has gotten better. Yet another one of those quirky human nature elements. “We have short memories!” and “It’s not real unless you document it!”

As I list my four reasons for assessments you may be thinking that the last two points can be handled by metrics and reports that are generated as part of your ITIL project. This may be true in part, but consider that reports are typically targeted at specific activities or Key Performance Indicators. Assessments allow for a much broader snapshot of the current practice and can include observations for all four of the key enablers of any process (Governance, Process, People and Tools). Add to this the power of having an outside objective voice conduct an assessment on your behalf and the power of the report is significantly enhanced.

In summary, conducting a process assessment for the purpose of planning input is only one of the reasons you will want to seriously consider investing time and energy into organizing and conducting an ITSM process assessment. At Pink we offer you several tools and options to equip you for success. Please take a look at PinkSCAN Online

Troy’s Thoughts What Are Yours?

“By three methods we may learn wisdom: First, by reflection, which is noblest; second, by imitation, which is easiest; and third, by experience, which is the most bitter.” ~ Confucius

You see, apart from some fine tuning of existing V2 processes and an improved focus on the concept of IT services and their lifecycle (It is a Service Management framework after all) the real difference is one of scope.

To illustrate this principle consider the story of Dorothy and her journeys in the land of Oz.

The story starts with an economic storm that disorients our heroine Dorothy (or should I say Dot.com) as her house of IT is transported to a strange land of of legislation, controls and new requirements. Basically she is lost without direction or bearings.

Then along comes this sage advisor/consultant (ok so she is a witch but she is a good witch of the North) Canada?

The story continues with Dorothy being told of this wonderful place called the ITIL V2 Emerald City where she will be given the means of finding her way home. (This Emerald City is a place where all Service Support and Delivery processes work together seamlessly under the guidance of benevolent and wise process ownership).

When she asks how to get to this wonderful place her guide says follow the “Yellow Brick” road and gives her an ITSM Roadmap to security and process harmony. (Yes I know I am stretching it here but this is an analogy after all).

Along her journey she gains team mates, each one critical to her success.

Dorothy: Provides the vision and leadership (we’re going to the Emerald City!)
The Scarecrow: Provides the brains and ITIL knowledge
The Tin Man: Provides the heart and passion for Service Management
The Lion: Provides the courage to break away from the technical silo status quo and overcome the many obstacles that they will face.

Ok so you are probably thinking what about Toto? Well Toto is Security Management since he dutifully barks whenever trouble approaches.

So along the way Dorothy and her team fight the good fight against what seems like insurmountable odds. Despite major operational Incidents, such as the Tin Man rusting solid and the Scare Crow catching on fire, the team keeps moving.

However, it looked like it was all over when they were diverted off the ITSM road by the attack of the minion flying monkeys of the project’s political adversary, the wicked witch of the West, who wanted Dorothy’s red slipper resources.

Finally, the team beats the odds and crests a hill after several years of process adoption and sees the ITIL V2 Emerald City shimmering in the near distance.�

However, to their shock, disappointment and despair they see the Diamond ITIL V3 city in the far distance. They realize that the Emerald City was not the final destination after all but only a milestone along the way of continual improvement.

Regardless of the new V3 processes and the now strategic reach of the ITIL framework, organizations will still implement the processes in the same relative order based on the need to first gain operational stability and control over production transition. Only after this is accomplished can they lift their eyes to the more proactive elements of strategy and design.

Who’s to say that as we continue the journey past the Emerald City and crest the hill overlooking the Diamond City that we don’t see at that time the ITIL V4 Platinum City in the far distance.

Troy’s Thoughts, What Are Yours?

“Every day you may make progress. Every step may be fruitful. Yet there will stretch out before you an ever-lengthening, ever-ascending, ever-improving path. You know you will never get to the end of the journey. But this, so far from discouraging, only adds to the joy and glory of the climb.” ~Winston Churchill

Epicor ITSM Webcast

On March 18th I participated in a Webcast with Epicor who have a solution called “Epicor ITSM”. In this webcast session I provided a general update on trends related to ITIL adoption and ITSM tools. You can watch this session “Tools and Trends for Aligning IT with Business Growth” hosted by James Norwood of Epicor at the following Link:

Tools and Trends For Aligning IT With Business Growth

StackSafe Interview

On March 17th I had the pleasure to provide an interview to Dennis Powell of StackSafe which has a very interesting product that supports Release and Change Management in relationship to providing a means to test and assure the production readiness of new releases being deployed to the production environment. Incidentally StackSafe won the Vendor Innovation award at our 12th annual ITSM Conference.

Pink Elephant ITSM Awards

The following is a partial transcript of the interview I had with Dennis and can be found in its entirety with audio on his blog at the following link:

Troy DuMoulin Discusses ITIL V3 and Beyond

Interview Transcript - Part 1

SS: How did you get into best practices and standards, what made you become interested in the topic?

TD: I’ve been doing this for the past ten years and I started getting into it from being introduced to Pink Elephant as one of the first North American employees. We were discussing something new and interesting called ITIL. As I got more into it I realized how rare service management and standards are.

How many industries have a common code of practice for conducting business or doing a certain activity? Think about it, is there a course or university where you can go to get a standard process for accounts payable, or a standard way of engineering? No.

But in IT we have a rare commodity which is a standard approach to managing and delivering services. What I found fascinating is the connection to other things that IT does; relationship to project management, application development, governance, etc.

The challenging part with the growing awareness of service management is that our IT education institutions are still producing people with no knowledge of the management side of IT. They graduate knowing how to create a system, develop an application, and build a data center but have no concept of what it means to be a Service Provider. I find that astounding. The education side of our industry is still behind.

SS: How can companies benefit from implementing ITIL V3? What would you cite as the ROI? (Financial savings? Freeing up resources? Technological advantages?)

TD: The benefit of implementing standards is a big topic. To simplify this, think of IT as three broad categories of activity:

* Managing Operations and Technology,
* Managing Projects
* Managing Services and Service Delivery

These are three different things.

Because of our historical background, we’re very segmented by silo and technology domain. Most frequently organizations will first focus on optimizing and reducing cost in an operational sense, or focus on project management methodologies to improve the ROI on projects to receive benefits more quickly.

The challenge with this is that it is still very fragmented. You can get projects up and running and get good at delivering on time and on budget, or you can optimize the technical domains to a certain point – but the real benefit or cost saving opportunity is when you realize there is all this redundancy across these silos. Each silo has to recreate the same practices over and over again, so there is redundancy across the entire system.

When we talk about version 3 and ROI you have to understand that it’s only when you start looking across the silos for new ways to optimize across the organization as opposed to within a specific project or domains that you begin to get that benefit.

There are three different types of improvement you can realize when you talk about ROI or improvement by using standards: cost-savings, quality improvement, and productivity. We did a survey recently with BMC of 800 companies on usage of best practices and what they got out of it. The majority said efficiency which falls under the categories of productivity and quality. Hard cost savings are difficult to attest to when you don’t have a good understanding of your current costs.

If you think of ROI primarily in terms of cost-savings, then it is very difficult to find justification for implementing practices that don’t currently exist. You will be successful at reducing outages, incidents and failed changes; however, most companies will find it hard to equate these to hard savings. The adoption of best practice typically means the reduction of waste and redundancy; however, it also means an increase in net new activity that was not done before. This means that while quality and productivity can improve dramatically the reduction of cost is less apparent. This is why we prefer to talk about Value On Investment versus Return.

The challenge here is that most organizations have no clue what the current cost of an Incident or failed Change is. Companies ask what is the ROI for implementing a process like Change Management or Incident Management? To answer that question you have to determine what is the current cost of an outage? Once that is identified and reduced by a certain percentage, I can give a real number.

The area where you can actually see a hard cost savings relatively quickly is around the IT Management tools in use in an organization. Many companies have significant redundancy here. When you have multiple monitoring, ticketing, or inventory tools in each silo, you will start to connect the fact that these processes and services are organizational wide – you will begin to understand tool usage is not by domain but is an enterprise issue. You must have a SINGLE workflow process and supporting tool for the entire enterprise. That reduction of redundant management tools based on reduced management and maintenance cost represents true hard savings and ROI from a service perspective.

SS: Are there legitimate reasons why a company should stay at ITIL V2 for the time being?

TD: If you truly understand what version 3 is, you’ll realize it’s not that different. All the processes that you know and understand in version 2 are still inherently a part of the package of version 3 but the scope has simply been enhanced with an increased emphasis on the Service Lifecycle.

An analogy I like to use is the idea of the Wizard of Oz. We have a person who is lost, and they find a path – the “Yellow Brick Road”, which is ITIL. Somewhere out there is the “Emerald City”, which is ITIL version 2, where all these processes are working flawlessly and integrated. On the way to the Emerald City, there are issues that arise (“flying monkeys”) in daily operations, but you continue down the path. Just as you are looking over the horizon, you see Emerald City, and think that’s the end. But to your shock and horror, you realize it wasn’t the end, it was simply a milestone. Beyond in the distance it is the “Diamond City”, which is version 3.

Version 3 is not a different beast or animal, it’s simply a different milestone down the path. The way organizations implement between version 2 and version 3 hasn’t changed. From an operational perspective, it’s the same. You’re simply walking a path and reaching a strategic level.

SS: What is the top challenge that you hear from companies who are in the midst of implementing ITIL?

TD: Without a doubt it’s organizational change and IT culture. The concept of working in a service mindset is a world of difference to a complete focus on the domain where each person manages their box or application as if it lives in mythical isolation from other technologies let alone the business. That comes back to the session in our recent conference in Vegas where I talked about focusing on optimization and cost-reduction as a total goal for IT.

I believe that the majority of executives believe that the “Total” goal of IT is to optimize performance and cost or technology silos. When you do this year over year you get down to the point where you’re razor-thin, consolidating data centers, moving to virtualization, and reducing people resources. You get down to a skeleton crew that is barely sufficient to manage the boxes and the applications, which gives no extra bandwidth to do these service management value-added activities above and beyond the technology optimization.

These organizations now have all these services to provide, but can’t afford to do it with the time and resources they have. There is a total paradigm shift from total cost-reduction as the primary goal to now adding value as a service provider. Being a service organization is about thinking, acting and being different in relationship to business value. The problem is they’re no longer at the resource level to exp