The Handoff Window Planner: A Worksheet for Mapping Every Handoff in a New Project Before Work Begins
Published
Most projects start with a milestone list. Dates get set, teams get assigned, and then everyone moves. What often gets skipped is a quieter question: where does work actually cross from one team to another, and how long will each of those crossings take?
Those crossing points are handoffs. When they're not planned at the start, they tend to surface as surprises mid-project—a team waiting on deliverables that weren't packaged for them, a contact who doesn't know they're the receiver, or a transfer window that wasn't budgeted into the schedule at all.
Some practitioner discussions describe this kind of cross-team dependency as one of the harder coordination problems to see in advance, because the gaps between teams aren't often visible in a task list (a practitioner discussion about cross-team dependencies).
This worksheet gives you a way to find every handoff in a new project before the first task starts, size each transfer window, name the contacts on both sides, and place the whole sequence on your project timeline. The output is a single handoff map your team can reference throughout delivery.
Why handoffs need their own inventory
A milestone tells you when a phase ends. A dependency tells you which task needs another task to finish first. A handoff is something slightly different: it's the active transfer of work, context, or responsibility from one team to another. It takes time. It needs a sender and a receiver. And it can fail quietly if either side isn't ready.
When you plan milestones without also planning handoffs, you're scheduling the work but not the transfers between the work. The gap between "Team A finishes" and "Team B starts" is where projects lose days—sometimes weeks—without anyone being able to point to a single cause.
Mapping handoffs at kickoff doesn't prevent every problem. But it does mean the team has a shared picture of where transfers happen, who owns each one, and how much time each transfer needs. That picture is worth building before execution starts, when it's still easy to adjust.
Step 1: List every phase boundary in the project
Start with your milestone list or project phases. For each transition from one phase to the next, ask: does work or responsibility move from one team to a different team at this point?
If the answer is yes, you have a handoff. Write it down. Don't filter yet—just collect every candidate.
Some handoffs are obvious: design hands off to engineering, engineering hands off to QA, QA hands off to deployment. Others are less visible: a research team hands off findings to a product team, a legal team hands off a reviewed contract to procurement, a data team hands off a cleaned dataset to an analytics team.
Try asking these questions at each phase boundary:
- Which team is finishing work here, and which team picks it up next?
- Is there anything that needs to be packaged, explained, or formally transferred—not just completed?
- Does the receiving team need time to review, ask questions, or get oriented before they can start?
- Is there a named person on the sending side who is responsible for the transfer?
- Is there a named person on the receiving side who is responsible for accepting it?
If you answer yes to any of these, treat it as a handoff and add it to your list.
Step 2: Fill in the five-column handoff inventory
Once you have your list of handoffs, move each one into this table. The five columns capture everything you need to schedule and own each transfer.
Here's the structure:
- Handoff Name — A short label that identifies the transfer (for example, "Design to Engineering," "QA Sign-off to Deployment," or "Research Findings to Product").
- Sending Team — The team or person completing the work and initiating the transfer.
- Receiving Team — The team or person who takes over after the transfer.
- Estimated Transfer Window (days) — How many days the transfer itself is expected to take, from the moment the sender packages the work to the moment the receiver confirms they're oriented and ready to proceed.
- Named Contact on Each Side — One person on the sending team and one person on the receiving team who own this handoff. They're the ones who confirm readiness, answer questions, and escalate if something is stuck.
Filled example
Here's what a completed table might look like for a mid-sized product launch project:
| Handoff Name | Sending Team | Receiving Team | Estimated Transfer Window (days) | Named Contact — Sender / Receiver |
|---|---|---|---|---|
| Research to Product | User Research | Product | 3 | Maya (Research) / Jordan (Product) |
| Product Spec to Design | Product | Design | 2 | Jordan (Product) / Sam (Design) |
| Design to Engineering | Design | Engineering | 3 | Sam (Design) / Alex (Engineering) |
| Engineering to QA | Engineering | QA | 2 | Alex (Engineering) / Priya (QA) |
| QA Sign-off to Deployment | QA | DevOps | 1 | Priya (QA) / Chris (DevOps) |
| Build to Marketing | Engineering | Marketing | 4 | Alex (Engineering) / Dana (Marketing) |
Notice that "Build to Marketing" runs in parallel with the QA process. That's intentional—and it's exactly the kind of overlap that's easy to miss until you lay all the handoffs out in one place.
Step 3: Estimate each transfer window honestly
The transfer window is the part that often gets skipped. It's common to plan when work will be done, but not how long the transfer itself takes.
A transfer window covers the time between "the sender considers this ready" and "the receiver is oriented and can move forward." That gap includes:
- Time for the sender to package and document the work
- Time for the receiver to review what they've been handed
- Time for questions, clarifications, and any back-and-forth
- Any formal sign-off or approval step in between
For a simple handoff between two people who work closely together, this might be half a day. For a handoff between teams in different time zones, or where the deliverable is complex and unfamiliar to the receiver, it might be three to five days.
Try to estimate based on the actual complexity of what's being transferred, not on optimism. If you're not sure, ask the named contacts on each side what they'd need to feel genuinely ready—not just technically in possession of the files.
Step 4: Place each handoff on the project timeline
With your inventory filled in, the next step is to put each handoff on the timeline. This is where the map becomes useful for scheduling.
For each handoff:
- Find the milestone or task completion date that triggers the handoff—when the sending team finishes their phase.
- Add the transfer window duration to get the date when the receiving team can realistically begin their work.
- Mark both dates on your project timeline: the handoff start date and the handoff end date.
When you do this for every handoff in sequence, two things become visible that weren't visible before:
Gaps: Places where the receiving team can't start until the transfer window closes, but the project schedule assumes they start immediately. These gaps need to be absorbed somewhere—either by adjusting the milestone dates or by shortening the transfer window through better preparation.
Overlaps: Places where two handoffs are happening at the same time, and a named contact appears in both. If Jordan is the receiver in the Research-to-Product handoff and also the sender in the Product-to-Design handoff, and those windows overlap, Jordan may not have enough bandwidth to do both well. Seeing this at kickoff means you can adjust before it becomes a bottleneck.
Step 5: Review the map as a team before execution starts
Once the handoff map is built, walk through it with the project team—ideally in the kickoff meeting or a short follow-up session.
You're looking for three things:
- Missing handoffs: Does anyone see a transfer point that isn't on the list? Ask each team lead to look at the phases just before and after their work and confirm whether a handoff is captured.
- Disputed transfer windows: Does the estimated window feel realistic to the named contacts? If the receiver thinks three days isn't enough, better to know now.
- Unconfirmed contacts: Is every named contact actually aware they're named? A handoff owner who doesn't know they own it isn't really an owner.
This review doesn't need to be long. Thirty minutes with the right people in the room can surface problems that would otherwise take weeks to discover.
Blank copyable worksheet
Use this table at the start of any new project. Fill in one row per handoff.
| Handoff Name | Sending Team | Receiving Team | Estimated Transfer Window (days) | Named Contact — Sender / Receiver |
|---|---|---|---|---|
After filling in the table, add a sequencing column or a separate timeline view that shows each handoff's start and end date relative to the project milestones. That's your handoff map.
How this fits into the broader handoff lifecycle
This worksheet covers the kickoff phase: finding and scheduling all handoffs before work begins. It's the first step in a sequence.
- Once you know which handoffs exist and when they're scheduled, The Handoff Timing Planner helps you size and structure a single handoff's transfer window in more detail.
- As the project moves forward, The Mid-Project Handoff Context Worksheet helps you check whether the context behind each upcoming transfer is still intact—or whether it's drifted since kickoff.
- When a specific handoff is approaching, The Pre-Handoff Readiness Check gives you a way to verify that both sides are genuinely ready before the transfer begins.
- For the dependencies that sit alongside handoffs—tasks that need to be completed before a transfer can happen—The Cross-Team Dependency Register is a companion worksheet for naming and scheduling those at kickoff.
Together, these tools cover the full arc: plan the handoffs, time each one, check context mid-project, and verify readiness when a transfer is imminent.
Keeping the handoff map visible across the team
A handoff map that lives only in a document tends to get forgotten. The transfer windows you identified at kickoff need to appear somewhere the whole team can see them alongside the rest of the schedule—otherwise the map doesn't change behavior, it just exists.
Tindlo is a multi-layer operational scheduling platform that separates teams, projects, and work types into parallel layers on a shared time axis. Its Google Calendar integration gives you a practical place to surface this. Once you've identified each handoff and its transfer window, you can place those windows on a shared calendar so they're visible next to the milestones and tasks they connect. The team can see when a transfer is approaching, who owns it, and how it fits into the surrounding schedule—without having to dig through a separate document.
If you're starting a new project and want a way to keep the handoff map in front of the team throughout delivery, Tindlo is worth a look.
A quick summary of the steps
- Step 1: Walk every phase boundary and ask whether work or responsibility crosses from one team to another. List every handoff you find.
- Step 2: Fill in the five-column inventory: Handoff Name, Sending Team, Receiving Team, Estimated Transfer Window, Named Contact on Each Side.
- Step 3: Estimate each transfer window based on the real complexity of the transfer—not just the optimistic version.
- Step 4: Place each handoff on the project timeline. Look for gaps where the schedule assumes instant transfer, and overlaps where one person owns two simultaneous handoffs.
- Step 5: Review the map with the team before execution starts. Confirm no handoffs are missing, windows are realistic, and every named contact knows they're named.
That's the whole process. It takes less time than most kickoff meetings, and it surfaces the kind of problems that are easy to fix at the start and expensive to fix in the middle.