Skip to content

Lesson 1 — Integrated Project Planning

At a glance

Learning objectives

By the end of this lesson you should be able to:

  1. Explain why a project plan is a set of interdependent decisions rather than a single document.
  2. Describe the components of an integrated plan and show how each one constrains the others.
  3. Explain what a baseline is, when it is set, and what changing one means.
  4. Choose an appropriate level of planning detail for a project, using rolling-wave planning.

Prerequisites

Introduction

Ask a room of developers what "the plan" is and you will get different answers: the schedule, the requirements document, the budget, or the thing nobody reads. All are partly right.

An integrated plan is the set of decisions that must agree with one another. Scope determines how much work exists; work determines duration and cost; cost and duration determine what risk is affordable; risk determines how much contingency you hold. Change one and something else must move. This lesson is about seeing the plan as one connected object — which is what makes it possible to say "we can do that, but here is what it costs us".

1. The plan is one connected set of decisions

The components of a project management plan are not independent documents. They are linked.

flowchart TD
    accTitle: How the parts of an integrated plan depend on each other
    accDescr {
    Scope leads to the work breakdown, which leads to the schedule, which leads to cost. Scope also
    leads to quality, and quality to cost. Cost then leads to risk and contingency, which feeds back
    into the schedule.
    }
    A[Scope<br/>what is included] --> B[Work breakdown<br/>how it is decomposed]
    B --> C[Schedule<br/>how long it takes]
    C --> D[Cost<br/>what it requires]
    A --> E[Quality<br/>how good it must be]
    E --> D
    D --> F[Risk and contingency<br/>what we can absorb]
    F --> C

Read the arrows as constrains. Scope constrains the work breakdown; the breakdown constrains the schedule; quality constrains cost, because better quality usually means more verification.

Analytics dashboard (illustrative)

A stakeholder of the analytics dashboard asks for the data to refresh hourly instead of daily. On its own that sounds like a configuration change. Following the arrows: hourly refresh increases the data pipeline's load (work), requires extra capacity (cost), raises the chance of undetected data errors (quality and risk), and adds integration testing (schedule). The integrated view is what lets you answer with a cost rather than a yes.

2. Baselines

A baseline is the approved version of scope, schedule, or cost against which performance is measured. A baseline is not a promise about the future; it is the reference point that makes "we are late" a meaningful statement.

Three things follow from that definition:

  • A baseline is approved, so it has an owner who agreed to it.
  • Performance variance is measured against it, which is how control works (Module 11).
  • Changing it is a deliberate, recorded act, not an edit.

If everything can be changed quietly, nothing can be measured — because there is no fixed point to measure from.

3. How much detail?

There is a real cost to planning: a detailed plan for work that will change is wasted effort and creates false confidence. There is also a real cost to under-planning: work is discovered late.

Rolling-wave planning resolves the tension: plan the near term in detail, keep the far term at a coarse level, and refine as you approach it.

Horizon Detail Purpose
Next few weeks Tasks, owners, estimates Day-to-day coordination
Next few months Milestones, dependencies, budget Decision-making and commitment
Beyond that Outcomes, major phases Direction and feasibility only

The refinement point is the key design decision: too early wastes effort, too late removes the benefit of having planned at all.

4. What the plan is for

A plan has three jobs, and knowing which one you are doing prevents over-planning:

  1. To think — the act of planning surfaces dependencies and risks nobody had noticed.
  2. To coordinate — the plan tells people what to do next and what others depend on.
  3. To compare — the plan is the reference for measuring progress.

A plan that only does job 3 has become a reporting artefact, and will be maintained for the wrong reason.

Key terms

Term Meaning
Project management plan The integrated set of documents describing how the project will be executed, monitored, and controlled
Integrated planning Ensuring the plan's components agree with one another
Baseline The approved version of scope, schedule, or cost used to measure performance
Variance The difference between planned and actual performance
Rolling-wave planning Detailing the near term while leaving the far term coarse
Contingency Time or budget reserved for known risks

Worked example

Task: build a one-page integrated plan for the illustrative analytics dashboard, then test it with a change.

Step 1 — Start from the charter's scope. Four increments: data connection, the first three measures, drill-down, and export. Success requires that the numbers are trusted.

Step 2 — Decompose and sequence. The data connection must precede every measure. Drill-down depends on at least one measure. Export is independent and can be dropped.

Step 3 — Estimate and cost. Six weeks of one developer at an illustrative 1 unit per week, so 6 units, plus 1 unit of contingency for the unknown data quality.

Step 4 — Identify the quality constraint that costs money. "Numbers are trusted" is not free: it requires a reconciliation check against a source system. Record it as work, not as an intention.

Step 5 — Test the plan with a change. The sponsor asks for hourly refresh. Trace the arrows: the pipeline needs rework (one week), capacity must be rented (0.5 units per month), and the reconciliation test must run more often (0.5 weeks). Total impact: 1.5 weeks and recurring cost.

Step 6 — Answer with the plan, not with a feeling. "Yes, that is 1.5 weeks and a recurring cost, and it delays the third measure. Which should I drop?" The plan has done its job: it turned a request into a choice.

Common misconceptions

“Planning is a phase”

The first plan is an estimate of the future. Planning continues as long as the project does, because the future keeps changing. A plan written once and filed is a historical document.

“More detail is better”

Detail costs effort and creates commitment to decisions made with less information. Match detail to the horizon, and refine near the horizon rather than far from it.

“A baseline cannot change”

Baselines change; what matters is that the change is deliberate and visible. A baseline that is silently edited is worse than no baseline, because it destroys the ability to measure.

Practical activity

Build a one-page integrated plan for an example project, then stress-test it.

  1. List the plan components and draw the dependency arrows between them as a Mermaid flowchart.
  2. State where the baseline will be set and who approves it.
  3. Choose a planning horizon and justify your choice in one sentence.
  4. Apply one plausible change request, and state its effect on scope, schedule, cost, and quality.

What "good" looks like: a change request whose consequences you can state in one sentence per dimension, and at least one component you realise you had not considered.

Self-assessment

  1. Why does quality constrain cost?
  2. What makes "we are two weeks late" a meaningful statement?

  3. A sponsor asks to add a feature "because it is only a small one". Using the integrated view, what is your response?

  4. Apply it — e-commerce platform. Two weeks before a launch window that is tied to a seasonal sales period, the business asks for a loyalty-points module. The plan has a fixed date, a fixed team of six, and a release gate that includes a security review. The team is already at capacity.

    Hint: A strong answer names at least three linked plan components, and says what has to be re-baselined and who may approve it.

Show answers
  1. Because achieving a stated level of quality requires specific work — reviews, testing, reconciliation, accessibility checks — and work costs money and time. Committing to a quality level is committing to the activity that produces it.
  2. A baseline. "Late" is only meaningful relative to an approved reference point; without one, the statement is a comparison against somebody's memory.
  3. Trace the arrows: identify which component of the plan the feature touches, then state the consequence — additional work, delayed milestones, reduced contingency, or reduced quality elsewhere. Offer the choice rather than absorbing the cost. "Small" is a description of the feature, not of its effect.
  4. The plan is one connected set of decisions, so with scope, time, and cost all fixed, the addition has to come out of the other two: quality (dropping or deferring the security review — not acceptable, and the gate is not yours to move), existing scope (defer something of lower value), or capacity (add people, which will not help inside two weeks because of ramp-up and coordination). It also touches risk: loyalty points mean a new data model and a financial-reconciliation concern that the current plan does not carry. So: put the request through change control, produce the impact analysis, let the business choose which of those it prefers, and if the baseline changes, re-baseline it deliberately at the agreed authority level and record the revision. Adding the module without changing anything is not one of the options.

Summary

  • A plan is a set of interdependent decisions; the linkages are what let you price a change.
  • A baseline is the approved reference that makes variance measurable, and changing one is a deliberate act.
  • Match detail to horizon: rolling-wave planning spends effort where it will still be useful.
  • A plan exists to think, to coordinate, and to compare — not only to report.

Further learning

Next

Continue to Module 04 — Agile, Scrum & Lean Delivery, and to Lab 01 — Writing a Project Charter if you have not yet produced a charter.