People Being People

This post is about the critical role people play in ITSM efforts. It is inspired by recently getting the pleasure to discuss ITSM with Pink Elephant's Troy DuMoulin. He shared a blog about rethinking the common mantra of People, Process, and Tools and I'd like to expand on this line of thought a bit.

I created a graphic that I think is a more accurate reflection of the relationship between these three pillars of how work gets done.

• People Being People - I first heard about the concept of jen from Alan Watts. In the context of ITSM, we can never forget that people are going to behave as people throughout history always have. They will forget things, they will sometimes take advantage of others, they will break rules to help others, and they will behave in all other sorts of noble and depraved manners. You can't ignore it, and you'll always have surprising and unexpected behaviors to keep things interesting.
• People Executing Process - Processes don't execute themselves. Furthermore, people don't truly execute a process, they execute their understanding of a process. Troy shared a great quote on this topic - "the tangibles are not the deliverables". The reason to create documentation is to facilitate a common understanding among people. Otherwise it's just ink on paper on a shelf!
• People Employing Tools - Tools are powerful, yet they can never guarantee quality or effectiveness. People will employ tools to do things they consider valuable, and "fire" them if they get in the way. That may or may not match up with your intent! For instance, if a Service Desk analyst values efficiency over data quality, don't be shocked when they figure out the quickest way to record a valid Incident record so they can get to the next caller. 

The key takeaway is that we tend to fall short of what people need to adopt ITSM. A great approach to use in ITSM is the Balanced Diversity portfolio advocated by Karen Ferris. Whatever approach you take, give yourself some slack when your improvement efforts are impacted by people factors. After all, you're people too!

Antifragile ITSM

This post is about applying antifragile thinking to ITSM, particularly in the realm of Change Management. I'm a big fan of Nassim Nicholas Taleb, the author of Fooled by Randomness and The Black Swan. I'm currently reading his latest, Antifragile, and it is thought-provoking as his previous works.

A key point in NNT's works is that we often fall into traps because we believe that we can predict the future based on our understanding of the past. While this is true in some domains, we can get ourselves into a lot of trouble when we do so blindly.

A simple example is building a house in an area prone to flooding. The high-water mark is often used to indicate where it is safe to build. But that high-water mark would have been considered safe before that flood occurred! Therefore, we cannot blindly assume that we have seen the worst-case scenario.

In the world of Change Management, managing risk is of the highest concern. Most risk schemes use some combination of projected impact and likely probability to assign risk. The difficulty, as we have seen, is that probability only works when we know the likelihood of outcomes. And in the real world, we don't!

So what should we do instead? NNT suggests that we use fragility as a risk measure. The idea is simple - if there is more downside to a variable than upside, we need to limit our exposure to that variable. If there is more upside, then we don't need to worry about it. Let's see how this idea works on the "7 Rs" that are often used in Change Management.

Variable	Fragile	Robust	Antifragile
Who RAISED the Change?	An individual limited by what they know and expect	Standard Change with pre-defined expectations	Group effort that accounts for multiple perspectives
What is the REASON for the Change?	Service reasons directly related to desired outcomes	Standard Change with pre-defined relationships	Technical reasons unrelated to the IT Service(s) affected
What RETURN will the Change deliver?	A failed Change will reduce the value of overall Services more than a successful Change will increase their value	The Change has no effect on the value of overall Services regardless of success/failure	A failed Change will reduce the value of overall Services less than a successful Change will increase their value
What RISKS are there if we do or do not carry out the Change?	The Change could interrupt one or more Services if it fails	The Change will not positively or negatively affect IT Services	The Change will only affect Services already unavailable (e.g. Emergency Change to restore service)
What RESOURCES will be required to perform this Change?	The Change requires resources limited in their availability	The Change only requires resources in ample supply	The Change will require less resources than it supplies
Who is RESPONSIBLE for this Change being performed?	The Change can only be performed by a subset of the team with confidence	The Change quality is the same regardless of who executes it	The value of learning the organization receives from others performing the Change is greater than the potential reduced quality of the Change
What RELATIONSHIPS are there between this and other Changes?	The Change may affect other Changes negatively	The Change does not interact with other Changes	The Change will only positively impact other Changes

Thinking in this way causes us to focus less on trying to predict what will happen and more on limiting downside. The benefit is that even when we are lousy at predicting the future, we are less likely to be hurt by it. And since we are all lousy at prediction, we end up with a system that is less impacted by our inevitable failures.

How can this thinking be applied to other areas of ITSM? More to come on this topic in the future.

My first book review for the IT Governance blog!

Please check out my review of Karen Ferris' Balanced Diversity and let me know what you think. I am working on another review that should hopefully be submitted by the end of the month.

ITSM Fundamentals - Focus on Outcomes

This is the first of a series of posts about the fundamentals of ITSM. It is inspired by the many times when I was working in the Service Desk that my prior bosses told me we needed to focus on "basic blocking and tackling". For the non-American football fans out there, they were saying that we needed to focus on the simple items that were the foundation for everything else. While it's easy to get caught up in the bleeding edge concepts that exist in every field, success or failure is often determined by how well we execute the basics.

Although the ITIL includes a lot of processes, one theme that exists over and over is the need to understand the value delivered by our work. Too often, IT gets focused on the activities being performed and loses sight of why we do them. Over time, this results in a shift towards efficiency and convenience for IT, instead of value for the consumers of the work.

For instance, Lean Six Sigma techniques are valuable tools for improving how IT works. If they are used without understanding the purpose of the work, we may remove value without even realizing we have done so! It's useless to do something fast and with high quality if it is worthless to the customer.

To avoid this, take the following actions:

• Regularly meet with the consumers of your processes and document the value they want from the process
• Review ideas for changes to processes with the key consumers of the process BEFORE implementing changes
• Perform surveys that focus on the value delivered (such as SERVQUAL) and avoid the temptation to ask about how much you are liked

Remember, the purpose of ITSM is to deliver outcomes desired by customers. Don't ignore this because you think you know best!

The Most Important ITIL Process

What if I told you that not only is there a most important ITIL process, it's widely misunderstood and rarely treated as a process? It's true! Lost in the discussions about incidents, portfolios, catalogs and CSI is the fact that they are all dependent on another process. It is called out many times in all of the ITIL books. But this Rodney Dangerfield of processes "gets no respect". 

This red-headed stepchild of ITIL is Knowledge Management. Most practitioners can recite DIKW (Data->Information->Knowledge->Wisdom) in their sleep. That's the output of Knowledge Management. Few could tell you the inputs to KM, and fewer still how to go about improving their ability to perform KM.

So what are the key inputs to Knowledge Management? EXPERIENCES and INSIGHTS. Quite simply, if your organization cannot capture the experiences and insights of its members and reuse them, ITSM is hopeless. For instance, if your incident management process does not capture what was done and what was learned while service was being restored, problem management becomes nearly impossible.

While KM is a process, it is not an algorithm. It uses heuristics and is a prime candidate for Adaptive Case Management techniques to ensure its outputs achieve their intended purpose. Effective knowledge management is built on standards that include the following items:

• Standards for recording data around key experiences and insights - incidents, problems, requests, etc
• Standards for processing data into information - classification, categorization, etc
• Standards for analyzing information into knowledge - comparisons to targets/expectations, trends, etc
• Standards for presenting knowledge to support effective decision making (wisdom) - identifying decision criteria, how to represent performance in graphs/tables/charts, etc

To support these standards, you can use models such as the Knowledge Spiral and Knowledge-Centered Support to increase your organization's capabilities. The benefits are that you are better able to discern patterns and address them effectively. And instead of a red-headed stepchild, knowledge management can be the Golden Child that improves your organization's efficiency and effectiveness.

Shifting the Burden on Problem Management

"The cure can be worse than the disease" - Peter M. Senge, The Fifth Discipline

This is another of an irregular series of posts inspired by Senge's book. In systems thinking, one of the most frequent archetypes is called "shifting the burden". We have all seen examples of this. A common example is when someone deals with the stress of everyday living by turning to alcohol, drugs and other addictions.

IT organizations frequently shift the burden when it comes to incidents. Here's a simplified systems model of what we often see:

As a Service Desk manager, our first instinct to improve how we deliver service is to focus on handling incidents faster. We focus on templates, scripts, etc in order to reduce the time needed to handle a call. We reduce time off the phone for training and focus on getting people off the phone faster. This allows the team to answer the next call more quickly.

Nothing wrong with that on the surface, yet this by itself is a doomed strategy. As the business changes, IT systems either become less aligned to the business or IT makes system changes to respond. Either way, we almost certainly will experience increased incident volume. We then work even harder to increase throughput - more training, scripts, templates, and maybe we even get more staff.

Here are the main downsides over time:

• as you get more efficient, we have to expend more and more effort to get the same amount of increase
• one of the frequent casualties of increased throughput is lower quality

The end result is an Incident Management process that delivers shoddy service, provides little useful data, and burns out its good staff. All of these reduce IT's reputation and ultimately drive a wedge between IT and the rest of the business. Quite a vicious circle!

In order to get leverage on incident response, we need to focus on reducing the causes of incidents. While it does not return immediate dividends, as problems are eliminated from IT systems, we begin to see fewer incidents. This improves incident responsiveness and frees up more time for investigating problems. 

Now instead of a vicious circle, we get a virtuous one. Fewer incidents mean that employees can focus on serving customers and delivering value. IT systems are delivering more value and has a better reputation.

In summary, it can be very easy to get fixated on responding to events faster. This is rarely a path to success. Instead, focus on the patterns causing the events. The end result will often be more satisfying work that provides more value to our organizations.

The One Tool You Need to Find the Source of Your ITSM Adoption Problems

"Nothing undermines openness more than certainty" - Peter M. Senge, The Fifth Discipline

This is the first of an intermittent series of posts inspired by Senge's book and how it relates to ITSM. I just finished reading it this weekend and there is a lifetime's worth of ideas in this book. I'd love to hear more from those in the field that have used his ideas to drive improvement in their organizations.

Just about anyone that's been through formal ITIL training can remember the moment when they were convinced that the path to nirvana had been found. Just stand up the processes, build a service catalog, and voila! Heaven on earth, with cool technology to boot!

Alas, nearly all of us found that even if we had support from our boss (and even higher), there was resistance or even outright hostility. The harder we tried to get people to see the way to enlightenment, the harder reality pushed back.

So as a public service, I want to share the one tool that can help you identify the source of your (and my!) failure to drive ITIL adoption.

Yep, it's you. Don't feel bad, it happens to all of us. We get to evangelizing about ITIL (or COBIT, or LSS, or PMI...) and forget that the people we are talking to have a vision of the future too. And if we don't help them find a way to see how their vision fits with our vision, they will reject it.

To avoid this, we need to be genuinely open to the vision of others and realize we don't have all the answers (this is particularly a peril of those who have just finished ITIL Foundations and not had certainty beaten out of the by the Intermediate courses). It's not about "compromise", it's about making the vision richer by including more perspectives and ideas.

The end result is an opportunity for genuine commitment and greater chances of success. And that makes looking in the mirror more tolerable.