Durations need an estimation basis

A duration estimate is meaningful only after the task's beginning and end are defined. Design work that starts from an approved brief differs from design work that starts while requirements remain disputed. Equipment readiness at a factory differs from equipment readiness for site assembly. An estimate that silently includes missing prerequisites can look cautious while concealing an undefined scope. An estimate that excludes them can look efficient while creating an unmodelled waiting period. The basis record should say what conditions the estimate assumes at its start and what evidence marks its finish.

Distinguish effort, elapsed time and lead time. Effort describes the work a resource performs. Elapsed time describes the interval between the defined start and finish. Lead time can include waiting, approval, production, transport and receiving. Converting effort to elapsed duration requires assumptions about resource availability, working time and interruptions. The companion app accepts elapsed weeks on a continuous basis. It does not infer working calendars or resource allocation from an estimate. A planner must translate the task basis deliberately before entering it.

The reference equipment supply task has optimistic, most-likely and pessimistic assumptions of 6.00, 8.00 and 10.00 weeks. These are authored fictional inputs, not estimates derived from supplier performance. Their purpose is to expose how the engine transforms estimates and propagates dependencies. In a real package, the corresponding values should refer to a stated scope, release condition, supplier basis and delivery boundary. A numerically tidy range is weak evidence if its endpoints refer to different outcomes.

Estimate ranges should reflect mechanisms. An optimistic case might assume prompt review and uninterrupted production. A pessimistic case might include a plausible additional test or a constrained shipping window. The record should explain which mechanisms are represented, whether they can occur together and what lies outside the range. Calling a value pessimistic does not make it an outer bound on all possible outcomes. Refusal of an approval, fundamental redesign or insolvency may require separate scenarios rather than a longer value on the same task.

The source of an estimate should remain visible through aggregation. A binding supplier commitment, a preliminary quotation, an experienced judgment and an analogy to another project carry different conditions. A single weighted mean can conceal that difference. The estimate record should preserve the evidence type and confidence rationale alongside the numerical assumptions. Confidence in the evidence is not itself a probability distribution. It describes why the team considers the basis suitable for the current decision and what further evidence could materially change it.

A continuous elapsed-week model deliberately avoids working-calendar complexity. That simplifies comparison, but it limits transfer to an executable programme. A task spanning a shutdown, holiday, seasonal access restriction or scheduled review window cannot automatically be forecast by adding continuous durations to a real calendar date. The operational schedule must encode the relevant calendars or translate the durations with a documented method. The paper's relative week outputs should therefore remain relative. Presenting them as actual completion dates would add assumptions that the frozen studies do not contain.

Waiting can be embedded in a task or shown as a separate release activity. The choice depends on control. If inspection booking is governed by a distinct owner and materially drives a successor, separate representation improves visibility. If small routine waiting is part of a repeatable supplier lead time supported by evidence, embedding it may be appropriate. The same waiting must not be included twice. A basis reconciliation should compare the task's duration contents with the dependency register and identify where each material approval, inspection or transport interval appears.

Estimate updates should distinguish new evidence from managerial pressure. A shortened duration can be legitimate when a supplier confirms capacity or a changed method reduces work. It is unsupported when the only new fact is that the desired target is earlier. The estimate log should identify the evidence that changed, the mechanism by which it affects duration and any compensating exposure. Additional shifts may reduce elapsed time while increasing resource cost or fatigue risk. Those consequences belong in the recovery decision even though the small app does not compute them.

Historical rates should be normalised before use. Similar task names can conceal differences in scope, equipment, workforce, calendar, location or acceptance. A previous installation completed quickly because receiving works were already accepted; an analogy that includes those works in the new task is not comparable. The record should preserve both similarities and differences. A historical rate is useful when its transfer is argued, not when a single number is copied into a blank cell and later described as experience.

Avoid false precision in the basis record. Decimal durations can be appropriate for a short model experiment, but the displayed precision should not imply that uncertain field work has been measured to that accuracy. The frozen ledger preserves the engine's exact scalar for reproduction; the manuscript formats it for interpretation. In operational planning, precision should follow the decision resolution and evidence. Rounding that changes an acceptance window deserves attention. Extra digits that change no decision can distract from the much larger uncertainty in scope and readiness.

A fictional review receives similar-looking duration ranges from two package owners. One range comes from a confirmed supplier slot under a released specification. The other is a judgment based on an earlier project with a different acceptance boundary. The numbers alone appear comparable. The estimate-basis review shows that their evidence is not. This does not automatically make the judgment unusable. It means the decision should recognise its transfer assumptions and the evidence needed before stronger reliance.

The confirmed slot still has conditions. Production may depend on a complete release, timely inspection and no configuration change. The reviewer records those conditions rather than treating the supplier's confirmation as unconditional certainty. The analogy requires a different check: which parts of the earlier scope match, which differ, and whether its reported finish included receiving acceptance. The ranges can remain numerically unchanged after this review while their permitted use becomes clearer.

The reviewer asks both owners to describe the optimistic and pessimistic mechanisms. The supplier's cases may concern capacity and inspection timing. The analogy may concern design maturity and workface access. If these cases refer to different scopes, the range needs correction. If the mechanisms are coherent but weakly evidenced, the record should state that weakness. A numerical transformation cannot repair the missing evidence. The model can calculate a mean, but it cannot make the input basis more credible.

The sponsor needs an internal sequencing choice before all evidence is available. The manager can use both ranges as explicitly conditional screening assumptions, provided the consequence is bounded. A later external commitment requires the missing confirmation or a suitable alternative analysis. This staged use prevents the project from stopping unnecessarily while also preventing a provisional estimate from silently becoming a firm promise. The same number can support different levels of reliance when its evidence boundary is stated.

The team defines an evidence update trigger. If the specification changes, the supplier slot is rechecked. If the receiving scope becomes materially different from the analogy, the judgment is revised. The forecast should move when those conditions change, even if management prefers the earlier date. The trigger is tied to the estimate's causal basis rather than a generic review interval. This makes updates more informative and less dependent on whether someone happens to notice a mismatch.

The lesson is that confidence cannot be inferred from the width or symmetry of a range alone. A narrow range may conceal missing mechanisms, while a wider range may reflect careful uncertainty analysis. The reviewer should inspect the scope, cases and evidence before interpreting precision. This fictional comparison supplies no calibrated distribution and no empirical claim that one estimate type is always superior. It demonstrates how the basis determines the appropriate use.

An estimate review should begin with the deliverable and release conditions. Ask the owner to describe what happens during the task, which resources and information are assumed available, and what could prevent acceptance. Only then compare numerical ranges. This sequence prevents the discussion from becoming a negotiation over an unsupported midpoint. It can also reveal that the task should be split. A technically straightforward production period may be preceded by an uncertain design decision whose outcome governs whether production should begin at all.

The reviewer should test whether the range is internally ordered and whether its cases refer to the same scope. The app rejects an optimistic estimate above the most-likely estimate or a most-likely estimate above the pessimistic estimate. This validation protects arithmetic integrity. It does not prove the range is well calibrated. A consistently ordered set of guesses can still omit important mechanisms. The estimate register should record which uncertainties are represented as duration variation and which remain outside the task model.

For the fictional receiving works, the estimate conversation identifies access, released dimensions, inspection capacity and required utilities as potential readiness assumptions. The owner decides which are embedded in the task and which appear as predecessors or separate activities. This is an illustrative reasoning exercise. It offers no site-specific construction durations. The important output is a traceable basis: a successor can see what the completion claim means, and a later delay review can distinguish failed assumptions from poor execution under assumptions that actually held.

Estimate ownership should include the right to state uncertainty. If an owner is required to give only the date management wants, the baseline loses diagnostic value. A useful challenge process can retain a sponsor target while recording the owner's current forecast and the actions needed to close the gap. This makes disagreement inspectable. It also permits a decision to accept exposure knowingly, instead of hiding that exposure by editing the estimate. Control depends on truthfulness about the basis more than uniform optimism in the presentation.

After review, freeze the basis with the estimate version. Future updates should point to the earlier evidence and identify what changed. If the receiving method changes, the task may no longer be comparable to its baseline duration. If only the review queue grows, the physical scope may remain comparable but the waiting assumption changes. These distinctions support a fair and useful variance explanation. A simple record of old and new numbers cannot show whether the forecast changed because the project learned, the scope changed or execution departed from the agreed plan.