Capital Project Intake: How to Build a Process That Ends in a Funding Decision

Completix Team|November 1, 2026|10 min read

Capital requests are not ordinary project requests. They compete for a fixed pool of money, they run across fiscal years, and the whole process exists to reach one decision: fund it or not. This guide walks through how to design a capital project intake process that reaches that decision with complete information and a clear record.

Why capital intake is different from project intake

Most project intake processes answer one question: should we do this work? Capital intake answers a harder one: should we spend this money, from this budget, in these years, ahead of everything else asking for the same pool? That changes the design in four ways.

• The money is the decision. In ordinary intake, approval and budget are often separate steps handled by different groups. In capital intake, the funding approval is the one that matters most, and the rest of the process exists to inform it.
• Requests span fiscal years. A plant upgrade or a facilities project often draws money over two or three years, so the request has to show spend by year, not one total.
• Capex and Opex are split from day one. Finance needs to know how much of a request will be capitalized and how much hits the operating budget, long before the project starts.
• Requests compete with each other. The capital pool is fixed for the year. Approving one request means another waits, which is why capital decisions are usually made by a committee comparing several requests at once.

Separate the two decisions

The most common design mistake is asking one form to carry both decisions a capital process makes. They are different questions, asked at different times, by different people.

Decision 1: does this request deserve a business case?

This is screening. It should be quick and cheap for the requester. The questions are about fit: what asset is involved, which site, what problem it solves, which business objective it supports, a rough order of magnitude, and whether it triggers a safety, regulatory or downtime review. Most requests should get a yes or no here in days, not weeks.

Decision 2: which business cases get funded this year?

This is the funding decision. It needs a full business case, a cost estimate split by year and by Capex and Opex, and a realistic view of who will deliver it. It is also a comparison, because the committee is choosing among several cases that together ask for more than the pool holds.

Treating these as two phases, with a clear end to screening before the business case opens, solves two problems at once. Requesters stop writing full business cases for ideas that were never going to pass screening, and the committee stops reviewing requests that are missing the basics.

Design the request form to ask for less, then more

Long capital request forms are not the problem. Long forms that ask every requester every question up front are. A few design rules keep the form complete without making it punishing.

• Ask screening questions first, business case questions later. Cost detail, benefits and delivery plans belong in the second phase.
• Show questions only when they apply. A safety review section matters for production equipment and building works, not for a software license. Conditional fields keep the form short for most people and complete for the cases that need it.
• Accept ranges early. An order-of-magnitude estimate is enough to screen. Precise cost by year comes with the business case.
• Capture funding years and cost type as data, not free text. "26 and 27, maybe" in a spreadsheet cell cannot be added up. Fiscal-year rows split into Capex and Opex can.
• Make fields required at the gate where they matter, so a request cannot move forward with the blanks that will stall the committee later.

The six stages of a capital project intake process

Every organization names these differently, but most well-run capital processes follow the same shape: two phases, five gates, and a handoff to delivery.

1. Request

   The requester picks the right request type and fills in the screening fields. Use one template per type, so a building project and an equipment purchase are not forced through the same form. This is where gated intake earns its keep.

2. Capital screen

   A capital planning lead, and anyone the rules name, checks fit and completeness. This gate ends the screening phase. A request that passes is invited to build a business case.

3. Business case

   The requester completes benefits, risks, a cost plan by fiscal year with a Capex and Opex split, and the delivery approach. Approvers here usually include finance and any specialist reviewers the request triggers, such as safety or engineering.

4. Funding decision

   Funding is requested against the right budget, year by year, and approved by whoever owns that budget. If your rule is that nothing moves until money is committed, the gate waits for funding approval.

5. Readiness

   Confirm the sponsor, the delivery team and the start date. This is the last check before the work becomes a project.

6. Promotion to project

   The approved request becomes the project, carrying its budget plan, funding and decision history with it. From here, delivery governance takes over, usually through project stage gates.

Decide who approves what, before the first request arrives

Capital processes stall when routing is decided case by case. Write the approval rules down as a policy, based on what the request actually says, so the right people see it without anyone chasing signatures.

Two habits make this work. First, approvers named at the same gate should review in parallel rather than one after another, which can take weeks out of a long approval chain. Second, every action, including a request for more information, should be recorded on the request with who and when. When someone asks months later why a project was funded, the answer is in one place.

Put the funding decision on the request

In many organizations, the business case is approved in one place and the money is found in another, often a spreadsheet owned by finance. That gap is where capital processes lose time and lose their audit trail.

A cleaner model is to treat each capital budget as a funding envelope, for example one per line of business per fiscal year, holding a Capex and an Opex amount. A request draws on an envelope at the funding gate, the draw sits as pending until the budget owner approves it, and finance can see at any moment what is approved, what is waiting and what is left. Nothing should be released automatically, a person approves each draw. This is the same discipline good portfolio financial management applies once projects are running, moved earlier to where the decision is made.

Because the draw is attached to the request rather than to a project that does not exist yet, the committee can commit money before delivery starts, and the record of who approved it travels with the work.

Compare candidates against the capital, and the capacity, you have

Funding decisions are comparisons, so the process needs a way to look at several requests together. Two constraints matter.

• Money. Add up what the shortlisted requests ask for in each fiscal year and set it against what is left in the envelope. It is simple arithmetic, but only if cost by year was captured as data.
• People. Capital projects lean on the same scarce teams, often maintenance, engineering or facilities staff. A combination that fits the budget can still be impossible to deliver if it lands three projects on one team in the same shutdown window.

A practical way to handle both is to model the shortlist. Build a what-if version of each candidate with an estimated schedule, budget and team, group the candidates into scenarios, and compare them side by side before anything is committed. Scenario planning combined with capacity by named person is what turns "we can afford it" into "we can afford it and deliver it".

Where capital intake processes break

The request lives in an email attachment

Versions multiply, blanks stay blank, and nobody is sure which file the committee approved. It is the same problem that makes spreadsheets fail at portfolio management, concentrated in the one process where the numbers matter most.

Approval happens in an inbox

A "looks fine" reply is not a decision record. When auditors ask, someone rebuilds the trail from memory and forwarded threads.

Funding is decided somewhere else

The business case says approved, the budget spreadsheet says pending, and the work either starts without committed money or waits without anyone knowing why.

Capacity is checked after the money

Projects get funded, then discover they cannot be staffed, and slip into the next fiscal year carrying their budget with them.

The approved request does not become the project

Delivery starts from a new record, and the link back to the business case, the approvers and the funding is lost the moment it is needed.

Where software helps, and where it does not

A good intake platform can:

• hold one template per request type, split into gates and phases, with conditional and required fields
• route each gate to approvers by policy and record every action with who and when
• carry a multi-year Capex and Opex budget plan on the request, and attach funding draws to it for approval
• let you model shortlisted candidates and compare scenarios before committing
• promote the approved request to a project without re-entering anything

It cannot decide which requests matter most, write the business case, or produce a credible cost estimate. Those stay with requesters, finance and the committee. Software makes the decision visible, complete and recorded, it does not make the decision. If you want to see how this works end to end, here is how Completix handles capital project intake with funding at the gate.

Before you launch, check that

• Screening and business case are separate phases, with a clear end to screening
• Each type of capital request has its own template
• Cost is captured by fiscal year and split into Capex and Opex
• Approval routing is written down as rules, not decided request by request
• Funding is requested and approved on the request, against a named budget
• The committee compares shortlisted requests on both cost and capacity
• Every approval, rejection and request for more information is recorded
• An approved request becomes the project, with its history attached