Unit 11: Tracking Progress

INT416 — Software Project Management Laboratory 9 min read

I. Foundations of Project Progress Tracking

Project progress tracking is the systematic process of recording actual performance, comparing it with the approved plan, and revising forecasts so that the schedule represents the project’s current condition. In tools such as Microsoft Project, tracking depends on a time-phased schedule containing tasks, dependencies, resources, costs, and a saved baseline.

  • Governing principle: Progress is meaningful only when actual results are compared with an approved reference plan.
  • Baseline: A fixed snapshot of selected planned values, normally saved immediately after the schedule is approved.
  • Current schedule: The latest working version of task dates, durations, work, costs, and forecasts.
  • Actual values: Recorded results such as Actual Start, Actual Finish, Actual Duration, Actual Work, and Actual Cost.
  • Variance: The difference between a current or actual value and its corresponding baseline value.
  • Status date: The reporting cut-off date at which project performance is evaluated.
  • Data-date convention:
    • Completed work should normally appear before or on the status date.
    • Remaining work should normally be scheduled after the status date.
  • Updating sequence: Save the baseline, set the status date, enter actuals, reschedule incomplete work, inspect variances, and communicate the revised forecast.
  • Control discipline: A baseline should not be overwritten merely because the project is late; approved changes must be distinguished from performance deviations.

II. Baseline Management — Freezing the Approved Plan

A baseline preserves the authorized schedule and cost targets against which subsequent performance can be measured.

A. Saving a baseline

Saving a baseline copies selected current plan values into protected baseline fields without creating a separate project file.

  • Values captured: A standard baseline stores planned Start, Finish, Duration, Work, and Cost values for tasks, resources, and assignments.
  • Time-phased information: Baseline Work and Baseline Cost may also be distributed across time, allowing analysis by day, week, or accounting period.
  • When to save: Save the initial baseline after scope, task logic, resources, dates, and budget have been approved but before execution is recorded.
  • Microsoft Project procedure:
    1. Open the approved project schedule.
    2. Choose Project > Set Baseline > Set Baseline.
    3. Select Set baseline and choose Baseline.
    4. Apply it to the entire project or selected tasks.
    5. Confirm the operation and display the Tracking Gantt or baseline fields.
  • Multiple baselines: Microsoft Project supports the main Baseline and numbered sets such as Baseline1 through Baseline10; these can preserve approved revisions or milestone-stage plans.
  • Selected-task option: When adding approved tasks, baseline values may be rolled up:
    • To all summary tasks: Updates every affected level of the work breakdown structure.
    • From subtasks into selected summary task(s): Limits roll-up to the chosen summary hierarchy.
  • Interim plan distinction: An interim plan generally stores only Start and Finish values; it does not provide the full work-and-cost reference of a baseline.
  • Verification: Insert fields such as Baseline Start, Baseline Finish, Baseline Duration, Baseline Work, and Baseline Cost. Empty values indicate that no relevant baseline has been saved.
  • Control limitation: Rebaselining erases visible variance against the replaced plan. It is justified only by formally approved scope or planning changes, with the previous reference retained when audit history is required.

III. Performance Measurement — Detecting and Interpreting Variance

Performance comparison converts recorded progress into evidence about whether the project remains aligned with its approved objectives.

A. Compare actual values to the baseline estimates

Comparing actual and current values with baseline estimates identifies schedule, effort, and cost deviations that require management attention.

  • Date variance: Start Variance and Finish Variance measure the movement of current dates from baseline dates.
TEXT
Start Variance  = Current Start - Baseline Start
Finish Variance = Current Finish - Baseline Finish
  • A positive Finish Variance usually indicates a forecast delay.
  • A negative Finish Variance indicates an earlier forecast finish.
    • Duration variance: Duration Variance compares the present scheduled duration with Baseline Duration.
TEXT
Duration Variance = Current Duration - Baseline Duration
  • Work variance: Work Variance reveals whether the current expected effort differs from the authorized effort.
TEXT
Work Variance = Current Work - Baseline Work

Here, Work is commonly measured in person-hours or person-days.

  • Cost variance: The basic schedule-field comparison is:
TEXT
Cost Variance = Current Cost - Baseline Cost

A positive result represents an expected overrun when higher cost is unfavorable.

  • Actual versus current: Actual values describe work already performed, whereas current values combine actual performance with the latest estimate for remaining work.
  • Useful views: The Tracking Gantt overlays baseline bars with current bars; the Variance table displays baseline, current, and variance fields; Task Usage and Resource Usage show time-phased work.
  • Worked example: If Baseline Finish is 10 June and Current Finish is 14 June, Finish Variance is +4 elapsed calendar days as a date difference. Project displays may express variance according to the project calendar and field behavior.
  • Interpretation rule: A variance should be traced through task dependencies. A four-day delay on a noncritical task with six days of total slack may not delay the project, while a one-day delay on the critical path can move the completion date.
  • Data-quality limitation: Comparisons are misleading when actual work, remaining duration, dependency logic, resource calendars, or baseline values are missing or outdated.

IV. Schedule Updating — Maintaining a Credible Forecast

Schedule updating incorporates reported performance and recalculates unfinished work so that future dates remain achievable.

A. Updating the project schdeule

Updating the project schedule means applying a consistent reporting date and adjusting incomplete work to reflect what has actually occurred.

  • Status date: Set the reporting cut-off through Project > Status Date; using a fixed date makes weekly reports comparable.
  • Recommended order:
    1. Collect approved timesheets, completion reports, and revised estimates.
    2. Set the status date.
    3. Record actual starts, finishes, work, duration, and costs.
    4. Correct remaining duration or remaining work.
    5. Reschedule incomplete work after the status date.
    6. Recalculate and review the critical path and finish forecast.
  • Progress movement: Project > Update Project can reschedule uncompleted work to start after the status date, eliminating past-due remaining work.
  • Dependency effect: When a predecessor finishes late, an automatically scheduled successor is moved according to dependency type, lag, calendars, and constraints.
  • Constraint caution: Hard constraints such as Must Start On can prevent logical movement and create scheduling conflicts; flexible constraints usually produce more realistic forecasts.
  • Forecast principle: Changing Remaining Duration from five days to eight days is a forecast correction. It should not change the original Baseline Duration unless a new baseline is formally authorized.
  • Quality checks: Inspect tasks with future Actual Start dates, incomplete work before the status date, completed work after it, negative slack, broken links, and unexplained date constraints.

B. Update task and project

Task-level and project-level updates serve different purposes and must be chosen according to the reliability and detail of available progress data.

  1. Update task: Use task-level updating when exact information is available for a particular activity.
    • Fields: Enter Actual Start, Actual Finish, Actual Duration, Actual Work, Remaining Duration, Remaining Work, or % Complete.
    • Completion relation:
TEXT
% Complete = Actual Duration / Duration x 100
  • Work relation:
TEXT
% Work Complete = Actual Work / Work x 100
  • Important contrast: % Complete is duration-based, whereas % Work Complete is effort-based; they can differ on resource-intensive tasks.
  • Direct entry: Marking a task 100% complete normally records an Actual Finish, while entering an Actual Finish makes the task complete.
  1. Update project: Use project-level updating for a common status cut-off or broad progress operation.
    • Date range: Update work as complete through applies progress up to a specified date.
    • Scope: The operation may affect the entire project or only selected tasks.
    • Rescheduling: Reschedule uncompleted work to start after moves unfinished portions beyond the chosen date.
    • Limitation: Automatic percentage updates assume work followed the plan; they should not replace verified actuals when timesheets or task reports are available.
  • Calculation effect: After either update, the scheduling engine recalculates successor dates, resource assignments, costs, slack, and the projected project finish.
  • Consistency rule: Avoid entering conflicting values independently; for example, Actual Work plus Remaining Work should support the current total Work forecast.

V. Tracking Workspace — Presenting the Required Information

A tracking workspace should expose the fields and commands needed for frequent updates while suppressing irrelevant interface detail.

A. Customizing toolbars and fields

Customizing toolbars and fields makes progress entry faster, more consistent, and less prone to selecting the wrong command or measure.

  • Toolbar or ribbon access: Add frequently used commands such as Set Baseline, Update Tasks, Update Project, Project Information, and Go To Selected Task to a custom toolbar or the Quick Access Toolbar.
  • Legacy interface: In toolbar-based versions, use View > Toolbars > Customize; in ribbon-based versions, use application options to customize the Ribbon or Quick Access Toolbar.
  • Tracking table: Insert relevant columns by right-clicking a column heading and choosing Insert Column. Useful fields include:
    • Baseline Start and Baseline Finish
    • Actual Start and Actual Finish
    • % Complete and % Work Complete
    • Actual Work and Remaining Work
    • Start Variance and Finish Variance
    • Baseline Cost, Actual Cost, and Cost Variance
  • Custom fields: Fields such as Text, Number, Date, Flag, Cost, and Duration can hold organization-specific tracking information.
  • Formula example: A custom Flag field can identify delayed incomplete tasks using a condition based on Finish Variance and % Complete; graphical indicators can then display a warning symbol.
  • Lookup tables: A Text field may restrict entries to controlled values such as Not Started, Blocked, Under Review, and Accepted, improving reporting consistency.
  • Naming: Rename fields to meaningful labels such as Delivery Risk or Approval Status, while documenting whether the field is task-, resource-, or project-level.
  • View preservation: Save the selected table, filter, group, timescale, and bar styles as a named view, such as Weekly Tracking.
  • Design limitation: Excessive fields obscure important exceptions. A focused tracking view should prioritize status, variance, criticality, ownership, and the next forecast date.