Unit 7: Shortening Your Project

I. Orientation — Critical-Path-Based Schedule Compression

Shortening a project means reducing its planned completion time without unintentionally changing its scope, quality, cost, or risk profile. The governing principle is the Critical Path Method (CPM), developed in the late 1950s: only changes that shorten the current critical path can directly advance the project finish date.

• Critical path: The longest-duration sequence of logically connected tasks from project start to project finish; it determines the earliest possible completion date.
• Critical task: A task whose scheduling flexibility is at or below the criticality threshold, commonly zero total slack.
• Total slack: The amount of time a task may be delayed without delaying the project finish date.
• Dependency: A logical relationship—Finish-to-Start, Start-to-Start, Finish-to-Finish, or Start-to-Finish—that controls when tasks can occur.
• Schedule compression: The deliberate shortening of the schedule through methods such as crashing, fast tracking, scope adjustment, calendar changes, and removal of unnecessary constraints.
• Dynamic behavior: The critical path can change after durations, dependencies, resources, calendars, constraints, or progress data are modified.
• Software convention: In tools such as Microsoft Project, critical tasks can be displayed in the Gantt Chart, highlighted through formatting, or isolated through a filter.
• Control principle: Every proposed compression must be evaluated against time, cost, scope, quality, resource availability, and risk.

II. Setting the Critical Path — Establishing Schedule Criticality

Critical-path settings determine how project-management software identifies and displays schedule-driving tasks. A valid critical path depends on a complete network, realistic task durations, appropriate calendars, and logically linked activities.

A. Setting The Critical Path

Setting the critical path involves preparing the schedule correctly and selecting the slack threshold under which a task is treated as critical.

• Build the task network: Enter all deliverables and activities, estimate their durations, and connect related tasks with predecessors and successors.
  • A task without a predecessor or successor may become an unintended open end.
  • Summary tasks should summarize subordinate work rather than replace detailed task logic.
• Use logical relationships: The usual dependency is Finish-to-Start, meaning the successor begins after the predecessor finishes.
  • Example: “Complete design” must finish before “Begin coding.”
  • Leads and lags should represent real conditions, not merely force desired dates.
• Define working time: Project, task, and resource calendars determine the working hours available for scheduling.
  • Five working days equal one week only when the calendar defines a five-day working week.
  • Holidays and resource leave may extend the elapsed schedule.
• Avoid excessive constraints: Hard constraints such as Must Start On can override normal network calculations.
  • Prefer flexible constraints, such as As Soon As Possible, where business rules permit.
  • Use deadlines to monitor target dates without fixing the task artificially.
• Set the criticality threshold: In Microsoft Project, the calculation option “Tasks are critical if slack is less than or equal to” specifies the threshold.
  • A value of 0 days treats tasks with no total slack as critical.
  • A value of 2 days also identifies near-critical tasks with two days or less of slack.
• Choose the calculation scope: A master project may calculate one critical path for the entire project or multiple critical paths for separate task networks.
  • Multiple critical paths are useful when independent deliverables each need monitoring.
  • They may also display more tasks as critical, so interpretation must remain network-based.

The underlying calculation is:

Total Slack = Late Finish − Early Finish
            = Late Start − Early Start

Here, Early Start (ES) and Early Finish (EF) are the earliest feasible dates; Late Start (LS) and Late Finish (LF) are the latest dates that do not delay project completion.

B. Validation and Limitations

Critical-path settings are meaningful only when the schedule model reflects the work that will actually be performed.

• Schedule validation: Check for missing links, unrealistic durations, incorrect calendars, unexplained lags, and unnecessary date constraints before accepting the displayed path.
• Progress-date effect: Once execution begins, actual starts, actual finishes, remaining durations, and the status date can produce a different critical path.
• Threshold limitation: Raising the slack threshold does not change the mathematical longest path; it only broadens the set of tasks classified as critical.
• Resource limitation: CPM initially reflects logical and calendar constraints. Resource overallocations may make calculated dates unrealistic until resource conflicts are resolved.
• Milestone treatment: A zero-duration milestone may be critical because it lies on the critical path, even though shortening the milestone itself cannot save time.

III. Using the Critical Path View — Reading the Schedule-Driving Chain

A critical path view visually distinguishes tasks that control the finish date from tasks that possess scheduling flexibility. It supports diagnosis, communication, and focused schedule control.

A. Using The Critical Path View

Using the view requires displaying critical-task formatting and tracing the sequence responsible for the project completion date.

• Display the Gantt Chart: In Microsoft Project, open a Gantt-based view so task dates, durations, links, and bars appear together.
• Highlight critical tasks: Critical formatting commonly displays critical bars in red and noncritical bars in blue, although styles can be customized.
• Use Tracking Gantt when required: Tracking Gantt compares the current schedule with saved baseline bars.
  • Baseline bars show the approved plan.
  • Current bars reveal schedule movement and critical-path changes.
• Inspect supporting fields: Add columns such as Critical, Total Slack, Predecessors, Successors, Constraint Type, and Deadline.
  • Critical = Yes identifies tasks meeting the configured slack threshold.
  • Total Slack shows how close a noncritical task is to becoming critical.
• Trace task paths: Task-path highlighting can show predecessors, driving predecessors, successors, and driven successors for a selected task.
  • A driving predecessor directly controls the selected task’s start or finish.
  • A predecessor with spare slack may be logically connected without currently driving the date.
• Read the path as a chain: Follow critical bars and dependency lines from the project start toward the final milestone.
  • Disconnected red tasks may indicate separate critical networks, constraints, or multiple critical-path settings.
  • The project summary task provides the current overall duration and finish date.

B. Interpretation and Practical Use

The view should be used to identify causes of delay and possible intervention points, not merely to locate red bars.

• Prioritization: Managers monitor critical tasks more closely because a one-day delay may produce a one-day project delay.
• Near-critical paths: A path with one or two days of slack can become critical after a minor problem; displaying Total Slack reveals this exposure.
• Baseline comparison: A task may remain critical even while finishing on its baseline date, or become critical because other paths gained or lost slack.
• Communication: A simplified critical path view helps stakeholders understand why selected approvals, procurements, or technical tasks need immediate decisions.
• Display limitation: Bar color is a result of schedule calculations, not proof that a task is strategically important. A high-cost or safety-critical task may have substantial slack.
• Updating requirement: The view must be refreshed through accurate progress entry; outdated remaining durations create a misleading path.

IV. Filtering for Critical Tasks Only — Isolating Schedule Drivers

Filtering temporarily hides nonmatching tasks while preserving them in the schedule. A critical-task filter produces a focused list for analysis, reporting, and status review.

A. Filtering For Critical Tasks Only

A critical filter selects tasks whose Critical field is set to Yes under the current scheduling calculation.

• Apply the built-in filter: In a task view, use the filter control and select Critical.
  • Critical tasks remain visible.
  • Noncritical tasks are hidden rather than deleted.
• Use AutoFilter for refinement: Filter the Critical column to Yes, then combine it with other fields.
  • Example: filter Critical = Yes and Resource Names = Testing Team.
  • This isolates critical testing work without changing task assignments.
• Retain summary context when needed: Showing related summary tasks helps identify the phase or deliverable containing each critical activity.
• Analyze useful columns: Display Duration, Start, Finish, Total Slack, Predecessors, Resource Names, and Cost alongside the filtered list.
• Clear the filter correctly: Restore No Filter or clear all filters before reviewing the complete plan.
  • Hidden noncritical work still consumes resources.
  • Printing while filtered produces only the visible task set.

B. Applications and Limitations

Filtering improves concentration but removes network context that may be necessary for sound decisions.

• Status meetings: The filtered list supports concise review of incomplete schedule-driving work.
• Responsibility reports: Grouping filtered tasks by resource or department identifies ownership of immediate schedule risk.
• Compression analysis: Candidate tasks can be compared by duration, cost, resource demand, and feasibility of acceleration.
• Context limitation: Hidden predecessors, resource conflicts, and near-critical tasks may still affect the proposed change.
• Dynamic limitation: After a critical task is shortened, another path may become critical; the filter must therefore be reapplied after recalculation.
• Reporting caution: “Critical only” does not mean “important only.” Governance, compliance, quality, and safety tasks must remain controlled regardless of slack.

V. Shortening the Project — Compressing the Completion Date

Project shortening is an iterative process of modifying critical-path work, recalculating the schedule, and checking whether the finish date improves without unacceptable consequences.

A. Shortening The Project

Only a reduction affecting the controlling path shortens the overall project; reducing a noncritical task usually increases its slack instead.

1. Crashing
   • Principle: Add resources, overtime, better equipment, or external expertise to reduce a critical task’s duration.
   • Cost slope: Compare acceleration alternatives using:

Cost Slope = (Crash Cost − Normal Cost) /
             (Normal Duration − Crash Duration)

• Definitions: Crash Cost is the accelerated cost; Normal Cost is the planned cost; Crash Duration and Normal Duration are the corresponding completion times.
• Selection rule: Prefer feasible critical activities with lower cost per unit of time saved, while checking resource productivity and quality.

2. Fast tracking
   • Principle: Overlap activities that were originally sequential, usually by changing dependencies or introducing lead time.
   • Example: Begin coding approved modules before the entire design is complete.
   • Risk: Rework increases if the unfinished predecessor later changes.

• Reduce or refine duration estimates: Break broad tasks into smaller activities, remove embedded contingency where risk reserves exist elsewhere, and use improved methods or automation.
• Change calendars carefully: Additional shifts, weekend work, or longer working days may shorten elapsed time but increase fatigue, cost, and operational risk.
• Review scope and quality requirements: Defer low-priority features or simplify deliverables only through formal change control; never silently reduce agreed acceptance criteria.
• Remove unnecessary delay: Shorten approval cycles, procurement waiting periods, lags, and handoffs where the underlying business condition permits.
• Use deadlines rather than forced dates: Removing artificial constraints can allow the scheduling engine to calculate an earlier feasible plan.

B. Evaluation and Control

Every compression step must be tested against the recalculated network and project objectives.

• Iterative procedure:
  1. Save or confirm the baseline.
  2. Identify the current critical and near-critical paths.
  3. Select a feasible compression action.
  4. Modify one controlled element.
  5. Recalculate and inspect the new finish date.
  6. Recheck cost, resources, scope, quality, and risk.
• Diminishing returns: Shortening one path stops helping when a parallel path becomes equally long; both paths may then require compression.
• Resource check: Adding people does not always shorten work because communication, onboarding, and task indivisibility can reduce productivity.
• Approval requirement: Changes to scope, budget, baseline dates, contracts, or working conditions require authorization through project change control.
• Documentation: Record the original assumption, approved modification, expected time saving, additional cost, responsible owner, and resulting schedule.
• Final criterion: A successful compression produces an earlier realistic finish date—not merely shorter task durations—while keeping residual risk acceptable.