How to Run a 15-Minute Solar Project Handoff

Fifteen minutes is enough to transfer a solar project. It is nowhere near enough to discover what the project is. That work belongs in the packet, before the meeting begins.

The handoff call should test whether the receiving role can act from the current evidence, customer decision, accepted scope, commitments, and open questions. It should end with a named outcome: accepted for the requested work, accepted with controlled limits, returned for specific evidence, or routed to specialist review.

This guide is for installer and EPC teams moving work among sales, design, engineering, procurement, project management, and field operations. The timebox is a workflow proposal, not a measured performance claim. Safety, engineering, code, contract, authority, utility, and manufacturer decisions remain with their responsible parties.

Treat the meeting as an acceptance test

Most handoff meetings fail because they are narrated chronologically. The sender retells customer calls, site visits, and internal debates. The receiver takes notes and still does not know which document controls or what decision is required next. A timebox forces a better structure only if the packet carries the history.

Define the acceptance test before scheduling:

• Can the receiver state the customer’s next decision in one sentence?
• Can they identify current source evidence and its dates?
• Can they distinguish verified conditions from assumptions?
• Can they see commitments already communicated?
• Can they identify the requested output, release level, and deadline source?
• Can they name each open question, owner, and consequence?

If any answer depends on memory, improve the packet. Do not extend the meeting by default. More conversation can conceal the same documentation defect.

NASA’s public Systems Engineering Handbook discusses systems engineering processes, technical reviews, information, and configuration concepts in a much broader and more formal context. A rooftop project is not a NASA program. The transferable discipline is that decisions and baselines need identifiable inputs and outputs.

Build the packet around six cards

The packet should be short enough to scan and deep enough to trace. Use six cards or sections, each linked to original records rather than copying every detail.

Keep each card to decisions and references. A site-evidence card should link to dated photos and drawings, not embed a collage too small to inspect. An assumption card should identify the model field or document where the assumption lives. A commitment card should quote the relevant customer or contract statement when accuracy matters.

Make the requested output proportionate

“Design the project” is not a handoff request. Name the artifact and its allowed use: preliminary layout for customer discussion, site-survey plan, load-profile review, structural information request, permit drawing update, bill-of-materials release, or field clarification.

The Department of Energy’s PV system design overview describes connected system components including modules, mounting, inverters, storage, and balance-of-system elements. Because the work is connected, a vague request can spread unverified assumptions across several outputs.

Put three labels beside the deliverable:

1. Purpose: the decision or activity this output supports.
2. Evidence threshold: what must be verified before release.
3. Prohibited use: what another person must not infer from it.

A remote layout may be suitable for an early site conversation while remaining unsuitable for material release. A consumption screen may support a request for interval data while remaining unsuitable for a savings commitment. These boundaries help teams keep work moving without giving preliminary output accidental authority.

Use the first three minutes for purpose

The sender opens with the customer or project decision, not a greeting followed by history. State who will use the next output, what they need to decide, and the source of any deadline. Distinguish a customer date from an internal target.

Minute zero to three should answer:

• Which site and scope are being transferred?
• Who is the decision-maker or downstream user?
• What question must the next output answer?
• What has the team promised to deliver, and at what level?
• Which event makes the timing relevant?

The receiver repeats the decision in their own words. This is not ceremony. It catches a mismatch between “layout for feasibility conversation” and “proposal ready to sign” before design begins.

Do not use this segment for a complete sales recap. Link the call notes and retain the customer’s exact constraints in the packet. Mention only the points that change the requested work.

Use minutes three through seven for evidence

The sender shows the source register and current design basis. Begin with identity: address, meter or service, roof area, customer entity, and project revision. Then cover site, consumption, equipment, authority, utility, structural, and other evidence that controls the requested output.

Use three states consistently:

• Verified for this decision: supported by an identified source and current enough for the stage.
• Planning assumption: used to explore a scenario, visibly subject to confirmation.
• Required before release: unresolved and too material for the named output.

The receiver should challenge evidence, not politely accept it. A photograph can be current and still show the wrong roof. A bill can be genuine and still cover the wrong account. A product sheet can be official and still describe a different model. The packet should carry identity and date, not merely a file icon.

Do not solve a technical disagreement in the handoff unless the responsible people and evidence are present. Convert it into a decision request with an owner. The timebox protects focus; it does not reduce the standard of review.

Use minutes seven through eleven for commitments and exceptions

This segment protects the project from the promises that live outside drawings. Review customer options, exclusions, equipment preferences, aesthetic constraints, schedule statements, survey boundaries, and unresolved financial or operating questions. Quote the source when wording matters.

Then inspect the exception register. Sort by consequence rather than anxiety:

The sender should not soften an exception to make the handoff pass. “Engineering to check later” is incomplete unless the team knows the question, owner, required evidence, and latest stage at which it must be closed.

Use minutes eleven through fifteen for acceptance

The receiver now states one of four outcomes:

1. Accepted: the requested work can begin from the identified evidence.
2. Accepted with limits: work can begin, but the output and assumptions must carry named restrictions.
3. Returned: a specific missing or conflicting input prevents responsible progress.
4. Escalated: the next decision belongs to a specialist or authorized party.

For every open item, say the owner, due date, consequence, and return path. “Sales to confirm” is not enough. “Account lead to obtain the latest interval export from meter A before financial scenario release; design may prepare the roof concept meanwhile” creates usable separation.

End by naming the controlling packet version and where the acceptance record will live. Do not leave the meeting with five private note sets. The sender or designated coordinator posts the record immediately, and the receiver acknowledges it.

The Lean Construction Institute describes the Last Planner System as a production planning system focused on reliable workflow and commitments in design and construction. This article is not an implementation of that system. The relevant principle is that a handoff should produce a workable commitment rather than an optimistic assignment.

What should the handoff acceptance record contain?

The handoff acceptance record should identify the project, packet revision, transfer stage, requested output, evidence reviewed, commitments preserved, assumptions and exceptions, specialist decisions, receiving owner, due-date source, permitted use, prohibited use, and outcome. It should clearly capture accepted, accepted with limits, returned, or escalated status, so attendance or silence cannot be mistaken for ownership of incomplete work after the meeting.

Write the record during the final segment, then ask the receiver to confirm it after the call. A meeting recording or transcript may preserve discussion under applicable policy, but the working team needs a concise controlled disposition it can use without replaying the conversation.

Use this copy-ready acceptance record:

Add this closing note:

Customer or project decision:
Requested deliverable and stage:
Controlling packet and source revisions:
Assumptions carried forward:
Open questions and owners:
Specialist decisions pending:
Work allowed now:
Release prohibited:
Receiver outcome and acknowledgment:

Keep the current owner when the receiver returns the handoff, unless the process explicitly accepts a limited transfer. Assigning the task anyway creates a queue item without usable authority. The return should name closure evidence and the next review point rather than merely changing the assignee back.

If the receiver accepts with limits, place those limits on the requested output and work record. A caveat spoken during minute fourteen is not a control when the next person sees only the resulting layout, BOM, or proposal.

Keep safety communication out of the compression trap

A short handoff must never compress a safety-critical discussion into a bullet that nobody owns. Site hazards, safe access, energized conditions, fall protection, weather, lifting, and construction controls belong in the project’s safety management process and prework planning.

OSHA’s Recommended Practices for Safety and Health Programs describe management leadership, worker participation, hazard identification, training, and other program elements. OSHA also discusses worker participation, including access to safety information and involvement in the program. The exact legal and project obligations depend on the workplace.

The handoff packet can flag a safety dependency and point to the controlled plan. It should not paste a generic hazard checklist and treat that as completed planning. If the requested next work requires site access, identify who owns access authorization and safety preparation before the handoff is accepted.

Give the receiving role a legitimate stop path. A designer should be able to say that site evidence cannot be collected safely under the current arrangement. A field lead should be able to reject an instruction that lacks the required review. A fast meeting has value only when people can surface a real block.

Separate the handoff from detailed technical review

The handoff identifies which specialist reviews exist and how they connect. It should not attempt to complete structural analysis, electrical calculations, utility interpretation, financial modeling, contract review, or safety planning in fifteen minutes.

Create linked decision requests. Each request contains the project identity, exact question, current source evidence, proposed configuration, requested decision, deadline source, and downstream consequence. The specialist returns a record that can be inserted into the packet without paraphrase.

Federal Highway Administration resources on construction quality improvement sit in a different project context, yet they illustrate the separation between quality systems and a single meeting. Handoffs are one control inside a wider process of planning, inspection, documentation, and improvement.

If the technical review changes the project, reopen the handoff only for the affected roles. Do not summon the original audience for every update. Send a delta summary that identifies what changed, which prior assumption or commitment moved, and what decision is required next.

Make asynchronous review do the heavy work

Send the packet early enough for the receiver to inspect it. A handoff is not ready if the recipient first sees a large drawing set during the call. Require comments in the record, not private messages. The sender resolves simple corrections before the meeting and groups unresolved questions by decision owner.

Use a readiness check:

• packet version frozen for review;
• required source links accessible;
• no broken or duplicate project identities;
• current layout, SLD, BOM, and proposal revisions listed where applicable;
• assumptions and open items have owners;
• recipient has reviewed and marked questions;
• specialists invited only for live decisions they can make.

Cancel or convert the meeting into an evidence request if those conditions are absent. Holding the meeting to protect a calendar slot teaches teams that preparation is optional.

When should a fifteen-minute handoff be cancelled or converted?

Cancel or convert a handoff when the packet is inaccessible, project identity conflicts, the requested output is undefined, evidence is missing, assumptions lack owners, the receiver has not reviewed the package, or a decision requires absent authority. Use the slot for an evidence or specialist request only when the people and sources are present. Never force acceptance because attendees assembled.

Use a preflight check before the meeting:

1. Confirm the project, customer, site, stage, and packet revision.
2. Confirm the requested artifact, decision, audience, and prohibited use.
3. Test every source link and identify the current design or scenario.
4. Separate verified, assumed, missing, conflicting, and specialist-owned evidence.
5. Confirm that commitments and exclusions trace to their sources.
6. Confirm the receiver reviewed the packet and marked questions.
7. Invite only the roles that can make known live decisions.
8. Identify safety, engineering, contract, authority, utility, or financial work that belongs elsewhere.
9. Decide proceed, convert to evidence review, route to specialist, or reschedule.

Conversion should produce a narrower output. An evidence review may resolve which meter file or roof image controls. A specialist decision session may answer one complete structural, electrical, safety, contract, utility, or financial question through the qualified process. Neither session becomes a general handoff unless the receiver can accept the resulting baseline.

Use this conversion note:

Preflight failure:
Requested evidence or decision:
Current owner:
Responsible responder:
Sources already checked:
Work allowed while waiting:
Next handoff trigger:

Track converted meetings separately from accepted handoffs. A high conversion count may reveal weak packet preparation, inaccessible sources, unclear stage definitions, or missing decision authority. Inspect cases before assigning a cause; do not treat conversion itself as failure when it correctly protects downstream work.

Protect revision control after acceptance

The accepted packet is a baseline for the next work, not a permanent truth. When customer scope, site evidence, equipment, utility direction, or design changes, issue a delta. Identify the affected card, former value, new evidence, decision, and downstream records that must update.

Solar Proposals can support the customer-facing record, Irradiance and shading analysis and the Generation and Financial Tool support modeled scenarios, and electrical design provides technical workflow context. Keep their revision references in the handoff where they affect the next output.

Results depend on source data, assumptions, equipment models, configuration, and review. Outputs support design and documentation workflows but do not replace approval by the responsible engineer, authority, lender, insurer, or utility.

Do not overwrite a prior acceptance. Preserve it, link the change, and state whether the receiving role must reaccept the project. A small customer wording change may need no technical rehandoff. A changed module, array zone, operating profile, or interconnection basis may reach several roles.

Audit returned work as a handoff defect

How should a rejected solar handoff be recovered?

Recover a rejected handoff by keeping ownership with the sender, recording the blocking evidence or conflict, assigning each correction to its owner, and defining the next acceptance test. Correct the packet rather than explaining around it, preserve unaffected work that may continue, and re-present only the delta. Rejection is complete when the receiver can identify why the baseline is actionable.

Start with one consolidated return. The receiver should inspect the packet against the named stage and avoid sending a new missing item after each correction when a complete review could identify related gaps. One repaired source can legitimately expose another dependency, but the review record should explain that sequence.

Illustrative workflow example, not a measured company result: A design team returns a sales handoff because the interval file belongs to an unidentified meter and the proposal refers to another consumption period. Roof evidence is sufficient for a preliminary layout, but the requested output also includes a financial scenario.

The handoff does not become a blanket rejection. Sales retains ownership of the consumption and proposal conflict, while design may accept the roof concept under a narrower recorded purpose if the workflow allows. The account owner obtains meter identity and current data, the financial review is rerun from the corrected source, and the next handoff presents only the changed evidence and affected commitments.

Use this recovery record:

Returned packet and requested output:
Blocking item or conflict:
Why it invalidates the stage:
Source owner and correction:
Unaffected work allowed:
Commitments or outputs held:
Revised source and packet identity:
Delta for receiver review:
Next acceptance result:

After acceptance, classify the return mechanism at the earliest detectable point: wrong identity, missing source, stale revision, commitment gap, unowned assumption, missing specialist decision, or inaccessible record. Repair the relevant intake field, packet card, source system, or stage rule rather than adding another meeting reminder.

Link the broader mechanism to the common solar design mistakes and rework guide. This article owns the transfer interface; the adjacent guide covers design defects that can exist even when the handoff itself is clear.

Before the recovery meeting, ask the sender to run two traces. The first follows the corrected item from its original source through the packet card, requested output, and commitment it affects. The second follows an unaffected item that should remain stable. This catches a fix that repairs one conflict while silently changing another baseline.

The receiver should then answer five questions without hearing the backstory:

1. Which packet revision is active?
2. What exact defect caused the return?
3. Which source changed and who accepted it?
4. Which work was allowed to continue during recovery?
5. Which outputs or commitments must now update?

If the receiver cannot answer, keep the record returned. More confident narration is not closure. Repair the source link, status label, delta summary, or ownership field that failed.

Record the timebox outcome separately from the correction itself. A short rehandoff can still transfer weak evidence, while a longer technical review may be entirely appropriate. The quality test is whether the receiver can act within the named boundary, not whether the calendar event ended on schedule.

Finally, remove stale packet links from active task views. Historical versions remain useful for audit, but search results, pinned messages, and duplicated attachments can make the former baseline look current. Supersession is part of recovery, not an administrative afterthought.

When work returns, log the reason at the point where it became actionable. Categories may include wrong site or meter, missing source date, ambiguous requested output, promise absent from the packet, assumption presented as fact, stale revision, ownerless question, or specialist review missing.

Review the category, not the person. Sales may have lacked a way to record a technical constraint. Design may have returned a question through a private message because the workflow lacked an exception field. The repair belongs where the information relationship broke.

Test the process with one ordinary project. Give the packet to a colleague who missed every prior meeting. Run the fifteen-minute agenda and then ask them to prepare the next artifact. Note every question that required off-record history. Improve the card that should have carried it.

Change the evidence threshold at each project stage

The six-card packet can travel through the project, but its acceptance threshold must change. A sales-to-design handoff may carry remote geometry as a visible assumption. A design-to-procurement handoff cannot treat the selected equipment and quantities with the same uncertainty. A construction handoff needs current released documents and clear field verification points.

Use a stage matrix:

The sender should remove irrelevant history at each stage while preserving traceability. Procurement does not need every early customer email, but it needs the accepted equipment decision and any contract restriction that came from those conversations. The field does not need the model’s entire iteration history, but it needs current drawings, controlled changes, and hold points.

Stage-specific handoffs also prevent premature detail. Asking sales to supply final attachment data at first enquiry is unrealistic. Asking procurement to release attachments while structural basis remains open is equally weak. State the maturity expected from each role and the route for exceptions.

Run the fifteen-minute agenda against the current stage, not a universal checklist. The first three minutes still cover purpose, but the user of the next output changes. Evidence review still takes four minutes, but the required sources become stricter. Commitment and acceptance remain, while the people authorized to decide can differ.

When one person carries several roles in a small company, keep the decisions separate in the record. The same individual may sell, design, and manage a project, yet a customer preference, technical assumption, and commercial authorization remain different information classes. Role clarity matters even when the names repeat.

After the first few handoffs, inspect the questions that repeatedly consume meeting time. If recipients keep asking which proposal is current, add revision fields to the packet and remove old links from active records. If site identity keeps causing confusion, fix intake naming. If every call debates the requested release level, define stage labels with examples. The timebox should expose weak information design, then the team should repair that design rather than teaching people to speak faster.

The timebox succeeds when the project becomes portable. Fifteen minutes should reveal whether the packet is ready, preserve the disagreements that matter, and produce an explicit owner for the next decision. It should never make incomplete work appear complete merely because the clock expired.

Frequently Asked Questions

Can a complex commercial solar project be handed off in fifteen minutes?

The meeting can fit fifteen minutes when participants receive a complete packet beforehand and the call is used for decisions, exceptions, and ownership. Complex analysis should remain in linked records or a scheduled specialist review. If the packet is incomplete, stop and request evidence rather than compressing unresolved work into a rushed conversation.

Who should attend a solar project handoff?

Include the person transferring current context, the person accepting next ownership, and only the specialists needed to decide a known exception. Sales, design, project management, procurement, engineering, or field roles may participate depending on the stage. A larger audience often turns the handoff into a status meeting.

What documents should be ready before the handoff?

Prepare the current brief, customer decision, site and consumption evidence, accepted design or concept revision, commitments, exclusions, authority or utility information, risk and assumption register, change history, and requested next output. Link originals and identify dates; do not paste conflicting facts into a new summary without resolving them.

What happens when the receiving team rejects the handoff?

A rejection should state the missing or conflicting item, why it blocks the requested work, the person responsible for resolution, and the next review point. The project remains with its current owner unless the workflow explicitly accepts a limited path. Rejection is a control decision, not a reason to assign blame.

How should the team measure handoff quality?

Track returned work by cause, age of unresolved questions, version conflicts, and whether downstream roles can identify purpose, source, assumption, and owner without reconstructing a meeting. Use internal results to repair intake and release controls. Do not claim a universal time or rework improvement without retained evidence.