Episode 33: Plan and Manage Schedule
A schedule is not just a list of dates—it is the time-based model of how the project plan will unfold. It protects the sequencing of value delivery by making dependencies visible, defining when work should start and finish, and forecasting whether commitments are realistic. Without a schedule, scope and cost plans are blind because they have no temporal context. The project manager’s stance here must be one of realism and honesty, resisting the temptation to simply endorse “desired dates” without analysis. Forecasts should be transparent, with assumptions documented so they can be tested later. On the PMP exam, scenarios that describe impossible deadlines or ignored dependencies are usually testing whether you can recognize and enforce this discipline.
Building a schedule model starts with deriving activities from the work breakdown structure. Each deliverable is broken down into manageable tasks, which form the building blocks of the schedule. Milestones are added as key markers—events with zero duration that signify significant achievements, like design complete or product launch. Once activities and milestones are identified, they must be sequenced logically. Dependencies define how tasks connect: finish-to-start means one task must end before another can begin, while start-to-start allows tasks to begin together. Other less common types include finish-to-finish and start-to-finish. These relationships provide the skeleton of the schedule, ensuring logic reflects reality.
Dependencies can also include leads and lags. A lead means starting a successor task slightly earlier than strict logic would allow, while a lag introduces a delay between tasks. For example, you might allow testing to start two days before all coding is complete, representing a lead. Or you may insert a seven-day lag to cure concrete before construction continues. Calendars must also be considered: weekends, holidays, and working shifts influence start and finish dates. Constraints, such as “must finish by,” add external pressures. Documenting these assumptions is critical for later impact analysis. On the exam, assumptions left undocumented often hide the correct answer.
Estimating durations is the next step. One-point estimates assume a single best guess of how long a task will take, but this can be overly optimistic. Three-point estimates provide more realism by considering optimistic, most likely, and pessimistic durations. The expected duration can be calculated as a weighted average, often giving more weight to the most likely value. Expert judgment and historical data anchor these estimates in real-world experience, but optimism bias must be guarded against. Learning curves, resource experience, and risk responses may shorten or lengthen tasks. Transparency is key: every estimate should be tied to explicit assumptions and acceptance criteria.
Bias in estimating deserves emphasis because it is one of the most common pitfalls in scheduling. Teams often underestimate how long things will take, forgetting about integration, approvals, or learning curves. Overconfidence leads to brittle schedules that fail at the first slip. Three-point estimating helps reduce this risk by making uncertainty explicit, but it is only effective if assumptions are written down and tested. On the exam, stems that describe “the team is confident” or “stakeholders insist it will be done faster” are red flags. The correct answer usually involves re-estimating with transparency or performing risk analysis, not simply accepting aggressive dates.
Once activities are sequenced and durations are estimated, the schedule baseline can be established. This baseline is the approved version of the schedule that becomes the yardstick for performance. It must align with the cost and scope baselines to ensure integration across the project plan. Communication of the baseline requires appropriate visuals. A network diagram displays the logical relationships and critical path, helpful for analysis. A Gantt chart, by contrast, presents activities over time, making it more digestible for most stakeholders. Both views are valuable: one for the project manager’s analysis, the other for sponsor communication.
Establishing a data date and forecast convention is another subtle but important step. The data date is the point in time when actual progress is measured against the plan. Without a clear data date, variances cannot be interpreted consistently. Forecast conventions, such as how to handle partially completed tasks, must also be defined. Linking the schedule baseline to change control ensures that alterations are not made casually. Any proposed change to the schedule must undergo impact analysis across scope, cost, and risk, and only after approval is the baseline adjusted. PMI emphasizes that baselines are sacred; they cannot shift without governance.
Monitoring and controlling the schedule means constantly comparing actual performance against the baseline. Tracking progress requires updates to task status and recalculation of the network. A common error is to focus only on the critical path; near-critical paths also deserve attention because a small delay could push them into critical status. Issue and risk registers must remain linked to the schedule, because delays often arise from unresolved risks or unforeseen events. On the exam, correct answers often emphasize monitoring both critical and near-critical paths, not just the obvious one.
Managing slippage requires careful impact analysis. If a task runs late, the project manager must evaluate which paths are affected, what float is consumed, and whether downstream dates are jeopardized. Forecasts should be updated transparently, and ranges may be communicated where uncertainty remains. For example, instead of promising “the release will be ready June first,” it may be more realistic to say, “the earliest finish is late May, the most likely is early June, and the latest is mid-June.” This style of communication sets accurate expectations while respecting uncertainty. On the exam, answers that involve presenting ranges are often correct.
The role of communication in schedule control cannot be overstated. A late task is not just a scheduling detail—it may have cascading effects on cost, risk, and stakeholder trust. Communicating these impacts early gives sponsors options: adjust scope, reallocate resources, or accept schedule shifts. What is never correct is hiding slippage until the last moment or unilaterally promising impossible recovery. PMI expects project managers to treat schedule as a governance artifact, not a personal commitment. On the exam, look for answers that involve early communication, structured analysis, and documented options.
Schedule monitoring also involves integrating progress with earned value management in predictive projects, or throughput tracking in agile and hybrid settings. In predictive contexts, progress is measured against planned value and forecasted completion dates. In agile, velocity and burn charts become proxies for schedule health. The project manager must be able to interpret both: when governance demands baseline comparisons, and when agile transparency suffices. The exam often presents this as a translation challenge. The correct answer usually bridges these two worlds, ensuring governance is satisfied without breaking agile cadence.
Another important part of schedule management is linking risks directly to time. Many risks are schedule-driven: regulatory reviews, vendor delays, or resource availability. Proactively addressing them often involves inserting buffers or adjusting dependencies before they become issues. On the exam, look for subtle clues about risks that have not been accounted for. The correct choice often involves updating the schedule to reflect risk responses rather than ignoring them. PMI emphasizes that a schedule model is a living forecast, not a one-time guess.
Teams should also remember that schedules are political instruments as much as technical ones. Stakeholders will often push for dates that serve organizational priorities rather than realistic capacity. The project manager’s role is to defend realism with data. Network diagrams, historical evidence, and risk assessments provide the backbone for explaining why certain dates are achievable and others are not. On the exam, the correct answer is rarely to “agree to the aggressive date.” PMI stresses integrity: honesty about what is feasible, backed by transparent analysis, always comes first.
In summary, Part 1 of this task has shown how a schedule provides the temporal structure for scope and cost delivery. Activities are derived from scope, sequenced logically, estimated transparently, and baselined carefully. Monitoring focuses on both critical and near-critical paths, with communication of variances and risks done early and honestly. On the PMP exam, the traps are easy to spot: accepting impossible dates, ignoring dependencies, skipping documentation, or re-baselining without governance. The correct answers consistently involve realism, transparency, and structured analysis, which together define professional schedule management.
To understand schedule management deeply, we need to explore how networks and float work. A schedule network is a logical diagram of activities showing the sequence and dependencies. To analyze it, project managers perform what is known as a forward pass and a backward pass. In a forward pass, you calculate the earliest start and earliest finish times by moving from the project beginning to the end, adding durations as you go. The backward pass works in reverse, calculating the latest start and latest finish times by moving backward from the project completion date. Once both sets of numbers are known, you can determine float. Float is the amount of time an activity can slip without delaying the project.
Float can be calculated in two equivalent ways. You subtract the earliest start from the latest start, or you subtract the earliest finish from the latest finish. Either calculation produces the same number, which represents total float. Activities with zero float form the critical path, the chain of tasks that directly determines the project finish date. If any of these tasks slip, the whole project slips unless corrective action is taken. Activities with small but nonzero float are on near-critical paths, and project managers must watch them carefully because small slips could make them critical. PMI stresses that protecting schedule logic is more important than promising unrealistic dates.
When float is available, it must be managed responsibly. It is not “extra time” to waste, but a buffer that protects flexibility. For example, if a task has five days of float, it can slip by up to five days without affecting the project finish. That does not mean it should be delayed carelessly. Float belongs to the project, not to the individual task owner. On the exam, distractor options often misinterpret float as “slack that can be used freely.” The correct interpretation is that float must be managed strategically to protect overall project delivery.
Once the schedule network is understood, project managers may need to compress it to meet tighter deadlines. Two major techniques are crashing and fast-tracking. Crashing involves adding resources to shorten task durations. This may increase cost and sometimes risk, because more staff can mean more coordination complexity. Fast-tracking overlaps tasks that were previously sequential, allowing them to run in parallel. This may reduce schedule time but increases the risk of rework if dependent tasks are not truly independent. PMI emphasizes that the best approach is to choose the least risky and least costly option that still meets the goal.
Crashing often comes with diminishing returns. For example, doubling staff on a ten-day task may not cut it to five days because of training and coordination overhead. At times, it may only reduce the task to seven days while doubling cost. Fast-tracking, while attractive, must be used carefully. Overlapping design and development, for example, may lead to expensive rework if the design later changes. The PMP exam often tests whether you know which technique to apply. The correct choice usually involves analyzing trade-offs first, then applying the lowest-impact option that still preserves quality and compliance.
Agile and hybrid projects interpret schedule differently. In agile, cadence acts as the schedule baseline. The sprint or iteration length is fixed, and backlog order becomes the primary sequencing tool. The project manager monitors velocity and throughput trends to forecast delivery pace. Burn-up and burn-down charts show remaining work against time, while cumulative flow diagrams visualize bottlenecks. In predictive projects, milestones and stage gates drive schedule accountability. Hybrid approaches bridge the two, ensuring agile increments align with milestone reporting. On the exam, correct answers respect agile cadence while also honoring predictive governance in hybrid contexts.
Agile scheduling also emphasizes ranges rather than fixed dates. A release plan may state, “earliest finish is late June, most likely is mid-July, latest is early August.” This style acknowledges uncertainty and builds credibility. Hybrid projects require project managers to translate agile increments into milestone-based communication. This ensures executives see familiar reporting formats while the team works in agile cadence. On the exam, the correct answers are the ones that preserve cadence and transparency, not those that try to force agile teams into detailed predictive Gantt charts for every task.
Let’s examine a scenario. A sponsor requests that the launch date be pulled in by two weeks. One activity on the critical path is bottlenecked by a single scarce resource, while another path has a risky overlap opportunity. Options include fast-tracking the high-risk tasks, crashing non-critical work, conducting analysis and proposing a phased minimum viable product, or re-baselining immediately. The best next action is to analyze the situation first, propose a phased minimum viable product that still delivers benefits, and then selectively crash if needed, always seeking approval through governance. On the exam, the correct answer is rarely “re-baseline first.” Analysis and options must come first.
In agile, the same situation would be expressed differently. If stakeholders request earlier delivery, the product owner may re-order the backlog to deliver the highest-value items first, essentially creating a minimum viable product slice. The cadence remains fixed, but benefits are realized earlier. The exam sometimes disguises these scenarios with agile vocabulary. The correct answer usually emphasizes backlog reordering and benefit slicing, not over-promising or working unsustainably. PMI’s philosophy is consistent: urgency equals structured trade-offs, never haste.
Common exam pitfalls include approving date changes without analysis. This undermines governance and credibility. Another is misinterpreting float as extra time for individual tasks, rather than a project-level resource. Overlapping work without acknowledging rework risk is another trap. Finally, re-baselining prematurely is a frequent mistake. PMI expects baselines to move only after structured analysis, option exploration, and sponsor approval. On the exam, if an option involves re-baselining first, it is almost always wrong. The correct answers emphasize discipline and transparency.
Misunderstanding float is particularly common. Some assume that if a task has float, the resource can use it however they like. In reality, float belongs to the project and must be managed at the portfolio of tasks. If several tasks share float, careless use by one task owner may eliminate flexibility for the rest. On the exam, distractors often use language like “give the float to the resource.” The correct interpretation is to manage float strategically for the project as a whole.
Overlapping work without controls is equally dangerous. Fast-tracking can be effective, but only with safeguards like additional reviews, risk monitoring, and rework planning. Simply saying “start both tasks now” ignores the very risks PMI wants you to recognize. The exam often sets this trap. Correct answers involve acknowledging risks, mitigating them, and choosing overlap only when the cost of delay is greater than the cost of rework. This disciplined approach demonstrates maturity in schedule compression.
A quick playbook captures PMI’s expectations for schedule management. First, model logic clearly and honestly, with dependencies visible. Second, estimate transparently and baseline once. Third, track not just the critical path but near-critical paths, because risk often lives there. Fourth, analyze before acting: investigate slippage causes, compute float, and present options. Fifth, compress only with the least-risk and least-cost options, escalating to governance as needed. Finally, keep artifacts and assumptions updated so decisions remain traceable. On the exam, answers aligned with this playbook consistently reflect PMI’s philosophy of stewardship and discipline.
In conclusion, planning and managing the schedule is about far more than drawing charts. It is about building a logical, transparent model of how time flows through the project, estimating honestly, baselining responsibly, and monitoring continuously. Float and compression techniques give managers levers to adjust under pressure, but they must be applied with discipline. Agile and hybrid methods show that cadence and backlog order can serve as schedule anchors without losing accountability. On the PMP exam, the correct answers emphasize analysis before commitment, transparency before action, and discipline before shortcuts. This is what makes schedule management a cornerstone of project success.
