Archive for category: Uncategorized

As you start your week, I would like to posit 2 things to consider:

1. No matter what initiative you are working on, build in an improvement mechanism. What our stakeholders view as valuable today will not be what they value tomorrow. We must account for how to handle the change, creating improvement opportunities in both what we do and how we do it.

2. Take an iterative approach with small steps. If the last two years have taught us nothing else, the best long-range plans and initiatives will be disrupted by external factors.

Disruption is coming.

We must do better.

We measure many things, but few relate to business objectives.

We capture a lot of data, possibly too much, but do so without matching to business objectives and desired outcomes.

Two things we must begin doing:

1. Ask all stakeholders what outcomes they desire, and prioritize accordingly.
2. Make sure every activity, measure, and resource to these prioritized outcomes.

Sounds simple.

It is not.

However, there is no better time to start than now.

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.

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.

With every organization becoming increasingly complex due to technology, I have seen something surprisingly change …

the increased focus on the skills to solve the problem placed ahead of time in the industry.

Yes, industry experience matters.

However, someone who knows how to solve the problems you are facing through expertise and intelligence will only struggle to learn the organization for six months to a year, if that long. But, that is just one small piece of the puzzle as that person knows how to solve the problem they were hired.

The learning curve for someone with good – not great – ability who is intimately keen on the industry will take years to catch up in skills and abilities, if they ever do.

With common technology problems to solve, the industry-specific requirements will become less important.

I know some will disagree.Please comment below.

But, I would argue that most organizations are more similar than most realize. Having bridged many industries, I can say that the core problems are very similar.