Tag Archives: Reporting

Why your ITSM house of cards is a bad deal for your business

Share twitterlinkedinmail

Is your ITSM implementation like a house of cards, prone to fail with the slightest disturbance?  Here’s some examples:

  • A request for change that isn’t appropriately vetted yet is implemented within the live environment. Subsequently, that implemented change results in an extended outage of a critical business system.
  • Service interruptions are characterized by frantic efforts to restore service, cause analysis exercises that produce more theater than substance, and lost opportunities for improvement.
  • A seemingly simple service request that requires extraordinary effort and time to fulfill.
  • An IT organization that is surprised when the failure of a third party’s product or service cripples the business.

ITSM, done well, delivers effective and efficient services and practices based on the use of technology.  Done well, ITSM connects IT efforts and technology investments to business results and strategy.

Instead, what many ITSM implementations produce (or reinforce) is siloed behavior, disjointed delivery efforts, lack of transparency, and poor end-user satisfaction. Further exasperating the situation is that in many cases, IT doesn’t even understand how what it does enables business results and value realization.

Why does bad ITSM happen within good IT organizations?

Every IT organization has talented people who are knowledgeable, smart, and have outstanding technical skills. These people are motivated to be the absolute best that they can be and are driven to  succeed. Good ITSM should augment the efforts of these talented people and enhance the overall performance of the IT organization. ITSM should help the IT organization become a valued, respected, and competitive differentiator for a business.

Sadly, this is not the case with many IT organizations. Many implementations have fallen short of achieving the benefits of good ITSM and wasted the talents and efforts of people within IT because the foundational elements needed for success are missing. What are some attributes of a “house of cards”  ITSM implementation?

  • Taking only a “technology-first” approach – While having the appropriate tools are important, good ITSM doesn’t result only from the implementation of technology. With a technology-first approach, ITSM thinking becomes limited to the capabilities of the technology, and not how ITSM should meet the needs of the business.
  • No alignment to organizational strategy – ITSM implementation is about IT, not about how IT efforts and provided technologies enable the achievement of business goals and objectives. Other than justifying the organization’s investment in the selected technology, there is no business case that was developed to help executives recognize the value of the investments in ITSM.
  • No shared and agreed understanding of ITSM benefits – Some organizations believe that ITSM is just something “that the service desk does” for processing a user request or managing an incident. Making a bad situation worse is that many within IT think that ITSM has nothing to do with the work that they are doing.

How did this happen?

There are several reasons why ITSM is no more than a house of cards for many organizations.

Many ITSM implementations suffer from short-term thinking, prioritizing technology implementation over business value and employee experience, or even worse, prioritizing internal IT concerns over business results.

A house of cards ITSM implementation is often the result of inconsistent processes and a lack of governance, exasperated by poorly designed, implemented, and unenforced policies.  As a result, different parts of the IT organization manage its work differently, making transparency into IT difficult.

In most fragile implementations, ITSM was treated as an IT initiative, not a business initiative.  Had business stakeholders been involved from the beginning, ITSM would be business-oriented, with reports and measures that matter. Instead, ITSM became a layer of bureaucracy for interacting with IT.

Regardless of how it happened, there’s been no reason for senior business management to care about ITSM – until now.

Why business executives need to care

Historically, many senior business executives have paid little attention to service management – and understandably so. Reports contained data that had no meaning to executives. Performance metrics produced by IT said one thing, but end-users told a vastly different story regarding their experiences with technology and processes. ITSM was viewed simply as something being done at the service desk. With so many foundational elements missing, many ITSM implementations gave executives little reason to care.

But times are changing – and changing fast.

Businesses are rapidly and increasingly relying on technology to drive the business –  and the customer experience – to new horizons.  With ever increasing frequency, customers are interacting with technology, such as intelligent automation, chatbots, natural language processing, and generative AI, and not with humans.

But without good ITSM, how can an organization ensure that technology is delivering the desired value and outcomes needed by both the business and its customers? There are many known cases (including the UK’s NHS IT program[i], Canada’s Phoenix Pay System[ii], and Knight Capital Group software deployment[iii]) where businesses that ignored good service management practices and have experienced significant and embarrassing failures.

The fact is that today’s digitally driven businesses require good ITSM for business success. The question that was usually never answered remains – how will your ITSM implementation support your business’ strategy?

Today is a good day to prepare for the ITSM of tomorrow

Good ITSM is more relevant today than ever for modern, digital businesses. Here are three steps for moving ITSM from a house of cards to a reliable and solid business capability.

  • Develop a business capability map. A business capabilities map is a visual tool used to depict what a business does, not how it does it. A business capability describes the capacity, materials, and expertise an organization has or needs to complete its work.[iv] One of the things that makes a business capability so interesting from an ITSM perspective is that capabilities have outcomes.
  • Conduct an ITSM capability assessment. Not to be confused with a maturity assessment, a capability assessment evaluates the organization’s service management abilities, capacity, and skills. Do not limit this assessment to IT operations – look at ITSM capabilities holistically, from strategy through design, development, transition, and continual improvement.
  • Do a gap analysis between the business capability map and the ITSM capability assessment. What areas of business capability are well-supported by good ITSM practices? Where are the gaps between business capabilities and ITSM capabilities? What are the impacts of those gaps? What needs to be done differently from an ITSM perspective to meet the demands and requirements of those business capabilities?

Stop relying on an ITSM approach that is built as a house of cards. Completing the above steps will start your ITSM implementation on an incredible transformation to strategic capability, both for the organization and for IT.

[i] Asgarkhani, M. (2022). Failed tech deployment initiatives: Is poor IT governance to blame? European Conference on Management Leadership and Governance, 18(1), 524–528. https://doi.org/10.34190/ecmlg.18.1.728

[ii] Ibid.

[iii] https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

[iv] https://www.lucidchart.com/blog/a-quick-guide-to-business-capability-maps , Retrieved February 2024.

Share twitterlinkedinmail

Start with Reporting first *then* Measurement

Share twitterlinkedinmail

What are some common reasons why IT organizations measure and report metrics? Unfortunately, in my experience, the answers are not always the greatest.

  • “We produce this report / measure this indicator because we always have.”
  • “We measure this indicator because everyone else we know does.”
  • “We produce this measure because our tools enable us to.”
  • “We read/heard about this measure in a magazine/training class, and it sounded like something we should be doing.”
  • “My boss expects to see this report.”

Like I said, not the best reasons that I’ve ever heard.

The purpose of measurement and reporting is to enable fact-based decision making. But if no one is making any kind of decisions from your reports, then you’re not capturing and providing the right measures to the right people in your reports. Perhaps you should apply outcome-based thinking and start with reporting first, then measurement!

Are your measures and reports telling the (right) story?

The fact is that regardless of the quality of your measures and reports, a story is being told. But is it the story that needs to be told?

But what you measure, what you report, and the story that is told within those reports is the difference between enabling valuable insights and actions and just noise and confusion. Here are some common measuring and reporting mistakes:

  • Mistaking outputs for outcomes. Many reports contain measures that confuse activity (outputs) with accomplishments (outcomes). In other words, just because you closed the incident record, or answered the telephone within 60 seconds, doesn’t mean that you’ve accomplished any kind of result.
  • Only focused on the Service Desk. Measures that are meaningful and relevant to the service desk have little to no meaning outside of the service desk. No one outside of the service desk really cares about measures like ASA or utilization.
  • Missing business-oriented measures. In today’s digital enterprise, technology is integrated with business processes – so integrated that businesses cannot function without technology. But IT-produced technology-based measures and reports typically do not reflect the business of the business.
  • The infamous “watermelon SLA” report. The measures that IT reports do not reflect the experience of the consumer. IT hits its (self-defined) targets, pats itself on its back, but then wonders why customers aren’t happy. Well…
  • “Customer satisfaction” isn’t about the customer – part 1. First, many IT organizations conflate the terms “customer” and “user.” Remember, a customer defines the requirements for a service and signs a service level agreement (SLA). Users do not sign SLAs. Yet IT organizations send out satisfaction surveys to users and call that “customer satisfaction.”
  • “Customer satisfaction” isn’t about the customer – part 2. Secondly, the surveys that are being sent out to users are often not returned. And if they are returned, it is typically from people who are not happy with the interaction that they just had with IT. Yes, occasionally you get a response from a happy user. Yes, it’s good to know that users have had a poor experience. But regardless of the response, IT continues to send out the same surveys, containing the same questions, reporting the same measures, and nothing changes– good or bad – about user interactions with IT.

Not having consistent, relevant, and meaningful performance measures and reports damages the reputation and value of IT. What’s worse, measurement and reporting are activities often done as an afterthought.

Start with reports first

Starting with a “reports first” mindset will dramatically improve the usability and impact of your reports. How can you apply outcome-based thinking to measurement and reporting? In other words, how to start with reporting first?

Identify the audiences for your reports. Yes, audiences – plural. At a minimum, your audiences will be consumers, IT management, senior executives, and the service desk team. Keep in mind that each audience will have unique reporting requirements. For example, reports that you may provide to senior executives will be different than reports that you may provide to consumers; reports that you may provide to service desk staff will be different than reports that you may provide to other IT colleagues.

What does each audience want to know? Why do they need to know this information? What will they do with the information? What decisions do they need to make? Do they have performance objectives or targets that rely on this information? How frequently do they need the information?

What do you want your audiences to know? Why do you need them to know this information? What would you like them to do with the information? What decisions do you want them to make?

By identifying what your audiences want to know, as well as what you need to tell them, you’ll identify the specific measures that you will need to capture, monitor, and report…but there’s still more to do.

  • Does the data to develop these reports exist?
  • Can the data for each measure be captured?
  • Is the data coming from a source that can be controlled?

If the answer to the above questions is “yes,” you’re on your way to providing the measures and reports your audiences need – and value. But if the answer is “no,” never fear. This just means that you and your audiences will have to do some more work and negotiate what can be done that will meet your audience’s needs.

Make your reports measure up!

Do your reports measure up (pardon the pun!)? Here are my suggested steps for getting your approach to measurement and reporting up to speed.

  • Audit your current reports. Do you know the audience for each of your reports? Are you “missing” an audience for reporting? Do you know what decisions are made from what is reported?
  • Develop decision maps for each published measure. What decisions are enabled by a published measure? Who makes or should be making decisions based on the measure? What may potentially no longer need to be reported?
  • Compare published measures with the organization’s Mission, Vision, Goals, and Objectives (MVGO). Are your measures strictly technology or process measures? What measures are needed to relate the activities of your team or department to MVGO?
  • Review your reports with your audiences and gather feedback. Yes, meet with the receiver of each report and walk through your current reports with them. Ask questions about their job function, business contributions, and goals for their team. Ask them to tell you what measures they need to act upon or make decisions. This does a few things for you. One, it helps you understand how reports are being used. Two, it provides you with insight into another area of the organization. Three, it builds and enhances your reputation as a business-focused (not just technology-focused) colleague.

Effective measuring and reporting don’t happen by chance. Starting with reporting first will result in better measures, better decisions, and better value.

Do your reports measure up?  Do you need reporting that drives good decision-making and tells the right story?  Contact Tedder Consulting today for an no-obligation chat about how to tune-up your reporting and measuring!

Share twitterlinkedinmail