Practical workflows
Fit a Demo Workback Plan to One Person’s Capacity
Two tasks can be independent on paper and still compete for the same person’s working day.
Build a workback plan in two passes. First connect the work that must finish before other work can begin. Then check whether the named people can actually do the tasks at the same time. A dependency diagram permits overlap; it does not supply the capacity to make that overlap happen.
Here a builder has ten working days before a product demo. A dependency-only calculation suggests nine days, including a buffer. But the builder owns both tasks on the parallel branch, and each needs full attention. Once that conflict is resolved, the original plan needs eleven days. The useful deliverable is a revised schedule with an explicit scope decision, not an optimistic countdown.
Define the demo and the unit of time
The original request is to show two agreed workflows with prepared sample data in a rehearsed demo. Later in this example, an explicit scope decision reduces that request to one workflow. Neither version is a claim that a complete production product is ready. The plan includes scope definition, a prototype, data preparation, assembly, rehearsal and one working day of buffer.
Call the start of the demo T0. In the tables, T-4 means a boundary four working days before T0. A task running from T-4 to T-3 consumes one full working day. Finish and start boundaries can meet without counting that day twice. The model assumes no work outside the declared working calendar.
Before applying this to a real date, define the working hours, unavailable days, holidays, timezone and exact demo cutoff. Ten calendar days and ten available working days are different inputs. A day-based countdown cannot perform that conversion on its own.
Draw prerequisites before assigning dates
A defines the scope. B builds the prototype and C prepares sample data; both require A but neither requires the other in this fictional dependency model. D assembles the demo and requires both B and C. E rehearses the assembled demo. The buffer sits between the end of rehearsal and T0.
If B and C could run with independent capacity, the elapsed duration would be 1 + max(4, 2) + 1 + 2 + 1 = 9 working days. The two-day data task fits inside the four-day prototype branch. That calculation is valid only under the overlap assumption. It is not yet a promise that one builder can finish in nine days.
Put the shared owner back into the plan
The same builder owns B and C, and both estimates assume full-attention days. There is no spare capacity to place two days of C inside four full days of B. One possible resource-feasible order is B followed by C. Reversing those two tasks would take the same total time here.
The elapsed duration is now 1 + 4 + 2 + 1 + 2 + 1 = 11 working days. Working backward from T0 gives the schedule below. Because the builder becomes available at T-10, the scope task would need to start one working day before availability. The gap is exactly one day under these assumptions.
Do not solve that gap by drawing overlapping bars while leaving both tasks assigned at full capacity to the same person. Part-time interleaving is possible only if you revise the capacity allocation and duration estimates. Switching between tasks does not create an additional working day.
| Step | Duration | Prerequisite | Owner | Start → finish |
|---|---|---|---|---|
| A · Define scope | 1 day | None | Builder | T-11 → T-10 |
| B · Build prototype | 4 days | A | Builder | T-10 → T-6 |
| C · Prepare sample data | 2 days | A; placed after B for capacity | Builder | T-6 → T-4 |
| D · Assemble demo | 1 day | B and C | Builder | T-4 → T-3 |
| E · Rehearse | 2 days | D | Builder | T-3 → T-1 |
| Buffer | 1 day | E complete | Reserved time | T-1 → T0 |
Choose a change that actually removes the conflict
There are three useful changes in this example. Narrow the prototype enough to reduce B from four full days to three; assign C to another qualified, available person; or move the demo one working day later. Each changes a real constraint. None is guaranteed merely because it appears in a table.
For the revised plan, the builder and demo owner agree to show one workflow instead of two. The builder estimates that the narrower prototype needs three days. The data, assembly and rehearsal estimates remain valid for that workflow. This is an explicit assumption to review, not a general claim that removing a feature saves one day.
A second owner is an alternative only if that person can prepare the data independently after A and any coordination or handoff effort is included. Under the original simplified estimates, restoring that overlap returns the plan to nine days. If the original scope and owner both remain fixed, moving T0 one working day later is the remaining schedule change.
| Option | Result in this example | Condition to confirm |
|---|---|---|
| Narrow B: 4 → 3 days | 10 working days | One-workflow scope is accepted; revised effort is credible |
| Give C a second owner | 9 working days | Owner is qualified and available; coordination fits the estimate |
| Move demo by 1 working day | 11 working days available | Demo owner accepts the new date and dependencies allow it |
Write the ten-day plan as a handoff
With the narrower scope, begin A at T-10, run B for three days, then C for two. The later stages keep their original boundaries. The plan now fits the available ten working days and still keeps the one-day buffer visible.
Define what each handoff contains. A ends with the agreed workflow and the excluded second workflow written down. B delivers a runnable prototype for the agreed path. C delivers sample data that matches that path. D ends when the assembled path can be demonstrated. E ends after a complete rehearsal and resolution or explicit disclosure of remaining demo issues.
Those handoff descriptions help uncover missing work. If importing the sample data needs another day, add it and recompute; do not hide it in “assembly.” If rehearsal discovers a blocker, use the buffer consciously and record how much remains. Buffer is available time for uncertainty, not evidence that the demo is already ready.
| Step | Duration | Start → finish | Completion check |
|---|---|---|---|
| A · Agree narrower scope | 1 day | T-10 → T-9 | One workflow agreed; second explicitly excluded |
| B · Build narrower prototype | 3 days | T-9 → T-6 | Agreed path runs |
| C · Prepare sample data | 2 days | T-6 → T-4 | Data matches the agreed path |
| D · Assemble demo | 1 day | T-4 → T-3 | Prototype and data work together |
| E · Rehearse | 2 days | T-3 → T-1 | Complete run; remaining issues resolved or disclosed |
| Buffer | 1 day | T-1 → T0 | Remaining allowance recorded |
Convert the feasible plan to real dates
Only after choosing a feasible option should you map the working-day boundaries to actual dates. Check each date against the working calendar and the demo’s exact time. Put those dates, the accepted scope and the dependency record in the project system that holds the detailed work.
Date Countdown Lite can make the manually entered demo date visible as a day-based countdown, with an optional local reminder. It does not calculate this dependency graph, assign owners, convert working days or decide whether the prototype is ready. Keep the exact cutoff and timezone in the authoritative event or project record.
When a duration, owner, scope or demo date changes, update the detailed plan first and then update the saved countdown date if needed. Review the next incomplete handoff and the remaining buffer. “Days left” becomes useful when it leads to that decision; it is not a substitute for the decision.
Copy the complete revised plan
FICTIONAL DEMO WORKBACK — revised v2 Outcome at T0: demonstrate ONE agreed workflow with prepared sample data after rehearsal. The second workflow is excluded; this is not a production-readiness claim. Owner: one builder. B and C each require full attention; do not overlap them. Time convention: T0 = demo start. T-4 to T-3 is one full WORKING day. Use a declared working calendar; map to dates only after confirming hours, holidays, availability, timezone and exact cutoff. Available interval: T-10 to T0. A: agree narrower scope | 1 day | T-10 to T-9 | no predecessor Done: one workflow agreed; second workflow explicitly excluded. B: build narrower prototype | 3 days | T-9 to T-6 | needs A Done: agreed path runs. Three-day estimate depends on accepted scope reduction. C: prepare sample data | 2 days | T-6 to T-4 | needs A; follows B for owner capacity Done: data matches the agreed path. D: assemble demo | 1 day | T-4 to T-3 | needs B AND C Done: prototype and data work together. E: rehearse | 2 days | T-3 to T-1 | needs D Done: complete run; remaining issues resolved or explicitly disclosed. BUFFER: 1 day | T-1 to T0 | record use and remaining allowance. Total: 1 + 3 + 2 + 1 + 2 + 1 = 10 working days. Original scope needed 11 with one owner; nine days assumed independent B/C capacity. If the three-day prototype estimate is not credible: reconfirm scope, a qualified second owner, or a later demo date. Do not silently overlap full-attention tasks or delete rehearsal/buffer. Still to fill for real use: authoritative event reference, actual dates, timezone/cutoff, calendar exceptions and scope approval reference. Change rule: revise detailed schedule first; then update any day countdown. Readiness follows handoff evidence, not the countdown value.
A complete example to adapt to your task.
Open the complete text to save as a file ↗