IPEXIQ · LEARN
Chapter 09 · Aligned with AACE 86R-14, 52R-06 and PMI EVM

Time-Phased Budgets & Change Management

A budget without a time-phasing looking at only one dimension of a multi dimensional problem. Once that same control-account budget is spread across the schedule, it becomes a planned-value curve. Additionally, each approved change needs the same detail time phasing per period (typically weekly)

The tabular cost-report gap

Most projects define their budgets well. Professional services scopes are built up through a CTR (Cost, Time, Resource) sheet. EPC and construction scopes land as a full TIC estimate. Both end up as clean control-account totals - and there the discipline often stops.

Cost reports are typically delivered in tabular formats: totals by control account, sometimes sliced by period, but rarely showing the time-phased profile of how that budget is expected to burn. The schedule exists, loaded with hours and resources, which is exactly what is needed to generate a true time-phased budget. Yet the back-integration from schedule into the cost system is often weak or missing entirely.

The result is that real time-phasing lives in Excel - manually built, manually maintained, and disconnected from the system of record. Spread that same total across time using start/finish dates and a sensible distribution, and the control loop changes shape entirely. Variance, forecast at completion, and S-Curves all fall out automatically. While overall spreads at a control-account level using simple start and finish dates gets us part of the way, it is far more advantageous to load the full detailed deliverable-based budget to activities, as we discuss in our Deliverable Management chapter.

Control increases exponentially

No time-phasing: month-end actuals vs a single total - variance only visible at the end. Or time phasing in excel, its works, but isn't a systems based approach.

Schedule-loaded time-phasing: every control account inherits dates from its activities. As we are only discussing a budget spread, or an approved budget (with approved changes), we are not specifically looking at forecast schedules. However, when we get a change, we should immediately look into the current forecast schedule and understand the impact from the change and use that time phasing to load into your system to showcase when the change hours are planned as of the approved date of the change.

The setup

From a flat estimate to a phased baseline

Modern cost systems - Ecosys, Cobra, ARES Prism, EVMS suites - all support time-phased budgets. The capability is rarely the problem. The discipline of actually loading the hours in a time phased manner and keeping them consistent with the schedule.

1. Control account dates
Every control account gets an explicit start and finish - sourced from the schedule, not typed by hand. However, that is only part of the detail, we also need dates on deliverables, and dates on deliverable gates too based on the schedule.
2. Schedule loading
Budgets that are loaded to your deliverables and associated gate weightings are loaded onto Level 3 schedule activities.
3. Spread curve
There are several options for generating the specific time phased spread of hours. You can choose generic curve based on the control account data, you can use a spread based on the dates from deliverables and gates, or you can use the explicit spread generated from the resource loading in your schedule.
4. Back into reporting
With system loaded time phasing S-Curves can be generated automatically.
Time-phased original budget across control accounts
Original budget time-phased per control account - the planned-value (BCWS) baseline that every later report measures against.
Approved changes

Every approved change needs its own spread

When a change is approved, it adds (or removes) budget against one or more control accounts. The hard part is that it almost never arrives with a matching, schedule-loaded time-phasing.

Why the mismatch? Changes are inserted into the current working schedule, not the original baseline. The working schedule has already moved - activities are re-sequenced, durations are re-calibrated, and resource curves are different. A change loaded against today's working schedule does not naturally produce a spread that lines up with the original baseline's control accounts. However, the first step is to do just that - load into the current schedule - showcase the spread - load that spread as the time phasing for that change.

This is not a Delay Analysis Often times, how changes are reflected in time phased data are used to substantiate claims management. The chapter does not deal with Claim Management, or even the concept of getting a revised baseline approved. Its typical that approved changes come WITHOUT an approved schedule rebaseline. This leads to a conundrum that we need to put the time phasing of the approved changes into our PLAN, but do not have an explicit schedule to do that with.

What's needed: a custom spread per change, per affected control account, that the cost tool can carry alongside the original baseline so the total time-phased budget = baseline + Σ(approved changes).

a. Scope the impact
Identify every control account the change touches - adds, deletes, or re-rates - before sizing the spread.
b. Build the change spread
Use the working-schedule dates for the impacted activities, then apply a spread (often linear or bell) per CA.
c. Load & reconcile
Push the change's time-phased budget back into the cost tool, separately tagged so the original baseline stays intact.
Time-phased approved change spread across control accounts
Approved change time-phased against the working schedule - a custom spread per impacted control account.
S-Curve comparing original baseline and approved change
Resulting S-Curves - the original baseline curve and the approved-change curve, summed to a current planned-value position.
Industry Standards & References

How time-phasing and change control are framed

AACE's Recommended Practices treat the time-phased budget as the foundation of variance analysis and forensic schedule work. PMI's EVM standard makes it explicit: without a Planned Value curve, Earned Value is undefined.

AACE 9R-90
Project Code of Accounts
Underpins the control-account structure that time-phasing is applied to.
AACE 10S-90
Cost Engineering Terminology
Defines control account, time-phased budget, BCWS / planned value.
AACE 17R-97
Cost Estimate Classification System
The CTR / TIC estimate is the un-phased input that time-phasing converts into a planned value curve.
AACE 29R-03
Forensic Schedule Analysis
Why a defensible time-phased baseline (and a separate working schedule) matters when changes are assessed after the fact.
AACE 52R-06
Time Impact Analysis - Approved Changes
How approved changes are inserted into the working schedule, and why that loading rarely matches the original baseline.
AACE 57R-09
Integrated Cost & Schedule Risk Analysis
The cost-loaded, time-phased schedule is the foundation for any credible cost/schedule risk model.
AACE 86R-14
Variance Analysis & Reporting
BCWS vs BCWP vs ACWP only works if BCWS is genuinely time-phased per control account.
PMI EVM
Practice Standard for Earned Value Management (2nd ed.)
PV (Planned Value) IS the time-phased budget. Without it, EV and SV are not defined.

Where IPEXIQ fits

The same Detailed Progress App referenced in Chapter 07 carries time-phasing details against each control account - both for the original baseline and for every approved change - so the BCWS curve, EV roll-up and change-by-change S-Curves are generated automatically.