4.8. Plan and Manage Schedule
💡 First Principle: A schedule is only as reliable as the estimation technique and dependency logic behind it — this task tests whether you select the right estimating and sequencing approach for the selected development approach, then actively maintain the schedule as reality diverges from plan.
Enablers: prepare a schedule based on the selected development approach, coordinate with other projects and operations, estimate project tasks (milestones, dependencies, story points), utilize benchmarks and historical data, create and baseline a project schedule, execute the schedule management plan, and analyze schedule variation.
Notice "story points" sitting alongside "milestones" and "dependencies" in the same enabler — the 2026 ECO explicitly expects schedule competency across both predictive (critical path, dependencies, baselines) and agile (story points, velocity-based forecasting) techniques, not one or the other.
Building a predictive schedule
The sequence is tested directly: define the activities (the activity list and milestone list), estimate their durations and dependencies, sequence them into a network, develop and baseline the schedule, then execute the schedule management plan and monitor for variance. The schedule baseline is the approved version and changes only through formal change control. A milestone is a zero-duration point that marks progress; a deliverable is a work product. Detail grows through progressive elaboration — near-term work planned finely, later work roughly — rather than pretending to know everything on day one. The charter's summary milestones and the lessons learned of earlier projects are your starting inputs.
"Coordinate with other projects and operations" is where many schedules quietly fail. A scarce specialist shared with another project, a maintenance window owned by operations, or a vendor delivery date are all constraints your network must reflect. Identify where a scarce skill can come from — another department or an outside vendor — and when it is actually available before you commit dates that depend on it. Benchmarks and historical data from the organization's lessons learned repository are what turn an estimate from a guess into a defensible number.
Dependencies, leads and lags
Two separate questions describe any dependency: why it exists, and how the two activities connect.
| Why it exists | Meaning |
|---|---|
| Mandatory | Legally or contractually required, or inherent in the work — the wall before the roof |
| Discretionary | Chosen from best practice or preference — can be changed to compress the schedule |
| External | Links project work to something outside the project, such as a permit or another project |
| Internal | Between activities inside the team's control |
The connection is finish-to-start (the default), start-to-start, finish-to-finish, or the rare start-to-finish. A lead lets a successor start early; a lag forces a wait, such as concrete curing.
⚠️ Exam Trap: "Bring the next feature forward and work it in parallel, but keep the release order" is a lead with a finish-to-finish relationship — the lead pulls the start earlier, and finish-to-finish stops the second feature finishing before the first. A lag moves work later, never earlier.
Critical path and float
The critical path method finds the longest path through the network, which sets the shortest possible project duration. Activities on it have zero total float — the time an activity can slip without delaying the project end date. Free float is the slip allowed without delaying the next activity. Delay a critical activity and the finish date moves.
Estimating techniques
| Technique | How it works | Best when |
|---|---|---|
| Analogous | Compare with a similar past project or feature as a whole | Early, little detail, a credible precedent exists |
| Parametric | Multiply a unit rate by quantity — cost per square foot, hours per function point | A reliable statistical relationship exists |
| Three-point / PERT | (O + 4M + P) / 6, standard deviation (P − O) / 6 | Uncertainty should be expressed as a range |
| Bottom-up | Estimate each work package, then sum | Scope is decomposed; most accurate, most effort |
Early estimates should be honest ranges. A rough order of magnitude estimate commonly runs −25% to +75%, so 26 weeks of initial analysis is reported as roughly 20 to 45 weeks, not "26 weeks" and not a falsely tight 24 to 28. When a lead developer has built a near-identical feature that took four months, that analogy outweighs an optimistic six-week team guess. Record the beliefs underneath an estimate — "the third-party system uses the same language" — in the assumption log, so they can be validated later.
Compressing and balancing the schedule
Schedule compression shortens duration without cutting scope. Crashing adds resources for the least incremental cost; fast tracking overlaps activities normally done in sequence, adding risk and rework but no direct cost. Resource leveling resolves over-allocation and may lengthen the critical path; resource smoothing adjusts only within available float, so the end date holds.
⚠️ Exam Trap: "Finish sooner, but there is no more money" rules out crashing — the answer is fast tracking. And resource leveling is not a compression technique at all; it usually extends the schedule.
Critical chain project management plans around resource constraints and strips padding from individual tasks into shared buffers: feeding buffers where a non-critical chain joins the critical chain, and a project buffer at the end of the critical chain, before the finish date.
Adaptive planning: roadmaps, iterations and time boxes
Agile teams still schedule — they plan adaptively in layers. The reason adaptive planning suits uncertain work is that a business representative continually re-prioritizes the next pieces by value while the team delivers usable increments, prioritized, built and tested in small slices. Frequent feedback catches wrong assumptions early, and working software is the primary measure of progress — not one large release at the end. A product roadmap gives sponsors the medium- to long-term view across quarters; a release plan shows which features land in which release, and is the right answer when a customer asks an agile team for "a schedule." Features are broken into user stories — short descriptions from the user's perspective, written as Card, Conversation, Confirmation, and carrying a description, priority, estimate and acceptance criteria. An iteration or sprint is a time box: a fixed period, typically one to four weeks, that is not extended.
Prioritization decides what makes the cut. MoSCoW sorts items into Must have, Should have (important, but the release is viable without it), Could have and Won't have this time; ordering by value against cost and delivering until time or money runs out is the same idea. A time-boxed spike investigates a problem blocking progress, and deliberate slack — a refactoring card that can be displaced by an emergency — protects the plan.
In Scrum, sprint planning starts with the product owner walking the refreshed backlog so the team reaches shared understanding; the sprint ends with the review, then the retrospective. The artifacts are the product backlog, sprint backlog and increment — a change control board is not a Scrum event.
Relative estimating and velocity
Agile teams estimate relatively: find the smallest story, size it, and size everything else against it in story points. Planning poker reveals estimates simultaneously; when they diverge (3 versus 8), the high and low estimators explain their reasoning and the team re-votes. If the team starts converging in seconds without discussion, they are anchoring — the technique has decayed into groupthink. Under high uncertainty, or to size a large backlog fast, T-shirt sizing and affinity estimating group items into relative buckets.
Velocity is the points completed and accepted per iteration. It takes a few sprints to establish, sets how much work the team selects, and grounds conversations with anyone demanding more — show the velocity and ask them to prioritize. When velocity ranges from 25 to 35, plan around 25 to 30, not the peak; a team that carries over the last 10% of every sprint, from different items each time, is simply overcommitting.
⚠️ Exam Trap: Comparing velocity across teams. Points are relative to each team's own baseline, so the same work earns different numbers on different teams — velocity forecasts one team's pace and ranks nobody.
Flow-based scheduling with Kanban
Kanban visualizes the workflow, limits work in progress, and lets the team pull new work only when it has capacity. When too much is in progress and throughput is falling, the fix is a WIP limit and a focus on reducing cycle time — visualize the system first, with a Kanban board or value stream map, before redesigning it. A flow team forecasts by projecting its average throughput forward, and reads cycle time to see how fast cards finish once started. Low-tech boards are deliberate visual management, and manual work-categorizing for a PMO is non-value-add effort best automated.
Analyzing schedule variation
Monitoring means comparing actual progress with the baseline and reporting honestly. A one-week slip that nudges a risk upward but keeps it inside tolerance is recorded in project reporting and raised at the next status meeting — not escalated as a crisis, and not hidden.
⚠️ Exam Trap: Applying predictive scheduling vocabulary (critical path, float, baseline) to a scenario that's clearly agile/iterative, or vice versa. Match your terminology and technique to the development approach the scenario describes.
