How Project Management Breaks | Dependencies and Delays

Did you know? Every member of a team can finish their assigned task on time—and the final project can still arrive late. The reason may be that one person’s ‘done’ is not usable by the next person, or a critical decision has never been made.

That is how project management breaks. A project is not simply a calendar of independent tasks. It is a network of promises, dependencies, resources and decisions that must come together to produce an agreed result.

Quick answer: projects drift when the goal or scope is ambiguous, important task dependencies are hidden, responsibilities are split, the schedule ignores available capacity, or progress reports count finished activities without checking usable deliverables. The repair starts with a single definition of success, a dependency map, named decision owners and earlier checks at the handover points.

The project plan can look green while delivery is red

Imagine four students preparing a Science exhibition. The writer completes the explanatory text. The designer finishes a poster. The researcher updates data in a spreadsheet. The presenter rehearses the final talk. Each tells the teacher their part is finished.

But the poster uses older numbers, the script describes a different experiment and a required diagram has not been approved. Four tasks are complete; the one deliverable is inconsistent.

The problem is not merely lateness. It is the missing agreement about how separate pieces must fit together.

The existing How Teamwork Breaks | When Trust and Coordination Fall Apart examines this as a cooperation problem. Project management adds the scheduling, scope, cost, risk and decision controls needed to turn that cooperation into a finished result.

Seven points where the project chain can break

Ambiguous outcome: stakeholders hold different pictures of what successful completion means.
Scope drift: tasks and expectations expand without corresponding decisions about time, resources or value.
Hidden dependencies: downstream work starts or finishes without a required input being available and checked.
Unrealistic capacity: the schedule assumes people or equipment can be in two places at once.
Unclear decision rights: no one knows who can approve an exception, resolve a trade-off or reject a change.
Late risk discovery: foreseeable bottlenecks are only discussed after they have affected the deadline.
Misleading progress measures: completion percentages rise while quality, integration and stakeholder needs remain untested.

These issues interact. An unclear outcome encourages scope additions. The additions create new dependencies. Those consume resources already promised to other tasks. When the timetable slips, the team may rush past quality checks and create more rework.

What Project Management Institute evidence reveals

In its Pulse of the Profession 2021 appendix, the Project Management Institute reports survey responses identifying changing organisational priorities, poor requirements gathering, changing project objectives and poor upfront planning among frequently selected contributors to project failure. Poorly managed dependencies were also selected by respondents.

These figures reflect a survey, particular respondents and a specified period, not a universal law about why every project fails. What they show is that failure is often connected to the choices and information that link individual work packages.

A 2025 literature review and interview study of Dutch infrastructure projects likewise highlights scope changes, coordination and communication problems, and poor project structure and scheduling in the context studied. Its findings should not be mechanically applied to every industry.

The dependency you forgot matters more than a beautiful calendar

Consider a simplified school group project: researchers must provide validated numbers before the writer finalises claims. The writer must finish before the designer lays out the final chart. The designer must complete the visual before the presenter rehearses the final version.

A calendar may show three independent deadlines, but the true relationship is research → writing → layout → presentation. A delay in research can move the dates for all three downstream activities if there is no buffer or useful alternative work.

A practical dependency map can be very simple. Write each deliverable as a box and draw arrows for what it requires. Mark the person who must receive and confirm the input. Then ask which chain constrains completion.

More sophisticated planning software can help when complexity justifies it, but an unexplained software dependency chart is no better than an unexplained paper diagram.

What counts as a real handover?

A team member emails a file and reports that the task is done. However, the recipient cannot open the file, identify the latest version or confirm the information is correct. Has the handover been completed? Operationally, not yet.

A reliable handover defines the deliverable, version or location, acceptance criteria, receiving person and next action. The receiver has a practical opportunity to confirm the input is usable.

For high-consequence work, additional checks may be necessary. For a school poster, a simple version label and verification may be enough. The underlying principle is the same: ‘sent’ and ‘received correctly’ are different events.

How scope creep turns a manageable plan into a different project

Imagine a tutor and student team planning a short history presentation. Midway through, they add an interactive map, a filmed interview and a printed booklet. Each addition sounds educationally interesting.

But the deadline and team size remain unchanged. The project is no longer the same one the original plan described.

A sound change decision asks what value the addition contributes, which other task or requirement it replaces, whether the resources exist and who is authorised to approve the revision. Saying no to an attractive extra can be an important act of project management.

Scope control is not opposition to learning or creativity. It helps people make conscious trade-offs so essential outcomes are delivered rather than abandoned under a mountain of optional features.

The critical path is not the busiest person

In a dependency network, some sequences determine the earliest possible finish date. A delay along such a sequence may affect the overall delivery date unless the plan changes. Other tasks may have some scheduling flexibility.

This is the practical idea behind the critical path. It is not necessarily the task that feels hardest or the team member who sends the most messages.

When a project slips, ask whether the delayed activity blocks another essential deliverable. A two-day delay in a noncritical illustration may matter less to completion than a one-hour delay in a required approval. The answer depends on the actual dependency map.

Why task counts can mislead project reporting

A team can report that 90% of tasks are complete even though the remaining 10% includes the one integration test, safety review or stakeholder approval needed for delivery.

Conversely, a major part of the work may be underway with relatively few small tasks marked complete. Neither raw task count captures the whole situation.

A useful project review asks whether the agreed deliverables meet acceptance criteria, which dependencies remain, what risk has changed and what decision is needed next.

The companion How Strategy Fails | When Plans Ignore Feedback and Reality explores why following a plan can be less useful than examining whether the plan still matches the real goal.

Five early warnings a project is drifting

Team members give different definitions of what must be delivered.
Key tasks have no named owner or receiver.
The schedule assumes work can begin before a required decision or resource is ready.
New requirements keep arriving without updated time and resource commitments.
Status reports celebrate task completion while integration defects appear only near launch.

One warning sign does not mean the project must be cancelled. It means the team should inspect the relevant dependency and decide what correction is proportionate.

A 30-minute project reset

Minutes 0–5: write the intended outcome and what acceptance would look like.
Minutes 5–10: identify necessary deliverables and separate them from attractive but optional additions.
Minutes 10–15: draw key dependencies, especially those that block later work.
Minutes 15–20: assign owners, receivers and decision rights to each critical handover.
Minutes 20–25: examine risks, available capacity and the earliest credible next milestones.
Minutes 25–30: choose a near-term verification point and record who will act on the results.

The time is illustrative; large programmes need more detailed governance. A small reset succeeds when it produces actionable decisions instead of another presentation about the project’s importance.

What to do when a deadline becomes unrealistic

A realistic recovery may require reducing scope, reallocating authorised capacity, changing dependencies, negotiating the deadline or recognising that the original commitment cannot be met without unacceptable risk.

The wrong approach is to simply insist everyone work faster while ignoring the problem that caused the delay. Rushing can create additional defects that worsen delivery.

Some projects involve safety, legal duties or regulated infrastructure. Those controls cannot be skipped merely to produce a green status report. Where necessary, communicate the constraint and seek legitimate approval for a revised plan.

How project skills transfer to students

Secondary students can practise the same reasoning on group assignments. Identify the question, write a clear deliverable, assign responsibilities, agree on one current document and schedule a check before the submission deadline.

Instead of asking only ‘Is your part done?’, try ‘Can the next person use what you finished?’ That makes the handover visible and encourages classmates to support one another without ignoring accountability.

A good project experience is also educational: it teaches planning, revision, communication and evidence-based problem solving, not just the subject matter of the final poster.

Frequently asked questions

Why can a project fail when every task seems on time?

Tasks may not be integrated, accepted or based on consistent inputs. Project delivery depends on handovers and a shared definition of completion, not isolated task status.

What is a hidden dependency?

It is an input, approval, resource or other condition needed for a task that the plan has not clearly identified or monitored.

Is adding more people the best way to save a delayed project?

Not automatically. More people require coordination and may not solve the constrained dependency. First locate the actual bottleneck and determine whether additional capacity would help.

What is one useful habit for a small project?

At every checkpoint, identify the next critical handover, its owner, the receiving person and what will demonstrate that it is ready to use.

The final idea

Project management breaks when individual tasks stop fitting into one dependable route to completion. Scope, dependencies, capacity, quality and decisions must remain visible together. Repair the interfaces, not only the calendar.

How Homework Fails | When Practice Becomes Busywork
How Project Management Breaks | When Dependencies and Deadlines Drift (this guide)
How Water Systems Break | When Leaks, Pressure and Treatment Fail
How Manufacturing Stalls | When Quality and Bottlenecks Multiply

The wider framework is explored in How Education Fails and How Strategy Fails. For the unchanged practical education reference, read Secondary 1 Mathematics Tutor Clementi | Small Groups Tutorials.

Evidence and further reading

Examples are illustrative teaching scenarios, not verified incidents. Interpret advice according to the actual learner, organisation or system and the rules governing it.

How Project Management Breaks | When Dependencies and Deadlines Drift