KEVOS · Templates & Examples · Frameworks
Project Schedule Status, Delay and Recovery Framework
A framework for updating engineering project schedules, managing holds, diagnosing delay and recovering forecasts without erasing the baseline.
Executive summary
The source schedules include completed, partially complete and on-hold projects, with several very long elapsed durations. Those histories show why a schedule needs explicit status, remaining work and hold reasons rather than simply extending finish dates. This framework explains how to update progress, diagnose slippage and recover the forecast without corrupting the original plan.
Separate effort, elapsed time and waiting
A task can consume ten days of engineering effort but remain open for months because it is waiting for customer input, supplier action, test capacity or a related project. The source examples include explicit “on hold” tasks and project notes indicating progress was paused pending another condition. Other schedules show long durations without a clear hold marker.
For useful reporting, preserve this distinction. Remaining effort tells the team how much work is left. Forecast finish reflects both work and waiting. Hold reason explains why the task cannot currently progress. Mixing the three into a single large duration makes historical lessons and future planning unreliable.
Minimum status fields
| Field | What it should mean | Control rule |
|---|---|---|
| Status | Not started, active/in progress, on hold, complete, cancelled or equivalent. | Use an explicit hold state when work cannot progress. |
| % complete | Progress on the actual task scope. | Update leaf tasks; do not “paint” summary percentages to make the project look right. |
| Remaining duration / forecast | Best current estimate of when the task will finish given known work and constraints. | Reforecast when evidence changes; keep baseline separate. |
| Hold reason | External commitment, resource, prerequisite, technical issue or decision preventing progress. | State a review trigger or next action. |
| Next gate / dependency | The event that unlocks the next stage. | Keep blocked downstream tasks linked to the condition. |
| Corrective action | Specific recovery step if the project is late for controllable reasons. | Assign owner and target date. |
Diagnose the delay before changing the schedule
- Find the first late or blocked controlling task. Do not start by moving the project finish date.
- Classify the cause. Is it additional scope, technical rework, supplier lead time, test capacity, resource conflict, external approval, missing information or bad original logic?
- Check configuration impact. If the delay is caused by redesign or a failed test, identify which downstream tasks are invalidated and must be repeated.
- Re-estimate remaining work. Use current information rather than adding a blanket delay to every task.
- Review safe concurrency. Decide whether any downstream preparation can begin without committing against unstable information.
- Protect gates. Do not recover time by bypassing evidence that is required for tooling or production approval.
- Update the forecast and action register. Make the new dates and the reason visible.
- Retain the baseline. Recovery should not erase the original commitment used for variance learning.
Common delay patterns visible in the source set
Some projects explicitly pause until another product modification or decision is complete.
Prototype or tooling correction loops extend the path when verification finds issues.
Tooling and quotation stages can dominate elapsed time when external turnaround changes.
Testing can wait for samples, rigs, gauges or test-laboratory availability.
Technical work may be complete while customer/stakeholder approval is still outstanding.
Production completion may precede usable stock by a significant freight period.
Using percent complete correctly
The source files contain percentage-complete values on both summary and leaf tasks. Summary progress is useful as a roll-up indicator only when it is driven by credible leaf-task progress. It should not be used as the primary update method.
For an engineering task, percent complete should correspond to defined work content. For example, a prototype test is not 90% complete because most cycles have run if a failure has invalidated the test and requires a restart. Conversely, a long waiting period after all engineering work is done should not force the task to remain at an arbitrary low percentage; use status and remaining-duration logic to show the waiting condition.
Recovery strategies that preserve technical control
| Recovery lever | When it helps | Risk to manage |
|---|---|---|
| Parallel preparation | Downstream admin/data work can start before formal gate, without irreversible commitment. | Work may need rework if upstream configuration changes. |
| Split long tasks | A generic activity hides independent work and waiting. | Over-fragmentation can make the schedule hard to maintain. |
| Prioritise test capacity | Testing is on the controlling path and samples are ready. | Do not rush an unready test method or fixture. |
| Early supplier clarification | Tooling quotation is waiting on ambiguities. | Changes must remain configuration-controlled. |
| Conditional production preparation | ERP/BOM preparation can proceed while approval is pending. | Do not release production/order before the gate authority allows it. |
| Alternative logistics | Freight is controlling the required stock date. | Cost, availability and commercial approval may change. |
When to put a project on hold
Use an explicit hold when the team cannot make meaningful progress because a prerequisite is outside its immediate control or because continuing would create avoidable waste. The source portfolio schedule also separates projects awaiting customer commitment and projects pending approval/resources, which reinforces the value of visible status categories.
A hold should have a reason, an owner for the next action, and a review trigger. “On hold” without a trigger simply hides a stale project. The trigger might be receipt of commitment, resource availability, completion of a prerequisite project, supplier response or a formal decision.
Related KEVOS templates
A disciplined weekly recovery conversation
Recovery planning starts with the current forecast, not the original promise. For each delayed or at-risk task, identify the remaining work, the blocking condition and the earliest credible finish date. Then trace only the downstream tasks that are truly dependent on it. This prevents the common response of moving every later date by the same amount even when some work can continue in parallel.
Next, choose a recovery action that changes the work system rather than the appearance of the schedule. Examples include supplying missing information, changing task sequence, adding an available resource, splitting a deliverable, expediting a sample, obtaining a faster decision or deliberately changing scope. Record the cost, risk and decision owner for significant recovery actions; a shorter forecast is not automatically a better plan if it introduces unacceptable technical or commercial risk.
Weekly status questions
- What changed since the last review: completed work, new delay, new evidence or changed assumption?
- Which task now controls the next gate or completion objective?
- Is the blocker within the project team, a support queue, a supplier, an approval path or an external commitment?
- What is the earliest credible recovery action, and who must decide it?
- Has any “on hold” item been given a clear restart condition rather than an indefinite date?
- Which forecast change needs to be communicated to stakeholders now?
Keep a brief delay reason history even after dates are recovered. Over several projects, repeated causes—late drawings, unavailable samples, tooling correction cycles, test-capacity constraints or approval waiting—become evidence for improving templates and capacity planning. The schedule is therefore both a control tool for the current project and a learning dataset for the next one.