The story goes that a wood worker was asked to cut ten planks of wood two feet long. He took the first measurement of two feet and cut the wood to the correct length. Then he took the correctly measured plank and used it to cut the second plank to the same length. He then took the second plank and used it to cut the third plank to the same length. Repeating this process, the tenth plank was six inches longer than it should have been.
You can only manage what you measure
What you measure changes behaviour
There are other similar sayings, but they can cause things to go sour when the measurement is off target; i.e. when your KPI doesn’t align with the business objectives. If you’re not paying attention, you forget the original intention of a KPI, using something to measure that moves you further and further from the original. Then you end up with a scenario similar to this, an example from the airport retail world. The ‘scanned boarding card’ performance measurement may have meant something to somebody at some point in the long history of retail in airports, but it’s flying in the face of the actual purpose of the store.
Imagine the leader of this company finding out that the stores are firing people because they didn’t scan a boarding card, a voluntary action, especially if this individual is contributing to helping customers find what they need in the store. The data from the scans may help the stores better stock their shops, but the new customers won’t be able to find anything because the most helpful employee has gone.
What is the reason the business exists? To provide customers with goods? Or to have perfectly stocked, yet empty stores? A perhaps innocent and well intentioned KPI has been built around something that is voluntary. While in itself not an issue, the desire to increase this number has created a toxic culture with a single word: “Key”.
When the “Key” creates a toxic culture, it’s best to drop the ‘K’ and go after something else.
Working this through in an IT environment could be something like wanting to know how many high priority changes are being implemented. I’m often asked for these kinds of data requests. To be honest it has become less frequent because I approach things differently now. On the surface, it’s a simple request, but the undercurrent is such that my usual response is to say, “No.” This means that the requester tries to achieve it themselves, and then they come back to me asking why I said no.
What’s the reason for asking for a report on implemented high priority changes? I would guess it’s because there are too many high priority changes happening. This reason lends itself to further interpretation. When someone wants a report, it should be to do something with. If they’re doing nothing with it, you might as well draw them a pie chart, or give them an actual slice of pie, and let them consume it in a coffee break.
If the requestor thinks there are “too many” then the action they want to take is to reduce high priority changes. And that is what we’re really after. You don’t want to know how many high priority changes are being implemented, you want a dashboard that will aid you in making better decisions to reduce high priority changes from being implemented, ideally before they are scheduled or even submitted for approval.
That should be the thought process in a dashboard.
If you don’t know what to do when you look at a dashboard, it’s a pointless dashboard.
The demand for things to be better, faster, cheaper, richer, fuller, simpler, more complete, more featured, more, more, more… is creating an industry entirely around improvement. Innovation, in its traditional form, has been superseded by the concept of improvement.
“There is nothing new under the sun.”
In Jenny Dearborn’s book, “Data Driven” she claims that competition is not based on who has the best products, but who can operate them most efficiently and effectively. It’s not that innovation is dead, but it should be thought of as insufficient for a business model. i.e. If you can’t deliver on your innovation it’s not worth the investment.
It has been said that innovation is, by its very nature, inefficient, so don’t try to make innovation efficient. What you need to do is focus on improving all the other areas of the business, so innovation can continue to thrive.
But most of the time, people are fire-fighting. And it’s a glamorous task.
Fire-fighting is a glamorous task.
That doesn’t make it a good task. High-risk high-reward is terrible if you had to set yourself on fire!
In hero cultures, it’s very hard to change the attitudes that pervade operational environments, where if you’re fixing broken stuff, you’re more valuable than if nothing ever breaks. And so, Reaction Service Improvement is born.
Organisations who have implemented ITIL, lorded as an industry standard, shoehorn a proactive process like Problem Management, into a glorified major incident management activity, trying to ensure a massive outage never happens again, instead of utilising its worthy components to ensure those outages wouldn’t even happen in the first place.
It takes great courage to change a culture to make improvements before they’re needed, so that the fire fighters can sit and wait longer and longer.
Major Incident Managers should be targeted with as much downtime as possible. The longer they sit idle, the more successful your organisation will become. (I have written previously that the target for your backlog should be zero.)
What action are you going to take when you see this number? If it’s to ask for more data, then it’s a bad place to start. Even in a leadership position, when you look at a dashboard, you’re wondering whether or not you need to call someone about bad performance, or whether you can carry on with what you were hoping to achieve each morning. A Major Incident Manager should be looking at a blank screen and if anything appears, they take action.
This means that there is a KPI behind my “high priority changes” that will help me understand if my process is healthy. Is it success percentage? Or percentage of service impacting changes? What is the main number that will give me the ability to decide if I need to take action and what action to take to get it healthy, or can I take initiative in another way because we’re all good here? And if I want to take initiative, that would involve an entirely different dashboard and KPI.
Now that we’ve established how to choose a KPI, in the next blog, I’ll build up to placing that on a dashboard and what else should be there.
When you get that right, you end up with a culture that is self-policing, in the best way possible; achieving the business goals set out by the leadership.
Let’s get to the thing behind the thing; the action behind the reason.
