Why Project Management Matters
Nobody sets out to run a project badly. Projects fail anyway — and when you look at the post-mortems, the causes are boringly consistent. That consistency is the good news: a predictable failure is a preventable one.
In short
- Projects rarely fail from one dramatic event. They fail from small problems found too late.
- The cost of a problem grows roughly tenfold at each stage it survives undetected.
- Almost every project-management practice is, underneath, a mechanism for noticing earlier.
- This is a learnable craft, not a personality trait — and it’s useful whether or not “manager” is in your title.
Projects fail slowly, then all at once
Ask someone why their last project went badly and you will usually get an event: a supplier fell through, a key person left, the client changed their mind in month five. Those are the visible causes. The interesting question is why the project had no capacity to absorb them.
A well-run project meets the same shocks and survives, because someone had already asked what would happen if the supplier fell through, because the plan had slack in it, and because the change in month five arrived through a process rather than a hallway conversation. The shock was never the difference. The preparation was.
This curve is the entire economic argument for project management. If problems cost the same whenever you found them, planning would be a waste of time and the fastest approach would be to start building immediately. They don’t, so it isn’t.
The five failure modes, and what each one really is
These are the usual suspects in project post-mortems. Read them as symptoms, not causes — the cause is always that nothing in the way the project was run would have surfaced the problem in time.
| Failure mode | What it looks like | What actually prevents it |
|---|---|---|
| Unclear scope | Two people describe the same deliverable differently in month three, and both are sure they’re right. | A written scope with explicit exclusions and acceptance criteria — 3.1. |
| Unrealistic schedule | The date came from when it was wanted, not from how long the work takes. Everything is “90% done” for six weeks. | Estimating from tasks upward, and knowing the critical path — 3.2. |
| Communication gaps | The person who needed to know found out afterwards. Everyone assumed someone else had told them. | A communication plan that names who hears what, when — 4.3. |
| Unmanaged risk | The thing everyone privately worried about happened, and there was no plan because nobody wrote it down. | A risk register reviewed on a schedule, not when it’s already an issue — 3.4. |
| No usable metrics | Status is a feeling. “On track” means nobody has escalated yet. | Progress measured against a baseline, not against optimism — chapter 6. |
Notice the pattern. Every one of these is a detection failure before it is an execution failure. The team was capable; the project had no way of telling them what they didn’t know yet.
What good project management actually buys
Stated as benefits, this list sounds like a brochure. Stated as things that stop happening, it’s more useful:
People stop working on the wrong thing
A clear goal and an ordered list of work means effort lands where it counts. Without them, the most persuasive person’s priorities win, which is not the same as the most important ones.
Nobody has to guess where things stand
Visible schedules and statuses replace the status meeting whose only purpose is finding out what happened. That time goes back to the team.
Bad news travels early
A culture and a mechanism for raising problems while they are still cheap. This is the single highest-return habit in the whole discipline.
Trade-offs get decided, not absorbed
When scope, time and cost collide, someone makes an explicit call. Otherwise the team absorbs it silently through overtime and quality, and you find out at the end.
Why this matters even if you’re not the project manager
Most of the value in the list above depends on people who are not the project manager. The PM cannot see a task slipping before the person doing it can. They cannot know that a requirement is ambiguous until the person building it says so. Roughly:
- If you do the work: the most valuable thing you can do is flag doubt early, while it’s on the left of the cost curve. “I don’t think this will take three days” on Monday is worth more than heroics on Friday.
- If you review or approve: your turnaround time is often the real bottleneck. Work sitting in review is invisible in most status reports and expensive in every one of them.
- If you sponsor or fund it: your job is deciding trade-offs the team cannot decide for themselves — and being reachable when they arise.
- If you just depend on the outcome: being specific about what you need, once, at the start beats correcting it three times later.
Project management works when it is a shared literacy rather than one person’s job. That’s the reason this guide is written for everyone on a project, not only the person running it.
It is a skill, not a temperament
There is a persistent belief that some people are just organised and others aren’t. In practice the competent project managers you have worked with were not born calm — they had a small set of habits they applied consistently: writing scope down, estimating from the bottom up, keeping a risk list, checking progress against a baseline, and closing things properly.
Every one of those is teachable, and each has a chapter in this guide. If you want the shortest useful path: 3.0 Project Planning Basics, then 6.0 Progress Tracking.
How this looks in AB
Each failure mode above maps to something concrete in AB Projects:
- Unclear goals → the project Wiki holds the “why” so it doesn’t drift; the project description holds the one-line version.
- Unrealistic timelines → the Gantt and Calendar views show where tasks bunch up before you commit to the date, and estimates default to a real value so unedited tasks aren’t invisibly weightless.
- Poor communication → mentions and Adaptive Cards put updates in front of the right person in Teams or Slack rather than in a tab nobody opens.
- Unflagged risks → comments keep the conversation attached to the task, and change history records when status shifted and why.
- No metrics → progress, status and the project dashboard answer “where are we?” without anyone assembling a report.
AB doesn’t manage the project for you. It removes the excuses for not knowing where it stands.
Terms used on this page
- Cost of change
- The observation that fixing a defect or misunderstanding gets dramatically more expensive the later in the lifecycle it is discovered. The reason planning and early review pay for themselves. More →
- Baseline
- The approved version of the plan — scope, schedule and cost — that actual progress is measured against. Without one, “on track” has nothing to be on track relative to. More →
- Risk register
- A living list of things that might go wrong, each with a likelihood, an impact and a named owner. A risk that has happened is no longer a risk; it is an issue. More →
- Critical path
- The longest chain of dependent tasks through the schedule. Any delay on it delays the whole project; delays elsewhere may not. More →
- Scope creep
- Work quietly added after the scope was agreed, without a matching change to time or budget. Rarely one big addition; usually forty small favours. More →
- QCD
- Quality, Cost, Delivery — a shorthand for the three things a project is judged on, and the three that trade against each other. Closely related to the triple constraint. More →
- Stakeholder
- Anyone affected by the project or able to affect it — sponsors, users, regulators, neighbouring teams. Unmanaged stakeholders become late-arriving requirements. More →
Related reading
3.0 Project Planning Basics
The four pillars — scope, schedule, resources, risk — and what goes wrong when each is thin.
3.4 Risk Management
How to keep a risk list that people actually use, instead of one written once and never reopened.
8.2 Lessons from Failed Projects
These failure modes seen in the wild, with what the teams involved would do differently.