A Program Budget That Never Controlled the Sites

Root cause: budget control is evaluated per project, against that project's own baselined budget. The hierarchy is a roll-up and reporting structure, not a shared financial envelope.

Follow the money: NW-SUBSTATION has a 48M baselined budget and zero transactions, so every control check it performs passes with the full 48M of headroom. NW-SITE-03 has 9.4M of commitments and no budget, so either control is not enabled for that project or there is nothing baselined for it to test against. Either way, nothing is compared and nothing is raised. The dashboard looks healthy because it is summing a budget from one project and costs from six others.

Option A - distribute and control at child level (usually correct for this shape):

• Allocate the 48M across the six children as each child's original budget (site-specific amounts, not an even split).
• Baseline each child budget, set each child's control level to Absolute, and confirm the control scope (top task versus lowest task) matches how the site teams will code transactions.
• The hierarchy then gives the program-level roll-up reporting, and each site gets a hard stop.
• Consequence to accept: a site cannot borrow another site's headroom without a formal budget transfer, which is normally exactly what EPC governance wants.

Option B - one project with six tasks: if a single envelope genuinely must flex across sites, model the sites as top-level tasks in one project and control at the top task. You then lose per-site project separation, site-specific security and site-level billing, so this is a bigger trade than it looks.

Commitments specifically: purchase order checking depends on Procurement budgetary control for the project document type and on the PO's project and task falling inside the controlled scope; POs created before control was switched on will not be re-tested until they are resubmitted.

No. The top level should be a pure roll-up vehicle, and the cheapest way to enforce that is the project type plus a template, not user discipline.

Recommendation:

• Give the program project a type with cost collection and billing disabled (no supplier invoice or expense can post to it, no bill plan can be created on it), cross-charge off, and capitalization off.
• Turn off or tightly restrict expenditure entry at the top level in the template, and remove the project manager's ability to create transactions there through project role security.
• Keep budgetary control off at the top level once child budgets carry the envelope. Leaving Absolute control on the parent with a stale 48M budget creates a second, meaningless control that will confuse every future exception report.
• Retain the hierarchy and use it for dashboard roll-up, program-level reporting and hierarchical security so the program director sees all six sites.

Why not just rely on training: costs keyed at the program level would sit outside every child control check but still roll into the program total, so the program could overspend while all six sites show green. Structural prevention is the only reliable control.

Alternative to consider and reject explicitly: if the only requirement is to group six independent projects for reporting, a hierarchical grouping is often enough and a transaction-capable parent project adds risk for no benefit. Decide this consciously with the PMO rather than by default.

Forecasts are generated per project, from that project's own cost, commitments, budget and labour demand, using the forecast rules configured for it. The program project has no expenditure items, no commitments and no labour assignments of its own, so there is nothing for the forecast rules to project forward. It cannot cascade down a hierarchy or aggregate child forecasts, and there is no mechanism that pushes a parent forecast onto children.

Correct approach:

1. Configure forecast rules that match how Northwind actually plans - typically a blend of remaining budget for unstarted work, commitment-based forecasting for subcontracts, and historical or assignment-based labour forecasting. Do this at the project type or template level so all six sites inherit consistent rules.
2. Generate and maintain forecast versions at the child project level, and make the site PMs own them each period; forecast accuracy in EPC lives or dies on the EAC being refreshed.
3. Roll the child forecasts up through the project hierarchy and the program dashboard for the program-level view. If the program variance needs its own commentary, capture it as a program-level budget with no forecast, and explain the variance on the roll-up rather than trying to forecast at the parent.
4. Schedule the periodic forecast generation and the summarization jobs so the dashboard is not reading a stale snapshot.

Diagnostic to add to the runbook: if a forecast looks empty or flat, check whether the project has any forecastable source at all (cost, commitments, budget, labour demand) before assuming the rules are wrong.