Write the paper the board can approve

A vendor proposal argues for a system. A capital paper has to let people who were not in the meetings make a decision. The difference is a named constraint, a stated set of assumptions, a sensitivity and a measurement plan.

A proposal is written by a party with an interest in the answer. That is not a criticism, it is its job. It presents one option, in its best light, with the assumptions that support it.

A capital paper has a different job. It has to let a group of people who were not in any of the meetings understand what is being asked for, what it rests on, what could make it wrong, and what happens if it is approved.

This explains a pattern most operators will recognise. The technically strongest option frequently loses to the one that was explained better, and the paper is the explanation.

Attaching the proposal and writing a covering page is the usual shortcut, and it is a common reason energy projects get deferred rather than declined. A deferral is what a board does when it cannot tell which parts of a document are measurements and which are forecasts.

The paper does not need to be long. Four pages is generous. It needs to contain six things that a proposal structurally cannot contain, because they are about the organisation rather than about the system.

What follows is those six, in the order they belong on the page.

One structural note before the content. Write it so the recommendation and its basis sit on the first page, and the support sits behind. A reader who has to reach page three to find what is being asked for has already formed a view about how clear the thinking is.

The first question a competent reader asks is why this capacity and not a different one. A proposal answers with what fits. A paper should answer with what binds.

Every commercial system has one constraint doing the work. The usable roof area after plant and clearances. The switchboard's headroom. The position the network will approve. Or the site's own load, where the roof could carry more than the business can use.

Naming it changes the conversation from a negotiation about size into a question of fact. It also tells the reader what would have to change for a larger system to be possible, which is the question that arrives second.

It has a second use. A named constraint is the thing that makes a later variation legible. If the array grows because an export limit was raised, the paper already explained why that was the number to watch.

The four inputs and how they interact have their own post: see "Four numbers decide the array". The paper does not need to re-explain them. It needs to state which one bound this site, and what the number was.

Where the binding constraint is the switchboard, say so and price the alternative. A board upgrade is a legitimate scope option and it is better presented as a choice than discovered as a variation.

Where the binding constraint is the load rather than the building, say that too, and say it early. A roof that could carry twice the proposed array is a fact a reader will notice, and hearing it from the paper is very different from discovering it in the appendix.

This is the section that decides whether the paper is credible, and it is the one most commonly missing.

The reason it matters is that a document full of numbers reads as authoritative regardless of where the numbers came from. A chart of modelled output and a table of metered consumption look identical on a page, and only one of them is evidence.

The left column is evidence. The right column is a set of estimates, each of which can be defended and none of which is a fact.

Certificate value sits firmly on the right, and it should be stated as an estimate with its basis. The mechanism has its own post: see "Why nobody can quote you an exact figure". Where the scheme publishes an estimating tool, cite it¹².

Doing this once removes most of the questions a paper attracts, because it pre-empts the one a sceptical reader was going to ask about every number on the page.

A practical convention that works: footnote every figure in the modelled column with its basis, and footnote nothing in the measured column beyond its source and date. The asymmetry itself communicates the point.

A single payback figure invites an argument about the figure. A range with its drivers named invites a decision.

It is also more honest about what is knowable. Nobody can state a twenty-year return to two decimal places, and a paper that appears to is either being careless or is hoping nobody checks.

Three variables move the result more than the rest, and all three belong in the paper. The self-consumption ratio, because it decides what each generated kilowatt hour is worth. The tariff and its escalation, because it compounds. And the certificate value, because it is set on a day nobody controls.

Present each one as a low, central and high case, and say plainly which case the recommendation is made on. The central case should be the defensible one, not the flattering one.

Then state what would have to be true for the project to fail its threshold. If the answer is a self-consumption ratio materially below the modelled figure, that is a specific, checkable risk and it can be monitored after commissioning.

Name the hard thing in this section rather than the next. Where the central case does not clear the organisation's hurdle, the paper should say so and recommend accordingly. Shrinking the scope until the number looks acceptable is how projects get approved and then underperform.

A contractor carries delivery risk. The organisation carries everything else, and the paper is where those are listed.

The failure mode here is a risk section written as reassurance. Five paragraphs describing why each risk is unlikely tells the reader nothing about what happens if one of them occurs.

Five belong on almost every list. Tenure, where a lease is shorter than the asset's life. Building works, where a roof replacement or a plant upgrade falls inside the period. Tariff change, where a retail contract is renegotiated. Business change, where a shift pattern or a tenancy alters the load shape the design was built on. And regulatory change, where a scheme's rules are still being made.

Each needs a sentence on treatment rather than a paragraph on description. Who owns it, what would trigger it, and whether the exposure is bounded.

The tenure risk deserves specific handling because it recurs. An array with a service life measured in decades on a lease with years left is a legitimate investment, provided the paper says what happens at the end of the term and who removes the equipment: see "Plan the removal when you plan the array".

Regulatory risk deserves a plain sentence where a scheme's rules are not yet final. Stating that a figure depends on regulations still being made is not a weakness in the paper, it is the reason the paper is trusted.

An approval that contains no way of knowing afterwards whether it was right is an approval nobody can learn from.

It is also what converts a one-off approval into an organisation that gets better at these decisions. The second energy project is easier to approve when the first one has a measured result attached.

The measurement plan is short. What will be measured, against which assumption, at what interval, and who reports it.

For a solar project it is usually four things. Generation against the modelled yield. Self-consumption ratio against the modelled ratio. Demand, if a demand tariff applies. And the actual certificate value received against the estimate used.

All four require metering that records generation and export separately, which is a scope item and should be named as one. A system that cannot report its own self-consumption cannot be measured against the paper that approved it.

Set the first review at twelve months. A shorter window measures a season, and seasons are exactly what the annual model averaged.

Name who reports it as well. A measurement plan with no owner is a plan that produces its first report when somebody asks for it, which is usually the year it has become awkward.

The last page is administrative and it is the one that saves the most time, because it tells the reader what happens next and what it costs to say yes.

Lodging the connection enquiry before the paper goes up is unusual and worth doing. It costs little, it takes the longest, and an approval that then waits a season on a network response looks like a project stalling.

That is the whole document. A named constraint, two columns kept apart, a range with its drivers, a risk list with owners, a measurement plan and a path. Four pages, and every one of them answers a question the reader was going to ask anyway.