How can a client tell whether an apparently fast project schedule will keep slipping?
No responsible team can promise that a project will never be delayed. A credible Wavesteam schedule includes discovery, design, development, integration, testing, remediation, and release; assigns every critical dependency an owner and date; and updates forecasts from completed outcomes. When scope or an external dependency changes, preserve the original baseline and record impact and options instead of quietly moving the deadline.
Fast is not necessarily reckless, and slow is not necessarily reliable. Mature components, clear scope, and parallel work can reduce calendar time. Ambiguous rules, unavailable interfaces, and layered decisions undermine any quotation. Evaluate the evidence behind the estimate rather than comparing two verbal totals.
| Delay source | Early signal | Response | Visible evidence |
|---|---|---|---|
| Scope growth | Backlog grows faster than completion; acceptance changes | Exchange, defer, or add budget after impact review | Original scope, change, old and new baseline |
| Client decision or material | Aging issues; account or content missing | Owner, deadline, and fallback | Dependency register and blocked days |
| Supplier uncertainty | No sandbox, sample, quota, or permission | Prove critical call, mock it, define exit | Interface test and supplier response |
| Underestimated quality or technology | Reopened defects, failed integration, rising rework | Reduce parallelism, fix cause, re-estimate | Build, test, and defect trend |
| Capacity change | Key-person dependency or sustained throughput decline | Transfer knowledge, reassign, forecast again | Staffing and handover status |
| Review or policy change | Official update, rejected material, required redesign | Isolate function or change release | Official response and resubmission state |
Keep the baseline and forecast visible together
The baseline is the agreed plan for a scope, resources, and assumptions. The forecast is today's range based on completed and remaining work and current risk. One must not overwrite the other. If a June baseline becomes July after an approved addition, reporting shows June, the change, approver, and current July forecast instead of rewriting history as “always on plan.”
Count an item only when it meets the definition of done. Merged code without integration, a screen backed by mock data, or a severe open defect is not 90% complete. A runnable build, acceptance examples, and tests are stronger evidence than a polished Gantt chart. Use actual throughput and cycle time to update the remaining range rather than false precision to one day.
Warn while a decision is still possible
A universal “two weeks' notice” is not useful: some dependencies must be solved at inception and some incidents happen today. Record likelihood, impact, trigger, owner, mitigation, latest decision point, and fallback. Escalate while the client can still reduce scope, replace a supplier, or alter release strategy—not after missing the date is inevitable.
A useful weekly report shows the period commitment, actual completion, reasons for carry-over, accumulated blocking, scope change, defect trend, critical path, and latest release range. Record meeting decisions. Client delays remain dependency facts without becoming blame; the purpose is early tradeoff.
Do not apply a mechanical 15% or 20% buffer. An unknown critical API may require a proof first, while repeated low-risk work has a narrower range. A buffer belongs to identified uncertainty and is not free capacity for new features. Adding people can initially slow a coupled critical path through onboarding and coordination.
Milestones use a real environment and critical task. By mid-project, at least one end-to-end loop should operate rather than every module being separately “80% done.” Release gates cover severe defects, production configuration, monitoring, tested recovery, rollback, and an operating owner. Do not push an untested build merely to retain the date.
Wavesteam preserves the initial scope and plan and shows evidence through the backlog, demo environment, versions, tests, and risks. When deviation appears, we provide executable choices—for example retain the date and remove non-core scope, or retain scope and adjust the date—with cost and risk for the client owner to decide. Contractual delay responsibility, client dependencies, and third-party exclusions remain in the written agreement. The Transparent Delivery Standard and service process describe this public method; the Scrum Guide supports inspection and adaptation rather than a guarantee of timeliness.