6 Queue Metrics for Diagnosing Solar Design Overload

Measure ready and unfinished work as well as overdue work. A queue can look active while important work ages, reviewers become bottlenecks, and incomplete requests consume attention. Average turnaround time alone can conceal the cause. A poorly scoped average can mix straightforward concept work with complex revisions, exclude side-channel requests and improve when a team finishes only the smallest jobs.

The Kanban Guide, May 2025, defines work in progress using the interval between a stated start and finish, including items that wait within that interval. Apply that distinction consistently here. This proposed solar diagnostic set is not a solar standard; define your request classes, evidence requirements and release controls.

Begin With States That Reflect Real Work

Metrics are misleading when a board calls everything “in progress.” A request awaiting roof evidence is different from a layout being modeled; a design awaiting technical approval is different from a job waiting for a customer’s decision. Define a small set of operational states and insist that every active project has one current state.

Do not create a state for every special case. A compact vocabulary permits comparison across weeks. Keep the reason for a blocked item as a separate field, such as customer evidence, site access, authority response, internal decision, supplier information, or technical review. That detail explains where the queue is actually constrained.

Metric 1: Age of Ready Work

Ready-work age is the time between a request becoming complete enough to start and a person beginning it. It is one of the clearest demand-versus-capacity signals because it excludes work that is blocked by missing information. Calculate it by class: preliminary concept, design revision, proposal support, permit-related output, installation support, or another grouping that reflects your workflow.

Look at the oldest ready items as well as a median. A low median can hide a few important tasks waiting for weeks. Then compare age to the commitment that was actually made. If ordinary concept work is consistently waiting longer than sales expects, the solution may be a changed customer promise, a capacity decision, better intake, or different service levels—not an instruction to “work faster.”

Avoid using age as a performance score for an individual. A task can be old because it was correctly deprioritized behind a documented safety or release issue. The management question is whether the reason is visible and whether the same category of work repeatedly suffers.

Metric 2: Work in Progress by Role

Work in progress (WIP) counts started-but-unfinished tasks within the boundary you define. If a started task moves into review or becomes blocked, it remains in that total until it finishes or receives an explicit cancellation disposition. Separately count tasks being worked on now to understand immediate focus load. Measure both by role or team, not only for the department. A design queue might be manageable overall while one technical reviewer is carrying too many parallel decisions. A designer may appear fully utilized yet spend most of the day reopening partial work after interruptions.

Set a working range rather than an arbitrary target. If tasks are highly variable, use separate limits for standard proposal layouts, complex projects, and urgent technical changes. When a new task exceeds the range, require a decision: finish something, place the new item in ready status, or authorize an explicit exception. This creates a visible tradeoff instead of pretending that adding another active item costs nothing.

A rising WIP count does not, by itself, explain its cause. Check intake quality, demand spikes, absences, changing project mix, and review availability before assuming the answer is hiring.

Metric 3: Blocked-Task Age and Reason

Blocked work is operational information, not an embarrassment. The problem is a blocked project with no owner, no requested evidence, or no next check date. Track both the count of blocked requests and how long they remain blocked. Segment by reason. A cluster of projects waiting for utility documents requires a different remedy from a cluster waiting for an internal design decision.

For each blocked task, record what is missing, who owns the next action, when the team will review it, and whether its promise date needs to change. A “waiting on customer” label should include the exact request, not merely a broad status. That lets customer-facing staff provide useful updates and stops a later response from becoming an unexpected emergency.

Long blocked age can also reveal a policy issue. If no one is allowed to close, pause, or requalify an old inquiry, it can distort the apparent size of the pipeline and distract from work that is genuinely ready.

Metric 4: Review Lead Time

A queue can also form where a design, assumption or output needs a decision. Measure the time from “submitted for review” to a recorded decision, along with the number returned for incomplete information. Separate different review types because an electrical review, commercial approval, and customer proofing step will have different owners and risk.

If review lead time grows, inspect the incoming quality. Are reviewers receiving a current revision, source evidence, the question to answer, and the desired release state? A reviewer who must reconstruct the project will take longer, even if they have adequate capacity. Standardizing the review packet may reduce wait more effectively than adding more meetings.

Do not interpret a rapid review as inherently good. It may mean the decision was simple, or it may mean a person had no time to check. Pair time with outcome: did the package return for clarification, create a later revision, or move cleanly to the next stage?

Metric 5: Priority Overrides

Count every time a task is moved ahead of the stated queue order. The number itself is not necessarily bad. A legitimate field blocker or documented deadline should be visible. The pattern becomes dangerous when exceptions are routine, approvals are unclear, or the same requester can repeatedly bypass intake requirements.

Log the trigger, approver, work displaced, and outcome. In a monthly review, group overrides by reason: safety, authority deadline, customer commitment, late intake, internal revision, supply constraint, or unknown. A high share of late-intake overrides is a signal to repair the request process. A high share of field-discovered changes may indicate a need to strengthen evidence collection or escalation routes.

The record makes the displaced work visible. Apply an agreed priority policy rather than assuming that logging an override makes the decision fair.

Metric 6: Revision Churn After Handoff

Revision churn measures how often a completed design or proposal returns because a material input, decision, or output was not aligned. Count returned items by cause: missing customer input, site evidence, design error, equipment change, financial assumption change, approval feedback, or unclear handoff. Do not use the metric to shame teams; use it to find where a purportedly complete package is not complete enough for its next stage.

An increase in churn after a period of faster throughput can reveal hidden quality debt. A team may be clearing tickets quickly by issuing outputs before they have the right evidence. The system then consumes capacity later when the work comes back with urgency. Pair churn with task class and source of change to identify the upstream control that needs adjustment.

Solar Designing is SurgePV’s solar design product area. SurgePV describes capabilities including AI roof generation, custom geometry, panel placement, DC stringing, BOM generation, and project outputs. Ask the presenter to trace a representative revision through the outputs you use. Confirm what the product actually records; review, approval and handoff rules remain your team’s responsibility.

Turn Metrics Into a Weekly Operating Review

Metrics become useful when they lead to a decision. In a short weekly review, look at the oldest ready tasks, WIP by role, blocked tasks past their next date, review queues, priority overrides, and recent revision returns. Choose one constraint to address. It might be a missing input field, a review packet, an owner decision, a temporary capacity adjustment, or a customer-communication change.

Do not respond to every metric by accelerating the entire queue. If ready work is aging but WIP is already above range, adding more active tasks will probably worsen focus. If blocked work is accumulating, pushing it into active design will not solve the missing dependency. The state data should guide the response.

Set baselines before declaring a target. A commercial EPC workflow may have longer legitimate review cycles than a standardized residential proposal process. Compare like with like, explain the conditions behind a movement, and adjust the process when the data shows a repeatable failure mode.

Frequently asked questions

Which metric should a solar team track first?

Start with the age of ready work by request class, then add started-but-unfinished work and blocked-task age. Keep start, finish and blocker definitions explicit so the measures distinguish missing inputs from a capacity or review constraint.

Is average turnaround time enough to manage a solar queue?

No. An average can conceal urgent work, old blocked work, and different task types. Use distributions and states alongside the average.

How often should a solar team review queue metrics?

Review a lightweight view weekly and use a monthly pattern review for deeper changes. Daily monitoring is useful only when it helps remove a current constraint; otherwise it can become another reporting burden.

Should blocked work count in capacity planning?

Yes. Separate blocked work by whether it has started. A started but unfinished task remains in WIP even while blocked; an unstarted request remains in intake or ready demand. Record coordination load separately from immediate hands-on work.

What is a reasonable turnaround target for solar design?

There is no universal target. It depends on project complexity, evidence readiness, team roles, jurisdiction, customer commitment, and defined output. Establish service levels by request class and revise them using observed flow rather than a generic industry number.

Can a small solar company use these metrics without new software?

Yes. A shared board or spreadsheet can track state, dates, reason codes, and owners. Consistent definitions matter more than the platform. Start with a few fields that lead to a useful weekly decision.