Creating a Project Schedule
A project schedule is not a list of dates. It is the architectural plan of time — a model of how the work fits together, what has to wait for what, and where the whole thing is fragile.
Most schedules fail for the same reason: they are built as a wish rather than as a model. Someone lists the tasks, guesses the durations, adds them up, and presents a number that was never achievable. This chapter is about building the other kind.
In short
- Sequence before you estimate. Dependencies determine the shape of the schedule; durations only determine its length.
- The critical path is your real deadline. Everything else has slack you can spend.
- Estimate with three numbers, not one. A single figure hides the uncertainty rather than removing it.
- Hold buffer centrally and visibly. Buffer hidden inside individual tasks disappears without anyone deciding to spend it.
Why build a project schedule at all?
- To make the flow of work visible so everyone shares one view of the process rather than five private ones.
- To attach a timeframe and a person to every piece of work — unowned tasks are the ones that slip silently.
- To align expectations about pace between the team and the people waiting on it.
With those in place, tracking progress and reacting to delay becomes a mechanical activity rather than an argument.
The five steps to build a project schedule
1. Identify the tasks (from the WBS)
Start from the Work Breakdown Structure you produced when defining scope. Breaking the scope down first, then scheduling, is what stops you from discovering forgotten work in week six. If a task is not in the WBS, it is not in the schedule — and it is not in scope either.
Rule of thumb: break down until each bottom-level task is something one person could finish in somewhere between half a day and two weeks. Smaller than that and you are managing a to-do list; larger and you cannot tell whether it is on track.
2. Sequence the tasks and map dependencies
Ask of every task: what must be true before this can start? “Design” cannot begin until “Requirements” is signed off. That is a finish-to-start dependency, the most common of the four types:
| Type | Meaning | Typical example |
|---|---|---|
| Finish–to–Start | B cannot start until A finishes | Testing starts after build completes |
| Start–to–Start | B cannot start until A starts | Documentation starts once development starts |
| Finish–to–Finish | B cannot finish until A finishes | Final QA cannot close until the last fix lands |
| Start–to–Finish | B cannot finish until A starts | The old system runs until the new one goes live |
Add lag where waiting is forced (approval takes three days regardless of effort) and lead where overlap is safe (start drafting the manual before build fully finishes). Missing dependencies are the most common reason a schedule that looked healthy on Monday is broken by Friday.
3. Find the critical path
Once tasks are sequenced, add up the duration of each possible route from start to finish. The longest route is the critical path — and its length is the shortest time the project can possibly take.
The practical consequence: attention is a resource, and the critical path tells you where to spend it. Adding a person to Content in the diagram above buys you literally nothing. Adding one to Build might buy you a week.
4. Estimate duration — with three numbers, not one
Estimation is where most schedules acquire their fiction. Three methods, in increasing order of effort and reliability:
- Analogous: “The last one like this took six weeks.” Fast, cheap, and only as good as the similarity.
- Parametric: a measured unit rate times a quantity — 20 pages at 1 hour per page. Defensible when the unit rate comes from real history rather than hope.
- Three-point (PERT): optimistic, most likely, and pessimistic, combined as
(O + 4M + P) / 6.
Two habits make estimates more honest. First, ask the person who will do the work, not the person who wants it done. Second, ask what the pessimistic case actually is — naming the failure mode out loud usually improves the whole estimate.
5. Set milestones
Milestones are zero-duration markers for meaningful checkpoints: an approval, a phase gate, a partial delivery, go-live. They give stakeholders something to track that is not a percentage, and they give you natural points to stop and ask whether continuing is still the right decision.
Choose milestones that represent a verifiable change of state (“requirements signed off”), not a calendar wish (“halfway”).
Making the project schedule realistic
- Hold buffer centrally. Ten tasks each carrying two hidden days will lose all twenty days invisibly. One visible ten-day project buffer gets spent as a decision.
- Subtract non-working time. Weekends, public holidays, the two weeks your lead engineer is on leave, the company offsite.
- Plan around real availability. Almost nobody is on your project full time. Someone at 50% turns a 16-hour task into a four-day one.
- Parallelise where dependencies genuinely allow. Then check the parallel branches are not competing for the same person.
- Use observed velocity, not ideal velocity. How fast has this team actually gone before?
Common pitfalls
Optimistic estimates
Every estimate assumes nothing goes wrong. Something always does. Estimating the good case and calling it a plan is how projects become late on day one.
Missing dependencies
One unmapped dependency turns a one-day delay into a five-day one, and nobody sees it coming because it was never in the model.
Static planning
A schedule written once and never reopened is a historical document. If it is not updated weekly it stops describing the project within a fortnight.
Keeping the schedule alive
A project schedule becomes useful only when it is used — weekly, as the basis for actual decisions. Update the status of each task, re-check whether the critical path has moved (it often has), and let the schedule be the single source of truth for both internal rhythm and external updates. When the plan and reality disagree, change the plan; do not just hope.
Summary: designing time is designing the future
Building a schedule is the act of shaping future time today. No project runs exactly to plan — which is exactly why the goal is not a perfect schedule but a schedule that can absorb change and still tell you the truth about where you are.
How this looks in AB
In AB Project Management, the schedule is not a separate document — it emerges from the tasks themselves. Each task carries a start date, a due date, and an estimate; subtasks roll up so parent tasks show real progress; the project Calendar shows where work bunches up week by week, so you spot bottlenecks before you commit to them. Milestones live as tasks of type “Milestone” with a fixed due date and no estimate. The schedule stays current by itself: move a due date and the Calendar reflects it; close a task — even from an AI assistant over the MCP server — and the progress figure shifts. You never maintain a plan on the side, because the project state is the plan.
Terms used on this page
Every term below is defined at more length in the full project management glossary.
- Critical path
- The longest chain of dependent tasks from start to finish. Its total duration is the minimum possible project duration, so any delay to a task on it delays the whole project. More →
- Float (slack)
- How long a task can be delayed before it starts pushing the project end date. Tasks on the critical path have zero float; everything else has some. More →
- Duration vs. effort
- Effort is how much work a task contains (16 person-hours). Duration is how much calendar it occupies (4 days, at half-time, across a weekend). Confusing them is the classic first schedule mistake. More →
- Dependency
- A constraint where one task's timing depends on another's. Four types exist; finish-to-start is by far the most common. More →
- Lag and lead
- Lag is enforced waiting between two tasks (a three-day approval window). Lead is permitted overlap (starting the manual before build ends). More →
- Milestone
- A zero-duration marker recording that a significant state has been reached — an approval, a gate, a go-live. It consumes no time itself. More →
- WBS
- Work Breakdown Structure — the hierarchical decomposition of total scope into work packages small enough to estimate and assign. The schedule is built from it. More →
- Three-point estimating (PERT)
- Estimating with optimistic, most likely and pessimistic figures, combined as
(O + 4M + P) / 6, so uncertainty stays visible instead of being averaged away. More → - Analogous estimating
- Estimating by comparison to a similar past task. Quick and rough — label it as rough when you give it, or it becomes a commitment. More →
- Parametric estimating
- A measured unit rate multiplied by a quantity. Only as good as the history the unit rate came from. More →
- Buffer (contingency)
- Time deliberately reserved to absorb the unforeseeable. Best held once, visibly, at project level rather than hidden inside each task. More →
- Baseline
- The approved, frozen version of the schedule you measure drift against. Changing it is a formal act called re-baselining. More →
- Crashing / fast tracking
- Two ways to compress a schedule: crashing adds resources to critical-path tasks (costs money), fast tracking overlaps tasks planned in sequence (costs rework risk). More →
Related reading
Where the task list comes from
The WBS this schedule is built on is produced during scope definition.
3.1 Defining Scope →How to draw it
Turning the sequenced tasks into a Gantt chart the whole team can read.
5.1 Using Gantt Charts →When it slips anyway
Diagnosing a delay and deciding what to do about it without panicking.
9.2 Practical Advice →