Weekly Solar Leadership Scorecard Checklist

A leadership meeting can spend an hour discussing numbers and still leave the company without a decision. Sales counts signed contracts, design counts submitted requests, operations counts scheduled jobs, and finance counts records that meet a different boundary. Every total looks plausible because each team is measuring a different event.

A weekly scorecard should make those differences visible. Keep that boundary explicit. Its job is not to prove that the business is healthy. Its job is to show which customer work, risk, commitment, or decision needs leadership attention now, and which evidence supports that conclusion. Financial, safety, employment, technical, legal, tax, contract, and customer claims still require qualified owners.

How should a weekly solar leadership scorecard be designed?

Design the scorecard backward from recurring leadership decisions. Give every measure a defined unit, entry and exit event, source, owner, time boundary, confidence state, exception rule, and action trigger. Keep trend and target separate. If a number cannot be reconstructed or does not change a decision, it belongs in diagnosis, not the executive view.

Start by listing the decisions that repeatedly cross functions. Examples include whether to restrict new commitments, reassign review capacity, resolve a customer promise, release procurement, investigate a safety condition, escalate missing cash evidence, or pause a workflow that produces returns. Do not start with every field the CRM or accounting export happens to contain.

NIST describes the Baldrige Excellence Framework as nonprescriptive. Its criteria cover leadership, strategy, customers, measurement, analysis and knowledge management, workforce, operations, and results. That framework does not prescribe a solar dashboard or target. It does reinforce a useful boundary: leaders should not read results without the systems, customers, people, and decisions that produced them.

Write a metric contract before adding color. “Design backlog” needs a unit, eligible request, accepted-entry event, exit event, reopen rule, waiting-state treatment, source, owner, and reporting cutoff. A request that design returned for missing information should not be indistinguishable from accepted design work. A completed layout that awaits qualified review should not be counted as customer-ready merely because one task closed.

Targets need their own contract. Record why the target exists, its source or assumption, time window, trade-offs, excluded work, owner, and event that forces review. A target copied from another installer can reward the wrong behavior because project type, geography, subcontracting, finance, complexity, and service scope differ.

Use status language carefully. A green cell can mean above target, within risk, fully verified, or merely unchanged. Put meaning in the label, not only the color. Accessibility also requires words or symbols that remain understandable when color is unavailable.

Which measures belong on the weekly scorecard?

Use seven decision areas as a starting worksheet: demand and commitments, accepted delivery flow, cash and commercial exposure, safety, quality, workforce capacity, and customer obligations plus unresolved decisions. These are not universal KPIs or benchmarks. Select measures from current risks and work, preserve definitions, and route specialized conclusions to qualified owners.

1. Demand and customer commitments

Separate inquiry volume, qualified opportunity, issued offer, customer decision, signed contract, and work that delivery has accepted. A sales forecast is not committed demand, and a signature does not prove that scope, design basis, finance, timing, or handoff is complete.

The weekly question is whether the company is making commitments that its current evidence and delivery system can accept. Show returned handoffs, expired offers, unresolved decision-makers, material discounts, changed scope, and promises that require another authority. The solar sales KPI guide can support sales definitions; it should not turn a forecast into fact.

2. Accepted delivery flow

Track work across receiver-defined states. New requests, accepted requests, active work, waiting, returned work, completed output, released output, reopened work, and customer change each reveal a different mechanism.

NIST Manufacturing Extension Partnership’s value-stream mapping overview describes a current-state map of material and information flow, diagnosis, future-state definition, implementation, and cross-functional participation. It is manufacturing guidance, not proof that a solar process will improve. Use the principle to follow complete customer work instead of optimizing one department’s activity count.

Queue size alone is ambiguous. A queue can contain accepted demand, missing evidence, externally controlled waiting, abandoned requests, duplicate options, or corrections. Show age and blocked reason beside the total. Leadership can then decide whether the constraint is capacity, intake, priority, review authority, customer evidence, or an external dependency. The solar project tracking guide covers the underlying state record in more detail.

3. Cash and commercial exposure

The leadership view should not invent an accounting subtotal. Finance must define cash, receivables, payables, commitments, deposits, billing state, collections, revenue, cost, margin, and forecast boundaries according to the company’s records and applicable requirements.

U.S. Small Business Administration financial-management guidance discusses bookkeeping, balance sheet, cash-flow projection, assets, liabilities, equity, receivables, payables, available cash, bank reconciliation, and payroll. It is general small-business information, not approval of a company’s accounts, tax treatment, liquidity, solvency, or statements.

Show source date and reconciliation state. An expected customer payment is not available cash. A supplier quotation is not always a committed payable. A signed project can have scope and procurement obligations that the headline contract value hides. Route interpretations to qualified finance and accounting owners. Keep the weekly view distinct from the assumptions and scenarios in solar business forecasting.

4. Safety conditions and preventive work

Do not reduce safety to incident counts. OSHA’s leading-indicator guidance describes leading indicators as proactive and preventive measures that can reveal whether safety activities are effective and expose potential program problems. It describes lagging indicators as measures of past events such as injuries, illnesses, and fatalities. This is general United States guidance, not a site plan or compliance finding.

The applicable safety owner should select measures for the company’s work. Leadership needs visibility into open conditions, stop-work or restricted-work decisions, corrective actions, training or competency gaps, contractor coordination, overdue controls, and any schedule pressure affecting safe decisions. Never set a target that discourages reporting.

5. Quality and release integrity

Count accepted outputs separately from first-pass activity. A design, proposal, permit package, procurement instruction, or installation state needs a release purpose and acceptance owner. Returns, reopened work, superseded versions, missing inputs, and customer corrections should remain visible.

A high activity total can coexist with growing rework. Review the reason and source stage rather than blaming the team that found the issue. Quality measures should help remove a mechanism, not encourage reviewers to accept incomplete work so a cell stays green.

6. Workforce capacity and capability

Show workload with competence, absence, onboarding, outside support, and reserved review authority. Headcount alone does not describe capacity. A role can contain different work, complexity, automation, geography, and subcontracting from week to week.

The Department of Energy’s Solar Workforce Development page describes initiatives involving education, training, work-based learning, certification, mentoring, job readiness, stakeholder feedback, and program-performance analysis. It does not prescribe a private employer’s credentials, staffing, targets, productivity, hiring, or growth.

Leadership should see where work depends on one person, where training has no acceptance check, and where a reserved approval queue limits release. Employment, wage, classification, credential, and safety decisions need their appropriate reviewers. Use the quarterly solar capacity planning checklist for a longer planning window instead of forcing hiring decisions into a weekly cell.

7. Customer obligations and unresolved decisions

Keep a short list of commitments that can change trust or delivery: promised dates, design assumptions, financing or tax questions, contract conditions, complaints, service obligations, utility or authority dependencies, and executive decisions without owners.

The row should name the customer or project record, owner, next evidence, due event, consequence, and authority. Do not put sensitive personal, financial, employment, or security data into a widely shared scorecard. Link to the controlled record and apply the company’s access and retention rules.

How should leaders run the weekly scorecard meeting?

Freeze the reporting cutoff, validate exceptions before the meeting, and review material changes by mechanism rather than reading every row aloud. For each issue, choose accept, investigate, restrict, reassign, escalate, or defer. Name an owner, required evidence, due event, and customer or operating effect. Reopen prior decisions before adding new actions.

Use this seven-step sequence:

1. Confirm the reporting window, source versions, missing feeds, and confidence states.
2. Review safety, legal, cash, customer, and technical items that can restrict work before volume.
3. Compare material movement with the underlying opportunity or project states.
4. Separate demand work, waiting, returns, rework, and externally controlled time.
5. Test whether a target or trend changed because its definition, mix, or source changed.
6. Assign one decision owner, next evidence, due event, and communication effect.
7. Close, revise, or reopen previous actions and record the reason.

Do not invite every team to perform its weekly update. The scorecard meeting handles cross-functional decisions. Detailed diagnosis can happen with the people and records needed for that issue, then return with a bounded recommendation.

Avoid averaging away a material exception. One safety condition, customer commitment, cash exposure, or technical approval can deserve action even when the aggregate looks normal. The scorecard should carry a separate exception lane for high-consequence items.

Also avoid metric punishment. When a team reports more returns after introducing better acceptance rules, the measure can worsen because visibility improved. Leadership should inspect the mechanism before rewarding a lower count that came from hiding or reclassifying work.

Treat missing and disputed data as operating information

A blank is a result when the required source did not arrive. Do not replace it with zero, carry last week’s value without a label, or ask an analyst to invent a midpoint. Mark the row unavailable or provisional, name the missing record, assign its owner, and state which decision cannot be made safely.

Disputed definitions also need a visible state. If sales and operations disagree about when a project becomes accepted work, show both counts with their boundaries for the current meeting. Leadership can decide which event supports capacity, forecasting, and customer communication after reviewing real examples. Quietly choosing one number makes the disagreement look solved when the workflow remains divided.

Keep late corrections traceable. When a prior week changes, record the original value, corrected value, reason, source owner, and whether any decision needs reopening. A dashboard that rewrites history without notice can make a trend look stable while the underlying process is not.

Data quality should lead to a control, not a scolding. Repeated missing source dates may require a required field, a receiver check, a system rule, training, or removal of a measure nobody can maintain. The owner of the scorecard should track the correction until the data path changes, then verify it on later work.

What copy-ready scorecard record should the team use?

Use one weekly record with a metric dictionary, current values and confidence, material exceptions, cross-functional decisions, prior-action status, and reopening triggers. Keep source detail outside the leadership view but linked. A reviewer should reproduce each material row and understand why leadership acted without relying on the presenter’s memory or an undocumented spreadsheet adjustment.

Weekly solar leadership scorecard checklist

Keep a definition-change log. When leadership changes a stage, unit, source, exclusion, or cutoff, preserve the previous definition and mark whether historical values were restated. A cleaner dashboard is not worth a false trend.

Illustrative example: backlog or intake failure?

This is an illustrative scenario, not a customer case, benchmark, capacity claim, or measured company result.

The scorecard shows a growing design backlog. Leadership prepares to approve outside design capacity. The metric contract reveals that sales enters a request when it wants an option, while design considers work accepted only after the customer decision, site identity, source materials, and requested output are clear.

The team splits the row into new requests, accepted requests, returned intake, active work, qualified-review waiting, and customer-evidence waiting. Several old requests contain duplicate options or no current customer decision. The revised view does not prove internal capacity is sufficient. It shows that the previous total mixed demand, failure demand, and waiting.

Leadership assigns sales operations to repair the request boundary, design to state acceptance reasons, and the capacity owner to forecast from accepted work after a bounded review period. Customer-facing commitments are checked separately. If accepted work still exceeds reviewed capacity, the company can consider reassignment, tools, outside expertise, or hiring from a better-defined record.

Where can software support the scorecard, and where does it stop?

Software can supply current project identity, source inputs, design versions, modeled outputs, equipment records, proposal revisions, tasks, owners, and workflow events when configured around defined states. It cannot set accounting policy, forecast demand, certify safety, judge competence, interpret law, validate customer promises, select targets, or make executive decisions.

The controlled SurgePV product record covers roof and array modeling, shade analysis, energy-yield and financial modeling, electrical workflow support, bill-of-materials output, and solar proposal generation. Results depend on source data, assumptions, equipment models, configuration, and review. Responsible engineers, authorities, utilities, lenders, insurers, finance owners, and company leaders retain their decisions.

That scope can support project and proposal evidence behind some measures. It does not make SurgePV an executive dashboard, CRM, accounting system, HR system, safety system, or integration claim. Leadership still needs source owners for data outside the product and controls for identity, access, retention, correction, and reconciliation.

Automate only after the metric contract is stable. If “complete” means different things to sales and design, a live dashboard refreshes the disagreement faster. Configure receiver acceptance, release purpose, reopen rules, and version identity before trusting totals.

The weekly test is practical: can another responsible person trace the material row to current work, see its confidence and exception, identify the decision owner, and understand what reopens the decision? If yes, the scorecard is carrying leadership context instead of decorating a meeting.

Frequently Asked Questions

What should a weekly solar leadership scorecard include?

Include only measures tied to current decisions: demand and commitments, accepted delivery flow, cash and commercial exposure, safety and quality, workforce capacity, customer obligations, and unresolved risks. Every row needs a definition, source, owner, time boundary, confidence state, exception note, and decision trigger. The exact measures should reflect the company’s work and authority.

How many KPIs should a solar leadership team review weekly?

There is no universal number. Use the smallest set that covers the material decisions leadership must make without hiding safety, cash, customer, delivery, or workforce risk. Remove a measure that never changes a decision, and split a measure that mixes incompatible work. A long appendix can support diagnosis without crowding the leadership view.

Should a weekly scorecard use targets?

Use a target only when its purpose, basis, owner, time window, trade-offs, and revision authority are documented. A target should not reward unsafe work, premature project stages, hidden discounts, delayed payables, or unreviewed customer promises. Where evidence is immature, show a baseline or confidence state instead of inventing precision.

Who owns the solar leadership scorecard?

One role should own the scorecard process, but each measure needs a source owner and a decision owner. Source owners verify definitions and exceptions; decision owners accept, investigate, or act. Finance, safety, engineering, legal, employment, and customer matters remain with qualified authority. The chief executive should not become the manual reconciler for every row.

Can solar software create an executive scorecard automatically?

Software can supply current project inputs, versions, modeled outputs, equipment records, proposal status, and workflow events when configured correctly. It cannot define accounting policy, forecast demand, certify safety, judge workforce competence, interpret law, validate customer promises, or choose executive action. Automated totals still need definitions, data-quality checks, exceptions, and responsible review.