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

Work-in-progress limits reduce stress in solar operations by making a simple fact visible: a person cannot give full attention to unlimited active projects. 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. Solar teams need their own limits because project evidence, review roles, customer commitments, safety controls, and local approval requirements vary.

The Difference Between Demand and Active Work

Solar companies often confuse a full pipeline with a full 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 waiting for a bill, survey detail, customer choice, or technical approval is not yet active design work.

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. A short standardized assessment often reduces later stress more than a detailed policy because it makes the next action unambiguous.

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

Complex work deserves a lower active limit because it requires more context. 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 is often the real 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. NIST’s framework emphasizes identifying and managing risk; in this context, an opaque handoff is a risk because no one can tell what decision was made on what evidence.

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. That may reduce manual transfer between tasks, but it does not eliminate the need to decide which project is ready, which review is required, or who can authorize a release.

How to Set Limits Without Guessing

Begin by observing the current state for two weeks. Count active tasks by class and role, note interruptions, and identify what tends to finish cleanly versus what repeatedly reopens. Set a provisional limit that is lower than the current active load but not so low that it ignores real 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

Does a WIP limit make customers wait longer?

It can make waiting more visible, but it often reduces total delay by helping the team complete ready work instead of repeatedly starting and stopping it. Customers benefit when the company can explain the next step and provide commitments based on real capacity.

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.