Every Plan Assumes It Has You
Three project plans, each of them realistic, each assuming it has the same engineer. Nobody ever adds them up — and the sum, not any one plan, is the schedule your organization actually runs.
Every plan in the building is defensible. Each one was built by somebody competent, reviewed by somebody sensible, and contains durations that a reasonable person would defend. And the organization will still miss most of its dates, because three of those plans quietly assume the same person has a full week available, and nobody has ever put the three plans on the same page.
This is not a planning failure. Every individual plan is right. It is an arithmetic failure, and specifically an arithmetic failure that nobody has been assigned — because adding plans together is not any project manager's job. Each of them owns a plan. Nobody owns the sum.
Why the sum is never computed
The structural reason is that plans are stored the way they are managed: one per project. A project is a container, a plan lives inside it, and every question the tool makes easy is a question about the inside of one container. "Is this project on track" is one query. "Is this person over-committed across every container they appear in" is a different query against a different axis, and almost nothing asks it by default.
The second reason is organizational and harder. The people best placed to notice are the ones with the least standing to complain. A project manager who says "I cannot have Mary in week six" is understood to be defending their own project against somebody else's, so the conversation becomes a negotiation between two managers rather than a fact about one calendar.
Every project manager owns a plan. Nobody owns the sum of the plans — which is the only one that predicts anything.
A count of tasks is not a measure of load
When a tool does offer a workload view, it is usually a count: open tasks per person, biggest number first. It is better than nothing and it is not a capacity signal, because it answers a question nobody has — how many items somebody has — rather than the two that matter, which are how much time those items need and when they need it.
| What you can measure | What it tells you | Where it misleads |
|---|---|---|
| Count of open tasks | Roughly who is busiest, at a glance. | A thirty-minute task and a three-week task weigh the same. Somebody with four large tasks looks idle beside somebody with twenty small ones. |
| Sum of estimated hours | How much work is nominally assigned. | Says nothing about when. Eighty hours is comfortable across a quarter and impossible in a week. |
| Estimated hours placed on dates | Where the collisions actually are. | Requires estimates on most tasks and dates on most tasks. In practice both are patchy, and a partial picture read as a full one is worse than none. |
| Hours placed on dates, against declared availability | Genuine over-allocation, as a number. | Requires a model of what each person is available for — leave, part-time, the fact that nobody delivers eight billable hours in an eight-hour day. |
Where we are on that table, stated plainly
A task here carries an assignee, an estimate in hours, a start date and a due date — everything row three needs. The roll-up does not use them. The workload view is a count of open tasks per person, which is row one, and the estimated hours are never added up anywhere: they are captured, validated, stored and shown on the task you are looking at, and no total is computed from them for a person, a project or a period. There is no availability model, so row four is not merely unbuilt, it is not currently expressible. The fields are live and the arithmetic is missing — a distinction worth naming, because it is the difference between a gap you can close with a report and one that needs a data model. The column that nothing reads is about this failure mode in general.
The four signals you already have
None of these needs a capacity model. All four work with an assignee field, a due date and somebody willing to look once a week.
-
The same name on two critical paths
You do not need to sum anything. Take the critical path of each active project — the sequence with no slack — and list who appears on it. A name on two of them is a scheduling risk on both, because any slip they cause has nowhere to be absorbed. This is a five-minute check and it finds most of the damage.
-
Concurrent start dates on one person
Sort every open task by assignee, then by start date. Two tasks starting the same week for the same person is either a deliberate split or an accident, and the person will usually tell you which within about four seconds of being shown it.
-
The estimate that never moved
A task estimated at eight hours that has been open for five weeks is not an eight-hour task; it is a task somebody cannot get to. That gap between estimate and elapsed time is the cheapest available proxy for contention, and it needs no capacity model at all.
-
Reassignment frequency
Work that moves between people repeatedly is usually work that keeps landing on somebody who has no room for it. A task on its third assignee is telling you about your capacity, not about the task.
What to do when two plans genuinely collide
The instinct is to resequence, and it is often wrong. Moving one project's tasks to relieve a person shifts that project's end date, which is a commercial decision being made quietly by whoever happened to notice the clash. Three options, in ascending order of honesty:
- Resequence within slack. If one of the colliding tasks is off the critical path, move it into its slack and nothing external changes. This is the only free option and it is available more often than people check.
- Substitute the person. Cheap when the work is genuinely generic, expensive and quietly damaging when it is not. The honest test is whether you would have assigned this person in the first place if the other project did not exist.
- Move a date and say so. The unpopular one, and the only one that keeps the plan true. A date moved deliberately in week two costs a conversation; the same date moved by reality in week nine costs the conversation plus the credibility.
What none of the three is: quietly assuming the person will absorb it. That is the default outcome of not looking, it works for a while because people do absorb it, and it stops working without warning.
Three questions for whoever supplies your project tool
Separating a workload widget from a capacity model
Show me one person's committed hours next week, across every project.
What you are listening for
A view, or a clear statement that it counts tasks rather than hours.
How to read the answer
A count presented in answer to a question about hours is the most common substitution here. It is not dishonest — it is just a different number, and you should know which one you are being shown.
What does the system think this person is available for?
What you are listening for
A figure, and where it comes from — a contract, a calendar, a default.
How to read the answer
If there is no answer, over-allocation cannot be computed at all, only eyeballed. That may be fine. It is not fine to discover it after building a process on top of it.
If I assign a task that pushes somebody past their week, what happens?
What you are listening for
A warning, a flag, or an honest nothing.
How to read the answer
"Nothing" is a perfectly good answer and most tools should give it. Be careful with a tool that shows a red bar but still accepts the assignment silently everywhere else — a warning nobody is required to act on trains people to ignore warnings.
A weekly habit that costs ten minutes
One person, once a week, across all active projects
- List the names on every active project's critical path. Any name appearing twice is discussed this week, not next.
- Scan for one person with two tasks starting in the same week. Ask them, rather than deciding for them.
- Look at open tasks whose elapsed time has passed their estimate by a wide margin. These are the queue, not the work.
- Note anything reassigned more than once since the last review.
- Record the decision made about each collision — resequenced, substituted, or date moved. The record is what stops the same clash being rediscovered monthly.
The short version
Plans are built one at a time and delivered all at once, and almost no organization computes the second thing. You do not need a capacity model to fix most of it: the same name on two critical paths, two tasks starting the same week, and estimates that elapsed time has overtaken will find nearly all the damage in ten minutes a week. Buy or build the capacity model later if the ten minutes stops being enough — but be clear whether the workload number in front of you is hours placed on dates or simply a count of open items, because those look identical on a dashboard and mean entirely different things.
