The Decisions an Industrial Project Depends On

An industrial project can involve a technology supplier, a site operator, an infrastructure owner, a delivery partner and a capital provider. Each controls a different part of the route to operation.

The project case shows how their decisions fit together. It sets out what has been demonstrated, which agreements exist and what each party has to decide next.

Take a heat project at an operating factory, used here as an illustration. The equipment has performed in a test. The installation also needs an electrical connection, an agreed operating window, integration work and a maintenance arrangement. The commercial case depends on how those pieces come together.

A presentation built around the complete project gives each organisation a clear basis for its next decision. This guide is about the decisions that sit across those organisations. The operating risk register covers the risk the host site carries once the technology is installed, and our guide to presenting FOAK risk sets out the evidence a capital provider weighs for a first commercial project.

Define the project boundary

Start by naming what is being proposed. It may be equipment supply, a complete installation, an operating service or a programme across several sites.

Each party draws the boundary in its own place. For an equipment supplier, completion could mean delivery and commissioning of its system. For the host, the project includes staff, operating procedures, integration and the effect on production. A capital provider may assess the route from initial expenditure to the cash flows expected to support its commitment.

Write those boundaries down. Identify which responsibilities sit inside the offer, which belong to another party and which remain open.

The boundary gives each claim a defined scope. A measured equipment result can then sit beside the conditions it depends on at the proposed site.

The US Department of Energy's Adoption Readiness Levels framework examines commercial adoption risks alongside technical readiness. A team can use it as a reference when it lists the market, resource and operating conditions a deployment requires.

Build a dependency register

Record the project's dependencies with the people responsible for each one. Keep the register as a working document before any of it goes into a presentation.

Dependency	What needs to be established	Owner to agree	Effect on the next decision
Site suitability	The assessment relevant to this installation	Site and technical leads	Shows whether the proposed location supports the work
External connection or service	Scope, availability, delivery date and agreement	Infrastructure or service owner	Sets when the installation can use the service
Integration	Interfaces, responsibilities and acceptance tests	Engineering and delivery teams	Connects component performance to the installed system
Operations	Staffing, training, maintenance and response arrangements	Host and relevant suppliers	Defines how the system will be operated and supported
Commercial approval	Scope, terms and the buyer's approval process	Authorised buyer and procurement	Sets out the commitment being requested
Funding	Conditions set by the relevant capital provider	Project team and qualified advisers	Shows what remains before the funding can be drawn

The register is a communication tool. The responsible specialists decide the technical, legal, financial and operational requirements of the project.

Record the evidence beside each entry. A dated study, an accepted specification or a signed agreement gives a reader something to check. Where an answer is still open, name the next action and the person responsible for it.

A working version adds columns for the evidence and its date, the status, the next action, the date it is needed and the consequence of delay. A shared status scale keeps the entries comparable, for example unassessed, under review, indicative proposal, conditions outstanding, agreed within stated scope, and completed and evidenced. Use the project's own terms where they are more precise.

State each partner's role and commitment

A project can hold several relationships at different stages. Label each one at its current stage.

An exploratory conversation records interest. An indicative offer describes terms with conditions attached. An active evaluation means the party is testing the fit. A signed agreement creates the obligations its terms specify. Check separately whether each organisation has agreed to be named and whether you may use its logo.

Apply the same care to delivery support and insurance. Describe the scope under discussion, the terms agreed and the conditions still outstanding. Each organisation should be able to tell which parts of the case it can rely on for the decision in front of it.

A relationship register keeps the public account in line with the underlying records. It holds the party, role, commitment status, evidence, conditions, approval to disclose and next action. Keep confidential documents in a private review process. Before the case circulates, ask the responsible project owner to check the wording, so readers can see which responsibilities each organisation has accepted and which remain open.

Buyer commitments follow a similar ladder, from a letter of intent to a purchase agreement, which our guide to offtake agreements sets out.

Put the calendars together

Each organisation works to its own timetable. The factory has an operating window. An infrastructure provider has a delivery schedule. A supplier has an equipment slot. A funding commitment may carry conditions and an expiry date.

Put those dates on one page. Mark confirmed dates and assumptions separately. Show which event has to happen before another can start.

In the heat project, the equipment delivery date can be agreed while the connection date remains provisional. The presentation shows that dependency and the decision it creates. The project team can then assess sequencing, staging or another arrangement with the relevant specialists.

Where the technology depends on infrastructure that is still being built, show what it can do with the infrastructure available today. Place the applications that wait on later rollout on the same timeline, with the organisation that controls each piece and the evidence behind its date.

Record what happens when an assumption changes. Identify the work affected, who reviews the change and which commitments need revisiting. Keep the dates consistent across the board paper, the customer proposal and the investor material.

Explain the benefit to the party carrying the obligation

One project can bring different benefits to different parties. The host may carry the expenditure and the production disruption. A customer may value the resulting product. Other stakeholders may benefit from an environmental outcome.

For each claimed benefit, record the beneficiary, the evidence and any agreed payment or contribution. Keep each potential benefit and each contracted revenue source in its own row.

The host's case explains the proposed operating change and its consequences. An infrastructure partner needs the dependency it is being asked to resolve. A capital provider needs the entity, obligations and evidence relevant to its assessment.

This work can reveal a gap in the underlying arrangement, such as a party that carries a cost and receives no benefit. Naming the gap gives the project team a specific issue to resolve with the right people.

Prepare audience versions from one source case

Build one source case with the agreed facts, assumptions, dependencies and commitments. Prepare the material for each audience from it.

The operating version explains installation, responsibilities and support. The procurement version sets out scope, supplier commitments and the proposed agreement. The board version explains the decision, the alternatives, the material uncertainties and the conditions. The investor version presents the project and the evidence its assessors require.

Each version uses the same facts, in the order and depth its reader needs. Our free course From Story to Stage applies the same method to talks, with one deep source cut for each room. For an industrial project, each cut shows one reader its own responsibility within the shared case.

Test the next decision

Ask a reader from each organisation to review its version and describe the next step. Compare the answers.

The answers should describe compatible commitments. If one reader expects an exploratory study and another expects approval to proceed, resolve the difference before the material circulates further.

Test the evidence too. Ask each reader which claim needs more support, which obligation remains unclear and which colleague must be involved. Put the answers back into the source case and assign the follow-up.

When the organisations are each waiting for another to commit, Why Nobody Wants to Become the Precedent maps who is waiting for whom and which commitment can move first.

The result is a project case that shows the work a decision needs. Engineering, legal, financial and operating judgements stay with the people qualified and authorised to make them.

For a defined project, our pitch and decision materials work brings the evidence, narrative and presentation together for the people who need to assess it.

Sources and further reading

• Adoption Readiness Levels (ARL) framework, US Department of Energy
• How to Present FOAK Risk Without Pretending the Risk Is Gone, Brighter Future, 2026
• The Buyer Believes Your Technology. They Still Have to Operate It., Brighter Future, 2026
• From Pilot to Purchase. The Internal Approval Pack, Brighter Future, 2026
• What Is an Offtake Agreement and Why Does It Matter for FOAK Climate Tech?, Brighter Future, 2026
• Why Nobody Wants to Become the Precedent, Brighter Future, 2026
• From Story to Stage, Brighter Future