Quick Answer
Solar design overload appears first in aging ready work, growing work in progress, blocked-task accumulation, frequent priority overrides, review delay, and revision churn. Measure these patterns by request class and use them to change intake, capacity, or sequencing before customer commitments slip.
Solar design overload is easier to prevent when teams measure the queue before the overdue list grows. A queue can look active while important work ages, reviewers become bottlenecks, and incomplete requests consume attention. Average turnaround time alone rarely explains why. It mixes straightforward concept work with complex revisions, excludes work waiting in side channels, and can improve temporarily when a team finishes only the smallest jobs.
The better approach is to measure flow and its causes. Atlassian’s overview of Kanban metrics offers general definitions for flow measures; a solar team must define its own request classes, evidence standards, and release controls. NIST’s cybersecurity framework likewise supports risk thinking rather than prescribing a project workflow.
Direct Answer
Track the age and state of work, not just completed volume. If ready tasks are aging, active work exceeds capacity, blockers remain ownerless, reviews wait, or priorities are constantly overridden, treat those as early signals that the solar design system needs intervention.
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.
| State | Definition | What the clock tells you |
|---|---|---|
| Intake | Request arrived but has not been assessed | Demand volume and intake response |
| Ready | Required inputs for the requested task are present | How long prepared work waits for capacity |
| Active | A named role is currently working the task | Work in progress and focus load |
| Review | A defined decision or quality check is pending | Review bottlenecks and handoff quality |
| Blocked | A named dependency prevents progress | Missing evidence, ownership, or external delay |
| Done | The requested deliverable has a recorded release state | Completed throughput and cycle time |
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) is the number of tasks in an active state. Measure it by role or team, not only for the whole 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.
High WIP often precedes longer cycle time, but it does not explain why WIP rose. 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
Many solar workflows do not fail in drawing creation; they fail at the point where a design, assumption, or output requires 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 benefit is fairness. Designers and project managers no longer have to arbitrate based on seniority or message volume because the organization can see the cost of exceptions.
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. Connecting these steps can reduce manual transfer and make a project revision easier to follow, but it does not replace a company’s responsibility to define review, approval, and handoff controls.
Design Solar Projects Faster with SurgePV
Book a demo to see how a connected solar design workflow can help your team keep inputs, design outputs, and customer-facing work in one project conversation.
Book a DemoNo commitment required · 20 minutes · Live project walkthrough
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
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, but separately from active work. It represents future demand and coordination load, while active work represents immediate focus load. Combining the two obscures whether the team lacks capacity or lacks inputs.
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.
Ready to Speed Up Your Solar Workflow?
Explore how SurgePV can connect solar design, analysis, and proposal work while helping your team retain project context.
Book a Demo
