PM Blog: Alan S. Koch

ITIL in an IT Services Company

2013-04-24T09:39:26-07:00

by Alan S. Koch, PMP

A while ago, Cinda Voegtli, CEO of Project Connections engaged me in a conversation about why she as a business owner should care about ITIL. That back-and-forth turned into an article that ended with an open invitation to answer your questions about ITIL. Reader "RRP" took us up on that offer, and my e-mail back-and-forth with him proved to be interesting in addition to being a lot of fun! What follows is an edited transcript of our exchange. Our conversation may help you figure out how to start a productive dialog with your customers in environments where IT is perceived as a utility, and IT service conversations as background noise.

What's the Point of Having a Framework?

RRP: The other day I was having a discussion with my elder brother, who is not in IT but is somewhat informed about the industry. I was telling him about my work training and promoting ITIL, which guides IT organizations/service providers in delivering quality services, aligning with the business needs, and enhancing their Service Management capabilities. My brother questioned if that applies to only IT service or to any service.

I was not sure how to answer, but I said: Because IT is not especially mature or standardized, the industry has been struggling to manage the services being delivered and supported. ITSM [Ed. Note: IT Service Management] best practices were learned from other service industries such as hotels and airlines, and applied to IT. Maybe these best practices can be used by other industries, but there is another name for that: BSM (Business Service Management).

Alan S Koch (ASK): Your answer was right on the money. ITIL is based on timeless principles of Customer Service that have been the basis of much good work over the decades (centuries?) ITIL takes those timeless principles and wraps them in practices that are very IT-specific.

One of my clients is the IT director of a hospital services company. She correctly saw that much of ITIL could be used to improve the hospital services their company provides. But that would require distilling the customer service principles out of ITIL and wrapping them in hospital-specific practices. (That turned out to be more work than the CEO was willing to expend.)

RRP: I was trying to explain to my brother that the ITIL framework fulfills several needs: It helps the service provider understand what services he is providing from both the perspectives of customer and Service Provider; it supports customer outcomes; it helps the provider understand that their services do facilitate the business value which is as defined/measured, and also bears on the specific risks and costs involved.

My brother said, it looks like more "management crap" like Six Sigma, which needs management support, lots of money, people's acceptance (which can drive attrition), and in the end it still does not succeed.

ASK: Your brother is not alone in his jaded view, and this view is based on the reality that many companies have indeed wasted too much money on these sorts of frameworks. Six Sigma, ISO 9000, PMBOK, CMMI ... and now ITIL.

The key difference between companies who have gotten real benefit out of these frameworks and those that simply wasted money boils down to their approach. The money-wasters try to "implement" the framework. They read the book, take the training, and then simply do what it says. The companies that benefit use the framework as a reference, and ask themselves how they can make their companies run better by exploiting the practices in the framework.

My favorite approach to keep clients from the money-waster mindset is to use more than one framework at the same time. With my current client, I am referencing ITIL, CMMI-SVC, and the PMBOK® Guide. So when someone wants to do something "the ITIL way," I can say, "But CMMI says this ... Let's look at which fits us better."

Defining Services and Building Relationships

RRP: I told my brother there are more than 10,000 organizations ranging from IT and non-IT organizations such as Disney, who have implemented these practices and reaped benefits. He asked how my training is going to help the individual employees who are not even aware what the contract/project agreement says; they don't have access to SLA document/Catalogue etc.

This is where I was dumbstruck.

ASK: Tell me about the project you're currently doing.

RRP: It's a Production support project, and it's divided in to IT (Application Development and Testing), and IS (Apps support, Change, Release, Service Desk, Incident Management, Enterprise Windows/Unix/DBA). No one understands the services we are supporting, as we are speaking in technology lingo: DNS service, Windows service/Unix servers, applications, etc. That's the structure of the teams.

ASK: What products and services does your company provide to your company's customers?

RRP: Our company provides a wide range of information technology-related products and services including application development; business process outsourcing; capacity planning; consulting; enterprise software; hardware sizing; payment processing; software management; and technology education services.

ASK: Who (generally) are your company's customers, and how do they use the products and services that your company provides to them?

RRP: Our company's customers include industry types ranging from healthcare to banking to telecom. The customer I'm supporting is in a NA Telecom company.

ASK: How does the work you are doing on your projects relate to the products and services that your company provides to your company's customers?

RRP: I work in the release and deployment process for a production support project, managing day-to-day release activities and change requests. It's a Time & Materials project, so I'm not really sure what is in the Master Service Agreement, but this project is not based on an SLA so there's no way to see the services our day-to-day tasks are helping. Our project is structured with all the technical management, application operations, service desk, Incident Management functions and processes.

So how can I talk about ITIL here? Service Agreements/contracts, Service Catalogue, SLA documents, etc. are not visible to us as the support/development/process managers. I doubt even our Service Delivery Manager has access to it. I'm not able to connect to what we are doing in day-to-day operations, and how ITIL will help.

ASK: ITIL makes a big point out of saying that most of our Customers use the IT Services that we provide to them as a means to provide their services to others. (e.g. The finance department uses IT Services to provide financial services to someone else.)

Your company is an IT Service provider. What can be confusing is that your customers are also IT Service providers (the IT departments of banks, Telecoms, etc.). The SLAs, Catalogs, etc., that you do not see are between your customers and their customers. What I hope you do have are SLAs, Catalogs, etc. between your company and your customers (the IT departments).

Your lack of visibility into your customers' commitments to their customers is a common problem for IT Service providers. Your services are being treated as utilities by your customers: "Just give me what I ask for and leave what I do with it to me." To act as ITIL expects us to, we must have a closer relationship with our customers and better visibility into how our services enable their services.

ITIL's Customer Relationship Management process (newly formalized with the 2011 update) is designed to build just that kind of relationship. As with any relationship, you will not be able to build it overnight. But the more effort we put into it, and as our customers (the IT departments) see that they benefit when we get insight into what they do with our services, the more open that relationship will become. At least, that is what we hope! (By the way, the Service Delivery Manager you mentioned in your initial message may be what ITIL calls the Business Relationship Manager.)

Just Give Me SMTP and Nobody Gets Hurt

RRP: In an ITIL training session one of the participants asked, Our company has only incident and problem management to deliver, so will these be services in real sense? If so, how will we catalogue only these services? (IT service Catalogue process)

ASK: Incident and Problem management are not really services; they are processes you use to support the services you provide. An Incident is defined as an interruption or degradation of a service. Give me an example of what has been interrupted or degraded when you are doing Incident Management.

RRP: Email is one of the services we provide incident management support for. The other day there was an outage of several hours, almost a day, and Microsoft's SMEs were on the call to resolve the issue.

ASK: When you look at it as I described above, you see that e-mail is one of the many services that you provide to your customers (the IT departments). You listed several other services in response to my first question (above): "application development; business process outsourcing; capacity planning; consulting; …". When you are doing Incident Management, you are supporting those services.

RRP: One last question: How do organizations manage their service delivery without using or being aware of ITIL?

ASK: ITIL is a collection of "best practices" in IT Service Management. Where did these "best practices" come from? The library that was ITIL v1 (though it wasn't called that) was compiled in the 1980s. But the IT industry (it was called "Data Processing" then) started 30 years earlier. Organizations just figured out how to do things, and some organizations figured out how to do some things really well.

The same is true today. Innovative people can figure this stuff out for themselves. But why waste the time and effort re-inventing the great practices that have already been collected into ITIL?

Got an ITIL Question? Let's talk about it! E-mail me at ask@ASKProcess.com.

Process Genesis*

2013-02-12T13:48:05-08:00

Chapter 2 of 2 -- In the Department of Eden

Last time, we recited Process Genesis Chapter 1, Creation. This time, we continue with Chapter 2, and recite the story of the first Process Owner, Manager, and Auditor.

Process Owner and Process Manager

The Lord God hired a man and assigned him the Role of Process Owner, and the man took on that Role.

Now the Lord God had planted a department in the east, in Eden; and there he put the man he had hired. And the Lord God made all kinds of activities grow out of the ground -- activities that were pleasing to the mind and good to do. In the middle of the department were the activity of Resourcing and the activity of Doing Things in Other Ways.

The Lord God took the man and put him in the Department to work it and take care of it. And the Lord God commanded the man, "You are free to do any activity in the department; but you must not do the activity of Doing Things in Other Ways, for when you do it your process will surely die."

The Lord God said, "It is not good for the Process Owner to be alone. I will make a helper suitable for him."

Now the Lord God had hired all the employees of the company and all the contractors. He brought them to the Process Owner to see what he would name them; and whatever the Process Owner called each worker, that was its title. So the Process Owner gave titles to all the workers, the employees of the company and all the contractors.

But for the Process Owner no suitable helper was found. So the Lord God caused the man to fall into a deep sleep; and while he was sleeping, he took some of the Process Owner responsibilities and closed up the place with oversight. Then the Lord God made a new Role from the responsibilities he had taken out of the Process Owner, and he brought her to the man.

The Process Owner said, "This is now planner of my plans and leader of my workers; she shall be called 'Process Manager' for she will manage my Process." For this reason a Process Owner will remove some of his Responsibilities and delegate them to his Process Manager, and they will become one team.

The Process Owner and his Process Manager were both politically vulnerable, and they felt no fear.

Process Auditors

Now the Team Lead was more crafty than any of the workers the Lord God had hired. He said to the Process Manager, "Did God really say, 'You must not do any activity in the department?"

The Process Manager said to the Team Lead, "We may do the activities in the department, but God did say, 'You must not do the activity that is in the middle of the department, and you must not touch it, or your process will die.'"

"Your process will not surely die," the Team Lead said to the Process Manager. "For God knows that when you do it your eyes will be opened, and you will be like God, capable of Doing Things in Other Ways."

When the Process Manager saw that the activity was good for doing and pleasing to the mind, and also desirable for Doing Things in Other Ways, she did it. She also told her Process Owner, who was with her, and he did it. Then the eyes of both of them were opened, and they realized they were politically vulnerable; so they formed a committee to cover themselves.

Then the Process Owner and Manager heard the sound of the Lord God as he was walking in the department in the cool of the day, and they hid from the Lord God among the activities of the department. But the Lord God called to the Process Owner, "Where are you?"

He answered, "I heard you in the department, and I was afraid because I was politically vulnerable; so I hid."

And he said, "Who told you that you were politically vulnerable? Have you done the activity that I commanded you not to do?"

The man said, "The Manager you put here with me -- she told me about it, and I did it."

Then the Lord God said to the Manager, "What is this you have done?"

The Manager said, "The Team Lead deceived me, and I did it."

So the Lord God said to the Team Lead, "Because you have done this; Cursed are you above all the employees and all the contractors! You will serve on committees and you will make presentations all the hours of your day. And I will put enmity between you and the Manager, and between your successors and hers; he will crush your motivation, and you will strike his productivity."

To the Manager he said, "I will greatly increase your pains in leadership; with pain you will lead your workers. Your duty will be for your Process Owner, and he will rule over you."

To the Process Owner he said, "Because you listened to your Manager and did the activity about which I commanded you, 'You must not do it;' Cursed is the Process because of you; through painful toil you will oversee it all the hours of your day. It will produce errors and defects for you, and you will have to answer to Process Auditors. By the sweat of your brow you will guide your process until you lose your job, since you were hired; for an employee you are and employment is 'at will'."

The Lord God made a Process Governance Board for the Process Owner and his Manager to give them political cover. And the Lord God said, "The Process Owner has now become like one of us, Doing Things in Other Ways. He must not be allowed to reach out his hand and take also from the activity of Resourcing." So the Lord God banished him from the Department of Eden to work the unending departments. After he drove the Process Owner out, he placed on the east side of the Department of Eden administrators and a flaming bureaucrat flashing back and forth to guard the way to the activity of Resourcing.

and so it began.

*Apologies:

Apologies to those who are not of Judeo-Christian heritage for not using your creation story.

Apologies to those who are of Judeo-Christian heritage for butchering your creation story.

Process Genesis*

2012-12-04T09:15:52-08:00

Chapter 1 of 2 -- Creation

In the beginning, God said, "Let us create!"

And the unnamed Us asked, "What is this 'Create'?"

And God said, "Let there be Process." And it was so.

And God made a Creation Process. And He socialized it with the unnamed Us, and explained, "A Process is a series of Activities that is triggered by a specific event or condition and transforms inputs into outputs in order to achieve a purpose. Because we will be creating many things, we need a Creation Process to guide all of our work, and to help us to Create all of those things consistently and efficiently."

Then God presented an Overview of the Creation Process to the unnamed Us. He explained:

The Purpose of the Creation Process and
The Outcomes the Creation Process was supposed to achieve.

And God saw that the Process was good. And there was evening, and there was morning -- the first day.

2nd Day

And God said, "Let us create!"

And the unnamed Us said, "We're not really sure how this Creation Process works."

And God said, "Let there be Process Structure." And it was so.

And God made structure in the Creation Process. And He socialized it with the unnamed Us, and explained, "Every Process has structure, which defines how the Process works."

Then God described the structure of the Creation Process to the unnamed Us. He explained:

The Triggers that will cause them to begin Creating something
The Inputs that they will use as they Create things
The Activities that they will do as they Create
The Outputs that they will produce as things are Created

And God saw that Process Structure was good. (And the unnamed Us finally understood the Creation Process well enough to agree!) And there was evening, and there was morning -- the second day.

3rd Day

And God said, "Let us create!"

And the unnamed Us said, "Explain this Creation Process to us again, for we don't remember everything you said yesterday."

And God said, "Let there be Process Documentation." And it was so.

And God made documentation for the Creation Process. And He socialized it with the unnamed Us, and explained, "Every Process must be documented so people can learn how to follow it and be reminded of things they may forget."

Then God delivered the Creation Process documentation to the unnamed Us. He explained that the:

Process Overview contained the Purpose, Outcomes and a high-level description of the Creation Process
Activity Streams for each part of the Creation Process contained a flowchart and explanation of the activities involved
Procedures detailed precisely how to perform the more complicated Creative Activities
Standards specified each kind of thing they would be Creating
Templates would provide a starting point when they were Creating something from scratch
Guidelines explained how to make decisions while they were Creating (for example, when to evolve an existing thing vs. starting from scratch) and how to handle difficult situations
Forms and Worksheets would lead them through the steps of Creation and capture important information about the things they Created
Training Materials would teach them the details about how to Create and help unnamed Us who would be hired in the future to become productive quickly

And God saw that Process Documentation was good. And there was evening, and there was morning -- the third day.

4th Day

And God said, "Let us create!"

And the unnamed Us asked, "Who is supposed to be doing what as we Create?"

And God said, "Let there be Roles and Responsibilities." And it was so.

And so God made the Roles and Responsibilities for the Creation Process and updated the Creation Process Documentation. And He socialized them with the unnamed Us, and explained, "Each activity in a Process is the responsibility of a specific Role, and these Roles are assigned to people. A Role might comprise many people (like a team). And an individual might be assigned multiple roles."

Then God delivered the updated Creation Process documentation to the unnamed Us. He explained the:

Role Descriptions in the Creation Process Overview. For each Role, He gave it a name, described it in general terms, and related it to the existing organizational structure of the unnamed Us.
Swim Lane Diagrams in the Activity Stream documents (that replaced the flowcharts). In the Swim Lane diagrams, each Role that participated in that part of the Creation Process got a Lane, and the activities that Role was responsible for were placed in that Lane.
RACI Matrices in the Activity Stream Documents. For each Activity in that part of the Creation Process, the RACI matrix showed which Roles were:

Responsible for doing the creating
Accountable for enabling the Responsible Roles and overseeing the creation
Consulted by the Responsible Roles as they created
Informed by the Responsible Roles about creation

Role-Specific Training Materials (that replaced the generic Training Materials). So each person would receive only training that was pertinent to his or her Roles.

And God saw that Roles and Responsibilities were good. And there was evening, and there was morning -- the fourth day.

5th Day

And God said, "Let us create!"

And the unnamed Us asked, "How can we know if this whole Creation thing is working as it should?"

And God said, "Let there be Process Metrics." And it was so.

And so God made Metrics for the Creation Process. And He socialized them with the unnamed Us, and explained, "Remember the Purpose and Outcomes we discussed for the Creation Process back on the first day? We need to measure attributes of the process or its outputs that will help us to know if it is achieving those things."

Then God described the Creation Process Metrics for the unnamed Us. He explained the:

Critical Success Factors that must be true in order for the Creation Process to achieve its Purpose and Outcomes. He ensured that each element of the Purpose and Outcomes was supported by at least one Critical Success Factor while keeping the list as short as possible.
Key Performance Indicators that measure the achievement of the Critical Success factors. He ensured that each Critical Success Factor was measured by at least one Key Performance Indicator while keeping the list as short as possible.
Targets for each Key Performance Indicator that clarified when the Creation Process was likely to achieve its Purpose and Outcomes, and when corrective action may be needed.
Measurement and Analysis Procedures to ensure that each metric was measured consistently, used appropriately and stored for future reference.

And God saw that Process Metrics were good. And there was evening, and there was morning -- the fifth day.

6th Day

And God said, "Let us create!"

And the unnamed Us asked, "What should we do when the Process Metrics indicate that something is wrong?"

And God said, "Let there be Process Improvement." And it was so.

And so God made the Process Improvement mechanisms for the Creation Process. And He socialized them with the unnamed Us, and explained, "There will often be ways that we can make the Creation Process better. Sometimes we will need to correct a problem that is highlighted by the Process Metrics. But even when there is nothing wrong, one of us might see that the process can be more efficient, more consistent in achieving its Purpose and Outcomes, or easier to perform."

Then God described the Process Improvement mechanisms for the unnamed Us. He explained the:

Process Improvement Register where the unnamed Us could record needed fixes and opportunities to improve the Creation process. For each entry, the register included information like how much effort would be required to change the Creation process, how much benefit they would get from the change, and how important the change was to the Creation process and to Him.
Periodic Process Reviews where He and the unnamed Us would review the Process Metrics and the Process Improvement Register and agree on changes to be made to the Creation process.
Process Improvement Activity Stream that would ensure that each change to the Creation process was chartered and managed as a Project, and included necessary analysis, design, review and testing activities.

And God saw that Process Improvement was good. And there was evening, and there was morning -- the sixth day.

7th Day

Thus Process was created in all its vast array. By the seventh day, God had finished creating the Creation Process, so he and the unnamed Us followed it to create "Rest". And He rested from all His work.

Next time, we will continue with Process Genesis Chapter 2, In the Department of Eden.

*Apologies: Apologies to those who are not of Judeo-Christian heritage for not using your creation story. Apologies to those who are of Judeo-Christian heritage for butchering your creation story.

Little ITIL, Big Results

2012-09-25T13:22:26-07:00

Steps 7 thru 10: Beyond Getting Started

by Alan S. Koch, PMP

Having completed Steps 1 through 6, you are officially no longer "Getting Started." Assuming you have been regularly keeping score and talking about it (Steps 3 & 4) and have made a whole series of "sweet" improvements and talked about them (Steps 5 & 6), you should have built a positive and rational relationship with your customers and stakeholders, both within IT and throughout the organization.

From that platform, you are now ready to launch into a new mode of operation that will pay large dividends to IT, to your customers and to your organization at large. This new mode of operation transforms IT from a mere supplier of services to an enabler of business success. That is, rather than IT merely responding to your customers' requests, you join with them in strategic discussions to identify ways that IT Services can be employed to make them wildly successful.

Step 7: Learn about Your Customers' Business

Before you are ready to talk with them about this (in Step 8), you have some homework to do. You need to understand their business plans, how their business works, and how and why they use IT services. As a part of that, you need to learn a bit about their industry, where they fit into it, and how others in that industry use IT.

Learn about your customers' industries.

Your primary (and your most important) customer is the organization you are a part of. If your organization provides IT services to customers, you already have a head start, having focused on IT as an industry in your own work. But most IT departments are a part of organizations that operate in a non-IT industry. For instance, if your IT department is part of a local bank, you will need to learn about the Financial Services industry. If it is part of a hospital, you will need to learn about the medical services industry. This learning is your starting point for making your IT services part of a strategic discussion. But that is only a start. You should also consider your other customers.

In almost all cases, the customers of your organization are direct users of some of your IT services, making them customers of IT. So it will be valuable to learn about their industries. While it may be unreasonable for you to learn about the industries represented by all of your organization's customers, you may be able to identify one or two industries that dominate your organization's customer base. If that is the case, learning about those industries will position you to help your organization to cater to their needs more effectively.

And of course, the various departments within your organization actually represent a variety of industries. Your Accounting department provides Financial Services to the rest of your organization. Your Personnel department provides Human Resources services, and so on. Gaining some insight into those industries will help you to understand the needs and opportunities of these very important customers of your IT services.

Discover how others in your customers' industries use IT.

Identify the "normal" ways that other organizations in the industries you identified above use IT. Every industry has trade journals and conferences where these sorts of topics are discussed. With this information, you will be able to ensure that your customers' use of IT is at least up-to-date.

But you won't just learn about their normal ways of using IT from those sources. There are innovators in every industry, and they like to crow about the innovative things they have done. You will also want to identify ways that the innovators in those industries have made creative or unusual use of IT Services to derive special benefits or competitive advantage. After your customers have mastered "normal" use of IT, they may be ready to capitalize on those innovations!

Identify where your customers fit into their industries.

Are your customers leaders and innovators? Or are they followers or even laggards? This will help you to understand what you can do to help them to achieve better results than they already have achieved. Do you need to help them get up to "normal"? Or are they ready to innovate?

Understand your customers' business plans and how they use IT services.

What are your customers trying to achieve today? And how successfully are they achieving those things? What role do your IT services play in their plans and in their successes (or lack thereof)? Do they already have plans for different use of IT in the future? Or do they have plans to delve into new areas of business that will be a rich opportunity for innovative use of IT? Any of these questions may yield opportunities for you to connect with them on a strategic level.

Step 8: Talk about Your Customers' Business Success

Having done your homework (in Step 7), you are ready to begin forging a new synergistic relationship between IT and your customers.

Your first order of business is to confirm (and correct as needed) what you have learned about their industry, their business plans, their business, and how they use IT services. Being a good listener and learner will not only assure that you have an accurate understanding of their business and position in their industry, it will also cement the positive relationship you are building and make them more receptive to innovative ideas you may have.

Then you will be in the position to discuss with them new ways that IT can enable them to become more and more successful at what they do. Point to ways that their competitors capitalize on IT services, or identify innovations that are begging to be made. Keep in mind that innovation is never an end in itself; your intent here is to identify innovations that will improve your customers' odds of success. They may not be receptive to your innovative ideas at first, but that's OK! Running their business is their job, not yours. Your job is to make IT as valuable to them as you can within your sphere of control.

In talking with your IT Staff, you have two priorities. First, to ensure that they have an accurate understanding of your customers' needs. And second, to engage in brainstorming about ways that IT can enable your customers to excel. (Your customers' competitors haven't thought of all of the good ideas yet!) IT Services that enable your customers to leap past their competitors is your ultimate aim.

Step 9: Help Your Customers Improve Their Business via IT

After you have succeeded in transforming IT (in your customers' minds) from a mere service to a strategic enabler (in Step 8), the flow of improvement opportunities will be unending. Each success will contain the germ of new ideas, and they may start identifying IT innovations before you do. (Cool!)

The Deming Cycle (Plan-Do-Check-Act, or PDCA) provides a good framework for continually improving.

Plan each improvement project.
Do what you planned.
Check the results.
Act on what you found when you checked, which will lead to the next plan!

Use this cycle cooperatively with your customers to build their success.

But, of course, don't neglect Step 10!

Step 10: Keep Talking

By the time you get to this point, Step 10 is almost redundant. Your relationships with your customers will be a continual flow of conversation. You will be discussing their success, their challenges and what IT can do to help them on a regular basis.

It is almost redundant!

The truth is that complacency sets in even with the most vibrant relationships. We get busy with our successful work, and we forget to keep talking. You must consciously cultivate the flow of discussion and take action when it dries up. Your best option is to have a regular plan to keep talking on a regular basis (even if it is only quarterly).

That way, the relationship will remain vibrant, and IT will continue to enable your customers' success.

Little ITIL, Big Results

2012-07-18T09:07:47-07:00

Step 6 of 10: Talk About improvements

by Alan S. Koch, PMP

Success! At last we have made our IT services better in a way that people will recognize and appreciate!

Step 5 in our "Little ITIL®, Big Results" series was the culmination of all of the foundation laying that went before it. We bought the time to do it; we talked about doing it; we figured out how to measure it; we talked in quantitative terms about it; and then we picked the low-hanging fruit, making things a bit better. Listen to our webinar on this 10-step process!

And Step 6 is what? "Talk"?… Again?

Yes, we must talk about the Improvements we have made. This talking is aimed at ensuring that each improvement we have made (and the benefits that people have enjoyed because of them) are recognized and appreciated. The purpose of this is far more than to get pats on the back. The big purpose is to build process improvement momentum that will allow us to attack those bigger problems that aren’t "low-hanging fruit".

Ensure the Improvement Is Recognized

How could people not notice the improvement?

Most IT Services are like utilities (think electricity). When they work, we tend not to think about them at all. (Then, when the bill arrives, we wonder why they cost so much!) But when they don’t work or are unreliable, they are top of mind for us. If the problem is repeated over the long term, we may become obsessed with it.

In other words, there is a very real danger that the work we have put into making the improvement and the benefits our customers have reaped will be mostly invisible to them unless we point them out. Every win must be advertised both within IT and to our customers. This is no time for false modesty! If we don’t highlight the gains we are making, other people may not notice or remember.

The good news is that we have objective measures. Remember Steps 3 and 4? We figured out how to measure what is important, and we used those metrics to reframe complaints about our service into a quantitative fact-based discussion. Here we will continue that fact-based discussion by contrasting the prior poor performance with the new better performance. We will show, using those same metrics that the things they care about have in fact improved.

Ensure Things Really Are Better

Of course, that assumes that we actually have made things better. The fact that the metrics we were focusing on have improved is good, but it may not be paired with a commiserate change in our customers’ opinions. If they are all smiles and high-fives, then we can breathe a sigh of relief. But if they are still unhappy in some way, we must learn from this, because our first analysis must have been insufficient, resulting in metrics that don’t measure the important things.

Hopefully our stakeholders will agree that we made an improvement, though possibly in something that is less important to them. But in the worst case, we may have had no visible positive impact on them at all, or may have even made things worse. Either way, we will need to cycle back to Steps 2, 3 and 4 to gain a new understanding of the problems that need to be addressed and identify a more appropriate way to measure our performance on those topics.

Adapt to New Improvement Priorities

Whether we got it right or wrong with the improvement we just made, we will also want to engage our stakeholders in revisiting the list of potential improvements we could make and reassessing priorities. Having been through one round of improvements and being in the position of anticipating the next, our stakeholders are likely to have new ideas about improvements. They may want to add things to the list, remove things from the list, or rearrange priorities.

Some of these changes will be due to what they and we have learned so far. But some changes will be due to the fact that the world has continued to turn while we were working on the last improvement. Context may have changed, the organization may have changed, the business environment may be different, and people may have moved on or changed positions.

There are many valid reasons why what had been a perfectly balanced priority list a few months ago may need significant rework now. And doing that rework is critical to ensuring that the next project we work on is as important as the last one was.

Keep the Improvement Momentum Going

Past successes do not guarantee future momentum. We must constantly be adjusting not only our improvement priorities, but also our approach to continuous improvement. We must keep our work aligned with what is important to our organization, and keep getting better at how we do it. This is where talking about the improvements within IT comes into play.

Our first priority is to ensure that each team member that expended effort to make the improvement a success is recognized for that effort. We at least want to make that recognition "public" within IT. But depending on our company culture and situation, we may chose to recognize the contributions in a fully public way, in front of all of the key stakeholders. People will work that much harder when they know their efforts are appreciated!

But again, the talking is not just a matter of back patting. We also want to discuss how the improvement project went and how we can get better at making things better. Yes, continual improvement of our continual improvement efforts is absolutely necessary if we are to maintain momentum toward our goals.

What does momentum look like? It is mainly a continuous cycle of Steps 5 & 6. Make an Improvement, then talk again, then repeat. This is a cycle that we can repeat for many years. And indeed, we should plan to keep this cycle going.

But of course, Step 6 is not the end of our 10-Step process. There is more we can do once we have the basics of this improvement cycle going. And that will be our topic next time as we go beyond merely improving what we do!

Little ITIL, Big Results

2012-05-08T16:50:36-07:00

Step 5b of 10: Making your first improvement

by Alan S. Koch, PMP

In the previous article of our "Little ITIL®, Big Results" series, we decided which improvement effort we will do first. Now it is time for us to get to work on it. Finally! This step of the process will draw on everything that has preceded it: Step 1, we bought the time to do it; Step 2, we talked about doing it; Step 3, we figured out how to measure it; and Step 4, we talked in quantitative terms about it. (Listen to our webinar on this 10-step process!)

So now, we "just do it!" Right?

If it were that easy, we would have done it long ago, and the landscape would not be littered with the dead carcasses of failed improvement efforts. Think about how people often react to the announcement of an improvement effort. "Oh oh! Here's the next flavor of the day. If we smile and nod, it'll die of its own accord just like all the others that preceded it."

Improvements seem so benign, but in the real world, they present us with real challenges. Being successful with improvements requires that we be aware of those challenges and address them explicitly.

Improvement Is a Project

One of the biggest causes of improvement failure is the failure to recognize that making any kind of an improvement is a project, and should be treated as such with all of the disciplines and oversight that implies.

In this article, we will not try to cover the whole topic of project management. We will assume that the reader has that information available either in their own training and experience, embodied in their organization's processes, or via the many great resources that have been published.

As such, we will use project management terminology and freely refer to project management concepts as if you know what we are talking about. We encourage you to look up any term or concept with which you are not fully conversant.

The Business Case for the Improvement

Before expending any time or money, we must gain the concurrence of the holders-of-the-purse-strings that it is an appropriate spend of the organization's time and money. If we don't start with these people on our side, the whole project could be stopped before it delivers anything.

Improvement Project Objective -- Begin by identifying the Business Objectives of the organization that are not being fully realized because of the issue that this project will cure. This hitches the Improvement project's wagon to a star that the decision-makers care about. Describe the Observed Problem that the project will cure (preferably one that the decision-makers have already articulated or at least observed), and drill down to the Root Cause of that problem. Your Improvement Project Objective is to cure the root cause, which will eliminate the observed problem and enable the organization to achieve its business objectives.

Improvement Project Benefits -- Although the Project Objective should be immediately identifiable as a "good thing to do," it begs the question of precisely how important it is. So we must explicitly list the benefits the organization will realize from the project. Most of the benefits must be quantified and translated into money. (The project won't just make a job quicker and easier; it will save x hours of labor, which computes to $y of cost avoidance. Or it won't just please customers; it will attract x amount of new business, which results in $y of new revenue.) You will need to tap colleagues (e.g. in Human Resources or Marketing) to come up with defensible money estimates. (If you have an important benefit that no one can quantify, be sure to include it anyway, because it may still garner some important support.) [Our Opportunity Screening Worksheet can help with this analysis. –Ed.]

Improvement Approach -- On your very first improvement project, this will be difficult to envision. There is the very real possibility that you will not realize some significant activities or other impacts for lack of experience with these sorts of projects. Your best bet is to collaborate with colleagues from other organizations who have done these sorts of projects before (or hire a few hours of consulting help) to make sure you have laid out an appropriate approach that has the best possibility of delivering the benefits you described. You should also list two or three alternative approaches that you believe would be less effective. (This shows the decision-makers that you really did your homework!)

Improvement Project Costs -- Computing the ROM (Rough Order of Magnitude) cost of your approach will also be difficult on your first project. So, again, you should collaborate with colleagues from other organizations or hire a few hours of consulting help to make sure your effort and cost ROMs are reasonable. This is critical because cost or schedule issues on the very first project can have disastrous long-term impacts!

Return on Investment (ROI) -- Go to your organization's accounting group and get them to help you crank the Costs and Benefits into the appropriate ROI format for the organization. (No, ROI is not as simple as Benefits minus Costs!) To make your case defensible, you must state it the same way any other investment would be stated in your organization!

All of these things taken together form the heart of your Business Case -- your logical argument for investing in the improvement project. The powers-that-be in your organization will weigh it against other investment opportunities (after all, there isn't enough money to invest in everything), and decide to fund your initiative if it appears to be appropriate.

Beware! You have just made a binding contract with the senior executives of your organization! They have agreed to invest in your improvement project in exchange for the benefits you have laid out. You had better be sure that you deliver what you promise, or you will find the well dry the next time you go to them!

Initiating an Improvement Project

Now that you have secured backing for your improvement, you must Charter the project. Your Project Charter will expand on what you said in your Business Case and fill in key details. For an Improvement project you should address these things:

Scope of Project Activity -- The Benefits and Approach must be translated into an explicit statement of what your project will do (and what it will not do). To be successful with improvements, you will do things like these:

Collect data about precisely what is going on today. Identify what is working well and what is problematic, and identify the causes of the pains you seek to correct.
Research how other organizations have solved the problems you have. Although you won't be able to simply apply their techniques without change, you will find that you can capitalize on other people's mistakes instead of making them yourself. This is where public frameworks like ITIL come into play!
Work with the people who will have to do things differently to figure out which of those good ideas from other companies apply to your situation, and the best way to put those good ideas to use. If you simply try to tell them how to change, you will generate resistance instead of acceptance. (Not to mention that you will probably be wrong!)
Document the new way of working. Create forms, templates, checklists and process flows that will help people to figure out the new way of working.
Pilot the new way of working to see if it works and to tune it for maximum benefit.
Train people on the new way to do things. Hold their hands and answer their questions. Do everything you can to be sure they are successful with the new way.
Collect data to quantify the impact of the new way, and to understand if the benefits you promised are indeed being realized.
Publicize your successes. Don't just report status to the powers-that-be. Celebrate every milestone and trumpet every success!

Stakeholder Involvement -- An improvement project requires far more that a Communication Plan. As you can see from the activities listed above, it requires a lot of involvement and action by a wide variety of people throughout the organization. Your charter must clarify your expectations of everyone's involvement in the project, and all of the powers-that-be must realize that in approving your charter, they are committing their own resources to the project's success.

The Project Team -- You can't do it all yourself. And although you will be involving lots of stakeholders, you will also need a core team of people who are focused on the project. This team will ideally include one member from each key stakeholder group. You want someone who knows the public frameworks you will be referencing, someone who knows the details of what goes on in IT, and often someone from other departments who are affected by the improvement. (For example, if the improvement will change how Marketing does part of their work, you will want a marketing team member dedicated to your improvement project team.)

Deliverables and Milestones -- Clarify precisely what the organization should get from your project and when they should see those things. There will be documents to publish, workshops to hold, reviews to be done, training to provide, the all-important rollout date, and of course, reports about the benefits achieved.

Planning an Improvement Project

Translating your Project Charter into a Project Plan is not very different from what you would do on any other project. The strategy, scope of activity, deliverables and stakeholder involvement all show up in your task plan, effort estimates, schedule and budget.

Here again, you will want to lean on someone with real experience doing these sorts of improvements to help you put together a realistic plan that doesn't overlook important details. Call once again on a trusted colleague or knowledgeable consultant to guide you in your planning and estimating.

Executing and Monitoring & Controlling an Improvement Project

After your plan is in place, managing your improvement project will be just like managing any other project. Do what you planned, monitor actual activity, costs and achievements against the plan, and take corrective action as needed to keep things on track. And yes, go back and re-plan if you find that things are significantly different from what you envisioned.

Closing an Improvement Project

When you reach the end of an improvement project, it is important that you not just stop working. There are a variety of things you will need to do to ensure the project results in the sustained benefits you envisioned, and to set up your next improvement for success.

First is the Lessons Learned. When you are doing something new (like improving your internal methods) for the first or second (or third) time, things will be a bit rocky. Each time you complete a project, you will want to step back and ask how the project went, and how you can make the next one easier and more successful.

Second is the Celebration. A celebration will be instrumental in sustaining momentum. Regardless of how rocky or difficult the road was, you got to the end of it and made things a little better. That is worth celebrating regardless of how modest the improvement may have been. You'll want to publicly thank those who contributed to the success and give everyone the opportunity to enjoy the success.

Finally, you will want to keep Measuring and Monitoring for many months to document the real, lasting benefit the project provided. If the benefit is substantial, it is yet another reason to celebrate. If it is a disappointment, it is a learning experience. Either way, you'll miss out if you aren't actively measuring and monitoring!

Picking the Fruit

After laying a solid groundwork and carefully choosing that juicy low-hanging fruit, you have finally started to make things better and enjoy the fruits of your labor. Of course, this isn't the end of the journey. Far from it! You have merely completed the first circuit on a path that has no end -- the path of Continual Service Improvement. Where do you go from here? We'll address that next time!

Little ITIL, Big Results

2012-02-29T18:48:00-08:00

Step 5 of 10: Pick the Low-Hanging Fruit (Part 1 - Choose your first improvements)

by Alan S. Koch, PMP

The first several articles in our "Little ITIL®, Big Results" series were all about setting the stage for improving your IT shop. (Listen to our webinar on this 10-step process!)

In Step 1, we bought some time to invest in getting started because no one has spare time just waiting to be used!
In Step 2, we talked with a variety of people about getting started, both so we can understand what is important from their perspective, and to build their buy-in for making improvements.
In Step 3, we learned the score by measuring important things so we can gain an objective understanding of the things that need to be improved.
And in Step 4, we talked about the score with our stakeholders to help them to gain the objective understanding we gained in Step 3, and to hopefully get more precise input from them.

Now finally in Step 5, we are ready to actually start making things better. But we can't fix everything all at once! So where do we start? We start with the Low-Hanging Fruit.

Why Low-Hanging Fruit?

Consider the apple tree out in the field with apples hanging from every branch. Some of the apples are gorgeous, others less enticing, some not quite ripe yet, and others way past their prime. Some of the branches are really far up, while others are more accessible. Just now, an apple sounds like a mighty nice treat. Which one would you pick?

A "Low-Hanging" improvement opportunity is one that will be relatively easy to do -- one that, like the apple, is easily within reach (or at least easier to reach than the others). It is important that we start with the easier improvements for several reasons. First, since we have been talking with our stakeholders for some time about making improvements, they are probably wondering when all this talk will turn into action (which as the saying goes, speaks louder than words). Second, getting started with improvements is its own challenge, so we want to pair this new behavior with something that is less difficult to do. And third, a quick win will help us establish momentum, which is particularly important in improvement efforts.

An improvement opportunity "Fruit" will provide obvious benefits -- one that, like the apple, will be judged by a variety of stakeholders to be sweet. An "improvement" that key stakeholders don't understand or care about will do nothing to build the momentum or generate the support we need for further improvements. But if they think that first improvement was sweet, they'll be clamoring for the next one.

A couple of important points: First, don't try to eat all of the apples at once or you'll get one heck of a tummy-ache! One or two apples at a time are enough. And second, we're not talking about making an apple pie (or streusel or Danish). Save the more advanced efforts until you have mastered the basics and built momentum.

Catalog the Fruit

The talking and measuring that you already did in Steps 2 thru 4 resulted in a lot of ideas for improvements you may need to make in your IT shop. If you haven't done so already, now is the time to catalog those ideas so you can prioritize them against each other. For the purposes of this article, your Improvement Opportunity Register should include this information about each opportunity:

Unique identifier and Name -- These make it easier for you to keep track of the improvement opportunities and talk about them with other people.
Description -- A sentence or short paragraph that describes the opportunity.
Benefits -- The sweetness factor for this opportunity. (See "Spot the Sweetest Fruit," below.)
Costs -- The cost factor for this opportunity. ("Find the Fruit Within Reach")
Priority -- This opportunity's relative ranking based on Benefits and Costs. ("Choose Your First Fruit")

This Improvement Opportunity Register needs to be a living document. Any time an improvement opportunity is identified, you will add it to the register. When an opportunity is rejected, or after each improvement is completed, you will remove it from the register to an archive for historical purposes. And of course, as situations change, you will adjust the Benefits, Costs, and Priorities of the improvement opportunities.

Spot the Sweetest Fruit

Assessing the sweetness of each improvement opportunity is a matter of identifying all of its benefits. The easiest way to do this is to list every group or individual who will benefit from it, and for each group or individual, to determine these things:

Name of the group or individual.
Importance of the group or individual to IT and the organization at large (e.g. High, Medium, Low). This is where we would differentiate between key stakeholders and others who are less critical to our success.
Urgency of the improvement to this group or individual (e.g. High, Medium, Low). How quickly does this group or individual want or need to see this improvement done?
Impact of the improvement to this group or individual (e.g. High, Medium, Low). How much will this group or individual benefit from the improvement when it is implemented?

A simple way you can combine all of this information into a Sweetness factor for each improvement opportunity is to translate the rankings into numbers (e.g. High=3, Medium=2, Low=1), then combine them arithmetically. For example, if I have one person who has High (3) Importance for whom this improvement is of Medium (2) Urgency and Low (1) Impact, I might compute their sweetness contribution as 3 x 2 x 1 = 6. I would then sum that with the Sweetness contributions of all of the other groups and individuals who would benefit to come up with the Sweetness factor for the improvement opportunity.

The improvement opportunities with the highest Sweetness factor will have the greatest benefits. But this is only part of our calculus. We also must consider whether the fruit is within reach!

Find the Fruit Within Reach

Determining how low each improvement opportunity is hanging is a matter of identifying all of the costs involved in implementing it. For each cost, we need to capture these things:

Description of the cost. Is this software, or analysis, or training, or behavior change, or policy updates, or ...?
Resource. Does it require money, people's effort, calendar time, other?
Magnitude of the cost (e.g. High, Medium, Low). This is not just for money; an improvement opportunity may cost a lot of people's effort or a lot of calendar time.
Scarcity of the required resource (e.g. High, Medium, Low). If an opportunity requires the effort of a person who is already overworked, then their effort would be Highly Scarce.

Identifying all of the costs can require some creativity, and will likely require some preliminary project planning. (Yes, implementing an improvement is a project -- but we will address that in our next article!) At the very minimum, every improvement will require calendar time and certain people's effort.

Combining all of this into a cost factor for each improvement opportunity should be done in a similar way as the Sweetness factor described above (convert Magnitude and Scarcity into 3, 2 or 1, then combine arithmetically). At this point, we are not trying to come up with a dollar cost; we are merely trying to rank the opportunities against each other on the basis of all of the costs (of which money is only one).

Choose Your First Fruit

After doing the Benefit and Cost analysis described above for each improvement opportunity in our Register, we are finally ready to pick the Low-Hanging Fruit. In principle, we want to pick the opportunity that has the highest benefit and the lowest cost. Of course, reality is rarely that easy. The highest benefit opportunities may not have low costs, and the lowest cost opportunities may not result in high benefits.

Picking Low-Hanging Fruit usually requires that you exercise professional judgment in selecting among the opportunities that bubble up toward the top on the basis of the Cost and Benefit computations. Only you can decide which considerations you will use as you make these judgments. But these things tend to be important:

Importance of the groups or individuals who will benefit. In general, we want our first improvements to provide benefits to the most important people. A Medium (2) benefit provided to a highly (3) important person is a higher priority than a high (3) benefit provided to a medium (2) importance person, even though the arithmetic ranks them as equivalent (3 x 2 = 2 x 3 = 6).
Calendar Time to complete the improvement. For our first improvement, minimum calendar time to delivery is by far the most important cost consideration. If I can deliver several Medium Benefit improvements in a short timeframe, that is far better than delivering only one High Benefit improvement in the same timeframe.
Ease of achievement. Finally, you need to consider how easy it will be for the responsible people to make the improvement (which may require a new set of behaviors), and for the beneficiaries to adapt to it (which may require changes to their daily work habits). This is not captured directly in any of the analyses above (though it may show up indirectly in the costs). And for the most part this will simply be a matter of judgment. But it is critically important that the very first improvement you undertake not be too challenging.

Taking all of this into consideration will allow you to use your judgment to assign each improvement opportunity a priority (e.g. High, Medium, Low). Then you can begin working on them in priority order.

Congratulations! You just picked the best apple. In our next installment, we'll talk about eating it!

Related Links
In addition to the previous articles in this series (linked above), you may want to refer to our templates for a Stakeholder Analysis and Cost-Benefits Analysis, as well as our guideline explaining various Estimating Methods. Our Scored and Ranked Project List for Portfolio Management illustrates one way of building a prioritized list in a spreadsheet using weighted rankings.

Little ITIL, Big Results

2011-12-20T19:31:41-08:00

Step 4 of 10: Talk About the Score

by Alan S. Koch, PMP

In our last article, "Little ITIL®, Big Results; Step 3 Know the Score," we continued looking at our 10 steps to starting an ITIL effort in a small IT shop. (Listen to our webinar on this 10-step process!) Step 3 was about objectively measuring what is important, not only the internal technical metrics, but also external customer-oriented metrics.

Back in Step 2 -- "Talk About Getting Started" -- you probably heard a lot of complaining from your constituents. And if so, those complaints were likely broad generalizations that had more of a basis in emotion than in metrics. The metrics you started collecting in Step 3 will provide a tool for moving those conversations away from emotion and toward consideration of facts.

This fourth step of the process is focused on restating the complaints you are hearing in terms of metrics. You do that by showing both your customers and your IT Staff what the metrics say, and by probing to see if other metrics are needed to address some complaints.

The point of this is not to prove to the complainers that they are wrong or over-stating the problems. Rather, it is to replace emotion with a reasoned basis for a rational conversation so all of you can agree on problems that need to be solved, and how you will know when things get better.

Starting Conversations About the Score

Having opened a communication channel with each of our constituents in Step 2, we have a built-in basis for these new conversations with them. With each person, we want to begin with the things we heard last time, which demonstrates that we were listening, and move the relationship forward by bringing the relevant metrics into the discussion.

Talk About the Score With Your IT Staff

It may be tempting to start by showing our customers the "real data," but we have a more important place to start -- within IT. Every member of IT needs to understand (in terms of hard data) what he or she does and how it affects the customers and end users.

Internal Technical Metrics -- We start with the internal, technical metrics (like server performance, network down-time, or person-hours per service request). They provide a basis for understanding and talking about how each component of our IT shop is performing and identifying opportunities to improve that performance.

If our staff members have complained about anything other than customers and end users (be it hardware reliability, software performance, or process efficiency), we will start there, by bringing out and discussing the metrics that clarify those issues. Compare staff members' perceptions to the hard numbers. Are things as bad as they seemed? Worse? Is there room to improve? Would the effort needed to improve be justified? What changes might we make to improve things?

But let's not limit our focus to complaints. Often people live with problems that they fail to articulate. Look at all of the available metrics. Do any of them indicate problems? Is anything out of line with expectations? Are opportunities for improvement apparent from the numbers?

This is the beginning of an important pattern we want to establish with our staff -- that of confirming or illustrating problems with metrics, and examining metrics to identify hidden problems. The more our people think in terms of measuring the IT environment to identify how to make things better, the more improvements we will be able to make.

External Customer-Oriented Metrics -- After looking at the technical metrics with our staff, we need to turn their attention to the customer-oriented metrics (like application response times as experienced by end users, down-time as experienced by end users, and hold-time when calling the service desk). Any of their complaints about customers or end users must be viewed through the lens of these metrics. Again, we want to confirm where problems exist, and understand them in a way that will allow them to be solved.

Then we must examine all of the customer-oriented metrics to look for issues. Much of what we have begun measuring at this point was prompted by customer complaints, so this will be our opportunity to translate complaints our staff may be hearing from their customers into quantitative form. It will provide all of us with insight into our customers' and end users' experience with our services, and will be the starting point for addressing the problems.

Your IT staff are in a unique position that allows them to draw connections between these customer-oriented metrics and the more familiar technical metrics. After using the customer-oriented metrics to confirm and understand each customer complaint, they can use the technical metrics as the centerpiece in root-cause analysis. This understanding of the causal connection between what goes on within IT and how our customers experience it is key to making meaningful improvements.

Talk About the Score With Your Customers

After exploring all of the metrics with our staff, we are ready to have similar conversations with our customers. But in this case, we will not talk about technical metrics (except with members of our customer community who are interested in them). With our customers, our focus will be on the customer-oriented metrics.

External Customer-Oriented Metrics -- As with our staff, we will start our discussion with each member of our customer community by revisiting the complaints they have already raised. We will demonstrate that we were listening to them, then bring out and discuss the metrics that clarify those issues. Compare the customer's perceptions to the hard numbers. Are things as bad as they seemed? Worse? Is there room to improve? What levels of service would meet their needs?

Again, we won't limit our focus to their complaints. We will look at all of the available metrics. Do any of them indicate problems? Is anything out of line with expectations? Are opportunities for improvement apparent from the numbers?

It is important that we not make any promises that we cannot be sure of meeting. At this point in our process, that likely means that we can't promise to do anything more than investigate how we might make appropriate improvements in the relevant metrics. (Indeed, that will be our next step!) For now, we have achieved the intermediate goal of translating their complaints into an actionable form.

As with our staff, this is the beginning of an important pattern we want to establish with our customers -- that of confirming or illustrating problems with metrics, and examining metrics to identify hidden problems. The more our customers think in terms of measuring their need for IT services, the better able we will be to actually meet those needs.

Talk With Your IT Staff About Your Customers

After exploring the metrics with our customers, we can return to our staff to discuss options. The issues have been quantified, and we have discussed with our staff how those customer-oriented metrics relate to the internal technical metrics. We are now ready to explore options for improving the services we supply to our customers.

This final step is important even if it seems clear to us what needs to be done. Every member of our staff must understand how the things they do and the metrics that they use contribute to the service levels our customers experience. Besides, they may have insights that we have overlooked! Clarifying how the changes we make within IT translate into service improvements to our customers closes a very important loop!

Little ITIL, Big Results

2011-10-11T13:56:15-07:00

Steps 3 of 10: Know the Score

by Alan S. Koch, PMP

In our last article, "Talk About Getting Started," we discussed the second of our 10 steps to starting an ITIL effort in a small IT shop. (Listen to our webinar on this 10-step process!)

Talking is all well and good, but we are not in this to hear ourselves talk! We need to do something, so let's get to work! But before we make any changes in our IT shop, we must lay some important groundwork. So, we continue in this article with Step 3, "Know the Score."

Step 3. Know the Score

What gets measured gets rewarded. And what gets rewarded gets done.

Having begun dialogs that will continue in all of the even-numbered steps, you now need to turn inward. You have heard about problems and opportunities for improvement from all sides. But before you can begin taking steps to improve the score, you need to know the score. It is said that, "all players know the score," so if you're going to be a player, you had better know the score. To carry the sports metaphor one more step, every player knows his or her own stats as well of the stats of the players they play with and against.

When there are many problems to address, it's tempting to dispense with the quaint idea of metrics and jump right into the important work of changing things. This impulse is foolhardy. Without baseline metrics, you lack an objective basis that will allow you to do four very important things:

Prioritize problems and opportunities to decide on the order of attack
Compare your IT shop with others to understand what they may be doing that you could capitalize upon
Judge the effectiveness of the supposed improvements you make to determine if they should be retained
Demonstrate that things are indeed improving to gain support from others for your continued efforts

Good baseline metrics (objective measures of how things are before you begin making changes) will enable all of those things as well as being useful in a host of other ways as your IT processes and practices become more mature.

But of all the things we could measure, which are the ones we should measure? Devising metrics, collecting measurements, then doing something with them all take time and effort. There is only so much time we can devote to metrics, so we must focus on those few things that will be valuable to us. The metrics you will need fall into two broad categories:

Internal technical metrics
External customer-oriented metrics

Internal technical metrics

These are the metrics we normally think of in IT: Utilization of CPU, disk and network; numbers of users, components, incidents, and requests; average effort to stand up a PC, resolve an incident, or fulfill a request; and many, many others. These sorts of metrics enable us to gain an objective understanding of our IT shop's current capabilities and performance, which will help us to recognize our opportunities for improvement.

The valuable internal metrics start with those that come for free. Our devices, systems, and software are capable of measuring and reporting on a variety of things. Those capabilities should be enabled and the data stored even if you have no immediate intention of using it. You will need some of it to diagnose problems at some point in the future, and having that data available to comb through sure beats beginning to collect it after it is needed.

Then there are the metrics that you will have to invest time and effort in defining, collecting, and using. How do we identify which of all those metrics are worth worrying about? Start with the concerns that are common in most IT shops (especially the small ones).

What chews up all the money? Capital purchases are obvious, but the other parts of TCO (Total Cost of Ownership) are also important. Service contracts, parts and supplies, training, consulting, and support or other help can add up.

The good news is that this data should be readily available from your bean counters. Whether you have budgetary responsibility or not, you should take it upon yourself to understand where the dollars go so you can make smart decisions or recommendations about future investments.
What chews up all of our time? Employee costs often are among the biggest IT costs, and they are certainly among the most controllable. Insight into where the time goes -- both your staff's and your own -- can help you to distinguish between the mere annoyances and the true time wasters.

But this data is difficult to collect. Most technical workers find it difficult to log where their time goes, and many have a downright negative reaction to the idea, fearing that the data will be used against them. Appropriate tools and processes can address the difficulty issue, but the fears must be handled with finesse. Lay the groundwork by making it clear that the data will be used to defend and support their jobs, not to threaten them, and demonstrate the behavior by logging your own time.

Then back those words with actions. Key among them: never, ever discipline an employee on the basis of the time data they log. This will be a difficult for you when the time log data shows a clear problem. But remember this: the moment you use data against those who collect it, it will cease to be real data, and will simply be manufactured to make them look good. (And the reality is that there will be other symptoms of the problem that you can use for disciplinary purposes.)
What causes our pain? This is where the information you gained in Step 2 comes in. The complaints you have heard, both from your customers and users and from your IT staff, often will point to things that should be measured. The first step in determining the legitimacy and priority of complaints is to measure them.

Of course, we can't give specific advice without knowing precisely the nature of the complaints. (We will address these topics in other articles on specific topics.) But some generic advice is still useful here.

For example, suppose that one of the complaints we are hearing from users is that problems or requests require multiple calls to the service desk before they are resolved. How shall we go about measuring this problem?
- First, capitalize on what you already measure. Often you can gain indirect insight into a problem through metrics you already have at hand. Better to capitalize on those than to invent something new.
  
  In our example, see what data the service desk already collects. Gross number of calls may be helpful if there is other data we can use with it. If each incident record includes the name of the person who called, you may be able to identify series of calls from the same users. And if there is a category or call-type attached to each incident, you may be able to see how often this multiple-call problem is actually happening.
- If you don't measure anything that is relevant, ask around. Someone else in IT or in some other part of the enterprise might have some usable data. The obvious place to start in this search is with the source of the complaint. But don't stop there. Be creative in your search, and you may be rewarded.<
  
  In our example, we would ask those who have made these complaints to give as many specific examples as they can recall. (We must be careful to ask in a way that does not sound like we are challenging the allegation. We must make it clear that we are seeking data to diagnose and fix the cause of the problem.)
- Finally, keep it simple. We technology people tend to want to do things rigorously and completely, and the costs involved in doing so are often not justified. For many kinds of problems there is a simple, easily available metric that will give you good enough insight. It may not capture all variables involved or quantify all aspects of the problem, but it will provide what you need to get started on improvements.
  
  In our example, it will be tempting to institute new procedures to ask callers if they are calling back about something they called about previously, and to collect specific data about the original call. Although this approach might give us precisely the data we want, we must consider the impact it will have on the callers as well as the productivity of our Service Desk personnel. A simpler approach (especially one that uses data you already collect) is likely to be good enough.

These internal, technical metrics are critical to your ability to gain control of what is happening in your IT shop. You can't manage what you don't measure.

External customer-oriented metrics

But you must manage more than the technical infrastructure and your IT staff. The other thing that is critical for us to manage is our relationship with our customers and users.

The metrics that enable us to manage what goes on within IT are not generally useful for managing these relationships, because for the most part they measure things that those people do not care about. (For example, they don't care how many person-hours the average request eats up; but they do care how long it takes to get what they requested.)

Your starting point for this is the list of services you provide for them. For purposes of communicating with your customer, you must be careful to define each service in the customer's terms.

For example, when your marketing department refers to CRM (Customer Relationship Management), they mean much more than the CRM application. We know that when a user clicks the CRM icon, many parts spring into action: their PC, the client side of the CRM application, the network, the server, the backend of the CRM application, the database server, the DBMS …. Those are the things we must manage. But they are mostly invisible to that end user, who only sees that either the CRM system works or it doesn't.

With this customer orientation in mind, it becomes clear why some of the services we routinely talk about within IT (like network services) and the metrics we use to manage them have little or no meaning to our customers and end users. But what can we measure that is relevant to them? Let's look at our services from the customer's perspective.

In the CRM example above, the marketing department cares about things like these:

Availability. By this, we don't mean the availability of the server or the network, or the DBMS, or any other individual component. The Marketing department cares about how often the CRM system is available to them, which is only true when all of the underlying components are working. We don't want to talk with them about the availability of the components that enable the CRM system. We must talk about the availability that the end users actually experience. Which means that we must find a way to measure that. (Not a simple feat!)
Performance. And just as above, we don't mean the performance of individual components, but the performance levels that the end user experiences. Again, we must find a way to measure from the customer's perspective.
Support. When things go wrong, or when they need something, how long must they wait? We must manage call pickup time, investigation time, escalation, and resolution. But, similarly to Availability and Performance, we must find a way to measure the customer's total downtime (the total elapsed time from when their ability to work is blocked to when they can get back to work).

It will take a while to understand your customers well enough to know which metrics will speak most loudly to them. (We will look more at this in Step 6.) But you already have enough information to begin rudimentary measurements that will be relevant to them. This is your start on metrics. You can't afford to measure everything to the nth degree, so don't try.

Putting Internal and External Metrics Together

The external, customer-oriented metrics give us a way to quantify and understand the service we are providing to our customers and to understand the impact they experience from problems with our services.

When the external metrics point us to a problem we need to address, we must turn to our internal technical metrics to understand how all of the pieces and parts contribute to the problem. This will give us the insight we need to know what to fix, as well as a way to understand the efficacy of any fixes we attempt.

When we believe that the problem has been resolved, we must return to the external customer-oriented metrics to confirm that the resolution had the desired impact on the service from our customer's perspective. Only after we have confirmed that the problem is resolved from the customer's perspective can we claim success!

Without these metrics, we may cast about blindly trying to solve problems, or we may even blame the customer. With these metrics, we will know precisely what is happening and what to do about it. There is no better basis for beginning to improve things than to know the score!

Little ITIL, Big Results

2011-08-02T09:37:05-07:00

Step 2 of 10: Talk About Getting Started

by Alan S. Koch, PMP

Wouldn't it be great if your IT shop operated like a well-oiled machine? No crisis. No hassle. No surprises. Click, whirrrrrrrrr. Click, whirrrrrrrrr. Happy staff. Happy users. Happy executives. Click, whirrrrrrrrr. Click, whirrrrrrrrr. Smooth. Efficient. Cost-effective. Click, whirrrrrrrrr. Click, whirrrrrrrrr.

If only reality could come close to that idyllic image! ITIL℠ (the Information Technology Infrastructure Library) tells us that moving toward that ideal is within the realm of possibility. But look at all that is involved! The processes. The books! The work!!! Who can find time to even begin such an effort?

In our webinar last week, we discussed the 10 steps to starting an ITIL effort in a small IT shop:

Step 1. Buy Some Time
Step 2. Talk About Getting Started
Step 3. Know the Score
Step 4. Talk About the Score
Step 5. Grab Low-Hanging Fruit
Step 6. Talk About Improvements
Step 7. Learn About Your Customers' Businesses
Step 8. Talk About Your Customers' Business Success
Step 9. Help Your Customers Improve Their Businesses
Step 10. Keep Talking

Let's take a closer look at step 2.

Step 2. Talk About Getting Started

Before you can get started on anything of consequence to improve your IT services and people's perception of them, you must connect with those people. Naturally, this will look quite different depending on your history with those people. So let's look at the two extremes: You have a long and contentious history to overcome, or you have no history, having been hired to fix all of those IT problems.

Extreme #1: You have been hired to fix all of those IT problems.

There are some significant positives about this situation. First, the fact that you got the job says that at least a few of the senior decision makers in the enterprise have confidence in your abilities. Also, as a new hire you will be afforded a “honeymoon” period during which mistakes will not be counted so strongly against you.

Although those positives are huge, you must also realize that you have significant disadvantages. The first is your lack of knowledge about the situation. Yes, you have heard stories and complaints as part of the hiring process, but you still know precious little about the history that underlies the situation. Taking what little you know as gospel and assuming that there is little that you don't know can be a fatal error.

The second disadvantage is in your relationship with your IT staff (or more properly, the lack of a relationship with them). While the newness of the relationship is generally a positive thing with the other stakeholders, it may be entirely different with the staff. When IT is seen as a problem by the organization, IT management and staff often hunker down in a defensive us-vs-them posture.

Now, their old IT manager has been fired or forced out, and you have been brought in to whip them into shape. They are likely to be hostile about their old manager's fate, and fearful about their own. They may see the entire set of developments in a very negative light. They may actively sabotage anything you do, or they may passively resist while they look for a new job to run off to.

Although you already have a plan (and you may have been hired specifically because of that plan), now is not the time to pontificate on what you intend to do. Your first job is to listen and learn and build relationships. You need to talk with every stakeholder you have. (And that is a lot of people!)

First is the community of people who use the IT Services—from VPs and managers, to power users and other users. Later, you will be coming back to these people with a specific agenda and questions. But at this point you are just laying groundwork. Tell them you are here to make things better, then shut up and take notes. You want to hear what is on their minds and start building the reputation of being someone who listens.

You will come away from these meetings with a relatively good idea of who your customers and users are, what services each uses, what they use those services for, and what pains they experience. You will not yet have a complete picture of any of this, but this beginning will give you what you need for Step 3.

The other people you need to talk with are your IT staff. Again, you are not there to tell them about how things are going to be different. You are there to listen and learn. Their perspective is diametrically opposed to that of the other stakeholders, and reconciling what you hear from them with what you hear from other people can be a valuable way for you to begin sorting through and making sense of it all.

This talking needs to happen both individually and with the various IT workgroups. You will be listening for their perceptions of the customers and end users of their IT services as well as perceptions of the others within IT. You will also be watching for dysfunctions that may be contributing to negative perceptions, both within IT and within the customer community.

And of course, the biggest thing you are doing with your staff is cultivating the idea that you are not the enemy, and that you are genuinely focused on making things better. You must build a positive relationship with them because you will be unable to do anything of consequence without their support and help.

Extreme #2: You have a long and contentious history to overcome.

If you are in this situation, I don't need to tell you about how painful it can be. The main problem is broken trust on both sides, and this second step is aimed at that problem. This is not to say that you can repair trust with a few meetings. That is not possible. But work on it must begin immediately so that relationships can begin to mend as soon as possible.

Just as above, you will need to meet with all of your stakeholders, both within IT and your customer and user community. The purpose of these meetings is to announce that beginning today things will be changing. But you do not want to start spouting specifics. You want to follow that announcement with as open a discussion as can be mustered about what they think should change.

Your external stakeholders may use this opportunity to skewer you and your staff, so be prepared to hold your tongue and simply take notes. By listening without defending, you may learn something about their situations and needs. Then again, you may find yourself simply weathering the same storm that has battered you before. The good news is that you are demonstrating the sort of civil discourse that must replace contention if the situation is ever to improve. Even if the civility is purely one-way, it is still a good first step.

With your IT staff, you want to begin brainstorming opportunities to do things better within IT. They are likely to focus on problems with the users and customers, and allowing this sort of venting is appropriate to a point. But you want to keep redirecting them to things that are under IT's control. What can we do better? How can we change? Even if there is more bellyaching than idea generation, it is still a good thing, because you are beginning a very necessary pattern that will take time to become ingrained.

Step 2 – A Springboard to What Follows

Beginning with Step 3, you will actually be making the changes that are necessary to improving how your IT shop runs. Step 2 opens the communication lines that enable all of the following steps. The criticality of Step 2 cannot be over-stated. You may think that you can just take command and do the right things, but your success will be limited (and may be completely scuttled) if your key relationships are not bolstered first.

How important is talking? Take a look at the 10 steps that we listed at the beginning of this article. (I'll wait while you scroll back …) Notice anything? That's right. Half of them involve talking. Hard work yields its best results when we forge strong relationships with our key stakeholders and we listen to them.

There's no time like right now to start talking!

Related Links
If you missed Alan's webinar, the recording is available for purchase here, along with Alan's detailed checklist, several supplemental templates, and instructions for claiming 1.5 Category A PDUs.