Unit 11: Tracking Progress - Subjective Questions

A project baseline is an approved snapshot of the original project plan against which actual performance is measured. It commonly stores the planned start dates, finish dates, durations, work, and costs.

Its purposes are to:

• Provide a fixed reference for performance measurement.
• Reveal deviations between planned and actual progress.
• Support schedule and cost control.
• Help managers forecast project completion.
• Preserve the original commitments even when the current schedule is updated.

A baseline should normally be saved after the plan has been reviewed and approved but before execution begins.

A baseline can generally be saved through the following procedure:

1. Complete the project plan by defining tasks, dependencies, resources, durations, and costs.
2. Review the schedule for errors, resource overallocations, and unrealistic dates.
3. Obtain approval from the relevant stakeholders.
4. Open the application's Set Baseline or equivalent command.
5. Select the baseline slot, such as Baseline, Baseline 1, or Baseline 2.
6. Choose whether to save the baseline for the entire project or only for selected tasks.
7. Confirm the operation and verify that baseline fields contain the planned values.

The exact menu names vary by tool, but the underlying purpose is to preserve approved planning data.

The three sets of values have different roles:

• Baseline plan: The approved reference values saved before or during controlled replanning. These values remain unchanged unless the baseline is deliberately reset.
• Current plan: The latest scheduled values calculated from current task information, dependencies, constraints, and remaining work. These values may change whenever the schedule is updated.
• Actual data: The work, cost, start date, finish date, and progress that have already occurred.

For example, a task may have a baseline duration of 5 days, a current duration of 7 days, and an actual duration of 6 days so far. Comparing these values helps identify variance and determine whether corrective action is required.

These actual fields record what has happened during execution:

• Actual Start: The date on which work on the task truly began.
• Actual Finish: The date on which the task was completed. It should be entered only when no work remains.
• Actual Work: The amount of resource effort already spent on the task.
• Actual Cost: The expenditure incurred for completed work, including resource and fixed costs where applicable.

When these values are entered, the project management tool recalculates fields such as remaining duration, remaining work, percentage complete, and forecast finish date. Accurate actual values therefore produce a more reliable current schedule and performance report.

A variance is the difference between a tracked value and its approved baseline value.

Common calculations include:

• Start variance:
• Finish variance:
• Duration variance:
• Cost variance:

A positive schedule variance measured in days usually means the task is later than planned. A positive cost difference under the stated cost formula indicates an overrun. Managers must check the convention used by their software because earned value systems may define cost variance differently, such as .

The duration variance is:

The cost variance is:

Therefore:

• The task is forecast to take 3 days longer than originally planned.
• The task is $2,500 over the baseline cost.
• The manager should investigate causes such as underestimated effort, resource productivity, rework, or scope change.
• If the task is on the critical path, the duration increase may also delay the project finish date.

Replacing the baseline after every schedule change removes the original reference and can hide poor performance. Variances would repeatedly return to zero, making meaningful trend analysis and accountability impossible.

Resetting or adding a new baseline may be justified when:

• A formally approved scope change substantially alters the project.
• A major external event makes the original plan unusable.
• The project is deliberately replanned after an approved review.
• A new phase requires its own authorized performance reference.

The original baseline should preferably be retained in one baseline slot, while the revised approved plan is stored in another. The reason, date, approval, and impact of the change should also be documented.

The status date is the reporting cutoff date used to separate completed performance from future work. It tells the project management application when progress is being evaluated.

Its role includes:

• Recording actual work up to a consistent date.
• Identifying tasks that should have started or finished but have not.
• Moving incomplete work from the past into the future when the schedule is rescheduled.
• Producing time-phased reports for a specific reporting period.
• Improving consistency across task, resource, and cost updates.

For reliable tracking, the same status date should be used throughout a reporting cycle, and progress should not be recorded ambiguously on both sides of that date.

A regular schedule update normally includes these steps:

1. Set the reporting or status date.
2. Collect verified progress information from task owners.
3. Enter actual starts, actual finishes, actual work, actual costs, and remaining work or duration.
4. Record approved scope, resource, calendar, dependency, and constraint changes.
5. Reschedule incomplete work that remains before the status date.
6. Recalculate the schedule.
7. Compare current values with baseline values.
8. Review critical tasks, milestones, resource overallocations, and cost overruns.
9. Apply approved corrective actions.
10. Save and communicate the updated schedule and key variances.

This cycle ensures that the schedule reflects both completed performance and a realistic forecast of remaining work.

The two approaches differ in precision:

• Percentage complete is quick and suitable when progress closely follows elapsed duration. For example, entering 50% complete may cause the tool to divide duration into completed and remaining portions. However, it can be subjective and may not represent resource effort accurately.
• Actual and remaining work records the effort already consumed and the effort still required. It gives a stronger forecast because remaining work can increase even when much work has already been spent.

For example, a task may have consumed 40 hours but still require 60 hours. Reporting only 50% complete could conceal the revised total of 100 hours. Actual and remaining work is generally preferable for effort-driven tasks.

Task-level updating records detailed progress for individual activities. It may include actual start, actual finish, actual duration, actual work, remaining work, and task-specific notes. It is appropriate when precise control and reliable task forecasts are required.

Project-level updating applies a common rule to many tasks or to the entire project, such as marking all scheduled work complete up to a selected date or rescheduling all incomplete work after the status date. It is faster but may be less accurate if individual tasks have progressed differently.

A practical approach is to use project-level commands for broad administrative updates and then verify or correct important tasks individually, especially critical, high-cost, or high-risk tasks.

A late predecessor may delay its successors, but the exact effect depends on the schedule logic. Important factors include:

• The dependency type, such as finish-to-start or start-to-start.
• Any lead or lag applied to the dependency.
• The successor's total and free slack.
• Task calendars and resource availability.
• Date constraints or manually scheduled dates.
• Whether the predecessor lies on the critical path.

If the delay consumes available slack, the successor may move without affecting the final project date. If no slack remains, successor dates and possibly the project finish date will move. The baseline dates remain unchanged and display the resulting schedule variance.

Incomplete work shown in the past indicates that the schedule no longer represents a feasible forecast. The manager should:

• Verify the task's actual progress with its owner.
• Enter any missing actual work or actual dates.
• Estimate the remaining work or remaining duration realistically.
• Use the scheduling tool's command to move incomplete work after the status date.
• Check how the movement affects dependencies, critical path, resource assignments, and milestones.
• Avoid changing baseline values merely to remove the variance.

The result should show completed work before the status date and unfinished work on realistic future dates, while retaining the approved baseline for comparison.

A tracking Gantt chart displays current or actual task bars together with baseline bars on a time scale. It helps users visually identify:

• Tasks that started or finished later than planned.
• Tasks whose durations have increased or decreased.
• Incomplete work and revised finish dates.
• Milestone slippage.
• Critical tasks and schedule changes affecting the project finish.

Baseline bars are usually displayed beneath or alongside current bars. A large separation between the two indicates significant variance. The chart should be used with numeric variance fields because visual inspection alone may not reveal the exact number of delayed days or the cause of the deviation.

A large finish variance should be analyzed systematically:

1. Confirm that baseline and current dates are valid.
2. Check whether actual progress was entered correctly.
3. Review changes in duration, remaining work, assignments, and resource calendars.
4. Inspect predecessors, successors, leads, lags, and constraints.
5. Determine whether the task is critical or has sufficient slack.
6. Identify the root cause, such as late inputs, underestimated effort, rework, or resource shortage.
7. Evaluate corrective options such as resequencing, resource changes, scope adjustment, crashing, or fast tracking.
8. Obtain approval for changes that affect scope, cost, or commitments.

The manager should focus on impact and root cause rather than merely changing dates to eliminate the displayed variance.

Custom fields are user-configurable columns used to store or calculate information not adequately represented by standard fields. They can improve progress tracking by capturing organization-specific data.

Examples include:

• A text field for Delay Reason.
• A list field for Approval Status.
• A number field for Defects Remaining.
• A date field for Forecast Handover Date.
• A flag field for Executive Attention Required.
• A formula field that marks a task as late when current finish exceeds baseline finish.

Custom fields should have clear definitions, controlled values where possible, and consistent ownership. Too many fields can reduce data quality and make schedule maintenance unnecessarily complex.

A custom variance indicator can be created as follows:

1. Select an unused custom field, such as a number, flag, or text field.
2. Rename it clearly, for example Schedule Health.
3. Define a formula based on an existing field such as finish variance.
4. Establish thresholds, such as Green for no delay, Amber for a small delay, and Red for a major delay.
5. Configure graphical indicators or controlled text values.
6. Add the field to the relevant task table or view.
7. Test it with on-time and delayed tasks.
8. Document the threshold definitions so reports are interpreted consistently.

The indicator summarizes schedule health, but users should still inspect the underlying baseline and current dates before taking action.

Toolbar customization places frequently used commands where they can be reached quickly, reducing repetitive navigation during schedule updates. Useful commands may include Set Baseline, Update Tasks, Update Project, Set Status Date, Reschedule Work, and Tracking Gantt.

A typical process is to:

• Open the application's toolbar, ribbon, or quick-access customization settings.
• Locate the required commands by category.
• Add them to a custom group or toolbar.
• Arrange them in the sequence used during reporting.
• Remove rarely used commands to avoid clutter.
• Save or distribute the configuration if the tool supports shared templates.

Customization improves efficiency but does not replace a documented and controlled update procedure.

The commands operate at different scopes:

• Update Task applies detailed values to one or more selected tasks. It commonly allows entry of actual start, actual finish, actual duration, remaining duration, and percentage complete. It is suitable when task-specific information is available.
• Update Project applies a broad update rule across the schedule. It may mark work complete through a chosen date or reschedule incomplete work to begin after a chosen date. It is suitable for periodic project-wide processing.

Update Task provides greater precision, while Update Project provides speed and consistency. After a project-wide update, critical or unusual tasks should be reviewed individually to ensure that the generalized rule did not misrepresent their actual condition.

A suitable weekly workflow is:

1. Prepare: Confirm that the approved baseline is preserved and set the weekly status date.
2. Collect data: Obtain actual starts, finishes, work, costs, blockers, and revised remaining estimates from team members.
3. Update tasks: Enter detailed actual and remaining values for active, critical, high-cost, and high-risk tasks.
4. Update the project: Apply project-wide completion or rescheduling commands where appropriate, then inspect exceptions.
5. Recalculate: Allow the tool to update successor dates, resource demand, costs, and the critical path.
6. Compare with baseline: Review start, finish, duration, work, and cost variances using tables and a tracking Gantt chart.
7. Analyze: Identify root causes and assess effects on milestones, budget, scope, and final delivery.
8. Respond: Record corrective actions, owners, and approved changes. Preserve the original baseline and save any formally authorized rebaseline separately.
9. Customize the workspace: Use a concise tracking toolbar and custom fields for delay reason, health indicator, and action owner.
10. Communicate: Publish the updated schedule, key variances, decisions, and forecasts to stakeholders.

This workflow combines accurate data entry, controlled change, efficient tool use, and decision-focused reporting.