7 Work-in-Progress Limits That Can Reduce Stress in Solar Operations

A work-in-progress policy makes unfinished commitments visible. A team may have a healthy pipeline, yet its day can still be dominated by reopening half-finished layouts, finding missing documents, answering status requests, and responding to late escalations. More active tickets do not necessarily mean more progress.

The purpose of a limit is not to slow a company down or refuse good opportunities. It is to decide which work is genuinely being handled now and which work should wait in a prepared, visible queue. Atlassian’s guide to work-in-progress limits describes the general practice. The Kanban Guide defines WIP as items that have started but not finished. Use that boundary consistently, including started items waiting or blocked. Solar teams must set their own policy because work mix, review roles, commitments and local requirements vary.

The Difference Between Demand and Active Work

Keep the full pipeline separate from the current workbench. Demand includes every inquiry, signed job, revision request, authority question, site finding, and customer change. Active work is the smaller set a particular role can responsibly progress before it begins losing context. If those definitions are merged, managers try to show responsiveness by opening every project. The result is a board full of “in progress” items and a team that cannot explain what will finish next.

Use four basic locations for work: received, ready, active, and blocked or waiting. Add a separate review state where a decision is required. This structure does not diminish a customer request; it records its real condition. A project awaiting a bill, survey detail, customer choice or technical approval may not be receiving hands-on design now. If it has already crossed your start boundary, it remains in WIP until finished or explicitly cancelled.

Limit 1: Intake Assessment

Limit the number of new requests that can remain unassessed. This is not a design limit. It is a promise that the team will quickly decide whether a request is complete, what class it belongs to, and who owns any missing information. Without this step, incomplete work enters the active queue through email or chat and competes with projects that are ready.

An intake assessment should identify the project, current revision, requested deliverable, requester, intended due point, evidence attached, missing evidence, customer expectation, and next owner. Check whether a short assessment makes the next action clear; do not claim a stress reduction without evidence.

Limit 2: Standard Concept Work

Standard preliminary concepts need their own active limit. They are often short enough to be interrupted frequently, which makes teams assume they have no cost. But a steady stream of “quick” concepts can prevent designers from completing the complex, evidence-heavy tasks that need uninterrupted thinking.

Define what counts as standard. It might be a familiar project type with an address, stated customer objective, available consumption evidence, and no known technical exception. When a request exceeds that definition, move it to a complex or investigation class rather than forcing it through the standard lane. This protects the customer from a quick but poorly supported output.

Limit 3: Complex Design Investigation

Test whether context-heavy work needs a different limit from routine concepts. Multi-plane roofs, uncertain evidence, substantial customer changes, nonstandard equipment, or interdependent design and commercial questions can occupy attention even when no drawing is being edited. A designer who has four such jobs open may spend the day reconstructing what each issue means.

Make the complexity visible in the queue. Name the question to resolve, the evidence currently available, the next decision needed, and the likely dependency. This is not a judgment about project value. It is a way to prevent critical work from being diluted by too many simultaneous investigations.

Limit 4: Review Work

Review can become a bottleneck. A design may be complete enough for a decision, but it waits because the reviewer has too many competing packages or lacks a concise evidence record. Set a separate review limit and require each submission to state the exact question. “Please review” is not sufficient. A reviewer should know whether they are checking a design revision, a financial assumption, a material change, a customer-facing proposal, or a release condition.

Track return reasons. If many reviews come back for missing source documents or unclear revision identifiers, improve the package before increasing reviewer capacity. Use the queue metrics guide to inspect review waits and return reasons before choosing a capacity response.

Limit 5: Customer-Change Work

Customer changes need a distinct rule because they are emotionally urgent. A request to change location, capacity, equipment, financing, or schedule may affect a design, output, proposal, BOM, and delivery plan. If every change interrupts active work instantly, the system rewards incomplete initial discovery and makes commitments less reliable for everyone else.

Capture the requested change, source, project revision, affected outputs, deadline, and decision authority. Then classify it: immediate safety or delivery blocker, time-sensitive customer commitment, scheduled revision, or incomplete request. The classification is how a team respects the customer without pretending every change has identical consequences.

Limit 6: Field-Support Interruptions

Installation and field teams sometimes need rapid design clarification. Those interruptions can be legitimate, particularly when safe work, equipment mismatch, or a current site condition is involved. Give them a defined path rather than forcing field staff to find an individual designer. The request should identify the location, observation, affected work, photos or evidence, current issue date, and required answer.

Reserve limited capacity for genuine field support, then measure it. If the same questions recur, investigate whether the installation pack, survey process, design output, or pre-install review needs improvement. A field-support limit should surface systemic defects, not become a gate that leaves crews without a responsible escalation route.

Limit 7: Improvement Work

Teams under pressure often defer process fixes indefinitely because all capacity is consumed by live projects. That creates a loop: the same unclear intake, revision confusion, and handoff defects keep generating interrupts. Set aside a modest, visible limit for improvement tasks such as a better intake form, a revision checklist, a source-of-truth map, or a review packet.

Improvement work should be tied to an observed failure pattern, owned by a named person, and reviewed for effect. It is not a broad “optimize operations” ticket. A small fix that removes a recurring blocker can create more capacity than adding another active project to an already overloaded person.

Solar Designing is SurgePV’s solar design product area. SurgePV says it brings AI roof generation, custom geometry, panel placement, DC stringing, BOM generation, and design outputs into one cloud-based platform. Ask the presenter to trace the inputs and outputs for your task. Verify actual product behavior rather than assuming the platform supplies queue limits or release authority; your team still owns those decisions.

How to Set Limits Without Guessing

Observe a period that covers the work classes and interruptions you need to manage. Count active tasks by class and role, note interruptions, and identify what tends to finish cleanly versus what repeatedly reopens. Set a provisional limit from that evidence; do not automatically lower it below current load without examining the workflow boundary and delivery needs. Explain that the limit is an operating experiment, not a productivity target.

When the limit is reached, choose among three actions: finish or unblock existing work; keep the new request in a ready queue; or approve an exception and name the displaced item. The third option must stay available for genuine events. Its documentation makes the organizational cost visible and generates data for improvement.

Review the limit after enough work has flowed through it. If customer commitments routinely wait despite clean intake and focused work, capacity or service-level choices may need adjustment. If work remains active for long periods because of missing evidence, refine readiness criteria rather than increasing the limit.

What a Limit Should Never Hide

A limit is not a reason to conceal demand from leadership or a customer. Keep the ready queue visible, show the date an item became ready, and explain which priority class it occupies. If a recurring request class cannot be handled within its stated service level, that is useful planning evidence. The response may be to change intake, move a review decision earlier, add capacity, or change the promise made at sale.

Likewise, do not use a WIP limit to skip an obligation that needs immediate responsible attention. The team should have an escalation path for safety concerns, verified field blockers, and documented external deadlines. The distinction is that the exception has an owner and a consequence; it is not simply another item placed on top of an already overloaded workbench.

Teams should also watch for hidden work outside the board. If designers receive direct messages, email attachments, or informal requests that never become tasks, the limit will appear to work while people remain interrupted. Make the route for requests easy enough that staff use it, then coach requesters to preserve the shared queue rather than bypassing it.

Frequently asked questions

Do work-in-progress limits mean rejecting new solar projects?

No. They distinguish received and ready work from work that a person has actively started, making demand visible without requiring every request to be opened immediately.

What should happen when an urgent solar task exceeds a limit?

A named owner should document why it is urgent, which active task is delayed, what review remains required, and who communicates the changed commitment.

Does a WIP limit make customers wait longer?

A limit can make waiting visible, but it does not guarantee a shorter elapsed time. Compare completion, waiting, returns and customer commitments before and after the trial using equivalent work classes. Explain what is waiting and why.

Can different solar roles have different limits?

Yes. Sales support, design, technical review, procurement coordination, and field support have different task sizes and interruptions. Set limits close to the actual constraint rather than forcing every role into one number.

What if management insists on adding a project anyway?

Record the exception, consequence, approver, and displaced work. This is not resistance; it is the information needed to manage commitments honestly and decide whether the pattern requires more capacity or a changed process.

How does a team prevent limits from becoming rigid?

Use explicit exception criteria for safety, documented external deadlines, and material delivery blockers. Review exception patterns regularly. A limit should guide tradeoffs, not prevent responsible action.