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.

Service Management is not a Project!

Projects are like weddings, services are like marriages

We have a tendency in IT and ITSM to focus on getting done. While that is commendable, don't forget that at the end of the improvement project, whatever is delivered has to live on. 

Are you focused on the wedding or the marriage?

All Measures are Proxies

I've been a stat-head my whole life. Whether it's sports stats, how much milk our cows were making, box office data, or incident data, I'm interested. So I'd like to focus this post on what data can tell us and what is cannot.

Most people are familiar with the notion of proxies - a measure that is used when you can't measure something directly. In theory, anything can be used as a proxy for anything else. For instance, the number of mirrors I have broken or black cats that have crossed my path could be a proxy for how unlucky I will be in the future.

In practice, we tend to only use a proxy when we perceive a cause and effect relationship. For instance, we use a customer survey score as a proxy for customer satisfaction. A good proxy meets the following conditions:

• Credibility - stakeholders believe that the proxy is a reasonable stand-in
• Correlation - movement of the proxy appears to mirror the movement of the item to which it is linked

In a sense, even things that we can easily measure serve as proxies for something else we can't measure. For instance, batting average in baseball is a proxy for whether a player is a good hitter. The amount of money in our bank account is a proxy for how wealthy (or poor!) we are. And so on.

Where this becomes important in ITSM is when no one agrees on how to measure something. For instance, think about the warranty measures - availability, capacity, continuity and security. There is no one agreed definition for any of these terms that would allow you to take a set of data and calculate its measure. This causes a lot of headaches as people debate what the "right" formula is to calculate availability, for instance.

The most useful way to think about these terms is to understand why we want to measure these things. Most groups want to measure these things so they can understand how well a service is performing. It also helps them communicate with the customers of their service. 

Do we need the "correct" calculation in order to do these things? No! We just need to calculate it in a way that is credible to stakeholders and that correlates with delivery of good service. As long as everyone views the calculation as reasonably approximating reality (as they see it), and helps them focus on what areas to improve, the measure is as good as it needs to be!

So the next time you're struggling with metrics, ask yourself why you're trying to measure something. As Lean principles state, overproduction is waste. Don't try to produce a perfect measure when a decent one will let you do what is needed to deliver value!

The Inverse Anna Karenina Rule

“All happy families are alike; each unhappy family is unhappy in its own way.” 
― Leo Tolstoy, Anna Karenina

Anyone who has been in IT for a while starts to hear the same themes repeated:

• "Why did they make a change to X when $BIG_IMPORTANT_THING is going on?"
• "I called this in last month and it's still not fixed and I haven't heard a thing"
• "Why are we spending on X when Y is is such lousy shape?"

This experience along with seeing the Tolstoy quote above led me to coin The Inverse Anna Karenina rule:

All unhappy IT shops are alike, each happy IT shop is happy in its own way.

IT shops with low maturity in ITSM are fundamentally the same. They don't manage their processes, require heroes to save the day, and are always in reactive mode. People are busy, but IT is an order taker and nothing more.

As IT shops mature, they begin to align with their business. They take good practices, get good at the fundamentals, and then truly make them their own. They develop effective relationships both within IT and with their customers. IT becomes a strategic enabler and truly becomes part of the business. And since all businesses are different, the happy IT shop also becomes unique.

Reactive, Proactive, or Innovative?

When I used to work on help desks, people told me that we needed to be proactive instead of reactive. The image that popped into my head was Minority Report. I pictured something like this:

Roger (on phone): Hi, this is Roger from the Help Desk.
Employee: Hey Roger, what's up?
Roger: In 10 minutes, you're going to get an error when you try to save a file. Just add a 2 to the end and you'll be fine.
Employee: Cool, thanks. What number am I thinking of right now?
Roger: You're actually thinking about the letter Q.
Employee:  WOOOOOOOAAAAAAAAAAAAH!

How can we be less reactive without being clairvoyant? By understanding our business better.

Causes and effects

Most IT work is driven by the impact on the consumer of a service or process. They get an error, they call us. They have a need, they submit a request. This is reactive. No matter how fast you are, the consumer is still impacted.

Consumers are driven by their needs. They create demand on our resources and capabilities to fulfill those needs. Being proactive starts by understand their drivers and how they use our services. We can then monitor those resources and capabilities before demand occurs. 

For example, a sales person enters orders into our system when their customer buys a product. The application is a resource they need to complete their work. So we monitor the application. It goes down. We let the sales force and other stakeholders know and update them on progress until it is back up. This is proactive. We mitigate some or all of the impact of the service outage. Good for them, good for us!

Now let's go another step back on the chain. We mentioned that consumers create our demand. Where does their demand come from? It comes from their consumers! So they would like to be more proactive to their environment so they can be a better service provider. 

What happens the better we understand this environment? We in turn can provide advice on how our consumers can better use our services. We can also modify or add services that help our consumers serve their consumers. In short, we help our consumers be more proactive in their environment. This is innovative. We provide better services that help our consumers serve their market. Now we are serving a more strategic role - awesome!

Reaction is a part of being a service provider and never goes away. The more we can think about how we can be more proactive and innovative, the more we will contribute to business success and distinguish ourselves from other providers. Even if we can't be PreCogs, we can still provide value.

Obligatory Introduction Post

Welcome! This blog is my attempt to give back to the IT Service Management community. This post gets the introductory stuff out of the way. Let's tackle this in a Q&A format:

Who am I?

I'm Roger and I am in my mid-30s. I grew up in Oklahoma, got my degree from the University of Arkansas and now live in North Carolina.

What's my ITSM background?

I have been involved with ITSM since 1996. I started working on the help desk for a large retailer in Arkansas and now work at a large retailer in North Carolina. I have held technician and leadership roles in Service Desks and Problem Management groups. I currently lead a small team that performs internal ITSM consulting, process governance and project management.

What certifications do I have?

I am an ITIL v3 Expert, v2 Problem Practitioner and hold an ISO20K Foundations certification.  The value of ideas is my focus, not who's got the bigger cert.

Anything else?

I am open to changing my ideas when better ones present themselves. So feel free to disagree with anything I post and present a case for your thoughts.

RogertheITSMGuy