Workback Schedule: A Downloadable Plan From Deadline to Today
Build a workback schedule with a downloadable template, an eight-day worked example, dependency checks, and practical options when the dates do not fit.
A workback schedule starts with a required finish date and works backward through the tasks, reviews, and handoffs needed to reach it. Its purpose is to reveal the latest feasible start and expose conflicts early. It does not make an impossible deadline possible merely by placing dates beside every task.
The most useful result may be discovering that you need to change the scope today, rather than apologize for the same problem next Friday.
What goes in the schedule?
Record the deliverable, owner, duration, predecessor, start, finish, and acceptance check for each meaningful step. Count review and handoff time explicitly; a draft awaiting approval is not a finished delivery.
Download the workback schedule template. The plain text file includes a blank planning structure, the worked example, and a feasibility checklist. It uses numbered working days so you can map it to your own calendar without inheriting someone else's holiday assumptions.
| Field | What it prevents |
|---|---|
| Deliverable | Scheduling vague activity without a finish condition |
| Owner | Assuming someone else has accepted the task |
| Duration | Treating a deadline as an estimate of effort |
| Predecessor | Starting before required inputs exist |
| Start and finish | Hiding how early work must begin |
| Acceptance check | Calling a submitted draft complete |
| Calendar constraints | Depending on unavailable people or nonworking days |
Asana's workback scheduling guide describes reverse planning around a deadline, with dependencies, milestones, and owners. Those principles work in a shared document too. Choose a tool your collaborators will actually keep current.
Use the schedule for a bounded delivery: a presentation, a report, a workshop, or a reviewed document. If your real problem is deciding which ongoing responsibilities deserve attention, start with weekly planning instead.

How do you build it backward?
Begin with what must be accepted at the end, identify the step immediately before it, and continue until you reach work you can start. Then run the sequence forward to check that the backward arithmetic describes a possible working plan.
- Define the finish. “Send the report” and “deliver the approved report” have different dependencies.
- List the necessary outputs. Include research, drafting, review, revision, and delivery when they apply.
- Ask owners for durations. Record uncertainty instead of choosing the shortest imaginable estimate.
- Connect predecessors. Identify which inputs must be complete before each task begins.
- Place the final step. Work backward using the relevant working calendar.
- Check availability and capacity. A free date in your calendar says nothing about the reviewer's calendar.
- Confirm the commitment. Share the assumptions and obtain agreement before publishing a promise.
Separate effort from elapsed time. A review may require an hour of attention but occupy two working days because the reviewer has other obligations. Assigning “one hour” to the timeline would conceal that waiting period.
Atlassian's project planning guidance connects deliverables, resources, scope, and timing. Check these together rather than letting the deadline decide every other number.
If two tasks can genuinely run independently, place them in parallel. If both require the same person at the same time, the apparent shortcut may disappear. Use the weekly focus capacity calculator to examine your own available work time before accepting overlapping commitments.
What does a complete example look like?
An eight-working-day example shows the dependency chain without implying that every similar project takes eight days. This fictional team is preparing a short reviewed briefing; the durations are chosen for illustration and must be replaced with estimates from the actual owners.
| Step | Duration | Working days | Must follow | Finish test |
|---|---|---|---|---|
| Gather approved inputs | 2 days | 1–2 | Confirmed brief | Sources complete |
| Draft the briefing | 3 days | 3–5 | Approved inputs | Reviewable draft |
| Review and revise | 2 days | 6–7 | Draft | Reviewer accepts revision |
| Final checks and delivery | 1 day | 8 | Accepted revision | Correct file delivered |
The sequential chain is 2 + 3 + 2 + 1 = 8 working days. If day 8 is your required delivery day, gathering inputs must start on day 1. This example contains no separate contingency allowance; add one when the uncertainty warrants it.
Suppose delivery is due Friday and your team works Monday through Friday with no intervening holidays. Day 8 is Friday, day 7 Thursday, day 6 Wednesday, day 5 Tuesday, day 4 Monday, and days 1–3 are Wednesday through Friday of the preceding week.
That mapping places the first work on the previous Wednesday. Do not copy those weekdays if a reviewer works a different schedule or an office closure occurs during the period.
Now check the sequence forward. Are the inputs available on day 1? Can drafting start on day 3? Has the reviewer reserved days 6–7? Does final delivery require another person's permission? An answer of “probably” belongs in the assumptions, not invisibly inside the schedule.
Asana's guide includes milestones at handoffs. In this example, “draft ready for review” is a useful milestone because it tells the next owner that their work can begin.
What if the dates do not fit?
Change a real constraint rather than shrinking estimates until the table looks acceptable. Your practical choices are to reduce scope, alter a genuine dependency, add usable capacity, or renegotiate the deadline.
For the fictional briefing, imagine that the reviewer is unavailable on days 6–7. Moving the review row onto those dates again does not solve anything. Consider these options:
- Reduce the first delivery: send an agreed factual summary, with the fuller analysis later.
- Review earlier material: ask whether the reviewer can approve the outline and sources before the complete draft exists.
- Use an authorized alternative: confirm whether another person can make the same approval decision.
- Move delivery: show the dependency and propose the earliest credible replacement date.
Earlier review is helpful only if the reviewer can make a meaningful decision on partial material. Do not assume that splitting a task removes the need to review the finished version.
Here is an original message you can adapt: “The current plan needs a review before final delivery. That review window is unavailable. We can deliver a narrower approved summary Friday, or the full briefing after the reviewer returns. Which outcome should I plan around?”
The workback guidance also recommends allowing for handoff uncertainty. Keep any buffer visible and explain what it covers. There is no universal percentage that makes every schedule reliable.

How do you keep the plan current?
Preserve the agreed baseline and update a separate current forecast when reality changes. This lets people see both the commitment and the expected outcome instead of losing the original agreement every time a cell moves.
At a check-in, ask what is complete, what input is missing, and whether the next owner can still start. Update affected dependencies together. A late input should prompt a conversation about the finish, not a silent transfer of pressure to the next person.
Record the decision when scope or delivery changes. Include the reason, the person who agreed, and the revised expectation. Keep completed work visible so the plan remains a record of reality as well as a forecast.
Bring today's necessary step into your daily planning template. Do Only 3 Things a Day helps with that daily selection: the schedule identifies the sequence, while the daily plan protects attention for the part you can move now.
Frequently asked questions
Is a workback schedule a Gantt chart?
No. Workback describes how you plan from the finish date. A Gantt chart is one way to display the resulting tasks and dates. A simple table can also hold a workback plan.
Should I count weekends?
Count the days on which the relevant work can actually happen. Include different owner calendars, holidays, and approval availability. Calendar days and working days are not interchangeable.
How much buffer should I add?
Base it on uncertainty, past experience, dependencies, and the consequences of delay. Label the allowance explicitly. A fixed percentage without those checks can create false confidence.
Can tasks overlap?
Yes, when their inputs and owners allow it. Record the partial handoff or independent work that makes overlap possible. Merely drawing bars beside each other does not remove a dependency.