The ITSM acid test for People, Process, and Tools

The ITSM trinity of People, Process, and Tools is most evident in reporting. If all three corners of the triangle are not in alignment, the following issues will be evident:

• If PEOPLE do not have the proper incentives and deterrents to encourage desired behaviors, reports will often have missing or incomplete information. This is because only enough information is captured in records to allow the person to meet their needs, while the needs of others are unlikely to be met.
• If PROCESSES are not defined, agreed, communicated, and trained, reports will have information that is disjointed, duplicated, and inconsistent between groups and team members. This is because different areas are applying different standards to how they capture information in records.
• If TOOLS are not properly configured, reports will not aid analysis required to determine trends and enable effective decision making. This is because the tool does not correlate information well, or is unable to access information in a manner to allow for trending.

How do we avoid these challenges? 

• Ensure that processes are more than documents in a binder. They must serve as agreements between teams on how work will be performed.
• Develop tool configurations in concert with process development. This must be an iterative approach as process development should drive tool selection and configuration, while tool capabilities may impose limitations on a process.
• Train staff on the intent of the process and how to use the tool to enable the process.
• Publish clear standards on how information created during process execution should be captured in records.
• Sanction appropriate rewards and reprimands to drive adherence to norms and rules.
• Monitor and improve all of these elements.

Getting the ITSM trinity working in concert will transform an ITSM practice into a value engine for the enterprise. That's the best kind of report!

The most neglected role in IT Service Management?

Pop Quiz:

• Who do most people in your organization go to first when there is a notable Problem?
• Who provides your final IT sign-off on a significant Change?
• Who defines the available Service levels?

Hopefully, your answer to all 3 questions was the same - the appropriate Service Owner. Sadly, in many organizations this is not the case. The ITSM organization is really a process organization. Even if the process owners try to focus on process improvement, they get sucked into being the default service owners for every IT Service. In trying to pull double duty, they often make little progress on either front. 

A friend of mine recently reminded me that Senge's Fifth Discipline calls out focusing on "highest leverage" points. One of those points for IT Service Management is clear accountability and authority for IT Services. A motivated Service Owner can often overcome poorly defined or nonexistent processes. 

If you're early in your ITSM journey, it's easy to get focused on all the processes described in ITIL. Don't fall into the trap of doing IT Process Management - it's called SERVICE Management for a reason!

My submission for TFT13

It's time to put the "Manage" back in IT Service Management - the ITSM way!

In my TFT13 presentation, I will apply Service Management thinking to the four domains that today's IT Manager must succeed in:

• I - great managers begin by managing themselves effectively
• Team - great managers build great teams with their staff and form great teams with their peers
• Stewards - great managers understand and deliver against the needs of their direct supervisors and other organizational leaders
• Marketplace - great managers respond to and shape their customers, industry, and society

For each domain, I will show how good practices from frameworks such as ITIL and COBIT 5 apply. I will also translate those ideas into specific actions you can take immediately to increase your value. 

After over 17 years in IT and over a decade in leadership positions, I have learned a lot about what works - and what doesn't. I would be honored to share some of these lessons with a global audience. Thank you for your consideration!

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!