How capital planning and project approval runs, step by step

Capital planning moves from policy to a funded, controlled project. Finance writes the rules and sets the spending envelope. Sponsors propose projects, analysts test the economics, and a committee ranks the requests. Approvers sign within their authority. Accounting then opens a project code with a hard limit before any money is committed.

The steps in order

1. Write or refresh the capital policy. The controller or head of financial planning drafts it and the CFO signs it. It defines what counts as capital spending versus expense. It also sets the capitalization threshold, the hurdle rate and the approval matrix that says who can sign at each level.

1. Set the capital envelope. Treasury and financial planning agree how much the business can fund from cash, debt or leases. The executive team, and often the board, approves this top-down figure before any project is discussed.

1. Collect project requests. Business unit sponsors submit requests on a standard business case template. A good request names the problem and the options considered. It also shows what happens if nothing is done.

1. Build the financial justification. An FP&A analyst turns the sponsor's assumptions into cash flows, net present value, payback and a sensitivity view. This is where weak cases get challenged. Tax and technical accounting confirm how the spend will be treated on the books.

1. Rank the portfolio. A capital committee made up of the CFO, operations leadership and divisional heads weighs return against strategic fit and risk. Mandatory items such as safety and regulatory work usually go first. Growth projects then compete for what remains.

1. Approve the capital budget. The executive team or board approves the ranked list as a whole. FP&A publishes the approved budget by project and by business unit.

1. Authorize each project at the point of spend. Being in the budget is not permission to spend. The sponsor raises an authorization request, sometimes called an AFE, when the project is ready to start. Whoever the approval matrix names for that level signs it.

1. Open the project in the ledger. The fixed-asset or project accountant creates the project code and its cost centre. The accountant loads the approved amount as a spend limit and maps the code to the right asset classes. The system can then block or flag commitments that exceed what is available.

1. Commit and buy. Procurement raises purchase orders against the project code. The system checks each order against remaining funds. Agreed tolerances between order and invoice amounts stop small variances from triggering new approvals.

1. Monitor spend and handle changes. The project manager reports actuals and forecast-to-complete against the approved figure. Any overrun beyond the policy tolerance goes back through a supplementary approval. Scope changes follow the same route.

1. Close and review. Once the asset is in service, accounting capitalizes the costs, starts depreciation and closes the project code so nothing else posts to it. Some time later, finance runs a post-implementation review comparing actual benefits with the original business case.

Where it tends to break

The gap between steps 6 and 7 causes most trouble. Sponsors often treat budget inclusion as approval and start ordering before the authorization request is signed.

Project codes are another weak point. If the spend limit is not loaded, or loaded as a soft warning, the system control exists on paper only.

Post-implementation reviews are the step most often skipped. Without them, optimistic sponsors keep getting funded because nobody checks whether earlier projects delivered.

Questions to ask the people who run it

What the policy says and what happens on a busy week are often different. These questions surface the real process:

• When a project is in the approved budget, does anyone still wait for a signed authorization before raising orders?
• Who actually builds the financial case: the sponsor, FP&A, or a consultant the sponsor hires?
• How often are hurdle rate or discount assumptions overridden, and who agrees to that?
• Are large projects ever split into smaller requests to stay under an approval level?
• Does the system hard-stop an order that exceeds the project limit, or just warn?
• What happens to unspent budget when a project finishes under its approved amount?
• Who decides a project is complete, and how long do codes stay open afterwards?
• When was the last post-implementation review, and did its findings change any later decision?
• Which approvals happen by email outside the system, and where are they kept?
• If a supplier invoice arrives above the order value, who resolves it and against which budget?

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.