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)
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.
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.
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.

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).


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.
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.