Skip to content

Capacity Dashboard

Always-on display artifact — instantiates Overcommitment Prevention

Puts current load, utilization, queue length, and deadline risk on one visible surface, so overcommitment is seen before it is felt.

Capacity Dashboard pulls the scattered signals of load — utilization, deadline risk, budget burn, queue depth — into one always-on display, so the state of capacity is visible to everyone who accepts or assigns work. Its distinguishing property is that it is a passive instrument, not a decision: it surfaces the signals that admission, renegotiation, and review decisions consume, and its entire value is making load legible at a glance instead of reconstructed from fragments. On its own it prevents nothing; wired to an admission rule, it makes overcommitment obvious the moment it begins.

Example

A managed-services provider runs a wall dashboard for its operations team: per-engineer utilization in green/amber/red, open-ticket queue depth by priority, SLA countdown timers, and this month's on-call budget burn. A sales engineer, about to promise a new client "24/7 coverage starting Monday," glances at it — the on-call rota is already amber at ≈92% utilization and the P1 queue is climbing. The dashboard renders no verdict, but the promise now happens in front of a red-tinged board instead of in a vacuum, and the team routes it to the intake gate rather than nodding it through. The signal was simply present at the moment of the promise, which is most of the battle.

How it works

The signature is aggregate and render, do not decide. It ingests capacity signals from the underlying systems — ticketing, rota, finance, calendars — and shows current state, trend, and threshold coloring on one surface. It carries no authority of its own; its whole design intent is to be read at the moments when work is promised or reviewed, so the raw truth of load is in front of the decider before the yes.

Tuning parameters

  • Signal set — which few metrics appear. Too many turns the board into noise; too few hides the binding constraint.
  • Threshold coloring — where amber and red trip. Tight thresholds warn early but cry wolf; loose ones warn too late to act.
  • Refresh latency — real-time versus daily roll-up. Live data catches spikes but is jittery and easier to game moment-to-moment.
  • Granularity and drill-down — a team headline versus per-person detail. Detail finds the overloaded individual but can be weaponized as surveillance.
  • Audience and placement — private to leads versus radiated to all. Broad visibility drives honesty but can incentivize gaming the colors.

When it helps, and when it misleads

Its strength is turning capacity from a background complaint into a shared, glanceable fact, and putting that fact in front of people exactly when they promise. Its limit is that it only shows: a beautiful dashboard beside a culture that says yes anyway changes nothing, because the prevention lives in the admission rule the dashboard feeds, not in the glass. The classic failure is "watermelon" reporting — green on the surface, red underneath — where the signals or thresholds are chosen to look healthy rather than to tell the truth. The discipline is to pick signals that can embarrass the team, wire them to real admission and renegotiation moments, and audit the thresholds against actual overload incidents.

How it implements the components

Capacity Dashboard realizes the visibility side of the archetype — surfacing signals, not acting on them:

  • capacity_signal — its content: utilization, deadline risk, budget burn, and other live indicators of remaining headroom.
  • backlog_and_queue_visibility — it renders queue depth and waiting or deferred work, so a growing backlog is seen rather than buried.

A pure instrument, it neither models capacity nor enforces anything — the usable-capacity model comes from Calendar Capacity Audit, the acceptance decision from Portfolio Intake Gate, and the periodic reconciliation from Commitment Burndown Review.