The Multi-Layer Schedule Health Check: A Worksheet for Finding Where Your Three Layers Have Drifted Apart

Published 2026-10-02 01:14 KST

You kicked off the project with everything lined up. Tasks were tied to milestones. Milestones matched the calendar. The team knew what was happening and when.

That was three or four weeks ago.

Since then, a few tasks moved. A milestone got quietly pushed. Someone booked a review meeting that doesn't quite match the deliverable it's supposed to review. Nobody made a bad decision—things just drifted, the way they do on every live project.

The problem isn't that drift happened. It's that you can't see exactly where the three layers have pulled apart, so you don't know which gap to fix first.

This worksheet gives you a way to find out. It takes about 20 minutes on a live project. You'll score each connection between your task layer, project layer, and calendar layer, then walk away with a short ranked repair list.

Some practitioner discussions describe this kind of misalignment—where cross-team dependencies quietly fall out of sync—as one of the harder coordination problems to catch early, because no single person has a full view of all three layers at once. You can find one such discussion in a practitioner thread about cross-team dependencies.

The article has two parts. First, a filled example so you can see how the diagnostic works. Second, a blank copyable template you can use on your own project right now.

A quick reminder: what the three layers are

If you've already read the Multi-Layer Schedule Builder, you can skip this section. If not, here's the short version.

• Task layer: The individual units of work—tickets, to-dos, action items. Each one has an owner, a rough size, and a due date or target week.
• Project layer: The milestone plan—the named checkpoints that mark when a meaningful chunk of work is done and something can move forward.
• Calendar layer: The booked time—meetings, reviews, handoff windows, and blocked focus time that appear on the team's actual calendar.

These three layers need to stay connected to each other. When they do, a task's due date feeds a milestone, and that milestone is anchored to a calendar event where the output gets reviewed or handed off. When they drift apart, you end up with tasks that float free of any milestone, milestones that assume capacity that's no longer booked, and calendar events that nobody has prepared for.

Why layers drift mid-project

Drift isn't usually caused by one big mistake. It tends to happen through a series of small, reasonable adjustments that nobody connects to each other.

A developer pushes a task by two days because a dependency wasn't ready. The milestone date doesn't move because nobody updated it. A stakeholder books a review meeting for the original milestone date. Now the task, the milestone, and the calendar event are pointing at three different moments in time—and the team won't notice until the review meeting arrives and the work isn't ready.

The three most common drift patterns are:

• Task-to-project drift: Tasks have moved or grown, but the milestone dates haven't been updated to reflect the new reality.
• Project-to-calendar drift: Milestone dates exist in the plan, but the corresponding calendar events—reviews, handoffs, sign-offs—haven't been rescheduled to match.
• Task-to-calendar drift: Calendar events assume certain work will be ready, but no task is explicitly tied to producing that output by that date.

The health check below looks at all three connections at once.

How the scoring works

For each layer-to-layer connection, you'll assign a score from 1 to 3.

• 3 — Solid: The connection is explicit and current. Dates match. Owners are clear. Nothing is assumed.
• 2 — Shaky: The connection exists but relies on an assumption that hasn't been verified recently. A date might be stale, or the link is informal rather than documented.
• 1 — Broken: The connection is missing or clearly wrong. Tasks float free of milestones, or a calendar event has no corresponding deliverable tied to it.

You'll score three connections: task↔project, project↔calendar, and task↔calendar. Then you'll add a short note explaining what's wrong and what would fix it. The lowest scores go to the top of your repair list.

Part 1: Filled example

This example uses a fictional software team three weeks into a feature release. The project has a task board, a milestone plan with four checkpoints, and a shared Google Calendar with review and handoff events booked.

Project snapshot

• Project name: Payments Feature — v2 Release
• Week of check: Week 4 of 8
• Layers in use: Task board (Jira), milestone plan (Notion doc), team calendar (Google Calendar)
• Last reconciled: Kickoff, Week 1

Step 1: List your milestones and their current assumed dates

Write down every milestone in your project layer and the date you're currently assuming it will be hit. Don't check the task board yet—just write down what the plan says right now.

Step 2: Check the task layer against each milestone

For each milestone, ask: which tasks are supposed to feed this milestone? Are those tasks on track to finish before the milestone date? Is every task actually linked to a milestone, or are some floating free?

Task↔Project score: 2 — Shaky. Two of four milestones have task gaps. M2 has a task that has slipped past the milestone date. M4 has a floating prep task with no due date.

Step 3: Check the calendar layer against each milestone

For each milestone, ask: is there a calendar event that corresponds to this milestone? Does the event date match the milestone's assumed date? Is the right person booked?

Project↔Calendar score: 1 — Broken. The integration review event is booked a week before the work will be ready. The QA sign-off has no calendar event at all, which means there's no protected time for it to happen.

Step 4: Check the task layer directly against the calendar layer

This connection is easy to miss. It asks: for each significant calendar event, is there at least one task explicitly responsible for producing the output that event requires? And does that task have a due date before the event?

Task↔Calendar score: 1 — Broken. Two of three calendar events have task gaps. The integration review event will arrive before the work is done. The go/no-go prep task has no due date, so there's no way to know if it'll be ready in time.

Step 5: Connection score summary

Step 6: Ranked repair list

Repairs are ranked by urgency: how soon will this gap cause a problem if left unfixed?

1. Reschedule the integration review event (Project↔Calendar / Task↔Calendar — urgent). The event is booked for Week 5 but the work won't be ready until Week 6. If this isn't moved in the next day or two, the team will show up to a review with nothing to show. Move the event to Week 6, Day 3 or later, and notify the attendees now.
2. Set a due date for the go/no-go prep task and link it to M4 (Task↔Project / Task↔Calendar — urgent). The stakeholder meeting is in Week 7. The prep deck task exists but has no due date and isn't linked to M4. Set the due date to Week 6, Day 4 at the latest, and link the task to M4 so it shows up in the milestone view.
3. Book a QA sign-off event on the calendar (Project↔Calendar — this week). M3 has no corresponding calendar event. Without a booked slot, QA sign-off is likely to get squeezed or skipped when Week 6 gets busy. Book a 90-minute slot in Week 6 and invite the QA lead and the feature owner.
4. Link the unattached frontend task to M2 (Task↔Project — this week). One frontend task isn't linked to any milestone. Link it to M2 so it's visible in the milestone view and doesn't get deprioritized accidentally.

That's the full diagnostic on the filled example. Four repairs, ranked by urgency, each with a concrete action. The whole check took about 18 minutes.

Part 2: Blank copyable template

Copy the sections below into a doc, a Notion page, or wherever your team works. Fill in each table for your live project. The scoring guide is repeated at the top so you don't have to scroll back.

Scoring guide

• 3 — Solid: Connection is explicit, current, and verified. Dates match. Owners are clear.
• 2 — Shaky: Connection exists but relies on an unverified assumption or a date that hasn't been checked recently.
• 1 — Broken: Connection is missing or clearly wrong.

Project snapshot

• Project name: _______________
• Week of check: _______________
• Layers in use: Task board: _______________ / Milestone plan: _______________ / Calendar: _______________
• Last reconciled: _______________

Step 1: Milestone list

Step 2: Task↔Project check

Task↔Project score: ___ / 3    Notes: _______________

Step 3: Project↔Calendar check