What each role knows in capital planning and project approval

Sponsors know what a project will really take to deliver. Finance knows how money is controlled, coded and booked. Approvers know which priorities matter this year. Each sees only part of the picture, so trouble appears where a decision made with one view collides with a fact held by another role.

The project sponsor

The sponsor holds the operational truth. They know whether the old machine is failing or merely inconvenient. They know the contractor's track record, the site constraints and the real reason a business case needs approving before quarter end.

Much of this never reaches the paperwork. Sponsors learn quickly which assumptions get challenged, and they shape the case to survive review. Contingency gets buried in line items. Phasing gets smoothed so the first year looks affordable. None of this is dishonest in intent. It is a rational response to a process that rewards a clean submission.

The analyst building the justification

Finance owns the method. The analyst knows the hurdle rate, how depreciation will hit the income statement and which costs the policy says must be capitalised. They also know where the model is fragile. A small change to the volume assumption can flip the answer.

What the analyst usually lacks is any way to test the sponsor's inputs. They can check arithmetic. They cannot check whether a vendor quote is realistic or whether the savings depend on a headcount change that operations has no intention of making. So the justification often comes out precise but weakly grounded.

The approval committee

Approvers see across the portfolio. They know that two divisions are asking for overlapping systems and that the board has signalled caution. They also know about the acquisition nobody else has heard of yet.

Their blind spot is execution. A committee approves a total. It rarely sees how that total breaks into commitments, how the budget sits in the funds control structure, or whether the project code even exists yet. Approval feels like the end of the decision. For everyone downstream it is the start of the work.

Buyers and budget holders who commit spend

Procurement knows what the market will actually charge, and it knows when a supplier has quietly changed terms. Budget holders know what has been ordered but not yet invoiced.

This is where overspending usually starts. Controls designed to stop spend beyond the approved amount only work if commitments are recorded when orders are raised. When purchase orders are raised late, or split across cost centres to stay under an authority limit, the system shows headroom that does not exist. Tolerances between order value and invoice value get set once and forgotten, so creeping overruns pass through as acceptable variances.

The fixed-asset accountant

The asset accountant is often the last to learn about a project and the one who must make it reconcile. They know whether costs posted to a project can be capitalised, which ones must be expensed, and when an asset is genuinely in service.

They frequently discover problems months after approval. Internal labour was never tracked against the project. Software subscriptions were treated as capital. A project was never closed in the cost ledger, so later unrelated spend drifted onto it. By then the sponsor has moved on and the original case is hard to find.

Where the gaps cause most damage

The costliest failures sit between approval and setup. A project is approved at committee, but nobody tells the team that maintains project codes and spend limits. Spend begins against a general cost centre and has to be reclassified through manual journals, each needing its own approval.

A second gap sits at close. Post-implementation reviews depend on actual costs being comparable to the justification. If the case was built on one cost structure and the ledger accumulates costs on another, nobody can say whether the investment paid off. That breaks the feedback loop that should make next year's cases more honest.

Policy drift is the quieter problem. Capital policies get rewritten by finance, but the thresholds and definitions in the system are updated separately, sometimes not at all. People follow whichever version they encounter first.

Questions to ask the people who run it

Practice often departs from what is documented, so ask the people doing the work.

• When a project is approved, who is told, and how? Is there a step that creates the project code and loads the budget, or does someone remember to do it?
• Do sponsors ever split a request to keep it below an approval threshold? What would happen if they did not?
• At what point is a commitment recorded: when the order is raised, when it is approved, or when the invoice arrives?
• Who sets the tolerance between order and invoice values, and when was it last reviewed?
• How does the asset accountant learn that an asset is in service?
• Which costs are routinely argued about between capital and expense, and who settles the argument?
• When did a post-implementation review last change a decision about a later project?
• If a project overruns, who finds out first, and who finds out last?
• Which parts of the capital policy do people ignore, and why?

Listen for workarounds described as normal. A spreadsheet that sits beside the system, or a person everyone calls before raising an order, usually marks the exact place where one role's knowledge is not reaching another.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.