Scheduling
Project scheduling and dependencies
Build a project schedule around real handovers, durations and calendars, then use dependencies to explain changes to the forecast.
A project schedule should show when work can happen, what must happen first and how a change affects the forecast finish. Start with the work and its real handovers. Then add duration estimates, a working calendar and the dates the team has agreed to manage against.
Build the schedule from work, not dates
List the deliverables and the activities needed to produce them. Give each activity an owner and an estimated duration. Ask the people doing the work whether the estimate means elapsed time or working time; the difference matters when weekends, leave or supplier availability intervene.
Next, identify what allows each activity to begin. A task with a target date but no predecessor may appear free to start even when it needs an earlier output.
Linking every task in a long chain can hide work that could happen in parallel. Record a link when one activity genuinely governs another’s start or finish.
| Schedule record | Question it should answer |
|---|---|
| Activity and duration | What work is planned, and how long is it expected to take? |
| Predecessor and successor | Which earlier event governs this work? |
| Milestone | What completed result or decision marks progress? |
| Calendar | Which days and hours count for this plan? |
| Baseline and forecast | What was agreed, and what finish is now expected? |
They do not make an estimate certain or establish that an assigned person is available.
Choose the relationship that reflects the work
A finish-to-start relationship means the successor cannot begin until its predecessor finishes. It suits a genuine handover, such as completing a final specification before producing work from it. Start-to-start means the successor can begin only after the predecessor begins; finish-to-finish means it cannot finish before the predecessor finishes.
Start-to-finish is another relationship type, though a simpler relationship may be easier to manage when it accurately describes the work.
A relationship expresses sequence, while a date constraint fixes or limits timing.
If a supplier cannot deliver before a known date, record that timing condition explicitly. If a successor must wait for a defined interval after its predecessor finishes, record the interval and why it exists. Do not use a convenient date or arbitrary lag to conceal missing work or an uncertain decision.
For each link, ask whether it is unavoidable or merely the team’s preferred order. A preferred sequence may change when time is tight; a genuine prerequisite cannot be removed just to improve the displayed finish date. If a dependency sits outside the project, name the external owner and when the team will seek an update.
When a predecessor changes, check the connected sequence for downstream effects.
Task Relationship Types in Project Scheduling
- Finish-to-Start (FS)Successor cannot start until predecessor finishes. Common for handovers (e.g., design approval before construction).
- Start-to-Start (SS)Successor cannot start until predecessor starts. Useful for parallel work like site prep and foundation digging.
- Finish-to-Finish (FF)Successor cannot finish until predecessor finishes. Suitable for joint testing after system integration.
- Start-to-Finish (SF)Less common; successor finishes only when predecessor starts. Used in shift handovers or continuous processes.
Read the forecast with its limits
Software that supports dependency scheduling can use activities, durations, calendars and relationships to calculate dates and identify a driving path. Work with little or no total float needs attention, but the result is only as sound as the inputs.
An omitted handover, unrealistic duration or inappropriate constraint can produce a plausible-looking answer for the wrong plan. The driving path can change after work slips.
Keep the agreed baseline separate from the current forecast. When an activity changes, update its estimate or actual progress, recalculate the forecast and explain the effect on the next milestone. An approved change may justify a revised baseline; retain the earlier reference and report which baseline is being used.
A logical path can fit on a calendar without confirming that assigned people are available; assess resource capacity separately.
Define activities and progress records
An activity is a task, job, operation or process that consumes time and may consume resources. It can also be treated as the smallest self-contained unit of work in a project. Use that boundary consistently so planned work and reported progress refer to identifiable units.
A unique activity ID is a code identifying an activity. Keeping an ID with the activity record helps distinguish it from other work in the schedule, including when activity names are similar.
Actual dates are when activities started and finished, rather than their planned or forecast dates. Actual progress measures completed work compared with the baseline.
Use a delay as a schedule check
Suppose site access is required before equipment installation can begin. If access is delayed, identify the linked successor, its earliest workable start and any later milestone affected.
Ask which preparation can proceed independently. Record any decision to change scope, sequence or staffing, and update the forecast rather than leaving an unsupported milestone date in place.
Schedule Health Check: Validating Dependencies
- Is the dependency real or preferred?Genuine prerequisites cannot be removed just to improve the finish date.
- Are external dependencies tracked?Name external owners (e.g., supplier, client) and set follow-up dates.
- Is there a delay buffer?Record delays explicitly—do not use arbitrary lags to mask uncertainty.
- Has the forecast been updated?After a change, recalculate and document impact on next milestone.
- Is scope or sequence changed?Record any decisions to adjust work, and revise the baseline if approved.
In this guide
- Planning a critical path in project softwareEnter real task relationships and durations, read float correctly and check why software marks a path as critical.
- Handling work that cannot start until another task finishesSet a finish-to-start dependency, define the handover and check the successor date when the earlier task slips.
