Key Concepts
Schedules are how projects communicate time: what starts when, what depends on what, and where the constraints are. A realistic schedule is the baseline that makes performance visible: without one, progress is subjective; with one, it is a matter of measurement. The form depends on the delivery approach, from Gantt charts to release roadmaps.
Schedules are how projects communicate time: when things will start, when they will finish, what depends on what, and where the pressure points are. A realistic schedule is not just a planning tool; it is the baseline that makes performance visible. Without one, progress is a matter of opinion. With one, it is a matter of measurement.
The form a schedule takes depends on the delivery approach. A predictive project tracks detailed activities against a Gantt chart. An agile project tracks features against a release roadmap and measures progress by what the team delivers each sprint/iteration. A hybrid project may do both. All three approaches require estimates, structure, a baseline, and a process for monitoring and adjusting as the project unfolds.
2.8.1 Prepare a Schedule Based on the Selected Development Approach
The delivery approach shapes everything about how a schedule is built and managed. Before creating any schedule artifact, the project manager needs to understand how this project will be delivered, because the tools and techniques that follow depend on that choice.
Schedule Management Plan
Predictive projects document their approach to scheduling in a Schedule Management Plan. This may be a standalone document or a section of the broader project management plan. It describes how activities will be defined and progressively elaborated, and typically includes:
- Accuracy of duration estimates: For example, activity estimates are plus or minus 20%.
- Units of measure: All estimates are in person-days.
- Control thresholds: Activities are deemed overdue two days past their scheduled completion date.
- Reporting formats: The project Gantt chart and network diagram will be updated weekly and published as PDFs on the project portal.
Having these agreements in place before scheduling starts means the team is working to consistent standards, and stakeholders know what to expect in project reports.
Agile Scheduling Approach
Agile projects use the product backlog and release plans to schedule work, typically organized around a release roadmap. This is a collaborative process: the product owner prioritizes the backlog and selects release candidates; the development team provides estimates, dependency information, and other inputs.
Agile schedules begin with estimates based on traditional approaches: bottom-up estimation of features, comparison to similar projects, or calculation based on story points. They then transition to evidence-based scheduling as the team’s actual production data accumulates.
Since agile teams exercise all development disciplines every iteration, each sprint produces real performance data. This data, net of interruptions, defect rates, and scope changes, makes future schedules progressively more accurate. Agile projects typically start with wide uncertainty in the schedule, then become considerably more predictable as velocity or throughput data builds.
Traditional approaches also refine schedules and plans as new data emerges. This is the core of progressive elaboration and rolling wave planning. What sets agile practices apart is having experience-based data about all activities and phases of development plus deployment gained in each iteration.
2.8.2 Coordinate with Other Projects and Operations
No project exists in isolation. Dependencies on other projects, shared resources, and hand-offs to operational teams all affect the schedule, and those effects run in both directions.
Update Programs and Portfolios with Forecasts
When a project is part of a program or portfolio, schedule changes need to be evaluated for ripple effects. A delay or acceleration on one project may or may not affect others; if it does, the overall impact on the program or portfolio could be significant. Project managers should share schedule information, including forecasts and potential delays, rather than holding it internal while hoping to recover.
Sharing news of a delay promptly lets the program or portfolio manager make informed decisions: adjusting sequences, reallocating resources, or resetting expectations with sponsors. Waiting until the delay is certain tends to make the wider impact harder to manage.
Agile teams manage cross-project dependencies through mechanisms such as the Scrum of Scrums, where representatives from multiple teams meet regularly to surface and resolve impediments that cross team boundaries. On larger programs using frameworks such as SAFe or LeSS, the Program Increment planning event surfaces dependencies across teams explicitly so they can be negotiated and tracked.
2.8.3 Estimate Project Tasks (milestones, dependencies, story points)
Before any schedule can be built, the activities and work packages that make up the project need duration estimates. These estimates are the raw material of scheduling.
Traditional Activity Estimation
In a predictive environment, activity estimates are developed by reviewing WBS work packages against the relevant planning documents. The process has two phases.
- Review the Schedule Management Plan for guidance on the approach.
- Review project assumptions and constraints.
- Review Enterprise Environmental Factors: any policies, procedures, or legislation inside or outside the organization that will affect scheduling.
- Review Organizational Process Assets: any plans, processes, and knowledge bases specific to scheduling.
Then, for each WBS element:
- Decompose the work package into its smallest component parts.
- Consult subject matter experts where further clarification is needed.
- Evaluate any activity constraints.
- Estimate the activity and record the result.
Agile Activity Estimation
Agile estimation zooms out to include the earlier project life cycle activities that shape the final schedule:
- Project scope is first explored using a vision exercise such as Design the Product Box.
- Feature workshops identify the majority (80% or more) of the product features. Rather than spending more time speculating about the rest, the team develops increments of a working solution to surface the remaining features.
- The candidate feature list is prioritized by the product owner into a product backlog.
- The product owner establishes an initial release plan, working with the development team to create high-level estimates for features and stories.
- Before each sprint or iteration, stories are refined and estimated in more detail.
Agile approaches accept that it is usually not possible to plan everything in advance on novel, complex, or high-change projects. Starting with a backlog that likely contains 80 to 90 percent of the final features means activity estimates need to include contingency. As the team works through the backlog, the velocity achieved each sprint, combined with observed rates of scope growth, is used to project completion.
Planning Poker
Planning Poker is a team-based estimation technique used by agile teams to size backlog items. Team members use cards with numbers from the Fibonacci sequence to represent relative size in story points. Each person selects a card privately, and all reveal simultaneously. Simultaneous reveal prevents early estimates from anchoring the group. Where there is spread, the outliers explain their reasoning and the team re-estimates. After a set number of rounds, or once estimates converge within an acceptable range, the team agrees on the estimate for that story.
Lean Pull Scheduling
Lean approaches do not use iterations; they pull items from a work queue continuously as capacity becomes available. Rather than producing detailed estimates for each work item, lean teams keep items to a similar size and measure throughput.
Throughput is the count of work items completed per day, week, or month. Cycle time is how long an individual item takes from start to finish. Using these two metrics, lean teams can predict when work will complete and assess the impact of process improvements without building detailed activity estimates.
2.8.4 Utilize Benchmarks and Historical Data
Good estimates start with good data. Historical data from past projects provides a reference for how long similar work has taken, and industry benchmarks can supplement what the organization has on record internally.
Organizational Process Assets and Lessons Learned
Predictive projects draw on Organizational Process Assets (OPAs) such as previous project plans, published industry benchmarks, and risk and issues logs from other projects. Lessons learned registers contain time-estimating insights, both successes and costly underestimates, that directly improve current estimates.
For example: if permits and approvals have consistently taken two months on similar projects, it makes sense to schedule at least two months for the same process now. When activities closely mirror work done on previous projects, historical actuals are more reliable than fresh estimates built from scratch. However, when the work is substantially new, historical data from other projects becomes much less useful, and the team’s own emerging performance data becomes the better source.
Analogous Estimation
Analogous estimation uses data from a comparable past project to set the estimate for the current one. The estimate is adjusted up or down based on known differences in scope, complexity, or team capability. It is faster than bottom-up estimation and useful when detailed information is not yet available.
The limitation of analogous estimation is that no two projects are identical. The closer the historical project is to the current one in type, size, and context, the more reliable the analogy. Where the comparison is weak, use the analogous estimate as a sense check rather than a primary basis.
Agile Velocity and Lean Throughput
For agile teams, historical velocity data provides this analogous estimate. Past throughput, measured in story points per sprint or work items per week, gives a calibrated basis for release planning: one grounded in actual team performance rather than aspiration.
However, rather than comparing from previous projects, agile and lean teams accept that most knowledge-work projects are unique and difficult to connect to historical data from. The better approach is to start the project, observe actual performance, and use that data to forecast forward.
Velocity measures the amount of work (typically in story points) a team completes per sprint/iteration. It reflects actual capacity, including interruptions for meetings, support, and defect fixes, so it captures real-world performance rather than ideal-case estimates. As velocity data accumulates across sprints, it becomes the primary input for forecasting remaining work.
Teams using a lean approach use throughput instead: the number of similarly sized work items completed per period. Both metrics become more valuable as the project progresses. At the start of a project, there is no recent performance to draw on. After three or four sprints, velocity or throughput data from this project is more relevant than any benchmark from a different one.
2.8.5 Create a Project Schedule
With estimates in hand and the delivery approach established, the project can build its schedule. The format depends on the approach.
Gantt Chart
A Gantt chart is a bar-chart view of the project showing activities, durations, milestones, and their relationships. Gantt charts also typically show resources assigned to each activity and percent complete information. They are the most commonly used scheduling format for predictive projects, and most project management information systems generate them from an activity list and duration estimates.
Milestone Chart
A milestone chart summarizes the major milestones of a project, usually on a single page. Milestones are points in time, not activities: they have no duration of their own, but they mark the completion of a significant phase or deliverable. Milestone charts are useful for senior stakeholders who need a high-level view of progress without the detail of the full schedule.
Network Diagram
Network diagrams show the schedule with start and finish dates for activities and the logical relationships between them. They make interdependencies visible and can reveal opportunities to compress the schedule.
Critical Path
Activities on a project often happen in parallel, so the total project duration is not simply the sum of all activity estimates. If two parallel paths of work begin at the same point, one taking 7 weeks and one taking 9 weeks, the project cannot finish until the longer path is complete. This longest path through the network is the critical path.
The critical path is critical because any delay to an activity on it will delay the project finish date by the same amount. A delay to a non-critical activity that has available float may have no effect on the finish date at all. Ironically, the longest path through the network also represents the shortest time the project can possibly be completed in.
Float
Activities not on the critical path have some scheduling flexibility. Float (also called slack) is the amount of time an activity can be delayed without delaying the project finish date or subsequent activities. Two types apply:
- Free Float: The time an activity can be delayed without affecting the earliest start date of any activity that follows it.
- Total Float: The maximum time an activity can be delayed before it affects the project finish date.
The network diagram above shows that Activity 2 happens in parallel with Activity 3 and takes one week less to complete. So, we could start late or run over 1 week without a scheduling problem.
Also, since the following activity, Activity 4 is 3-weeks long, we could delay Activity 2 by up to 2 weeks before that top path now becomes the critical path. This first kind is Free Float. It is the time we can delay by without impacting any subsequent task’s earliest start dates. A two-week delay for Activity 2 is its Total Float, the maximum time it could be delayed by before delaying the project finish date.
Understanding float helps project managers identify where flexibility exists in the schedule and where it does not.
Dependencies
Activities have logical relationships. The relationship indicates if the start or finish of an activity is dependent on the start or finish of another activity. For example, a building inspection cannot start until the workers have finished building the walls and roof. This is an example of a mandatory dependency, but there are others.
- Mandatory – Contractually required or inherent in the nature of the work. E.G. By law, we cannot start the drug trials until we have finished experimenting with the formula.
- Discretionary – Based on knowledge or best practice. E.G. We should not move our belongings in until the lease is signed.
- External – Related to non-project activities. E.G. We are waiting for the 3D printers to be delivered before we begin printing prototype products.
- Internal – Based on things within the project team’s control. E.G. We will wait for Bill to finish Activity A before asking him to start on Activity B.
Precedence Relationships
While we can start moving into a home before it is fully finished, we cannot start wearing new shoes before we receive them. Activities have logical dependencies, as shown below:
Dependencies between activities take four forms:
- Finish to Start (FS): Activity 2 starts after Activity 1 finishes. This is the most common relationship. After the foundation is cured, building the walls begins.
- Start to Start (SS): Activity 2 can start once Activity 1 starts. Building screen prototypes and evaluating the user interface can begin in parallel once the first has started.
- Finish to Finish (FF): Activity 2 cannot finish until Activity 1 finishes. System changes and regression testing must both conclude together.
- Start to Finish (SF): Activity 2 cannot finish until Activity 1 starts. This is rare; it typically applies to handovers where one team picks up as another finishes.
Previously the PMP® exam contained questions requiring the calculation of float and critical path. Many of these calculations have been dropped in the new exam and instead it focuses on testing understanding of why and when to perform these calculations. So, be prepared to answer questions that test your understanding of the Where, When, Who and Why ideas more than How-to.
Agile Scheduling
In agile projects, the product owner creates a Product Roadmap showing features targeted for upcoming releases. There is no single standard format; what matters is that it shows which features are planned for which releases, and in what priority sequence.
There is no single format for a Product Roadmap, and some examples are shown below:
Product roadmaps show features and capabilities planned for releases. These releases are typically delivered by iterations of work that contain features and user stories pulled from the product backlog as shown below.
Within the hierarchy of releases, features, user stories, and tasks, user stories are the lowest business-understandable unit of work. They are the items the team can discuss, estimate, and demo to the product owner for acceptance. Tasks are the technical sub-units below user stories; they may not be business-readable, but they make the work estimable and assignable.
If we were developing a Netflix-type movie streaming service, we might have user stories about searching for movies by genre, actor or filming location. User stories are typically broken down further into tasks that get estimated by the team. These tasks may not be business-understandable, such as what database structures and indexes we should use to support the movie search requirements.
Iteration-based scheduling
During sprint or iteration planning, the team estimates the work selected by the product owner. They should know how much they can deliver by comparing the total size of the work selected (perhaps in story points) with how much work they could complete in previous sprints/iterations.
Flow-based scheduling
Flow based agile aprpoaches do not use sprints or iterations. Instead, the team just keeps pulling items from the backlog as they get capacity. They keep work items at a similar size, then use cycle time and throughput to predict completion. Without iteration boundaries, teams pull items from the queue continuously and track how long each takes from start to finish.
Acknowledging the Quality of the Input Data
These agile approaches lack the numerical precision and mathematical logic of traditional scheduling approaches. For example, there is no critical path calculation, no analysis of float, and less precedence weighting. These traditional techniques do work for agile projects, but we need to consider the quality of the input data and the frequency of changes.
In high-change project environments, activity estimates are often today’s best guess. Applying detailed mathematical scheduling to a collection of guesses can produce plans that look precise but change completely when the product owner reprioritizes after the next demo. Agile approaches embrace this by using remaining work divided by average rate of progress as a continuously updated forecast, rather than a fixed plan.
2.8.6 Baseline a Project Schedule
A schedule baseline is the approved version of the schedule model, used as the reference point for all future performance measurement. Without a baseline, there is nothing objective to measure against: every comparison between “what was planned” and “what happened” requires agreement on what was planned, and that agreement is what baselining establishes.
The schedule baseline is formal. It requires approval from the relevant authority, typically the sponsor or steering committee, before it becomes the reference version. Once approved, it cannot be changed without going through the change control process. This protection is deliberate: it prevents the baseline from drifting informally to match actual performance, which would make the schedule look perpetually on track while hiding real problems.
What the Schedule Baseline Captures
The schedule baseline records the planned start and finish dates for each activity and milestone, the critical path, and the float on non-critical activities. It is recorded at the point of approval, so there is a clear record not just of what was planned but of when the plan was agreed.
Protecting the Baseline
There can be pressure to adjust the baseline when performance slips, rather than treating the slip as a variance to be managed. A project manager who updates the baseline every time an activity runs late is not managing a schedule; they are rewriting history. Changes to the baseline must go through the formal change control process, and approved change requests that affect the schedule trigger a corresponding baseline update.
Agile projects do not typically maintain a fixed schedule baseline in the same way. The product roadmap and release plan evolve as the backlog is reprioritized and velocity data accumulates. Progress is measured against the original scope and date targets established at the start of a release, but the mechanism is different: burn-down and burn-up charts show remaining work and scope, not variance from a fixed baseline. Hybrid projects may maintain a formal schedule baseline for the predictive workstreams while managing agile workstreams against release targets.
2.8.7 Execute a Schedule Management Plan
Once the schedule is built and baselined, the project manager runs the process defined in the schedule management plan: tracking actual progress, comparing it to the plan, and reporting results to the appropriate stakeholders.
Traditional Progress Tracking
Predictive projects track progress against the approved baseline. If the project falls behind, corrective action is required. This approach works well when the upfront plan is reasonably reliable.
Tracking Gantt Chart
A Gantt chart updated with actual progress shows which activities have started, which are complete, and which are running late, with a visual read-across to the original planned timeline. Percent complete figures roll up to give an overall view of project progress.
Earned Value Management for Schedule
Earned Value Management (EVM) provides a quantitative view of schedule performance. The Schedule Performance Index (SPI) measures schedule efficiency as earned value, the budgeted value of work actually completed, divided by planned value, the budgeted value of work that was scheduled to be done by this point. An SPI of 1.0 means the project is exactly on schedule. An SPI of 0.85 means it is progressing at only 85% of the planned rate.
Unlike previous versions of the PMP® exam, the new version has fewer earned value calculations. While previously candidates could expect a question or two requiring manipulating the EV formulas, the new exam focuses on testing understanding of why and when to use earned value analysis. So, understand the principles, work through some example calculations. However, be prepared to answer questions that test your understanding of the Where, When, Who and Why ideas more than How-to.
Agile Progress Tracking
Agile teams acknowledge that initial plans are likely to change, since they were made when the project team knew least about the work. Tracking tools for agile projects need to handle reprioritization and scope evolution rather than just deviations from a fixed plan.
Release Burndown Graph
A release burndown graph shows estimated work remaining over time against a projected completion rate. The planned completion rate appears as a reference line; actual completion is plotted as work progresses. If the actual line trends above the reference line, more work remains than expected, and the project is at risk of a late finish. The team can see that risk materializing well before the deadline.
The example above shows the planned completion rate by the dotted blue line and the actual completion rate shown with the solid red line. Extrapolating the red line currently suggests the project will finish slightly late.
Cumulative Flow Diagram
A Cumulative Flow Diagram (CFD) shows the rate of work completion and, critically, any scope growth. Work in different states, such as not started, in progress, and completed, is shown as stacked bands over time. If the total-scope band is growing, scope is being added.
The gap between the in-progress and completed bands shows how much work is in flight at any point, which is a proxy for cycle time. Extending the completed-work trend line to meet the total scope line gives a projected finish date based on current performance.
2.8.8 Analyze Schedule Variation
Stuff happens, plans change, and we need to deal with it. Therefore, a crucial part of the success of running any project is having a plan to update the plan. In other words, knowing how we will deal with all the changes that are inevitably going to happen.
Traditional Approaches to Schedule Variation
Predictive projects manage variation by comparing actual performance to the baseline and initiating corrective action when deviations exceed the thresholds defined in the schedule management plan. Two planning concepts support adaptive scheduling throughout the project.
Rolling Wave Planning
Rolling wave planning is an iterative planning technique in which near-term work is planned in detail and work further in the future is planned at a higher level. This avoids creating overly detailed plans for periods that are likely to change. As the project moves forward, the next wave of work is planned in detail while the horizon beyond it stays at a summary level.
Progressive Elaboration
Progressive elaboration is the practice of adding more detail to plans as more information becomes available. When new information emerges that affects the plan, the plan is updated to reflect it. Used with rolling wave planning, progressive elaboration keeps plans at appropriate levels of detail and current when reality requires a change.
When corrective action cannot recover the deviation, a formal change request is needed to update the schedule baseline. Without that formal step, the baseline becomes meaningless as a reference.
Schedule Compression Techniques
When the schedule needs to be shortened, two main techniques are available.
Crashing
Crashing adds resources to critical path activities to shorten their duration, accepting a higher cost in exchange for a shorter schedule. Crashing only helps on critical path activities; adding resources elsewhere does not shorten the overall project.
Fast Tracking
Fast tracking overlaps activities that were originally planned in sequence, starting a later activity before the preceding one is fully complete. Fast tracking does not add cost but increases risk, since problems in the predecessor activity may affect the successor that has already started.
Agile Approaches to Schedule Variation
Changes are expected on agile projects. Several mechanisms built into the agile life cycle address them directly.
Frequent Demonstrations
Frequent demos bring sponsors and customer representatives together regularly to review the evolving product. This surfaces changes early, when they are comparatively cheap to incorporate, rather than late when they are expensive.
Backlog Reprioritization
Backlog reprioritization handles incoming changes by adding them to the backlog and reordering priorities. Well-written user stories with minimal interdependencies make reprioritization easier and reduce knock-on effects.
Short Planning Cycles
These limit detail to the near term. Only the next sprint is planned in full; beyond that, the backlog holds items at various levels of readiness. This rolling approach naturally limits the waste of planning work that will change before it is executed.
Product Owner as Change Authority
The PO evaluates, approves, and sequences all changes to the backlog. This works well when the product owner is engaged and knowledgeable; project managers can support it by reinforcing the significance of the role.
Frequent Retrospectives
Retros give the team a forum to surface what is working and what is not. In high-change environments, retrospectives also identify process problems slowing the team down and generate experiments to try in the next sprint.
Deliverables and Tools
Schedule Management Plan – A component of the project management plan defining how the schedule will be developed, maintained, reported, and controlled.
Project Schedule – A model presenting linked activities with planned dates, durations, milestones, and resource assignments.
Schedule Baseline – The approved version of the schedule model, used as the reference for performance measurement. Changes require formal change control.
Gantt Chart – A bar-chart schedule showing activities, durations, dependencies, and milestones.
Milestone Chart – A high-level summary of major project milestones for senior stakeholder use.
Network Diagram – A diagram showing the logical sequence and dependencies of project activities, used to identify the critical path.
Critical Path – The longest sequence of activities through the project network, determining the shortest possible project duration.
Float (Slack) – The amount of time an activity can be delayed without affecting the project finish date.
Product Roadmap – An agile artifact showing features and capabilities planned for upcoming releases.
Planning Poker – A team-based agile estimation technique using Fibonacci-sequence cards to size backlog items.
Velocity – The amount of work, measured in story points, that an agile team completes per sprint.
Throughput – The count of work items completed per period in a lean or flow-based delivery approach.
Release Burndown Graph – A chart showing estimated work remaining against a projected completion rate.
Cumulative Flow Diagram (CFD) – A chart showing rates of work completion and scope growth over time.
Lessons Learned Register – A repository of scheduling insights from current and past projects.
Related Topics
- 2.1 Develop an integrated project management plan and plan delivery
- 2.2 Develop and manage project scope
- 2.4 Plan and manage resources
- 2.6 Plan and manage finance
- 2.9 Evaluate project status
- 3.3 Manage and Control Changes
- 3.2 Manage project compliance
- 1.8 Plan and manage communication
- 2.3 Help ensure value-based delivery
- 2.7 Plan and optimize quality of products and deliverables
FAQ
Why does a schedule matter?
It is the baseline that makes performance visible; without one, progress is a matter of opinion.
Does the form depend on the delivery approach?
Yes. Predictive projects track detailed activities against a Gantt chart, agile projects track features against a release roadmap, and hybrid projects may combine both.
What does a schedule communicate?
When things will start and finish, what depends on what, and where the pressure points are.
