Progress must mean accepted work

Progress reporting becomes unreliable when different states are collapsed into a percentage. Work can be started, produced, inspected, delivered or accepted. Each state supports a different inference. Produced equipment may still fail inspection. Delivered equipment may still be incompatible with receiving works. Accepted equipment may still await a different package before assembly can start. A useful progress record states what happened and what the evidence proves, then connects the accepted event to the network’s release condition.

A percentage-complete judgment can be useful within a package if its basis is explicit. It should not automatically release a successor or establish value earned. A design team may have completed most drawings while the unresolved interface governs procurement. A construction package may have little physical work remaining but lack a critical test. Averaging completion across activities can make the package appear close to finished while hiding the item that determines acceptance. Report residual obligations and their consequences alongside any aggregate measure.

The schedule should use actual completion only when the defined event has occurred. If the task represents equipment accepted at the receiving boundary, factory production is insufficient. If it represents an approved design release, a submitted draft is insufficient. The actual-date record should link to the accepted evidence and the person who supplied it. This protects the meaning of the model. Otherwise the forward logic may release downstream work on an event that exists only in the reporting vocabulary.

Remaining duration is a new forecast, not simply the original duration multiplied by a remaining percentage. Work may be uneven, and the residual tasks may contain the hardest uncertainty. A package reported substantially produced can still face an uncertain acceptance cycle. The owner should forecast the remaining executable scope from the status date, with its prerequisites and evidence basis. The small app models complete fictional networks rather than actual progress updates; applying it to a remaining network requires deliberate restructuring and a declared origin.

Progress evidence has a date and a scope. A photo, inspection record or supplier report can be accurate at its time yet outdated after change. The integrated manager should know whether the evidence predates a configuration revision or whether it covers the entire package. A reported actual should not be overwritten casually when its basis changes. Preserve the original event and record the reopened obligation. This avoids making history appear different simply because the project later required additional work.

Accepted progress should be measured against controlled outcomes. A package can have interim acceptances that support limited release while final acceptance remains open. The report should name the level. Accepted for procurement, accepted for assembly and accepted for service are not equivalent. This vocabulary allows the network to represent staged readiness without pretending that each stage is final completion. It also prevents a milestone reached for one purpose from being used to justify another purpose with stricter conditions.

An evidence register should connect the reported event to the acceptance criteria, configuration and authority. A signed record can show that a review occurred, but the authority and scope determine whether it releases the successor. If a condition remains open, state its effect. The recipient may accept the package with an exception that does not affect immediate work, or may hold the release entirely. Reporting both as complete makes the schedule less useful at precisely the point where integration judgment matters.

Actual progress can reveal a defect in the model. If a successor begins before its entered predecessor is accepted, investigate whether the logic was unnecessarily restrictive, the work proceeded under qualified release, or the release control was bypassed. Do not simply move the predecessor’s actual date to make the chart consistent. The discrepancy is information. It can improve future logic or identify an exposure that needs corrective action. A programme should be reconciled with reality while preserving the reason for any departure.

The status update should distinguish evidence received from evidence verified. A supplier’s declaration of readiness may be accepted provisionally while an inspection is arranged. That can support a conditional forecast, but it should not be reported as independently verified acceptance. The distinction helps downstream teams choose an appropriate level of reliance. It also makes the eventual confirmation or rejection traceable. Control does not require distrusting every declaration; it requires stating what confidence and authority the declaration actually carries.

A progress meeting should focus on release and residual work. For each material package, ask what accepted outcome occurred, what remains, what evidence is missing and what decision could affect the forecast. This is more diagnostic than asking only whether the package is on track. A green status can conceal an approaching acceptance problem; a red status can reflect a recoverable local delay with no integrated effect. The network and package records should be used together to identify the consequence.

A fictional progress presentation shows installed equipment and labels the package accepted. The photo is genuine within the case, but it proves only that visible equipment was present at the photographed location and time. It does not establish the released configuration, hidden interfaces, test results or recipient acceptance. The manager challenges the claim rather than the image. Evidence quality depends on the proposition being asserted, not on visual persuasiveness.

The producing owner supplies the configuration and inspection records. The recipient identifies an open interface condition. The progress report is revised to distinguish installation evidence from accepted assembly release. This preserves genuine work while keeping the successor condition open. A correction should not erase the earlier photo or imply that nothing had been achieved. It should state the narrower claim the evidence supports and the additional evidence needed for the broader one.

The status date matters. The photo predates a configuration change, and part of the visible work may require modification. The manager records the earlier installation event and the later reopened obligation. Backdating acceptance would hide the change. Overwriting the actual with a new completion date without explanation would lose useful history. The record should retain both states and identify why the accepted scope differs from what was previously shown.

The executive audience needs a concise correction. The manager states that physical installation progressed, but acceptance remains conditional on the interface disposition. The forecast uses the remaining obligation rather than a percentage inferred from the photo. This is not excessive technical detail. It is the minimum information needed to avoid mobilising a successor on an unsupported readiness claim. The linked package record contains the deeper evidence for anyone who needs to inspect it.

The team also changes its reporting rule. Photos can accompany progress, but accepted milestones require the specified evidence and authority. A visual record should carry date, place and scope. This rule is proportionate where imagery is used for consequential release. It does not require every local activity to receive formal certification. The control follows the claim and the reliance it invites.

The lesson extends to dashboards and demonstrations. A functioning component, a successful test in one configuration or a saved document can be real evidence without proving the broader outcome. Report the property actually checked and retain its limits. This fictional case supplies no observed quality rate. It demonstrates how a truthful artifact can still be used to support an untruthful inference if its scope is lost.

The team then examines the remaining basis. Transport readiness, documentation and receiving capacity may govern availability. If those were included within the original supply task, the remaining duration forecast should identify them rather than inventing new scope. If they were excluded, the network perimeter requires correction or clarification. The decision depends on the original package boundary. Progress evidence therefore tests both execution and model completeness. A status meeting can reveal an integration gap that existed before work began.

An omitted receiving obligation is a network-definition problem, not simply a more conservative supply duration. If the network event means accepted availability, an unrepresented inspection or release must be located within the task or represented as a separate predecessor. The team should first establish which scope owner actually carries it, then check for double counting against existing activities. Adding every remaining duty as a new task can be as misleading as deleting it. The authorised correction should preserve the original package basis, identify the topology or duration that changed and recompute successor dates under the corrected acceptance event.

An acceptance-boundary correction can expose dependencies beyond the visible supplier milestone. Receiving access might depend on another package, while an inspection requires a qualified resource or authority window. The next forecast should represent the dependencies material to the declared release, retaining unknowns as evidence requests rather than assigning convenient dates. The app can check supplied network logic and recalculate it. It cannot establish that the added obligation is contractually included, that its duration is supported or that the recipient has authorised the release. Those are distinct duties in the package record.

At closure, preserve the sequence of states. Production, delivery and acceptance dates can inform future estimates if their scope and conditions are retained. A single final completion date loses the waiting and interface information that could explain performance. The historical record should therefore carry enough detail to distinguish productive work from release latency. This does not require collecting every operational event. It requires preserving the events whose meaning and consequence governed the accepted outcome.