A schedule assembled by typing dates into a calendar survives until the first delay. Then it turns out nobody knows what that delay actually affects — did we lose two days or two months? The difference comes down to whether the schedule is a list of dates or a connected model in which tasks know about each other.
A schedule starts from a list of work, not from dates
First rule: do not write a single date until you know what has to be done. The input to a schedule is the work breakdown structure — the list of deliverables and work packages. Only then do you add durations, sequence and deadlines.
The reverse order — "it has to be finished by October, let's fit the work in" — produces a schedule that is really a wish. That kind of plan does not fail at the end; it fails in the middle, when something has to be moved every week.
Estimating duration: three questions
- How much work is it? Effort in hours is not the same as calendar time.
- How available is the person? Forty hours of work does not finish in a week if the person can give it two days a week.
- How much waiting is involved? Approvals, deliveries, curing time, a client's reply — all part of duration, even though nobody is working.
The most common mistake is to estimate effort and write it down as duration. That is how schedules end up perfect on paper and 40% too short in practice.
Dependencies: what must come first, what can run alongside
| Type | Meaning | Example |
|---|---|---|
| Finish → start (FS) | B starts once A is finished | Foundation done → walls go up |
| Start → start (SS) | B starts together with A | Development starts → test prep starts |
| Finish → finish (FF) | B finishes together with A | Content done → copy-editing done |
| Start → finish (SF) | Rare, handover situations | New shift starts → old shift ends |
Most real dependencies are finish → start. What matters is distinguishing a technical dependency (walls cannot precede the foundation) from a resource dependency (the same person does both). The first cannot be changed; the second can be solved with money or another pair of hands.
The critical path — where delay actually costs
The critical path is the longest connected chain from project start to finish. Tasks on that chain have no slack: every day of delay pushes the end date out by exactly that much. Tasks off the critical path have float — they can slip without moving the deadline.
The practical value is simple: knowing which chain is critical tells you where to point attention, people and money. And when someone asks "is this delay bad?", the answer is calculable rather than a gut feeling.
Milestones: dates you can ask a yes/no question about
A milestone is a zero-duration point marking a significant achievement: contract signed, prototype complete, application submitted. A good milestone is binary — either it is there or it is not, never "70% done".
Three to five milestones per project is usually enough. With twenty, none of them means anything any more and the steering group does not know which one to watch.
Buffer: where to keep it and where not to
- The bad version: every contributor pads their own task by 30%. The buffer is invisible, it gets consumed, and the project manager never knows how much room actually remains.
- The good version: estimates are honest and buffer is pooled where it can be seen — at the end of the critical path and next to the larger risks. Then you can tell how much of it has been spent.
A schedule that is not a dead document
- Once a week, mark what is genuinely finished (not "almost").
- Check whether anything on the critical path has slipped.
- If it has, decide immediately: cut scope, add resource or move the deadline. The third is also a decision, but it has to be a conscious one.
- Record the decision and its reason, so nobody has to guess three months later.
How Projektiassistent speeds this up
Projektiassistent drafts a first schedule from your project description — phases, durations and dependencies included — and you correct it against your own reality. The Gantt view shows dependencies and the critical path; the Kanban board shows the same work in daily flow. Because schedule, budget and risks all sit on the same project, moving a deadline does not leave the budget out of date.
Summary
A good schedule starts from a list of work, estimates duration separately from effort, links tasks with dependencies, knows its critical path, uses few and clear milestones, and keeps buffer where it is visible. Most importantly, it gets updated.
Want the first version today? Start here: projekt2.projektiassistent.ee.