Project Management Fundamentals (Lesson 5): Scheduling and Progress Control

When allocating resources to tasks, we must distinguish between work effort and duration. Work effort is the total person-hours required to complete a task—how much human time the job consumes in total. Duration is the elapsed calendar time from task start to finish, determined by how resources are deployed. A single person can compress duration by concentrating effort, or spread it over time by part-timing; conversely, adding parallel workers can shorten duration but requires task divisibility and introduces coordination overhead.

Paint a room that needs 40 person-hours of work. One person working full-time completes it in 5 calendar days. Two people splitting the effort might finish in 2.5 days. But not all tasks scale linearly. Some gain speed from added hands; others suffer from communication overhead and diminishing returns—hence the saying "too many cooks spoil the broth." This mismatch between effort and duration shapes resource decisions: compressing duration costs more and risks inefficiency; reducing resources extends duration and surfaces scheduling risk early enough to replan or negotiate scope.

Four Dependency Types Shape Task Sequence

Reliable scheduling depends on understanding how tasks relate. Four dependency types appear in nearly every project:

• Finish-to-Start (FS): The most common. Task B cannot start until Task A ends. Examples: a race must conclude before the awards ceremony begins; prerequisite knowledge must be acquired before an exam.
• Start-to-Start (SS): Task B can start once Task A begins; both proceed in parallel. Example: concrete curing can start as soon as ground preparation begins. Useful when work can overlap safely.
• Finish-to-Finish (FF): Task B cannot finish until Task A finishes. Example: document review must complete when document authoring does. Applies when two tasks must conclude together.
• Start-to-Finish (SF): Rare but real. Task B cannot end until Task A starts. Example: the night-shift guard can only leave once the day-shift guard arrives. Typical of handoff scenarios.

Gantt charts represent these relationships as arrows connecting tasks. Recognizing which type applies to each pair of tasks prevents logical contradictions and unfeasible parallelism.

Milestones Mark Major Events

A milestone is a zero-duration marker of a significant date or event—project kickoff, phase completion, critical delivery, project close. Unlike ordinary tasks, milestones carry no work effort or duration; they simply flag a point in time. Imagine them as signposts on a journey: reaching each one signals completion of a phase and clarifies how much road remains.

Milestones concentrate stakeholder attention. A project typically opens and closes with one. Intermediate milestones mark stage boundaries: requirements frozen, design approved, testing complete. These points trigger progress reviews and highlight when delays threaten a deadline. Gantt diagrams display milestones as diamonds or flags, making them visually distinct from work tasks.

When a task sequence threatens to miss a milestone, the project manager receives early warning and can act. Disciplined use of milestones helps teams track critical objectives and proceed in stages toward defined goals.

Building Realistic Schedules

Many schedules fail because planners ignore constraints and real-world friction. A workable plan must account for:

Resource availability. Team members cannot dedicate 100% effort. Vacation, training, and standing duties consume time. Ignoring actual available hours creates illusory tightness; the plan looks feasible on paper but collapses in execution.

Variability in individual productivity. Different people work at different speeds. Even 8-hour days yield different output. New team members have a learning curve. Estimate duration using historical data or analogous task experience; avoid inflated optimism.

Task-switching cost. A person assigned to two tasks simultaneously often falls behind on both. Switching contexts demands refocus time, degrading quality and extending completion. Parallel assignment does not equal parallel progress; it typically means sequential delays. Minimizing multitasking or providing buffers between tasks improves throughput.

Resource contention. Multiple tasks competing for the same specialist, tool, or equipment create queues in reality. A plan that shows two tasks happening "at the same time" but depending on one scarce resource is not a plan—it is fiction. Check resource loading when scheduling and resolve over-allocation by reordering, adding resources, or adjusting dates.

Buffer for uncertainty. Requirements shift. Technical obstacles arise. External dependencies slip. A schedule with no slack breaks at the first disruption. Reasonable buffers—a few days before critical milestones—absorb foreseeable delays and preserve feasibility.

Effective planning requires the project manager to communicate with the team, validate task loads for balance, confirm dependencies for logic, and watch for over-constrained critical paths. Rolling-wave or rolling-horizon planning—refining near-term work in detail while keeping distant work flexible—helps keep the schedule synchronized with reality.

Critical Path: The Schedule's Backbone

In complex projects, the critical path is the longest chain of dependent tasks from start to finish. It determines the minimum time to complete the entire project. Delay any critical-path task and the project end date slips. Delay a non-critical task by up to its float (slack) without affecting the overall deadline. This makes the critical path the project's "lifeline" and the focus of risk management.

A familiar analogy: In Chinese tradition, the pilgrimage to the West took fourteen years. Monkey, pig, and sand demon could travel fast, but the human monk walked step by step. The team finished only when the slowest member completed his journey. The monk's route was the critical path—the overall duration depended on the longest leg, regardless of others' speed.

To identify critical tasks, compute float: the delay a task can tolerate without shifting the project end date. A task with zero (or near-zero) float is critical; any slip delays the whole project. Calculate each task's earliest and latest start/finish times using forward and backward pass; the difference is float. Zero-float tasks lie on the critical path.

A project may have multiple critical paths of equal length; any slip on any of them delays completion. After identifying the critical path, the manager prioritizes tracking these tasks, allocates resources preferentially, and escalates risks early.

Critical paths are not static. If a non-critical task overruns its float, it enters the critical path. If a critical task finishes early, the critical path may migrate to another chain. Dynamic monitoring during execution ensures timely intervention.

Critical Chain: Accounting for Resource Limits

The classical critical path assumes unlimited resources. Reality imposes constraints: one person cannot simultaneously full-scale two tasks. When the bottleneck is resource capacity rather than pure logic, critical path analysis alone is insufficient.

Critical Chain Project Management (CCPM) evolves the critical path method by integrating resource constraints. First, draw the project network based on task logic. Next, layer in resource availability; reschedule to respect resource limits. The resulting longest chain of resource-constrained tasks is the critical chain—a "resource-bounded critical path" that reflects real constraints.

CCPM then does something distinctive: it extracts the safety buffer embedded in task estimates. Teams typically pad estimates defensively; CCPM encourages realistic, aggressive estimates and pools the extracted slack into explicit buffers. This circumvents two human tendencies: Parkinson's Law (work expands to fill the deadline) and Student Syndrome (procrastination until the last moment). Rather than hiding margin in every task, CCPM centralizes buffer management.

CCPM employs three buffer types:

• Project Buffer: Placed at the end of the critical chain, this absorbs task overruns and protects the project delivery date.
• Feeding Buffer: Inserted before non-critical chains feed into the critical chain, preventing delays on secondary paths from cascading.
• Resource Buffer: A reminder or wait slot between critical-chain tasks that require resource handoff, ensuring the next resource is available and ready.

Execution requires the manager to monitor buffer burn. A project buffer running low while work remains signals escalating risk. Compared to traditional methods, CCPM asks team members to complete their task as quickly as feasible (knowing there is no hidden slack), while the manager centrally monitors and manages risk reserves. Practitioners report improved schedule adherence and compressed timelines.

Schedule Compression: Fast Tracking, Crashing, and Scope Reduction

Even careful planning meets tight deadlines. Three techniques compress schedules; each carries trade-offs:

Fast Tracking: Overlap or parallelize tasks normally done sequentially. Example: start development while design is still in progress, rather than waiting for design to finish. No added cost, since no extra resources are consumed—only reordering occurs. Risk rises because changes to early work force rework in parallel tasks. Suitable when work can overlap and teams can tolerate coordination overhead. Most appropriate when deadlines are urgent and budget is fixed.

Crashing: Invest more resources to shorten task duration—more staff, overtime, upgraded equipment, expedited services. The cost per unit of time saved is highest early and falls as more resources are added, until diminishing returns set in. Not every task responds to resource injection; some tasks, like creative or knowledge work, resist compression. Crashing is selective: identify which critical-path tasks justify the cost and apply resources where they yield the most schedule gain. Suitable when additional budget is available and resource-intensive tasks form the bottleneck.

Scope Reduction: Eliminate or defer lower-priority requirements and features. This shrinks the work directly, shortening the schedule. The trade-off is reduced deliverable value and potentially reduced customer satisfaction. Use as a last resort, negotiated with stakeholders: if the deadline is immovable and other methods are exhausted, trading scope for schedule may be the only path. Also reduces cost but requires explicit stakeholder approval.

Important caveat: schedule compression only shortens the overall timeline if applied to the critical path. Accelerating non-critical work does not change the end date. Compression introduces new risks—higher cost, quality concerns, team burnout—requiring careful cost-benefit analysis and risk mitigation planning.

Schedule Baseline and Progress Control

Once the schedule is approved, it is frozen as the schedule baseline—the official plan against which all progress is measured and all changes are evaluated. Only formal change requests can alter the baseline.

During execution, the manager compares actual progress to the baseline. Discrepancies reveal whether tasks are ahead, on time, or behind. These variances trigger corrective action: accelerate lagging tasks, rebalance resources, or negotiate scope and timeline adjustments.

The baseline also anchors change control. When stakeholders request adjustments (new tasks, shifted timelines, revised scope), the manager assesses the impact on the baseline. Approved changes update the baseline via formal process, creating a record of the plan's evolution.

The baseline serves as a ruler and reference point. It quantifies project performance (schedule variance, schedule performance index) and provides transparent communication: everyone sees the original plan and understands how new plans differ. Large projects maintain three baselines—scope, schedule, and cost—forming the core of project governance.

Without a baseline, there is no way to know whether the project is early or late. After locking in a realistic schedule as baseline, the manager monitors regularly. Large deviations prompt either corrective action (compress the gap) or a change request to reset the baseline (if conditions have materially shifted). This cycle makes the baseline the project's "compass," guiding steady progress toward goals and flagging when course correction is needed.