That executive dashboard tells you nothing
In most organisations, the leadership is eager to keep its finger on the pulse. Over the years I have seen many iterations for what is termed as the “Executive Dashboard”. The intention is to ensure the decision makers have enough information right at their fingertips. This should be a very powerful tool. The reality is much more painful.
The dashboard should provide real-time information to ensure that, for example: you don’t exceed the speed limit, or you know when you need to change the oil. However, the standard executive dashboard has so many bells and whistles, finding useful information would be like asking me to open up the bonnet and tell you where the alternator is. (I have now given you all an excuse to never lend me your car.)
What should a dashboard in a business environment have on it?
Remember the memory game? (The irony of asking that question is not lost on me.) You look at a tray of items for a minute or so, then a table cloth is placed over it and some items are taken away. When the table cloth is removed some items are missing. Your job is to name all the things taken away.
I dare you to do that with your “Executive Dashboard.”
I have a fair amount of experience in IT operations and service management environments. It turns out, what’s really important to the Director of Infrastructure, is not necessarily what the CEO cares about. (I’m talking to you, “Number of new incidents last month”.)
I bet you’re thinking, “I do need that, actually.” Do you? What is the first question you ask when you see that you had 7,000 incidents reported last month? Something along the lines of, “and how many of those were major incidents?” That’s what you want to know.
If this appears on your executive dashboard, get rid of it right now! I doubt it would be noticed as missing, unless they’ve read this blog.
The challenge really, is to take away what they really care about. Then you know they care about it. But what about the stuff you care about and want to be seen?
Why do you care about it if they don’t? There must be a reason? You need to find a way to communicate that through an item that can be placed on the dashboard.
It’s not easy is it?
Other colleagues will (or have) address(ed) quality, foundation, regulation, and operation on that data. Now we should think about the surfacing of the data.
One method I have employed is to use indexes.
From experience, this is always considered so far down the project waterfall, you might as well tie rocks to it and let it sink into the depths. Whatever ends up getting surfaced, without proper planning, is the equivalent of hoping my parents’ 106-year-old grandmother clock will ensure the trains run on time.
When you have clearly defined why your business does business, the next step is to figure out how to demonstrate that you are headed in the right direction. Commonly known as critical success factors (CSFs) and key performance indicators (KPIs), these metrics are going to make it easy to evidence that good decisions are being made, daily.
More often than not, however, these are poorly defined, and badly executed, with little concern for their gravitas. There are too many, they are too widespread, and are all very difficult to influence. They measure an historic position, reflecting disparate and uninteresting parts of the organisation.
Referring back to the “Number of new incidents” as a KPI mentioned earlier – what do you actually want to do with that ‘KPI’?
If you want less incidents, the ultimate solution is very simple:
Take away the new button.
Of course, that’s ridiculous. Since taking away the ‘create new incident’ step is not going away, we can start to understand why KPIs need to reflect something tangible and actionable. The challenge is that due to the sheer volume of information, you have to create lenses of data that create a culture that is responsible for that data.
Pick up those lenses; whether it’s the director, operations manager, or service desk agent. What do you want them to do when they see that KPI?
Context is king.
If you have a Service Desk that needs to resolve tickets as quickly as possible, high volume quick fixes will be the focus. If that relates to a development team whose target is to have as few issues raised against them, the Service Desk is inadvertently causing another part of the same organisation to fail.
This is why you need that business objective driving KPIs. Objectives at too low a level within the organisation means you can’t ensure you don’t have conflicting KPIs. But you will have a number of indicators at a more granular level that will demonstrate performance. These need to be communicated back up to the overall objective. That’s where indexes come in.
Like the FTSE or NYSE the intention is to consolidate the overall performance into a single score that can be glanced at and understood. If there is a cause for concern these can be delved into, so that focus can be given to the right area in a much more efficient use of management time. And you will avoid conflicting KPIs. If they conflict, you will continue to perform poorly until you realise that they don’t play nicely with each other.
Not sure how to set good objectives? Let’s take a look.
How to choose your business outcomes
Most businesses operate, rightly or wrongly, on the bottom line. Profit and revenue are, naturally, a good measure of the health of a business. People pay attention to the flow of cash.
However, the more prominent and useful goal for a business is not cash based, for the most part. Most customers do not pay for products and services because they want the company in question to have their hard-earned dough. Customers are much more selfish than that.
They are going to pay for things that enrich their lives. Whether it’s the essentials which mean they can have clean teeth each morning, or a smart watch that creates some lively experience that there is no real need for – the customer parts with money because it makes their lives better than it was.
So, the average company whose primary goal is profit is missing the main reason why a customer might engage with them. And if profit and cost are the main driving forces internally, the customers who enable that business to function will actually suffer. You can shout until you are blue in the face about cutting costs here and streamlining there (in and of themselves they are not bad initiatives), but it should always boil down to what is going to keep that business alive in one, three, five, ten years from now.
The customer is not going to be impressed by how much more efficient you are if your products are expensive and don’t enrich their lives. The business is only going to be alive if it still has customers. So, when you’re defining objectives, go with customer- or product-centric objectives.
I’ve written elsewhere that most SLAs are not really helpful. Most of them are based too late in a process (i.e. the end of it) and don’t capture the objectives the company is striving to achieve.
Of course, there are arguments to keep vendors honest with performance metrics, but more often than not the exact opposite takes place. One vendor I am aware of, because they would have to pay service credits for a P1 major incident, would simply classify a P1 as a P2. They would handle it and treat as a P1, but just lie about it in the classification. This is unhelpful on a number of counts, not limited to giving their customer a false sense of confidence that services were a lot healthier than they actually were.
This is outlined well (along with some other things) in this ServiceNow webinar. I don’t know if they go far enough, but it goes a good way towards a new approach. Without falling down the SIAM rabbit hole, if your SLAs aren’t supporting your objectives, then scrap them.
Now that I have deconstructed dashboards and metrics, it’s time to rebuild these concepts. But I’ll cover that another time.