Outputs or Outcomes

/in /by

Why do we measure outputs instead of outcomes?

There are many reasons, but here are a few:

1. outputs are easier to measure
2. to measure outcomes, you must ask stakeholders what outcomes they desire
3. our tooling is set up to report and measure outputs
4. we don’t think in terms of outcomes (sad, but true)

In IT, we are a service provider. This means we deliver (co-create) value through services.

This value comes in the form of outcomes.

An example where everyone can relate:
– you call the Service Desk
– they answer inside of 7 seconds (output)
– the agent resets your password (output)
– you can use your laptop (outcome)

IT provides the End User services to the organization. Uptime and usability might be desired outcomes.

Data

/in /by

Turning data into something actionable is more difficult than it seems.

We have ample data … possibly too much.

This data must be actionable for decisions.

Data is gathered, governed, and secured for decision-making.

Remember the D-> I -> K -> W model

The goal is to enrich and contextualize the data into wisdom.

Now, think about your ITSM & ITAM data. What do you need to do for that data to help make better enterprise-wide decisions?

These are the questions that need to be asked.

Don’t Blame the Tool

/in /by

If an ITSM or ITAM tool implementation is unsuccessful, it’s not because of the tool.

These tools are the best they’ve ever been and are improving all the time.

If an implementation is unsuccessful, it’s because of the service provider (implementer) or service consumer (client), not what’s being consumed (tool).

Getting calls after unsuccessful implementations, my questions usually are:

– what has leadership done to ensure success?
– were all stakeholders involved and engaged?
– were processes, procedures, and work instructions built for the users to be successful?
– how was the CMDB scoped?
– what governance was put in place?
– was discovery working well?
– what type of knowledge transferred and documentation created?
– was the tool implemented similarly to how the implementer has implemented the last few?

The tool implementations are transformations and have so much that can go wrong.

Our Why

/in /by

We have a problem in our industry …

millions of people have gone through ITIL Foundations training, but the majority of organizations struggle with Service Management.

Though good and helpful, this tells me that the answer is not more trainings. The material is not being applied.

I want to posit one potential enabler for improvement:

a place for thoughtful discourse.

We need to be able to share ideas, strategies, and everything else to raise the bar.

This is one reason I started the Service Management Leadership Podcast.

Check it out if you have not already.

Our stakeholders are expecting more and more from Service Management.