diagnostic<\/a> says whether it is your first lane.<\/p>\n","protected":false},"excerpt":{"rendered":"Before opening your dashboard, write down the decisions your business makes on a repeating schedule. Not the interesting ones. The ones that recur: how many people are on shift next week, whether this month’s spend continues, which of two things the team does first, when a price moves. Most teams can list them in a few minutes. The list is short and unglamorous, and it should become the starting specification for the dashboard. Almost every dashboard gets built without it, because by the time anyone asks what the thing is for, it already exists. Start from the calendar, not the data Every recurring decision has a rhythm attached. Staffing is decided weekly, usually on a particular afternoon. Spend continues or stops monthly. Hiring gets revisited quarterly. Pricing moves rarely and with warning. Write the rhythm beside each decision, and something useful happens immediately: you now know how often each number needs to be true. A figure consulted for a weekly staffing call has to be reliable weekly and can be noisy in between. A figure feeding a quarterly hiring decision can be slow, and buying speed for it means paying for freshness the decision will never consume. This is the inversion. Ask which decisions repeat, and let those decide what needs measuring. The dashboard becomes an output of the operating calendar, built to serve the decisions already on it. Two things usually surface while writing the rhythms down. Some decisions turn out to be made far more often than anyone claims \u2014 a weekly call that in practice gets revisited every second day. Others are nominally quarterly and have in fact been made once, then inherited. Both are worth catching here, because a rhythm you have misdescribed produces a signal at the wrong frequency and everybody blames the data. Give each decision a sentence before it has a number For each decision on the list, complete this before consulting any data at all: For , reviewed on : when crosses , will \u2014 unless . The first two fields are what the calendar produced; the rest is what serving that decision requires. Filled in for an illustrative service business: DecisionWhether to open the overflow shift CadenceWeekly, reviewed each Thursday SignalBooked hours compared with available hours ThresholdBooked hours exceed available hours OwnerOperations lead ActionOpen the overflow shift ExceptionTwo or more bookings remain provisional; reassess after confirmation Read back as one sentence: for the weekly overflow-shift decision, reviewed each Thursday: when booked hours exceed available hours, the operations lead opens the overflow shift, unless two or more bookings remain provisional. The exception needs governing as much as the threshold does. It has to name a narrow, observable condition and say what happens instead \u2014 reassess Thursday, escalate to a named person, wait for confirmation. An exception reading unless circumstances suggest otherwise hands discretion back to the team and calls it governance. Writing this before the data arrives is the whole method. Choose a threshold while looking at the chart and you will choose one that endorses the last decision you made. Choose it in advance and you have made a commitment the numbers can genuinely contradict. That is the difference between measuring and reassuring. The sentences are the Metric-to-Decision Contract, and at this stage they exist as demands. Each one is a specification issued to whoever builds the dashboard: this signal, at this frequency, accurate enough to act on at this threshold. A specification written this way is also a budget \u2014 it tells you which numbers deserve engineering effort and which need a spreadsheet somebody updates on Fridays. Now open the dashboard and see what is left over With the sentences written, the existing dashboard becomes something easier to assess: a pile of panels, some of which happen to serve a decision on your list. Three groups appear. Some panels match a sentence, and those stay. Some sentences have no panel, and that gap is the important half of the exercise \u2014 a repeating decision made with no signal behind it, invisible because the dashboard is full and a full dashboard looks like coverage. Everything else is a leftover: accurate, sometimes interesting, attached to no decision anyone repeats. Some of those leftovers earn their place anyway. A panel can exist purely to frame other numbers: total headcount, a market index, cumulative signups. Those trigger no response by design, and they may stay, provided they are labelled as context and kept outside the decision review. Displaying a number without a contract is fine; the damage comes from letting it consume decision time while pretending it governs something. The leftovers are easier to remove in this order than in any other. Audit a dashboard panel by panel and each one gets defended on its own terms, because any number can be made to sound relevant in isolation. Approach from the decision list and the question changes from is this useful to which of these decisions does it serve, and that question has an answer. The gaps cost more than the leftovers A decision made every week with no signal behind it is being made on memory and mood. It usually has an owner who is good at it, which is precisely why the gap has gone unremarked \u2014 competence disguises the absence, right up until that person is on holiday. Many of these gaps do not need a new dashboard panel. A weekly figure in a message, sent by whoever already has access, satisfies most of them. What they need is the sentence, so that the decision rests on a stated trigger instead of a practised instinct. An extra panel costs a little attention. A repeating decision with no signal costs a wrong call, on a schedule, invisibly. What the finished thing looks like The result is a dashboard organised by decision, with the data source as an implementation detail. Its panels are grouped under the decision they inform, ordered by how often that decision comes due, with the contract displayed beside each group. The review changes accordingly. The meeting stops walking the display and runs the list: this decision came due, this is the signal, the threshold was crossed or it was not, here is what the named owner did. Discussion happens where a threshold was ambiguous, which is where discussion is worth having. Additions get easier to refuse, too. A request for a new panel now has an obvious first question \u2014 which repeating decision does it serve \u2014 and requests that arrive without an answer tend to withdraw themselves. Write your decision list this week Take fifteen minutes and list the decisions your team repeats on a schedule, with the rhythm beside each one. Do it before you open anything. The list is also worth showing to someone outside the team. People close to the work tend to omit the decisions they make so routinely that they have stopped registering them as decisions at all, and those are often the ones running on the least evidence. Then write one sentence, for the decision that recurs most often, and check whether the signal it names exists anywhere in your reporting today. Whichever way that lands, you have learned something the dashboard could not have told you: either it is already serving the decision, or it has been serving something else all along. The reporting-and-visibility lane in the operations system is built around exactly that sentence, and the diagnostic says whether it is your first lane.<\/p>\n","protected":false},"author":113,"featured_media":34799,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"drb_seo_title":"Dashboards That Change Decisions, Not Just Reporting","drb_seo_desc":"Most dashboards report. Few change anything. Start from the decisions your business repeats, and keep only the numbers that would move one of them.","footnotes":""},"categories":[1629],"tags":[],"class_list":["post-34480","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-systems-operations"],"_links":{"self":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34480","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/users\/113"}],"replies":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/comments?post=34480"}],"version-history":[{"count":5,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34480\/revisions"}],"predecessor-version":[{"id":34785,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/posts\/34480\/revisions\/34785"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/media\/34799"}],"wp:attachment":[{"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/media?parent=34480"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/categories?post=34480"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dr-business.com\/en\/wp-json\/wp\/v2\/tags?post=34480"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}