Unit 7: Shortening Your Project - Subjective Questions

The critical path is the longest sequence of logically connected tasks that determines the earliest possible completion date of a project.

• Tasks on the critical path are called critical tasks.
• A critical task normally has zero or very little total slack.
• A delay in any critical task generally delays the entire project unless corrective action is taken.
• The critical path helps the project manager identify the activities that require the closest monitoring.
• It may change when task durations, dependencies, constraints, calendars, or resource assignments are modified.

The critical path is determined by analyzing task durations and dependencies through the following process:

1. List all project tasks and their durations.
2. establish the logical dependencies among the tasks.
3. Perform a forward pass to calculate the earliest start and earliest finish of each task.
4. Perform a backward pass to calculate the latest start and latest finish that will not delay the project.
5. Calculate total slack using or .
6. Identify the continuous path of tasks with zero or minimum slack.

The longest-duration path through the task network is the critical path and establishes the project's minimum completion time.

Total slack is the amount of time by which a task can be delayed without delaying the project's finish date or violating a scheduling constraint.

It can be expressed as:

or

• A task with zero total slack is normally critical.
• A task with positive slack has some scheduling flexibility.
• A task with negative slack indicates that the current schedule cannot satisfy a deadline or constraint.
• The critical path is generally formed by linked tasks having zero or the smallest amount of total slack.

A typical procedure for setting or reviewing the critical path is:

• Create a complete task list, including milestones and summary tasks.
• Enter realistic durations for all tasks.
• Define task dependencies using appropriate relationship types.
• Assign project and task calendars where necessary.
• Set the project start date or finish date.
• Avoid unnecessary fixed-date constraints because they can distort schedule calculations.
• Allow the software to calculate early and late dates and total slack.
• Open the Critical Path or Tracking Gantt view to identify critical tasks.
• Review the critical-task threshold in the scheduling options if tasks with a small amount of slack must also be treated as critical.

The critical path is primarily calculated from schedule logic; it should not be created merely by manually coloring or labeling tasks.

The Critical Path view presents the project schedule in a way that makes critical activities easy to identify and analyze.

Its main features generally include:

• A task table containing names, durations, dates, predecessors, and slack.
• A time-scaled chart displaying taskbars and dependency links.
• Distinct formatting, commonly red taskbars, for critical tasks.
• Different formatting for noncritical tasks that possess scheduling flexibility.
• Milestone symbols and summary-task bars.
• A visual representation of the sequence controlling the project completion date.

The view allows the project manager to focus attention on tasks whose delay is most likely to affect the final deadline.

A project manager can use the Critical Path view to:

• Identify tasks that directly control the project finish date.
• Compare planned dates with actual progress and updated forecasts.
• Detect critical tasks that are late, incomplete, or progressing slowly.
• Review dependency links and locate scheduling bottlenecks.
• Prioritize resources and management attention on time-sensitive work.
• Evaluate how a proposed duration or dependency change affects the completion date.
• Identify newly critical tasks after the schedule is updated.
• Select suitable tasks for crashing, fast tracking, or scope adjustment.

The view should be reviewed regularly because the critical path can shift as actual progress and remaining durations are entered.

A noncritical task can become critical if its available slack is consumed or if schedule logic changes.

Filtering for critical tasks only means temporarily displaying only those tasks that satisfy the scheduling software's definition of criticality, while hiding noncritical tasks from the current view.

It is useful because it:

• Reduces visual clutter in a large project plan.
• Helps managers focus on activities that influence the completion date.
• Supports focused status meetings and schedule reviews.
• Makes delayed or incomplete critical work easier to locate.
• Assists in selecting tasks for schedule-shortening actions.
• Produces concise reports for stakeholders.

Filtering changes only the displayed task set. It does not delete tasks or modify the underlying schedule.

The general procedure is:

1. Open a task-oriented view, such as a Gantt Chart or Critical Path view.
2. Open the Filter menu or view-filter controls.
3. Select the built-in Critical filter.
4. Apply the filter so that only tasks marked as critical are displayed.
5. Review fields such as duration, predecessors, total slack, finish date, and progress.
6. After completing the analysis, return to the filter controls.
7. Select All Tasks or clear the current filter to restore the full task list.

The exact menu names may vary between software versions, but the filter should affect only visibility and not task data.

Highlighting and filtering both help identify critical work, but they serve different purposes.

• Highlighting keeps every task visible and applies distinctive formatting to critical tasks.
• Filtering hides noncritical tasks and displays only critical tasks.
• Highlighting preserves the context of the complete schedule and makes relationships with noncritical work visible.
• Filtering provides a compact list suitable for focused analysis, reporting, and review meetings.
• Highlighting is preferable when the manager needs to understand the entire network.
• Filtering is preferable when the manager needs to inspect only schedule-driving activities.

Neither operation changes task duration, dependencies, slack, or the calculated project finish date.

The critical path is dynamic and may change whenever the project schedule is recalculated. Common causes include:

• Actual task durations differing from estimates.
• Critical tasks finishing early or late.
• Noncritical tasks consuming their available slack.
• Changes to dependencies or task sequencing.
• Addition, deletion, or modification of project tasks.
• Resource shortages, overallocation, or calendar changes.
• New deadlines and scheduling constraints.
• Changes in remaining duration, scope, or working time.

A path that was noncritical can become critical, while an earlier critical path may gain slack. Therefore, managers should recalculate and review the critical path after every significant schedule update.

Project shortening is the process of reducing the planned project duration so that the work finishes earlier or meets a required deadline.

Before shortening the schedule, the manager should examine:

• The current critical path and any near-critical paths.
• The amount of time by which the completion date must be reduced.
• Task dependencies and opportunities for parallel work.
• Resource availability and productivity.
• Additional direct and indirect costs.
• Quality, safety, and technical risks.
• Scope priorities and mandatory deliverables.
• Contractual obligations and stakeholder expectations.

Shortening noncritical tasks will not reduce the project duration unless those tasks become part of the critical path or affect a critical successor.

The main schedule-shortening techniques include:

• Crashing: Adding resources, overtime, equipment, or external support to reduce critical-task durations.
• Fast tracking: Performing tasks in parallel that were originally planned sequentially.
• Scope reduction: Removing, simplifying, or postponing lower-priority deliverables with approval.
• Dependency refinement: Replacing unnecessarily restrictive links or adding justified lead time.
• Productivity improvement: Using better tools, methods, automation, or more experienced personnel.
• Calendar changes: Adding working hours, shifts, or working days where feasible and lawful.
• Reallocation: Moving suitable resources from noncritical tasks to critical tasks.

Each technique must be evaluated for cost, quality, risk, resource feasibility, and its actual effect on the critical path.

Both methods should be applied to critical tasks and followed by schedule recalculation to confirm that the project finish date has improved.

Cost slope measures the additional direct cost required to shorten an activity by one unit of time. It is calculated as:

A systematic crashing procedure is:

1. Identify the current critical path.
2. Find critical activities that can be shortened.
3. Calculate the cost slope of each eligible activity.
4. Crash the feasible critical activity with the lowest cost slope.
5. Recalculate the schedule after each reduction.
6. Check whether another path has become critical.
7. Continue until the target date is reached or no economical reduction is possible.

When multiple critical paths exist, crashing an activity on only one path may not reduce the project duration. The manager may need to shorten a common activity or crash activities on all critical paths.

The cost slope is calculated using:

Substituting the values:

Therefore, the cost slope is $1,000 per day.

This means that each day removed from the activity's duration will add approximately $1,000 to its direct cost, up to the maximum possible reduction of four days. The manager should compare this slope with those of other crashable critical activities and with the financial benefit of earlier completion.

Adding resources does not automatically reduce either the task duration or the project duration. It may fail because:

• The task may be fixed-duration, so extra resources reduce individual effort rather than elapsed time.
• The work may not be divisible among additional people.
• New personnel may require training and supervision.
• Communication and coordination overhead may reduce productivity.
• Required equipment, workspace, or materials may be limited.
• The resource may not possess the required skills.
• Another task or path may become critical after the duration is reduced.
• The task may contain unavoidable waiting time, such as approval, curing, or delivery time.

The manager should test the assignment, recalculate the schedule, and verify that the project finish date actually moves earlier.

Dependencies and constraints determine when tasks are permitted to start and finish, so they strongly affect shortening opportunities.

• Finish-to-Start relationships may prevent successors from beginning until predecessors finish.
• Justified overlap can sometimes be introduced through Start-to-Start relationships or lead time.
• Unnecessary lags may be reduced after operational review.
• Hard constraints such as Must Start On or Must Finish On can restrict automatic rescheduling.
• External dependencies, approvals, and deliveries may impose dates that cannot be compressed internally.
• Removing or modifying a dependency without technical justification can create rework, quality problems, or invalid schedule logic.

Every dependency and constraint should therefore be reviewed for necessity, but changes must reflect how the work can actually be performed.

Schedule compression can meet an important deadline, but it introduces several trade-offs:

• Higher cost: Overtime, contractors, additional equipment, and expedited delivery increase expenditure.
• Quality risk: Reduced review or testing time may increase defects.
• Rework risk: Overlapping dependent activities may cause later changes to completed work.
• Resource risk: Overloading employees can reduce productivity and increase errors.
• Coordination complexity: Parallel work requires more communication and configuration control.
• Scope impact: Deferring features may reduce delivered value or stakeholder satisfaction.
• Safety and compliance risk: Mandatory checks must not be bypassed to save time.
• New critical paths: Compression of one path can make another path critical.

The chosen approach should balance time, cost, scope, quality, and risk rather than treating the earliest possible finish as the only objective.

A systematic schedule-shortening procedure is:

1. Save a baseline and record the current planned finish date.
2. Recalculate the schedule using current durations, progress, calendars, and resource data.
3. Open the Critical Path view to identify the schedule-driving sequence.
4. Apply the Critical filter to create a focused list of critical tasks.
5. Examine each critical task's duration, dependency, constraint, cost, resource assignment, and compression limit.
6. Select feasible actions such as crashing, fast tracking, calendar adjustment, dependency refinement, or approved scope reduction.
7. Estimate the cost and risk of each option before changing the schedule.
8. Apply the most appropriate change and recalculate the project.
9. Review the new critical path and check for multiple or near-critical paths.
10. Repeat until the target finish date is achieved or further compression becomes unacceptable.
11. Clear the filter, inspect the complete schedule, resolve resource conflicts, and obtain approval for the revised plan.

This iterative approach is necessary because every compression action can change task slack and move the critical path.