Research question

Which delayed inputs can still be absorbed by a delivery plan, and which ones are likely to move the promised finish date? A list of overdue tasks cannot answer that question. It describes lateness but leaves out the dependency chain, remaining room in the plan, and whether downstream work can begin.

NIST IR 8179 presents criticality analysis as a structured way to connect systems and components to the mission they support. NIST SP 800-65 separately identifies schedule slippage, dependencies, resources, and operational outcomes as risks that should be examined together. These sources concern technology risk, not a universal small-business scheduling formula. Their useful transferable principle is to trace importance through the work that depends on an item rather than rank items by age alone.

Unit of analysis and evidence model

Use one dependency edge as the unit of analysis: a defined output from a predecessor that a named successor needs. Record the predecessor, successor, required output, planned ready date, actual ready date, latest usable date, acceptance owner, and current evidence. “Waiting on client” is not a dependency record because it does not identify what is needed or when delay begins to affect delivery.

Calculate observed slack as the time between the latest usable date and the current forecast for an accepted input. Positive slack indicates room remains under the recorded plan. Zero or negative slack indicates that the successor forecast is exposed unless work is resequenced. This is a planning signal, not proof that the final date will slip.

Do not combine parallel dependencies into a simple average. If three inputs must all arrive before a review begins, the last accepted input controls that start. Conversely, an overdue input on an optional branch may have little effect on the committed result. The dependency structure therefore matters more than the count of late items.

A bounded observational study

Freeze one delivery plan before observing it. Preserve later schedule revisions as new versions rather than overwriting the original. For each dependency, capture planned and actual events from the source records. Separate “sent,” “received,” “validated,” and “accepted”; a file in an inbox may not be usable input.

At the end of the observation window, compare exposed edges with actual successor starts. Report four counts: edges with positive slack, edges at or below zero slack, exposed edges followed by a successor delay, and exposed edges absorbed through a documented change. This produces a confusion table rather than a dramatic but weak claim that every warning predicted failure.

Review false alarms and missed warnings. A false alarm may reveal undocumented buffer, an incorrect dependency, or successful resequencing. A missed warning may show that the latest usable date was too optimistic or that an unrecorded dependency existed. Both are improvements to the model, not rows to delete.

Interpretation and operating use

The result should guide attention, not automatically reassign people or alter commitments. An operations coordinator can maintain the dependency register, request missing acceptance evidence, calculate slack from approved dates, and prepare exception views. The project owner decides whether to change scope, sequence, resources, or a customer commitment.

Small samples and frequent replanning limit generalization. A plan with weak logic will generate precise-looking but unreliable slack values. Report the share of dependencies with complete dates and named owners beside every result. If that coverage is low, the primary finding is that the plan is not ready for dependency analysis.

Conclusion

Dependency slack is most useful as a traceable early-warning measure: it connects a specific input to a successor and shows how much room remains under the current approved plan. It should be read alongside evidence quality, dependency completeness, and the action taken after a warning. That is more informative than escalating every overdue task with equal urgency.

OperationsCoordinator can maintain the recurring register and evidence follow-up around this analysis through our operations support services. Scope and delivery decisions remain with the accountable owner.

Sources and limits

These sources support the analytical structure, not a guaranteed forecasting threshold. This article is operational research guidance, not engineering, financial, contractual, or risk-acceptance advice.