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 statemenet is true. However, in my opinion the reason that the majority of companies go no further is because all of the other processes require a company to fully understand what is an IT service and these companies would prefer to model, manage and organize around these processes.

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

This lack of recognition of IT as a service provider is a global IT reality.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 expend the time and energy to do this. It’s kind of a Catch-22 situation. They want to get better and move to a service perspective, but often don’t have the resources.

Read part 2 of this interview not captured here at the following link:

ITIL V3 and Beyond Part 2

Troy’s Thoughts What Are Yours?

“Sometimes when I’m talking, my words can’t keep up with my thoughts. I wonder why we think faster than we speak. Probably so we can think twice.” ~ Bill Watterson

So why is this topic so important to so many people? In my view it is because the true difficultly in implementing IT Service Management is not a lack of knowledge, resources or tools but it lies in the heart of IT culture, politics and lack of people resources. I wrote of this a while back in a blog post I called “The People, Process Technology Flaw”.

The reality is that most organizations which fail to in their initial attempts at adopting ITIL best practice do so because of an underestimation of the task. The design of a process flow and the documentation of policy and procedure is really not that hard. You can take several smart people, disappear into a meeting room and emerge with a fully documented process in a couple of days. Especially if you leverage a great tool like PinkATLAS.  Ok I am guilty of a little up sell here, but I am very proud of this service

So why does it take several months to even begin to deploy this process? That is because, process design is not the hardest issue you face. While changing work practices is difficult you have to also layer on top of that task the requirement to change (beliefs, values, behavior, tools and management reward and incentive structures.) We might as well realize that what your are really doing is re-structuring the DNA of your organization on a shoestring budget.

Once we realize the true size of the task before us we can start identifying all the issues, risks and road blocks that can potentially cause the project and change effort to falter, stall and fail.

As a wise man once said: “A problem defined is a problem half solved”

Early in my consulting career I came across an excellent exercise to identify and develop a strategy for these types of issues called:

The premise for using this exercise is that you have just formed your new project team and described the vision and scope of the effort to them and you see in their eyes the wordless (and sometimes not so wordless doubts) that plague your own mind. Rather than denying these doubts and gaining an ulcer it is better to get them out on the table so to speak, classify them as fact or fiction and then develop a plan to deal with them.

However, before we go further we need to baseline a few definitions:

• Mountain:A risk with a large impact and high probability to negatively impact to project success
• Mole Hill: A risk with a smaller impact and probability to derail or damage the project effort
• Dead Buffalo: An issue or risk that is perceived or real. However, no one is willing to name it due to political or social risk but it is present in the room like a stinking carcass of a dead animal. (These issues have to be identified and dealt with and hopefully shoveled out the door since they are very unpleasant to have hanging around the room)

To do this I suggest the following team exercise

Duration: 30 Minutes (longer and you risk a spiraling discussion of discouragement)

Objective:

• To provide an opportunity for creative risk identification and classification for issues that will potentially cause the project to fail.
• To separate fact from opinion
• To define high priority issues and risks. The exercise is not intended to solve issues only name them and place them in perspective.

Method:
Using brainstorming techniques discuss all the issues that the group sees as a dead buffalo, mountain or mole hill to achieving a successful process implementation. Each statement must be placed within the following table. (sources of risk: people, politics, resources, time legislation, environment, technology, funding, competing projects....)

Rules:
Define what constitutes “Fact” (group, consensus, historic, documented, measurable?)
Define what constitutes “Opinion” (group disagrees, difficult to measure, not documented)

Output:

• High Risk - Fact Based: Document these risks in the project charter and request the project sponsor / steering committee to provide leadership and guidance. (this is their job)
• Low Risk - Fact Based: Capture and monitor these issues in your project management risk log with mitigation strategies and continue to monitor them as potentials to turn into high risks.
• High Risk - Opinion Based: Assign each of these issues to a team member for further research and follow up to translate them into one of the other 3 categories for the next meeting.
• Low Risk - Opinion Based: Life is too short to worry about everything so drop these off your radar

Summary:
With this useful exercise you have accomplished some key objectives.
You have provided a forum for your new team to begin their team bonding by sharing concerns
You have allowed your team to voice their concerns in the open with a constructive output
You have identified and set actions to key project risks
You have hopefully named and dealt with those nasty dead buffaloes

Troy’s thoughts what are yours?

“Great things are done when men and mountains meet.” ~William Blake

This year the question even got more confusing with the release of ITIL V3 which dictated that the “Password Reset” is not an Incident which is what I thought it was for the last nine years and now calls it a Service Request. The premise being that an Incident is a service impacting event.

Incident: (Service Operation) An unplanned interruption to an IT Service or a reduction in the Quality of an IT Service. Failure of a Configuration Item that has not yet impacted Service is also an Incident. For example, failure of one disk from a mirror set.

Service Request: (Service Operation) A request from a User for information, or advice, or for a Standard Change or for Access to an IT Service. For example, to reset a password, or to provide standard IT Services for a new User. Service Requests are usually handled by a Service Desk, and do not require an RFC to be submitted.

I suppose the thinking here was that the service is still available whether the user of the service has forgotten their password or not. The call to the service desk in this view is a plea from the user to be let back into the service that is happily humming along without them. Oh well I am not going to argue semantics on this one and in this case an old dog is willing to learn some new tricks and terms.

This re-classifying of the Password Reset now prompts another question above and beyond “should we bother recording it.” Now we need to consider whether the action should be recorded in the incident tracking system or the Request Fulfillment tool.

However, whatever you want to call this task we still need to answer the first question. “To record or not record the Password Reset.”

The arguments for and against this activity typically comes from two different schools of thought.

View Point #1: Best practice theory and principles says that every support or request action taken should be recorded in the service management tool. How else will we learn from our past and capture critical business data for reporting and management decision making. Also, it is important to capture the work effort expended in support actions so that we can accurately assess head-count requirements.

This is the classic view point of the ITIL champions and it makes sense from the point of view of logic. However, there is a counter argument to this view that is also based on logic.

View Point #2: Why should we take the time and effort to record password resets. It takes more time to record the bloody ticket then it does to reset the password. If we were to record a ticket for every time a password was reset we would be spending more time entering data into the service management tool then doing the support work we are being paid to perform. In fact if we record every password then customer service is going to suffer since the phone’s and email will not be answered as quickly.  As long as there has been computer systems with a login people have needed password resets. This is a fact of life and it will not change until all security systems are based on biometrics.

As for myself I am an advocate of view point #1. To provide some context for this opinion I will share with you a story from my consulting past.

The year was 1999 and I was managing a service desk for a major insurance organization. I had recently taken on this role as an interim manager on contract and was covering for a maternity leave.

In order to get to know the support issues I asked my new team for the service desk reports so I could get a feel for what types of issues we were dealing with on a daily basis. While comparing the phone stats for incoming calls with the actual incident records opened I found a huge discrepancy between the numbers. Digging a bit further the agents on the service desk were quite open about the fact that the majority of the calls taken on a daily basis were password resets. In fact over 60% of the calls fell into this category and not one of these calls were being captured in the support tool.

To make an already long article a tad bit shorter I convinced the agents after many discussions to begin tracking these calls in the tool. What we observed is that of the all the password resets they were doing over 50% were from a single mainframe based application.

Now curious and wanting to improve the performance of the service desk team I was managing, we did some digging aka “Root Cause Analysis.” It turns out that the security team had developed a policy so strict for this application that it was almost impossible to come up with any password that could be hacked and for that matter remembered by the users. To ensure that each user had a strong password they had removed the ability to use common words like the days of the week, common names or the months of the year and so on. On top of this they had built in the requirement to change the password every 30 days and of course you could not use the last 9 passwords you had previously.

Having this data I took the information to the security group and explained the service issue and request a change the the security policy for this application. To say they were unmoved by my argument would be an understatement. I was the service desk manager and a contractor on top of that and they were the security group, keeper of the keys.

So with a polite but firm statement that they were not about to change anything, I left the meeting.

For the next 2 months we carefully tracked the volumes of password reset against this application. With this data we developed models which demonstrated the business cost of hundreds of password resets a week on one application. Armed with this data with a business value attached I requested another meeting and presented our case again within the context of financial and productivity impact. The outcome was modest but still was an improvement. They changed the policy from 30 days to 60 for password changes.

Not much of a victory perhaps but this story does shed light on why I believe it is important to capture and record password resets in your service management tool. Yes every one!

The irony of my story is that during this process I found out that the agents were giving the users passwords that they knew would work. These ready made passwords were kept on sticky notes and posted on the walls of their cubicles. So much for security.

So in conclusion, yes it is important to capture data about password resets regardless of the effort.

Troy’s thoughts, what are yours?

What is not defined cannot be controlled!
What is not controlled cannot be measured!
What is not measured cannot be improved!

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. Those of you who follow my posts will recognize a familiar theme in this statement. 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 function in your organization that manages and supports IT tools which are used by the enterprise IT function?
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 over the last 10 years 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. This scenario I address in the following article.  When ITIL Projects Collide

The following picture represents the concept of an integrated tool architecture with a focus on IT operations. As you can see from the diagram you could develop a whole new set of boxes on the development side of the IT house for the category I have listed as “Resource and Portfolio Management Tools”

With this picture in mind let me walk you through the following use case.

A business customer submits a request via the online service catalog for an enhancement to an application service. This request is fed into the Change Management process where the approval initiates the assignment of a development resource. The development resource engages with the release and deployment process during the build and test phases of the enhancement.

Once the release has been tested and validated as production ready the change process validates and coordinates the scheduled update of the production version of the application service. Triggered by the approved change schedule the provisioning tool picks up the code within the definitive media library and updates the production environment. As a final step and after validation that the release has gone without an issue that requires a back out of the change the CMDB is automatically updated with the new version number.

Sound like Fantasy? Not if you have integrated IT management tools. This concept diagram is exactly what the major ITSM vendors are striving for and is the basis for much of the merger’s and acquisitions you hear about on a regular basis. The prize they are after is a management tool to run the majority of your IT shop.

Two questions come to mind:

1. Are the tools there yet? (Many of you would agree with the direction but say we are several years off)
2. Is the average IT shop culturally and organizationally ready to take advantage of an Integrated IT Management suite?

In my view the same business logic that argues that Enterprise Resource Planning (ERP) tools like SAP or ORACLE Financial makes sense for the business (integrated modules connected to common data repositories) applies here as well. Some call this ERP for IT

Troy’s Thoughts What Are Yours?

”Where we have the choice between putting a dollar against those that are going to advance horizontal integration and those that are going to sustain current capability, we’d rather put them against the horizontal integration activity.” ~Stephen Cambone

A critical aspect of understanding IT Service Management is the ability to distinguish just who you are trying to serve.

As a reader you might read this first statement and raise an eyebrow at what seems to be an obvious question since you probably have a fairly good perception of who you believe your customers to be. However, the keyword that I just used in the last sentence is the word “perception”. You see the thing about perception, or to use a related word “Perspective” is that it changes based on where you are currently standing. 

So the question is, where am I going with this bizarre line of logic?

Consider that many of the articles in this Blog discuss the concept of maturity and the changing role of the IT function within the business. That change is the evolution of focus from technology optimization to the additional concept of service provision. During this journey of discovery there are at least three different answers to the question: Who is my customer?

Before I launch into this further let’s establish a few definitions.

Customer: A customer is an individual or group of individuals that uses or consumes products and services that you offer. The word customer derives from the english word custom. The context is a shop keeper who has a client who’s custom it is to come into the shop on a regular basis and purchase products or services unless that custom is disrupted or broken based on an unsatisfactory experience. In which case the custom of buying at the shop is stopped and they are a customer no longer.

Perspective: To establish a point of view or belief based on a filter of observable and experiential sensory evidence. As the saying goes: “Perception is reality”

Now that we have established my layman’s view of these two definitions consider the following maturity model.

The Changing Role Of IT Within The Business

1. IT is focused on technology optimization, infrastructure and applications are managed as separate and largely unrelated domains.
2. IT is focused on the integration of technology and the delivery of end-to-end systems (Business Solutions).
3. Enterprise IT (Applications & Infrastructure )groups have a single strategy and are focused on business process automation; however, IT sees itself as different and distinct from the business functions.
4. IT realizes that it provides a core business function and that there is no practical way to separate the digital business process from its underlying technology systems. The IT function considers itself one of many business functions. 
5. IT’s focus is enabling business services and products for use and consumption by outside customers.

As an organization moves through these five stages of maturity the answer to who is the customer changes.

• Stage 1: The question of who the customer is, is not even asked
• Stage 2: The customer is understood to be other IT groups or domains that need products and services for their part of the offering. Eg: Server Hosting for an applications group. (The exception here is the application group which understands the business units to be the customer)
• Stage 3: The customer is understood by the entire IT function to be the business units they enable.
• Stage 4 & 5: The customer is now the external customer of the organization, firm, hospital, etc.. (In addition to the IT and Business Unit Customers)

Remember that I commented above that perception and perspective are based on where you are standing!

However, what is equally true is that each definition of customer is true at all stages. So when you are defining your services to publish in the service catalog, who are you focusing on? In reality, you will have IT services defined for each type of customer so your service catalog should enable you to display different services and service types based on role.

Examples:
* IT Customer
* Business User Customer
* Business Unit Customer
* External Business Customer

Troy’s Thoughts, What Are Yours?

“The Total Perspective Vortex, in the fictional world of Douglas Adams’s The Hitchhiker’s Guide to the Galaxy, is the most horrible torture device to which a sentient being can be subjected. Located on Frogstar World B, it shows its victim the entire unimaginable infinity of the universe with a very tiny marker that says “You Are Here“ which points to a microscopic dot on a microscopic dot........ 

Automation Is The Key To Managing Complexity

A key strength of the ITIL framework is the fact that it gives us an integrated process model for delivering and supporting IT Services. It provides insight and guidance into the fact that processes have direct and indirect inputs and outputs to each other. This logical integration makes sense when read in print, but becomes overwhelming to keep in the forefront of your mind when you are faced with the daily task of managing an IT operation.

One of the most compelling reasons to adopt and implement a formal process within an organization is when you realized that the complexity of your support environment can no longer rely on tribal knowledge and best effort service levels when dealing with the delivery and support of business critical IT services. The same argument can be used for the necessity of using integrated IT service management systems over simple tools such as email or excel spreadsheets.  In time simple tools no longer provide the support you need for your processes.

In my personal opinion you can’t even get close to the level of process integration and efficiencies ITIL describes without an investment in an IT Service Management tool that focuses on integration of key processes over a best of breed approach for a single process. However, based on a historical approach of buying best of breed we have a tendency to select the best hammer in the market when our overall needs would be better suited by a reasonably priced multi-function tool.

To provide an example lets examine a use case scenario of automating a SLA.

Assumptions:

1. You have set targets for service restoration and published them to your clients
2. You have defined and established an enterprise IT policy and Operational Level Agreement for Prioritization (The Practicality of Prioritization)
3. You have implemented an IT Service Management tool that supports Incident Management and is integrated with a CMDB
4. The tool that you are using has a common business rule engine across process modules that enables automated assignment, escalations and notifications through email or paging systems.

Ok with these assumptions lets play through a support scenario:

Step 1: The Phone Rings At the Service Desk and A User Reports That An Application Service Is Not Available.

Using a set of general questions the service desk agent determines and records the Impact (scope) and Urgency (time sensitivity) of the call. The Service Desk agent will also do their best to classify the incident record by business service and technology failure based on the information they gain from the caller. (Its Classified)

This initial classification combination of what has failed and the relative Impact and Urgency establishes the Incident priority and the initial SLA target that will have a pre-defined set of of time and role based escalations and notifications automated by the business rule engine.

However there is more!

Step 2: Assigning The Person Record and Impacted Organization to the Incident Record.

We now have to consider that not all people are equal when it comes to support and service level agreements. People also have records in the IT Service Management tool with attributes that describe who they are, the function they play within the organization and their relative importance to the business. (role or position)

This means that each person record can have its own SLA target associated to either the organizational group they belong to or attached to their personal record.  The tool that you are using should be capable of assigning a unique SLA target to the person record that once associated to the Incident record overrides the initial SLA target if the VIP status of the person or organization in question requires a faster or higher level of service.

Were not done yet!

Step 3: Attaching A Configuration Item (CI) Record From the CMDB to the Incident Record

One of the most basic things that an integrated CMDB will support is the ability to attach a CI record to a workflow record such as an Incident, Problem, Release or Change record. In terms of this article a key reason why this is important is that just as people are not equal relative to IT support, neither are CIs.

Consider the common example of a server that hosts various applications. It is probable that the various applications hosted on this server have different levels of business criticality and for that reason have different Service Levels assigned to them. However, the server in question hosts them all so what SLA would you attach to that component? The answer of course is that it has to inherit the highest SLA of the various services it supports. This means that the server itself can also be assigned its own SLA through either inheritance from the application service or direct SLA association.

Now when you attach the CI record to the Incident record it compares the SLA target it carries to the one from the initial classification in step 1 and potentially overrides the initial SLA target with its higher level target just as we observed with the person record.

Summary:

As I mentioned earlier this may seem logical in print. However trying to keep all of this in mind when you are under fire in the trenches of IT support is practically impossible. This level of complexity truly requires automation, but before you can automate escalations and notifications to support SLA targets as I have described you need to define them on paper and get agreement to them first.

Troy’s thoughts, what are yours?

Complexity that works is built up out of modules that work perfectly, layered one over the other. ~Kevin Kelly

Enterprise Architecture as Strategy

It appears that I am on a book theme and since the holidays are close upon us and you may find time during this busy season to curl up by the fire with a good book I would like to recommend one of the best “Business” reads I have enjoyed this year.

”Enterprise Architecture As Strategy” published by Harvard Business School and produced by MIT Sloan Center for Information Systems Research (CISR) is a very useful and insightful book for those of you who spend your time thinking about IT Service Management issues and opportunities at an executive or senior level. One of the reasons I found this book interesting is that it is written from a different perspective than the books and articles you typically see put out by the various groups that support and endorse IT Service Management and ITIL. In many ways this book has a stronger and more compelling message in terms of gaining IT executive buy in for Service Management than the ITIL books which approach the concept of IT strategy from the perspective of business value generation.

There are many key messages in this book but the one I would like to highlight for this article is what the authors refer to as “The Four Stages of Architecture Maturity”. If you have read many of my other posts you will begin to see that I have a thing for maturity models and discreet lists. The point of this maturity model is that there is an observable trend of how organizations are centralizing and standardizing their use of shared IT resources such as common Infrastructure, business applications, data, and general IT management practices.

The CISR analysis and research states that they observe most IT organizations progressing through a similar pattern of architectural maturity.

Four Stages of Architecture Maturity

1) Business Silo Architecture: (Locally Optimal Business Solutions) Where companies look to maximize individual business unit needs of functional silos

At this stage of maturity, most business units invest in their own unique IT solutions and are likely to have their own data center and managed infrastructure. Process and management practices, if they exist, are focused at the business unit silo.

2) Standardized Technology Architecture:(Enterprise-Wide Technology Standards) Providing IT efficiencies though technology standardization and, in most cases increased centralization

At this stage of maturity IT organizations are moving to shared data centers and centralized IT infrastructure services such as email and telephony to achieve economies of scale and lower transaction costs. In addition you will also see investment in building increased application integration and data warehouses based on data source federation. In my experience it is at this point that you will also see companies establish a common Service Desk strategy and implement early stages of processes such as Incident, Request Fulfillment, Change and Problem Management. More advance companies at this stage will also move towards Service Catalog development and early implementation of Release and Deployment Management.

3) Optimized Core Architecture: Standardized Enterprise Processes/Data Company wide data and process standardization as appropriate for the operating model

While the second stage of maturity sees companies consolidate shared infrastructure and build complex data warehouses to aggregate business data with disparate data structures. Stage three sees the redevelopment of business applications from stand alone point solutions to modular application suites with common data structures, making the data warehouse model less required.  Based on this level of service integration the implementation of IT Service Design and Transition processes would be critical. For example, one can speculate that there would be an urgent need to implement the IT Service Strategy and Service Design processes such as Service Portfolio, Availability, Capacity, Release, Transition Planning, etc..

4) Business Modularity Architecture: (Standard Interfaces and Business Componentization) Reuse loosely coupled IT Enabled business process components (services) to preserve global standards while enabling local differences

The fourth and final stage of this model represents an IT Architecture maturity level where common IT Services and their supporting management practices and process are at a level of maturity that then can be re-used or re-deployed rapidly into new markets and customer opportunities. Consider that this is as similar to a franchise model where the business can leverage their mature IT Services and repeatable IT management practices for rapid growth, deployment and high value generation. (I know it sounds like IT Shangri-La, but one can hope can’t they?)

So in summary, if you are looking for that perfect Christmas gift to give to your executive to sell them on the benefits of IT Service Management considering rush shipping this book from Amazon into their hands. However, don’t forget to buy your own copy or at least read it first.

Troy’s and MIT’s thoughts, what are yours?

”Start with the end in mind” Seven Habits of Highly Successful People ~Stephen Covey

Surf’s Up—Grab Your Board

It has been two weeks since our whirlwind Asian tour that took us to Beijing, Shanghai, Kuala Lumpur and Singapore and I am still suffering from the last vestiges of jet lag.

While I am no stranger to life on the road, this particular trip gave me new and very important insights into the growing global markets blossoming in the regions of South East Asia and Greater China. In my last post I talked about a book called “The World is Flat” written by Thomas Friedman that explores the effect these growing economies are having on the global market. Much has already been said and written on how off shoring and international outsourcing opportunities are changing the labour market across the globe.

An area that has not received the same literary attention has been on the declining ability of IT professionals to differentiate themselves from their peers. We have traditionally done this by seeking out and stockpiling technical certifications to attach to our resumes. The principle being that the more Microsoft, Cisco, Novel, etc… certifications one obtained the better positioned we were for the good paying jobs. Yes, experience is the true test of our abilities but it was often the number of certifications that initially got us that first interview.

However, what happens when these certifications flood the market and now countless thousands of Asian IT professionals seek and gain these same certifications but offer their services at a much lower cost. The answer is that these certifications become commoditized in a flooded market.

This trend then puts pressure on individuals and organizations looking to differentiate their workforce and services to find new badges and certificates to obtain. 

In my opinion this observation is one of the primary drivers behind the rising interest in education and certifications that are oriented at Enterprise IT Management practices rather than a pure technology focus. Examples of these types of certifications focus on enterprise IT roles such as: Service Management, Security Management, Project Management, Solutions Architecture and Information Risk Management.

While the need to differentiate oneself in a crowded market is indeed an effective driver, I see three primary contributors to this rising interest.

Three Drivers For Enterprise Certifications

1. The evolution of the IT organization from technology to service management. The Service Organization
2. The rising interest and adoption of general IT controls based on growing legislative and compliance requirements.
3. The growing commoditization of technology focused certifications.

At Pink Elephant we have certainly seen this trend proven in the growth of our ITIL and COBIT education business and this is validated in the exam statistics provided by EXIN and ISEB. If you look at their statistics, interest and growth in ITIL certification more than doubled starting in 2005 from the previous yearly trends (coincidentally the same time period when these three drivers began to kick in).

Ask yourself if this is truly a coincidence or are there profound drivers at play here that are re-shaping the focus of our industry and personal IT careers. Just as a last piece of information consider that in 2005 more than 25% of the ITIL certifications globally were awarded in China.

Yes the world is flat after all!

Troy’s thoughts, what are yours?

”It’s a small world but I wouldn’t want to paint it” ~Stephen Wright

The World Is Flat After All

As some fellow Pinkers and I head off for an Asian tour to share knowledge about IT Service Management and ITIL I find myself reflecting on the power of a common definition of terms as a tool for communication and collaboration. Throughout history the power of the spoken and written word has been without a doubt one of the most important tools in developing a vibrant local and regional economy. However, due in part to the great diversity of languages spoken around the world and their geographical separation, these economies have been largely regionally contained.

Consider however what happens when the boundaries of your “Local Village” begin to expand or disappear due to the introduction of web based collaboration technologies, rapid transit and shipping capabilities that enable you to setup a call center anywhere in the world and have a product shipped to any location within the period of 5 business days.

The answer to this question is explored in a very interesting book called “The World Is Flat” written by Thomas Friedman.:

The World Is Flat: A Brief History of the Twenty-First Century is a best-selling book by Thomas L. Friedman, analyzing the progress of globalization with an emphasis on the early 21st century. ----- Friedman recounts a journey to Bangalore, India, when he realized globalization has changed core economic concepts.[1] Due to this discovery, he suggests the world is “flat“ in the sense that globalization has leveled the competitive playing fields between industrial and emerging market countries.  Wikipedia

In his book Friedman explores 10 flatteners, so to speak, that have created a leveled economic playing field. For more information on these 10 flatteners check on the link to Wikipedia I have posted above.

However, I would like to extend Thomas’ model with the additional consideration of common language or at least the adoption of a common definition of terms as an important enabler of this global economy.  From an IT context this can be seen evidenced by the global adoption of accepted IT Management frameworks such as ITIL, COBIT, CMMI, etc. My belief is that the adoption of these best practice frameworks plays a critical role as an enabler to international communication and collaboration within organizations and providers alike. 

One of the primary benefits of adopting an IT Management Framework such as ITIL has been the accepted use of a common vocabulary and lexicon. For example, consider your own work life experience in your local office or plant environment. How much time is spent in meetings, email trails or other forms of communication arguing about what is meant by a specific term such as “What is a change?” Now add to that conference calls and discussions with other regions, languages and cultures within your own company not to mention the inclusion of vendors and managed service providers and your head begins to hurt.

In short, significant time is wasted every day simply dealing with the challenge of basic communication that could be better spent on problem solving and getting things done.

This is where the power of standards comes in, Friedman addresses this several times in the context of his 10 flatteners and I would suggest that in this context the use of common definition of terms and IT business processes across companies, vendors, regions and continents goes a long way to facilitating the reality of an international collaboration.

Since I am obviously a big Douglas Adam’s fan I can’t help but throw in a reference to the “Babel Fish.” Of course for those of you readers that have never read the “Hitch Hiker’s Guide to the Galaxy” this reference will not make any sense. So to provide some context before you think I have veered off on some strange tangent . The Babel Fish according to Douglas Adam’s fictional writings is this amazing fish that once stuck in your ear translates all foreign language into something you can understand. 

“The Babel fish is small, yellow and leechlike, and probably the oddest thing in the Universe. It feeds on brainwave energy received not from its own carrier but from those around it. It absorbs all unconscious mental frequencies from this brainwave energy to nourish itself with. It then excretes into the mind of its carrier a telepathic matrix formed by combining the conscious thought frequencies with nerve signals picked up from the speech centres of the brain which has supplied them. The practical upshot of all this is that if you stick a Babel fish in your ear you can instantly understand anything said to you in any form of language.” ~ Douglas Adams

Since we can’t put our hands on such a useful animal as the friendly Babel Fish the next best thing we have is the adoption of a common definition of terms using these accepted IT Management frameworks.

So next week when David and I are speaking with IT Management professionals from Bejing and Shanghai about IT Service Management and ITIL, one of the benefits we will be promoting is the sociological and economic benefits of adopting a common definition of IT Management terms.

Troy’s thoughts, what are yours?

“I know that you believe you understand what you think I said, but I’m not sure you realize that what you heard is not what I meant.” ~Robert McCloskey