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?
Because BAU never constrains projects in any organisation
Because operational blackouts, shared staff, maintenance windows, and parallel change can block testing, training, and cutover even when internal project logic looks feasible
Because BAU dependencies remove the need for a critical path
Because schedules should ignore all external calendars
A project adds mandatory safety testing without changing the end date or removing other work. What is the most accurate integrated analysis?
Quality activities never affect schedule, so no analysis is needed
Additional quality scope on or near the critical path will consume float or extend duration unless other work is descope, overlapped (with risk), or accelerated (usually at cost)
Safety testing always reduces project cost automatically
Only the CBS is affected; the schedule cannot change
Sections you finish are checked off in the contents.