M1.3 — Integrated Baselines

M1.3 — Integrated Baselines

1. Practical outcome

By the end of this section, the learner should be able to establish, test and explain an integrated project baseline that brings authorised scope, schedule, budget, assumptions, progress rules and accountability into one coherent reference position. They should be able to distinguish a baseline from a current forecast, identify when apparently complete discipline baselines are not genuinely integrated, challenge unrealistic or internally inconsistent plans before approval, and preserve the approved reference so that later performance and authorised change remain visible.

The objective is not to “freeze a plan” for administrative convenience. It is to create a credible, approved model of what the project has committed to deliver, when it intends to deliver it and what authorised resources or budget are associated with that delivery. If that reference is weak, every later variance, trend, forecast and management decision will be weakened as well.

2. Core concepts

A baseline is an approved reference, not simply the latest plan

A project can have many working plans and forecasts, but a baseline is the formally authorised reference against which performance and change are measured. Once approved, the baseline should remain identifiable even when the current forecast moves away from it. The current forecast answers “What do we now expect?”; the baseline answers “What did we approve as the control reference?” Those are different management questions and both need to remain visible.

A useful principle is: forecast movement should become visible as performance information; authorised change should become visible as controlled baseline change. Neither should be hidden by casually replacing the reference.

Integration means the disciplines describe the same project

An integrated baseline is more than a schedule baseline sitting beside a cost baseline. Scope, schedule, cost and progress rules must describe the same authorised delivery model. If a work package exists in the WBS but has no schedule or budget representation, if schedule work is planned outside the authorised scope, or if cost is time-phased in periods that contradict the planned delivery sequence, the baseline is not genuinely integrated.

Integration therefore depends on the common structures established in M1.1 and M1.2. WBS identifiers, coding, responsibility and control-account relationships provide the traceability that lets the practitioner test whether each discipline is referring to the same work.

The integrated baseline has several connected components

·       Authorised scope: the approved deliverables, boundaries, exclusions and WBS.

·       Schedule: the logic-based sequence, durations, calendars, milestones, dependencies and relevant constraints.

·       Budget/cost baseline: the authorised budget allocated to scope and time-phased in a way that reflects the delivery plan.

·       Progress measurement rules: the agreed basis for determining physical accomplishment after performance begins.

·       Assumptions and planning basis: the key conditions on which durations, costs, interfaces and delivery strategy depend.

·       Responsibility: clear ownership of work and control points, including control accounts where used.

·       Version and approval evidence: the effective date, approving authority and preserved copy of the authorised baseline.

Not every organisation uses the same terminology or formal artefacts, but these principles remain. The baseline needs enough information to explain what has been approved and enough traceability to support later control.

Scope is the anchor

Schedule and budget should be traceable back to authorised scope. The practitioner should be able to take a representative WBS element and show the activities that deliver it, the budget associated with it, the owner, the progress method and the relevant assumptions. Missing or duplicated links create hidden baseline weakness.

Time-phasing connects cost and schedule

A budget total can reconcile while still being poorly integrated with the schedule. Distinguish the time-phased performance budget, the expected incurred-cost profile and the cash-payment forecast. The performance budget follows the planned work and its measurement rules; payments follow the commercial terms. A deposit may move cash earlier without representing earned work. Reconcile the three views rather than using a payment milestone alone to phase planned value.

Flat-spreading a budget across twelve months because it is easy to do is not the same as building a time-phased baseline.

Assumptions are part of the baseline logic

Every baseline contains assumptions: access dates, approval durations, productivity, supplier lead times, resource availability, working calendars, inflation or rate assumptions and many others. Material assumptions should be visible because a later forecast may change when an assumption proves wrong. If the baseline assumption cannot be reconstructed, the reason for subsequent variance can become ambiguous.

Progress rules should exist before performance is reported

Progress measurement rules established in M1.4 should be defined at or before baseline so that the project does not invent favourable measurement rules after results are known. The baseline should therefore identify how physical progress will be measured for material work packages, particularly where earned-performance techniques or integrated cost/schedule analysis will later be used.

A baseline must be credible enough to control against

Formal approval does not make an unrealistic plan credible. A baseline should represent an achievable authorised plan, with logic, durations, resources, costs and assumptions that can be defended. An externally committed date may be challenging, but the baseline should show the actual delivery logic needed to achieve it rather than disguising infeasibility through arbitrary constraints or unrealistic durations.

Where the approved target is genuinely more demanding than the current most-likely forecast, that tension should be transparent. A project should not manufacture apparent feasibility simply to obtain baseline approval.

Approval, preservation and effective date matter

Once the baseline is approved, the project should preserve the exact authorised version and record when it became effective. Later systems may display current plans, but the original approved reference must remain recoverable. Formal configuration control of approved baseline revisions is addressed in M6.3; at this stage the learner needs to understand why version preservation is fundamental to performance measurement and auditability.

Baseline change is not the same as routine replanning

Teams will continually replan the future in response to actual performance, emerging information and risk. That normally changes the forecast, not the approved baseline. The baseline should change only through the project’s authorised change process and only for approved reasons. Otherwise adverse variance disappears and management loses the history needed to understand performance.

3. Step-by-step method — how to establish an integrated baseline

1. Confirm the authorised scope and control structures. Start with the approved scope, WBS, coding structures and responsibility model. Resolve scope gaps or overlaps before trying to baseline schedule and cost information.

2. Confirm the planning basis. Record the key delivery strategy, calendars, major assumptions, external dependencies, productivity assumptions and constraints that underpin the plan. This gives later reviewers a basis for understanding why dates and costs were set as they were.

3. Develop and quality-check the logic-based schedule. The schedule should contain the activities and milestones needed to deliver the authorised scope, with realistic durations, credible dependencies and only justified constraints. Detailed scheduling methods are developed in M2.

4. Map schedule work to scope and responsibility. Check that material activities and milestones can be traced to the WBS and accountable owner or control account. Investigate work that has no clear scope home or scope elements that have no delivery activity.

5. Confirm the approved estimate and budget. The cost model should be based on the same scope and delivery assumptions as the schedule. Resolve exclusions, allowances, duplicated scope and ownership ambiguities before approval.

6. Map budget to the control structure. Allocate authorised budget to the WBS/CBS/control-account structure at a level suitable for later control. The mapping should allow costs and performance to be aggregated and reconciled.

7. Time-phase the budget. Align the performance budget with scheduled work, resources and progress rules. Reconcile it with the expected incurred-cost and cash-payment profiles, explaining procurement and commercial timing differences rather than substituting payment dates for planned accomplishment.

8. Define progress measurement rules. For each material work type, agree how physical accomplishment will be evidenced and calculated. Confirm that the proposed rules can support schedule updates, performance analysis and any earned-value method that will be used.

9. Reconcile scope, schedule and budget. Perform cross-discipline checks. Every material scope element should have appropriate schedule and budget representation; schedule and budget totals should reconcile through the defined structures; and phasing should make operational sense.

10. Test milestones and completion logic. Trace the major delivery sequence through to key contractual or public commitments. Confirm that the fixed dates are supported by logic and assumptions rather than simply imposed through hard constraints.

11. Review resource and capacity realism. Where resources materially affect feasibility, test whether the baseline assumes skills, equipment or supplier capacity that can actually be available. Resource optimisation is treated in M2.3, but obvious infeasibility should not be baselined.

12. Review risk and uncertainty explicitly. Confirm that major known risks, opportunities and assumptions are visible and that contingency or management reserve is treated transparently under the project’s rules. Do not bury known uncertainty inside unexplained activity durations or cost lines.

13. Perform a baseline-readiness review. Challenge completeness, integration, traceability, logic, cost phasing, progress rules, assumptions and governance. The review may be formal or proportionate to project scale, but it should be more than a document-completion check.

Where an Integrated Baseline Review (IBR) is adopted, use it to establish a shared understanding of baseline risk across technical work, schedule, cost, resources and management processes. It is not a pass/fail EVMS compliance audit and does not itself authorise scope or funding. Apply the relevant IBR arrangements and revisit material changes.

14. Obtain approval from the appropriate authority. Record what was approved, by whom, on what date, with any conditions or outstanding actions. Avoid ambiguous approval where different teams believe different versions are authoritative.

15. Preserve the approved baseline and establish control rules. Freeze or snapshot the authorised version, record the effective date and define how forecasts, status updates and approved changes will be handled without erasing the original reference.

4. Worked Reference Project example — Community & Learning Centre

The Community & Learning Centre Reference Project has a fixed core: 24 months, an approved budget of 50 million Cost Units (CU), six Level-1 WBS elements and a fixed public opening date. M1.3 turns those facts into a coherent baseline rather than treating them as disconnected targets.

Step A — establish the scope and milestone backbone

The project confirms the six Level-1 WBS elements: 1.1 Design & Approvals; 1.2 Site & Building; 1.3 Furniture & Specialist Equipment; 1.4 Digital & Technology Systems; 1.5 External Areas & Access; and 1.6 Operational Readiness, Testing & Handover. The schedule then links major milestones such as Design Approved, Main Contracts Awarded, Building Ready, Systems Installed, Testing Complete, Handover and Public Opening.

The learner should trace how each major milestone relates to scope. For example, “Systems Installed” should be supported by activities under Digital & Technology Systems and should connect logically to testing and operational readiness. It should not simply be a date typed into the schedule because management expects to see one.

Step B — connect budget to delivery

Assume the approved 50 million CU budget has been allocated across the six Level-1 WBS elements and then to lower control packages. Under 1.4 Digital & Technology Systems, costs may include design, hardware procurement, installation, configuration, testing and training. Show the planned accomplishment profile and reconcile the related incurred-cost and payment forecasts to the same scope and schedule.

If hardware procurement requires a deposit months before equipment arrives, the cash forecast may legitimately show an early payment. Its treatment in incurred cost and performance measurement depends on the accounting policy and the defined material or work milestone. The deposit alone does not justify placing installation planned value in Month 4 when installation is scheduled for Months 16–18. Manufacturing accomplishment may have its own earlier, evidenced measurement milestones.

Step C — test a representative control package

Take the specialist equipment package under WBS 1.3. The learner should be able to trace: authorised scope → procurement and installation activities → budget → supplier/contract code → accountable owner → progress measurement method → acceptance milestone. If one link is missing, later variance analysis will be less reliable.

Step D — challenge the fixed opening date

The public opening date is fixed, but that does not mean the schedule should simply be constrained to finish on that date. The learner should trace the logic through building readiness, equipment installation, digital commissioning, integrated testing, handover and operational readiness. If the calculated plan misses the required date, the baseline review should expose the gap and prompt an explicit decision on recovery, scope, resources or risk; it should not hide the problem.

Step E — preserve what was approved

Once the baseline is approved, the project records the effective version, approval date and key assumptions. Three months later, if a supplier forecasts a six-week delay, the current schedule forecast may move. The original baseline remains visible so management can see the variance. If a later approved change legitimately alters scope and budget, the baseline is revised through the change/configuration process rather than silently overwritten.

5. Interpretation and professional judgement

How detailed should the baseline be?

The baseline should be detailed enough to support meaningful control at the level where decisions are made, but not so detailed that maintenance consumes more effort than the control value created. A high-risk specialist package may need finer schedule and cost integration than a low-value routine purchase. Proportionality matters.

When is the plan mature enough to baseline?

A project should not wait for impossible certainty, but neither should it baseline major unknowns as if they were resolved. Ask whether enough scope, delivery strategy, interfaces, estimate basis and planning logic are known to create a reference that management can responsibly use. Remaining uncertainty should be explicit rather than hidden.

What if the authorised target is unrealistic?

The practitioner should distinguish between an ambitious target and a mathematically or operationally implausible plan. If current evidence indicates the target cannot be achieved, the issue should be escalated transparently. A project-control professional should not make a target appear achievable by adding constraints, reducing durations without basis or omitting required work.

Should every risk be built into the baseline?

No single rule fits every organisation. The important distinction is between planned work/assumptions and uncertain events. The baseline should include the work and allowances authorised under the project’s control rules, while risk exposure and contingency remain transparent. Avoid double counting the same uncertainty in both padded activity durations and separate contingency.

What is the difference between baseline movement and forecast movement?

Forecast movement reflects the project’s latest expectation and should occur whenever evidence changes. Baseline movement changes the authorised reference and therefore requires governance. If a forecast slips three weeks, the baseline should normally stay where it was so the variance remains visible. Only an approved change should alter the authorised reference.

How should cross-discipline inconsistencies be treated?

Do not accept them as “timing differences” without explanation. A mismatch may be legitimate, such as an advance payment before manufacture, but it needs a documented reason. Otherwise, investigate whether scope, coding, cut-off assumptions or phasing are inconsistent. Reconciliation is a diagnostic activity, not a formatting exercise.

Baseline quality should be judged by decision usefulness

A baseline is valuable when it gives managers a stable and credible reference from which to understand performance. A perfectly formatted baseline with weak logic, untraceable cost or unclear assumptions is not high quality. The practitioner should be able to explain how the baseline will support future variance, forecast, change and accountability decisions.

A useful practitioner test is: “Can I take any material work package and show what was authorised, when it was planned, what budget supported it, how progress will be measured, who owns it, and what assumptions made the plan credible?”

6. Practice diagnostic

Use this table to challenge the quality of the approach or deliverable. The rows consolidate the most important recurring red flags and checks; they are prompts for professional judgement rather than a substitute for the method above.

7. Try-it-yourself practical exercise

Using the Community & Learning Centre Reference Project, create and challenge a simplified integrated baseline pack rather than a single schedule or cost sheet:

1. Take the six Level-1 WBS elements and define at least twelve lower-level control packages or representative work packages.

2. Create a milestone map from Project Authorised through Design Approved, Main Contracts Awarded, Building Ready, Systems Installed, Testing Complete, Handover and Public Opening. Identify which WBS elements drive each milestone.

3. For at least eight work packages, define the planned start/finish window and the principal assumption supporting the duration.

4. Allocate the 50 million CU approved budget across the six Level-1 WBS elements and then allocate a sample portion to the selected work packages. The exact allocation is less important than internal consistency and explanation.

5. Time-phase those sample budgets in a way that reflects the delivery sequence. Include at least one legitimate early procurement payment and explain why its phasing differs from physical installation.

6. Define the progress measurement method for at least four different work types and identify the evidence required to claim progress.

7. Select three work packages and demonstrate complete traceability from scope to schedule, budget, responsibility and progress rule.

8. Introduce three deliberate defects: one scope item with no schedule activity, one cost profile inconsistent with the schedule, and one milestone held by an unjustified hard constraint. Identify each defect during a baseline-readiness review.

9. Assume management insists on the fixed public opening date even though your calculated schedule is two weeks late. Prepare a short note explaining the issue and three legitimate ways the project might respond without falsifying the baseline.

10. Produce a baseline approval record stating what version is approved, the effective date, the principal assumptions and how future forecast movement and approved changes will be handled.

What good performance looks like

The exercise is successful when the learner can demonstrate that the scope, schedule, cost, responsibility and progress rules all describe the same project; explain important differences in timing; identify deliberate integration defects; distinguish forecast movement from baseline change; and defend why the approved reference is credible enough to support control. A colourful baseline report on its own is not sufficient.

8. Bridge to capability

The How-to teaches how to establish and challenge an integrated baseline. At APPLIED and above, capability assessment should test whether the practitioner can reconcile realistic scope, schedule, cost, ownership and progress rules, identify contradictions and defend the approval basis. Baseline records, reconciliation checks and documented assumptions should substantiate the conclusion. Supporting work products are illustrative and should be assessed with the practitioner’s reasoning. Sample learning questions illustrate the judgement at each recognition level; they are discussion prompts rather than validated assessment items.

Learning question: Do you understand how an integrated baseline is established and protected?

Capability question for APPLIED and above: Can you demonstrate a coherent, traceable baseline and defend its readiness, assumptions and approval boundary?