A seven-day dependency schedule can be logically correct and still be impossible for the available team. The schedule describes when tasks could follow one another under its model; a staffing plan describes who can do the work and when. Confusing the two can turn a neat network diagram into an unrealistic promise. Read the dependency calculation first, then inspect resource availability separately. The invented example in this guide keeps the network small enough that you can verify every important timing without treating the calculator as a black box.
Describe relationships before choosing a finish date
Give each task a unique identity and enter only the prerequisites it actually needs. Our example starts with a Brief lasting two days. Review lasts three days after Brief. Build lasts four days after Brief. Release lasts one day after both Review and Build. A dependency says which work must finish first; it does not say which person is available or whether a supplier is open on a particular date. Workday Kit uses finish-to-start relationships without lags, calendars or resource leveling.
PMI's scheduling material explains the role of dependency calculations and the distinction between timing logic and resources. For this exercise, all durations use the same elapsed project-day basis. Do not mix an estimate in hours with another in days unless you convert them under a stated working-time assumption. Likewise, do not use an imposed deadline as though it were evidence that the work can be completed inside it. Start with a network that represents the actual prerequisites, then compare its outcome with the desired finish.
Work through the forward timing
Brief starts at project day zero and finishes at day two. Review can then run from day two to day five. Build can run from day two to day six. Release waits for both, so its earliest start is day six and its earliest finish is day seven. Brief, Build and Release form the controlling chain in this example. The calculator's seven-day result is therefore independently checkable by adding two, four and one along that chain.
The shorter branch does not disappear. Review still has to finish before Release can begin. If Review takes longer than expected, it may use its flexibility and become controlling. A task outside the current critical chain is not an optional task, and slack is not a suggestion to stop monitoring it. The network's logic provides a way to explain where flexibility exists under the supplied durations, not a statement about the business importance or difficulty of each activity.
Read slack as a timing difference
A backward timing pass asks how late each task could finish without moving the model's project finish. Review can finish at day six rather than day five, so its total slack is one day. Brief and Build do not have that freedom in this network. PMI's discussion of forward and backward passes provides the methodological background. Workday Kit shows earliest and latest timings in the result table so you can inspect the difference rather than relying only on the list of critical task names.
More than one branch can be critical. If Review were four days instead of three, both Review and Build would lead to the same Release start. All tasks on those zero-slack branches would appear as critical. Do not read a comma-separated list of critical tasks as one uniquely ordered path when the network contains parallel branches. Check the dependencies and the table together. A cycle or missing predecessor is rejected because the tool cannot calculate a meaningful acyclic schedule from those inputs.
Separate uncertainty from the network arithmetic
You may be unsure how long a particular task will take. For a separate estimation exercise, optimistic two days, most likely four and pessimistic eight produce a PERT expected duration of approximately 4.33 days and standard deviation one day. These describe one supplied uncertainty estimate. They do not establish the probability that the entire project finishes by day seven. The workflow deliberately does not silently replace every network duration with that one result or claim that averaging task estimates guarantees a project outcome.
Check the people plan on its own terms
The companion workload example lists Ada with twenty available hours and Sam with ten in one planning period. Tasks of twelve, six and six hours produce twenty-four assigned hours, with eighteen assigned to Ada and six to Sam under the tool's heuristic. Neither person exceeds their supplied total capacity. That checks aggregate loading only. It does not establish that the right person is free on the exact days required by the dependency network, or that every task can be performed by either person.
Before promising a delivery date, reconcile those two views. Identify skills, non-working days, task splits and competing commitments that the simple models omit. Recalculate the network if a real resource restriction forces a sequence change. Save the dependency timings and staffing assumptions together, but keep their meanings distinct. A responsible handoff can say “seven days under these relationships and durations” while also listing the resource checks still required. That is more actionable than presenting a mathematically correct network as a fully staffed delivery guarantee.