The Dependency Timeline Stress-Test: A 20-Minute Exercise for Checking Whether Your Schedule Is Actually Safe

Published 2026-09-23 22:50 KST

You're two or three weeks into a multi-team project. The schedule looks fine on paper. Milestones are set, owners are named, and nobody has raised a flag yet.

But somewhere in that schedule, one team is counting on another team to finish something first. And the date that first team is expected to deliver? It might be assumed rather than confirmed.

That gap—between what one team thinks will be ready and when another team actually needs it—is where deadline risk quietly builds up before anyone notices. Some practitioner discussions describe this as one of the harder coordination problems to catch early, partly because the gap isn't visible in any single team's view (a practitioner discussion about cross-team dependencies).

This exercise helps you find those gaps now, while there's still time to do something about them.

Why Assumed Dates Are Different From Confirmed Dates

When a project schedule is first built, some delivery dates are confirmed: the team responsible has looked at their workload, agreed to the date, and flagged any concerns. Other dates are assumed: someone made a reasonable guess based on past experience, a rough estimate, or a conversation that never quite turned into a commitment.

The trouble is that assumed dates and confirmed dates look identical in a calendar or a project tracker. Both show up as a date. Neither one carries a label that says "we actually checked this."

As the project moves forward, assumed dates tend to stay frozen while the real situation shifts. The team responsible for the dependency picks up other work. A small scope change adds a few days. A key person is out. None of that gets reflected in the schedule—because nobody went back to check.

By the time the receiving team is ready to start, the dependency they were counting on isn't there yet. And the deadline is now at risk.

What the Stress-Test Does

The dependency timeline stress-test is a focused exercise with one job: for each cross-team dependency in your current schedule, compare the assumed delivery date against the date the receiving team actually needs to start. Then score the gap.

It doesn't replace a full deadline risk audit, which covers estimates, handoff readiness, and context age. It doesn't replace a phase-transition checklist, which you'd run at a phase boundary. It's a narrower tool for a specific moment: mid-project, when you want to know whether your dependency assumptions are still holding.

You can complete it in one sitting, usually under 20 minutes for a project with four to six dependencies.

The Five Columns You Need

For each dependency, you'll fill in five things:

• Dependency name: A short label for what needs to be delivered. For example, "API spec from Platform team" or "Approved copy from Marketing."
• Assumed delivery date: The date currently in your schedule for when this dependency will be ready. Write it down exactly as it appears—don't adjust it yet.
• Receiving team's required start date: The date by which the receiving team needs the dependency in hand to begin their work without delay. This is not the same as the milestone date. It's the practical start date for the downstream work.
• Gap in days: Subtract the assumed delivery date from the required start date. A positive number means the delivery is expected before the receiving team needs it. A negative number means the delivery is expected after the receiving team needs to start—that's a problem.
• Risk rating: Score the gap as Safe, Watch, or At-Risk using the guidance below.

How to Score the Gap

There's no universal rule for what makes a gap safe or dangerous—it depends on the nature of the work and how much flexibility the receiving team has. But here's a practical starting framework:

• Safe: The assumed delivery date is confirmed (not just assumed), and the gap gives the receiving team at least a few days of buffer before they need to start. No known risks on the delivering team's side.
• Watch: The assumed delivery date is unconfirmed, or the gap is tight (one to two days), or there's a known risk on the delivering team's side—such as a competing deadline or a recent scope change. The dependency might be fine, but it needs a check-in.
• At-Risk: The assumed delivery date is later than the receiving team's required start date (negative gap), or the delivery date is unconfirmed and the buffer is zero. Without action, this dependency is likely to cause a delay.

When in doubt, score conservatively. A Watch rating that turns out to be fine costs you one conversation. An At-Risk dependency you missed can cost the whole deadline.

A Filled Example

Here's what a completed stress-test table might look like for a mid-sized product launch project with five dependencies.

In this example, one dependency is already at risk and two need a check-in before the week is out. Without this exercise, all five would look identical in a shared calendar—just dates on a timeline.

What to Do With the Results

Once you've scored your dependencies, the next step is straightforward:

• At-Risk dependencies: Act today. Reach out to the delivering team, confirm the real status, and find out whether the date is recoverable. If it isn't, you need to know now—not the day the receiving team is supposed to start. A dependency handoff brief can help you structure what the delivering team needs to communicate and when.
• Watch dependencies: Schedule a short check-in within the next two to three days. You're not escalating—you're just confirming. One message or a five-minute call is usually enough to move a Watch to Safe or catch a problem early.
• Safe dependencies: No action needed right now. Note them so you don't spend energy re-checking what's already confirmed.

If you're approaching a phase boundary, the phase-transition checklist picks up where this exercise leaves off. And if you want to extend this into a fuller review of estimates, handoff readiness, and context age, the 30-minute deadline risk audit is the natural next step.

Your Blank Worksheet

Copy this table into a document, a shared note, or a whiteboard. Fill it in for every cross-team dependency in your current project. Aim to complete it in one sitting.

Instructions:

1. List every dependency where one team's work must be complete before another team can start. Focus on cross-team handoffs, not internal task sequences within a single team.
2. For each dependency, write down the assumed delivery date exactly as it appears in your current schedule. Don't adjust it—you want to see the assumption, not the ideal.
3. Ask the receiving team (or check your project brief) for the date they actually need the dependency to begin their work. This is often earlier than the milestone date.
4. Calculate the gap: required start date minus assumed delivery date. Positive is buffer. Negative is a problem.
5. Score each dependency as Safe, Watch, or At-Risk using the criteria above.
6. For every Watch or At-Risk dependency, write one next action and assign it a due date before you close the worksheet.

Add rows as needed. Six is a reasonable starting point for most mid-sized projects.

Why These Gaps Are Hard to Spot Without a Shared View

One reason dependency date gaps stay hidden is that teams often track their work in separate places. The Platform team has their sprint board. Marketing has their content calendar. DevOps has their own queue. Each team's dates make sense in their own context—but nobody is looking at all of them on the same timeline at once.

When work lives in separate tools, a two-day gap between a delivery date and a required start date is essentially invisible until someone asks the right question. This exercise is that question, made systematic.

If you'd like a persistent view that keeps your project's dependencies, team schedules, and Google Calendar events on a shared time axis—so gaps like these are easier to spot without running a manual exercise every week—that's what Tindlo is built for. Its multi-layer scheduling view puts teams, projects, and work types on parallel layers so you can see where one team's work ends and another's needs to begin.

The Short Version

Assumed delivery dates and confirmed delivery dates look the same in a schedule. They aren't. The gap between when a dependency is expected to arrive and when the receiving team needs it is where deadline risk hides.

This exercise makes that gap visible—dependency by dependency, in a table you can fill out in under 20 minutes. Safe, Watch, or At-Risk. One next action per problem. Done before the risk becomes a blocker.

Try it on your current project today. You might be surprised by what you find.