Phase lanes, overlap window, risk tail, and protected release gateLive current inputs
Date & Time
Week Number Timeline Calculator
Build an ISO-week critical path from discovery, build, validation, and release phases while accounting for planned overlap, rework exposure, approval lag, and a protected release buffer.
Nominal release point—
Risk-adjusted finish—
Nominal critical-path length—
Calendar saved by overlap—
Expected rework allowance—
Buffer coverage of risk—
ISO week-year seams crossed—
Release confidence—
ISO critical-path ribbons
Phase lanes, overlap window, risk tail, and protected release gate
Four domain-colored ribbons share one ISO-week axis. Validation visibly overlaps build, expected rework extends a translucent risk tail, and the protected buffer begins only after approval.
Phase boundary register
Start, finish, dependency, and slack for every timeline phase
Use the register to verify which phase actually controls the release instead of adding all durations mechanically.
| Phase | Starts | Nominal finish | Duration | Depends on | Overlap | Risk/slack |
|---|
Timeline setup
Model dependencies before naming the release week
- Anchor the first phase to the approved ISO week.
- Estimate each phase from its own work and evidence.
- Enter only overlap that can genuinely run in parallel.
- Use observed rework probability and duration.
- Keep release buffer outside the nominal delivery path.
Critical-path logic
Overlap saves calendar only when dependencies permit it
Validation can start before all build work finishes, but approval waits for the later of build completion and validation completion. The controlling path is therefore determined by phase boundaries, not by a simple sum.
Expected rework is displayed as a risk tail and the release buffer as a protected gate. Combining them would hide whether the plan is absorbing risk or consuming contingency.
Calculation method
Compute the dependency path before adding risk and buffer
Discovery precedes build. Validation starts before build finishes by the allowed overlap. Approval begins after both build and validation are complete. Expected rework and protected buffer are kept as separate extensions.
Detailed calculation process and general formulas
t_build = t_0 + 7Dt_validate = t_build + 7max(B - O, 0)t_approve = max(t_build + 7B, t_validate + 7V)t_nominal = t_approve + At_risk = t_nominal + 7pR + 7FSymbols, meanings, and units
- D, B, V
- discovery, build, and validation durationsweeks
- O
- permitted overlap between build and validationweeks
- A
- release approval lag after phase completiondays
- pR
- probability-weighted rework allowanceweeks
- F
- protected release bufferweeks
Release architecture
Read the timeline as a dependency system
Four results reveal whether the displayed release week is resilient.
Nominal path
—Finish after dependencies and approval, before risk and buffer.
Parallelization value
—Calendar time removed by defensible overlap.
Risk extension
—Probability-weighted rework added after nominal finish.
Protected landing
—Risk-adjusted finish after preserving release buffer.
Decision takeaway: Do not advertise the protected landing as nominal duration; preserve the distinction between work, risk, and buffer.
Timeline controls
Test the dependency assumptions
- Confirm what validation can start before build completion.
- Do not overlap work that shares the same constrained people.
- Measure approval lag in elapsed days.
- Rebaseline after scope changes rather than consuming buffer silently.
Timeline evidence
Sources for phase and risk estimates
- Prior phase actuals
- Dependency map
- Validation entry criteria
- Approval service-level history
- Rework cause log
Practical applications
Decisions this calculator is designed to support
Cross-year product release
A release begins in ISO week 45, overlaps two validation weeks with build, and crosses the new year.
What the result clarifies: The ribbons show the true controlling phase and preserve the week-year label.
Policy implementation timeline
A policy team separates approval lag, expected rework, and a two-week protected launch buffer.
What the result clarifies: Decision makers can see which portion is actual work versus risk protection.
Worked example
Current-input substitution and reconciliation
Model limitations
This four-phase model uses expected rework rather than a probabilistic simulation. It does not represent resource leveling, multiple dependency branches, calendars by team, partial workweeks, or correlated schedule risks.
Week Number Timeline Calculator FAQ
Why is approval based on the later phase finish?
Approval cannot begin until both build and validation evidence are complete.
Can overlap exceed validation duration?
The calculator caps effective overlap so validation cannot begin before the timeline permits.
Is expected rework part of nominal duration?
No. It is shown separately as a probability-weighted risk allowance.
Why add buffer after risk?
The protected buffer is contingency beyond the modeled expected rework burden.