18.2 Dependencies and What Drives the Schedule
Key Takeaways
- Dependencies determine sequence, and a schedule with missing dependencies produces dates that cannot be achieved.
- Business-as-usual constraints — operational freezes, seasonal peaks, shift patterns, and staff availability — routinely drive project dates more than internal logic does.
- Cost constraints affect the schedule by limiting how much work can run in parallel and how much resource can be bought in.
- Quality requirements affect the schedule through the time needed for testing, review, and rectification of defects.
- Adding mandatory scope without changing the end date or removing other work is not a plan — it is an unresolved constraint that will surface as a late overrun.
Outcome 20b asks you to understand there are links and dependencies between activities within a project and business-as-usual activities, and states plainly that business-as-usual activities, costs, quality, risks and scope can all impact the schedule. The examinable idea is that a schedule is not an independent artefact — it is the place where every other constraint shows up.
Dependencies between project activities
A dependency is a logical or imposed relationship that constrains the order or timing of activities.
Common dependency types (conceptual)
| Type | Meaning | Simple example |
|---|---|---|
| Finish-to-Start (FS) | Successor cannot start until predecessor finishes | Pour foundations → erect steel |
| Start-to-Start (SS) | Successor cannot start until predecessor starts | Begin documentation when design starts |
| Finish-to-Finish (FF) | Successor cannot finish until predecessor finishes | Testing finishes with final defect fix delivery |
| Start-to-Finish (SF) | Rare; successor finish constrained by predecessor start | Specialised shift handover patterns |
Most project logic is finish-to-start. Lags (delays) and leads (overlaps) refine timing (for example, cure time lag after concrete pour).
Internal vs external dependencies
| Category | Description | Management focus |
|---|---|---|
| Internal (within project) | Between project activities/teams | Team coordination, integrated schedule |
| External | On suppliers, regulators, other projects, utilities | Interface agreements, lead times, escalation |
| Mandatory / hard logic | Physical or contractual necessity | Cannot "wish away"; plan around it |
| Discretionary / soft logic | Preferred practice or policy | Challenge if optimisation needs re-sequence |
| Resource dependencies | Same scarce people/equipment needed by parallel work | Resource smoothing/levelling (resource LO) |
Critical path (conceptual)
The critical path is the longest path of dependent activities through the network that determines the earliest project completion (for a given logic and durations). Activities on the critical path have zero (or least) total float — delay to them delays the end date unless logic or duration changes.
You do not need deep network mathematics for PMQ, but you must reason:
- Adding scope or quality gates on the critical path extends duration unless compensated elsewhere.
- Fast-tracking overlaps critical activities (more risk); crashing shortens critical durations (usually more cost) — next section.
- Monitoring critical and near-critical paths is essential because float can disappear when reality changes.
Links and dependencies with BAU
Projects rarely run in a vacuum. BAU (operations) creates dependencies that pure project networks often miss:
| BAU interaction | Schedule impact | Example |
|---|---|---|
| Blackout / peak periods | Forbidden cutover windows | No retail go-live before Christmas peak |
| Shared resources | Operations staff needed for testing/training | Clinic nurses cannot leave wards for five-day workshops |
| Operational data / environments | Access only in maintenance windows | Night-only database migrations |
| Regulatory / reporting cycles | External calendars | Year-end freeze on finance system changes |
| Hypercare capacity | Post-go-live support loading | Cannot launch three sites the same week |
| Parallel change | Other projects contending for the same BAU | Two programmes training the same call centre |
Scenario B — BAU dependency ignored
A hospital IT project schedules user acceptance testing in the first week of a major winter pressures period. Clinical BAU cannot release staff; testing slips four weeks and the critical path moves. Integrated schedule management would have treated clinical availability as an external dependency with a named operational owner and alternative windows — not as an infinite resource pool.
How cost, quality, risk, and scope impact the schedule
The schedule is not independent. Syllabus LO20b expects you to explain links among these factors.
| Factor | How it impacts schedule | Reverse link (schedule → factor) |
|---|---|---|
| Scope | More/less product or work changes activity count and path length | Compressed dates force scope trade-offs or phased delivery |
| Cost / budget | Funding profile and cash constraints delay starts; cheap slow methods vs expensive fast methods | Acceleration usually increases cost (crashing, overtime, dual teams) |
| Quality | Reviews, testing, rework loops, certifications add duration and dependencies | Rushed schedules raise defect risk and rework (quality cost later) |
| Risk | Risk response activities, contingency time, and threat materialisation alter forecasts | Tight schedules increase risk exposure; float is a risk buffer when used deliberately |
| Resources | Availability and skill constrain parallel work | Schedule density drives resource peaks and conflict with BAU |
| Procurement | Lead times and award dates set early constraints | Late package definition pushes supply onto the critical path |
Scenario C — quality and risk on the path
A medical device software release is scheduled for a fixed regulatory submission date. Scope growth adds features without extending test cycles. Quality risk rises: either defects escape or the submission slips. Integrated planning would re-estimate test effort, re-sequence or descope features, and escalate the scope–quality–schedule trade-off to the sponsor with options — not silently steal test float.
Scenario D — cost-driven delay
A capital project’s funding arrives in two financial years. Even if technical work could start now, the CBS/budget profile forbids major spend until April. The schedule must show constrained starts, not a fantasy early start that finance cannot fund.
Practical tips for PMQ long responses
When a scenario mentions late delivery or dependency failure:
- Clarify outputs vs outcomes vs benefits relevant to the scope.
- Use PBS / WBS / CBS language to show structure and missing work/cost.
- Identify dependency types (internal, external, BAU, resource).
- Discuss critical path conceptually: what is driving the end date?
- Explain impacts from scope, cost, quality, and risk both ways.
- Recommend integrated re-planning with named owners and governance.
That chain satisfies LO20a–b and sets up continuous re-estimating and schedule optimisation (LO20c) in the next section.
Why must project schedules consider business-as-usual (BAU) dependencies?
A project adds mandatory safety testing without changing the end date or removing other work. What is the most accurate integrated analysis?