Solar Project Cycle Time: Find the Wait Between Sale and Install

A solar project does not become slow because one person takes too long; it becomes slow when important work waits without a visible owner or decision. For an installer or EPC, the interval between sale and installation can include customer documents, site assessment, design, review, permitting, utility activity, procurement, scheduling, and customer communication. A single end-date metric cannot explain which part is actually constraining delivery.

This is a desk-research guide for solar professionals. It does not replace local permit rules, utility processes, workplace safety controls, contract terms, engineering review, or project management judgment. The U.S. Department of Energy Solar Energy Technologies Office provides sector context; the Baldrige Performance Excellence Program provides general measurement and improvement resources. Neither establishes a required timeline for a particular project.

Define the Clock Before Trying to Improve It

“Sale to install” sounds clear until a team compares projects. Does the clock start when a customer expresses interest, signs an agreement, makes a deposit, or supplies all required documents? Does it end when the crew is scheduled, when equipment arrives, when installation finishes, or when the system receives permission to operate? Each answer can be useful, but they are different measures.

Choose an operational clock that matches a real decision. A team focused on sales-to-design flow might start with a design-ready brief and end with an accepted preliminary proposal. A delivery team might start with a signed project that has met entry criteria and end with an install-ready release. Keep customer, authority, and utility milestones separate rather than forcing them into a number owned by one department.

The goal is not to declare one number as the company’s permanent truth. It is to make a number reproducible. Put the definitions in a simple data dictionary. If the entry criteria change, record the change and do not compare the new series to the old one as if nothing happened.

Separate Touch Time From Waiting Time

Many cycle-time discussions collapse active work and waiting into one complaint. That makes it difficult to act. A designer may complete the modeled work quickly but wait two days for a usable bill, one day for a reviewer, and another day for a customer decision. Those waits may be legitimate, but they should be visible.

For each stage, capture three time categories: active work, internal wait, and external wait. You do not need a stopwatch-level timesheet to begin; a well-defined status history can show whether a record was pending customer input, awaiting site information, in technical review, queued for an authority response, or awaiting a procurement confirmation. The codes matter more than false precision.

Avoid a generic “pending” label. It produces a dashboard full of indistinguishable stalled records. A specific status lets the team decide whether to send a clearer request, prepare an alternative scenario, schedule a review block, escalate a legitimate external delay, or wait without creating false urgency.

Map the Handoffs That Create Rework

Cycle time is usually lost at boundaries. Sales may record a customer objective but not the consumption evidence needed for financial modeling. A survey may identify a roof feature but not attach the photo or clarify its location. A layout may change after a proposal is shared without a clear decision on which output is current. Installation may receive a pack that is technically complete but does not identify a customer access constraint.

Create a simple handoff map with five questions at every boundary:

1. What output is being handed over?
2. What evidence must accompany it?
3. Who decides the output is acceptable for this stage?
4. What conditions remain assumptions rather than confirmed facts?
5. Where is the current version and its issue log?

This is more useful than a large process diagram that nobody uses. A project should not enter a downstream queue because it has a status label; it should enter because the named entry criteria are met or because the exception is visible and accepted by the appropriate owner.

Find the Constraint With an Aging Report

Averages often conceal the project that is about to cause the next customer escalation. Review aging: work that has exceeded a stage’s expected review point or has had no substantive status change. Sort the report by age and blocking reason, then examine real records together.

The question is not “who is responsible for this delay?” It is “what is the next fact or decision required to move it?” Sometimes the answer is a customer document. Sometimes it is an internal reviewer who lacks a clear acceptance standard. Sometimes it is a legitimate authority queue that the sales team needs to explain honestly. These are different remedies.

Do Not “Fix” Time by Moving Risk Downstream

The wrong way to improve a cycle-time chart is to relabel incomplete work as complete. Sending a proposal without the necessary caveats, releasing a design before a required review, or scheduling a crew before access conditions are understood may shorten one internal clock and lengthen the project overall. It can also create customer disappointment and safety or compliance risk.

Keep mandatory gates visible. A team may be able to work in parallel—for example, organizing documents while a customer supplies a missing bill—but it should not pretend a release criterion is satisfied. Good flow is not the absence of checks. It is clear, proportionate checks that happen at a predictable point with the right evidence.

Use Weekly Reviews to Improve the System

Run a brief weekly flow review around a small set of questions: Which work is oldest? What is currently blocked? What repeated return reason appeared? Did project mix change? What one experiment will the team test before next week? Keep actions named and dated.

For example, a team could hypothesize that a structured design request will reduce returns caused by missing site photos. The test should define the new request, the project population, and the signal to watch. If returns decline, inspect a sample to make sure the apparent improvement is not a change in coding or review rigor. Treat metrics as evidence for investigation, not as automatic proof.

Use the Same Record for the Customer Conversation

Customers do not need every internal status, but they do need truthful updates. A project owner can say, “We are waiting for the latest bill because it affects the scenario we can responsibly present,” rather than offering a vague promise. If an authority or utility process has an external timeline, state that it is outside the installer’s control and describe the next known event.

Clear status language protects trust. It also prevents sales, design, and operations from telling different stories because each is looking at a different spreadsheet, email thread, or version of the project. Solar Designing can help keep the project model and its connected outputs in one workflow; it does not replace the team’s decision rights or external approval processes.

Frequently Asked Questions

What is a good solar project cycle time?

There is no universal responsible benchmark. Cycle time depends on project type, site conditions, customer evidence, permit and utility routes, equipment, season, and local practices. Compare similar work against a clearly defined baseline rather than relying on a generic industry number.

Which solar delays can an installer control?

Teams can improve the clarity of evidence requests, internal handoffs, review capacity, version control, status visibility, and customer communication. They cannot control every authority, utility, weather, supplier, or customer event, but they can make those waits visible and communicate them accurately.

Should permits be included in cycle-time reporting?

Yes, but report permit preparation and authority waiting separately. Combining them can make an internal process look slow when the delay is external, or hide a weak submission process behind an external average.

How do you avoid cycle-time metrics becoming a blame tool?

Define comparable work, keep reason codes, review actual records, and use the data to change system conditions. Do not judge individuals from a single blended measure that ignores complexity, missing evidence, and review scope.

Make the Next Wait Visible

Start with one project family, document five handoffs, code the waiting reasons for thirty days, and inspect the oldest records every week. The first improvement is usually not a dramatic automation change. It is a missing decision, evidence requirement, or ownership rule made explicit.