Performance grid

A grid of the few measures that tell you whether the work was run properly in the period just gone. One row per measure, one square per period — a shift, a day, a week, a month, whatever the work's own rhythm is. Green means the period met the rule, red means it missed, blue means the number is not in yet. There is no amber, deliberately: a third colour is where an uncomfortable miss goes to be called "nearly fine", and removing that negotiation is most of what makes the grid work. Blue matters for the same reason — a missing measurement is a different problem from a missed target, and it must never hide inside green. The letters SQDIP — safety, quality, delivery, inventory, productivity — are one well-worn set of rows. They suit a team where those five map to levers it pulls inside a single period, and they have a second advantage: when every area on a site uses the same five rows, a visitor can read any board without translation. They are not the method. For most commercial, service and knowledge-work teams the rows are simply the critical few measures at that level — the ones that, when missed, are worth stopping for. What never changes is the shape of a row: what is measured and where the number comes from, the rule that decides red or green written before the period starts, a named owner, one square per period, the reason it went red captured in the period, and an action with an owner and a date. A red square is not a status update; it is the trigger for a problem-solving cycle. Influences, paraphrased rather than reproduced: W. Edwards Deming on tampering and on judging people by a system's output; Donald Wheeler on separating the voice of the process from the voice of the customer; and the shop-floor board tradition behind QDIP (quality, delivery, inventory, productivity) and SQDC (safety, quality, delivery, cost), whose printed sheets are commercial products even where the pattern itself is common practice.

The measures, their rules and owners

Three to six rows, no more. Each carries a name, where the number comes from, a standing goal or a written rule, and an owner who is a person rather than a department. Write the rule before the period starts — deciding afterwards what counted as a hit is how a board goes green and stays meaningless. A row that has never been red means the goal sits below what the process already does; a row that is always red is a project wearing a measure's clothes and belongs in an improvement plan.

Cadence — the period a square covers

Pick the period from the work, not from habit. A cadence that fits passes three tests: the number lands inside the period, a countermeasure can act within a few periods, and the period is shorter than the time the problem takes to do its damage. Per shift or daily suits production and service desks; weekly suits most commercial, professional and office teams, because that is the rhythm at which both their work and their data move.

The squares, and the reason behind every red

Mark the squares at the same point every period, by the team, in a couple of minutes. A number decides its own colour against the goal; a rule that is a judgement — any injury is red — gets marked by the team. Every red gets one line of fact: what happened, never who. Write it in the period; it cannot be reconstructed a month later, and that single line is the only thing that survives the period intact.

What is being done, by whom, by when

Every red gets containment — something that protects the next period — with an owner and a date. Add a permanent countermeasure once the cause is understood, and keep the two apart so a temporary fix is never mistaken for a solved problem. Cap the open list: one improvement per person at a time. A list that only grows is the most-reported failure of daily management, and a limit is the only thing that reliably stops it.

Colours, discipline checks and the reason Pareto (computed)

Computed for you: the colours, the two checks that matter — reds with no reason, and reds with nothing being done about them — and the Pareto of reasons that keep repeating. Nothing to enter here.

What the grid says

Drafted from the grid actually built, and grounded only in what it computes.

The example below is an inside sales team on a weekly cadence. Twenty squares, seven of them red — and two causes account for six of those seven, which is exactly why the reasons are worth more than the colours. Pricing approval held up proposals in three separate weeks; an uncovered shared inbox produced the other three reds and appeared under two different measures, which is the clue that it is a staffing rule rather than a sales problem. Three reds still have nothing being done about them, one of those was never given a reason at all, and one square is blue because that week has not been marked yet. A worked example where everything was green would teach the opposite of the method.

• Treating a red square as evidence that something changed

  It is not. A steady process with a goal near its own average produces reds, and runs of reds, with nothing to find. Chasing each one separately adds variation instead of removing it. Contain every red; only a repeating pattern earns an investigation.

• Adding amber

  Amber is where an uncomfortable miss goes to be called nearly fine. Two colours force the only question that matters — did we meet the rule we set — and blue keeps a missing number visibly different from a miss.

• Marking the squares just before the meeting

  Reasons written from memory are already vague, and a Pareto built from them says things like "process issue". The reason is worth more than the colour, and it decays within hours.

• Letting the grid become a report to management

  Once its audience is upward, the numbers get managed instead of the work. The team marks its own squares for its own use; anyone above reads the same board rather than asking for a version of it.

• Too many rows

  A team facing eight problems a period acts on none of them. Three to six measures it can actually move beats a complete picture it cannot.

• Free text instead of a consistent reason

  "Tool change", "changing tool" and "tool changeover" are one cause split across three bars, and the real driver hides. Say the same reason the same way every time.