Break the work down from deliverables

The natural first move on a project is to collect everyone's task lists. It produces a long list with holes and duplicates, because nothing shows what the tasks are supposed to add up to.

Start from the other end: deliverables, the things the project hands over that someone can check. For physics, the brief's in list gives them: the curriculum, practice sets, the tutor pool, the diagnostic test, the landing page and booking by subject, launch communications. Tasks come second, as the way each deliverable gets made.

The difference shows up fast. Danylo's sixty lines, Vira's list and Roman's list overlap on practice problems, and none of them mentions who sends the launch email. Seen from the deliverables, both problems jump out: one deliverable has two authors, another has none. A deliverable frame also stays stable while tasks change daily, so it can be the backbone of the plan.

A deliverable is a thing the project hands over that someone can try and then accept or send back: the diagnostic test that places each learner at a level, the curriculum unit on mechanics, a pool of tutors who passed a demo lesson. A task is an activity that helps produce one: call five candidates on Tuesday, fix the subject dropdown in booking, meet Vira about the mechanics unit.

A handy test is grammar. Deliverables are nouns, things you can point to and check. Tasks are verbs, things someone does. The planning tree is made of nouns; verbs live one level lower, on the owner's own board.

Why it matters: tasks only count because of the deliverable they produce. A project lead who tracks verbs ends up asking “did you call the candidates?” instead of “is the tutor pool on track?”, and sees activity rather than progress.

A work breakdown structure (WBS) is a tree. The project sits at the top. Below it come the deliverables. Each deliverable splits into pieces of work small enough for one person to own and estimate. Individual tasks sit below that, on the owner's board, not in the tree.

For physics, one branch reads top to bottom: the physics launch → the tutor pool → demo lessons and vetting (one owner) → “send candidate 7 a demo slot” (a task on that owner's board). Other branches split the same way: the curriculum into five units from mechanics to atomic physics; the tutor pool into sourcing and screening (Roman), demo lessons (Vira) and onboarding (Roman); the test into Vira's question bank and Danylo's build on the platform.

Each level answers a different question: what do we hand over? (deliverables), who does which part? (pieces), how today? (tasks). The project lead tracks the pieces, not every message to a candidate.

A tree is only useful if it passes the 100% rule: it covers all the work of the project, and every piece of work appears in it once. The rule has two halves, and each catches a different failure.

Something missing. Nobody listed launch communications, so the landing page would wait for visitors who never come. And project management itself (the plan, the weekly status, the risk list) is real work with real effort: leave it out and your days come from nowhere.

Something twice. Vira's units already include practice problems, and there's a separate branch for practice sets. If the same problems sit in both, someone counts the effort twice, or each author thinks the other one writes them. Give each piece one home.

The rule doesn't care about style choices: splitting the curriculum into five units, or hanging demo lessons under the tutor pool rather than the curriculum, is fine as long as each piece appears exactly once.

Break the work down until each piece has one owner who can estimate it in days, roughly up to two weeks of effort. Stop there. Below that level, the owner keeps the task list, not the project lead.

Danylo's sixty lines stay on his board; the tree says “diagnostic test on the platform, owner Danylo”. Going deeper doesn't make the plan more accurate. It makes it heavier to maintain, it changes daily, and it takes the owner's planning away from them. A lead tracking every hour of Danylo's work learns nothing that “the test build is on track, about 8 of 12 days done” wouldn't tell them.

Going too shallow fails the other way: a piece like “platform work, 40 days” can't be estimated or owned by one person, so it hides surprises. If a piece is bigger than about two weeks, or two people would argue about what's inside it, split it one more level.

Once the tree passes the 100% rule, flatten it into a deliverable list: one line per piece, with four columns.

1. The deliverable (a noun someone can check).
2. One owner.
3. An effort range in person-days: optimistic, likely and pessimistic, because a single number hides how uncertain the piece is.
4. What it needs first: the pieces that must be done before it can start.

Effort is person-days, not calendar weeks. How much work there is and when it can happen are different questions: Roman works on the launch two days a week, and demo lessons can't start before the curriculum exists. The calendar comes from a later step, the schedule, which uses the “needs first” column.

The list is what the rest of the module works with: next lessons add what “done” means for each line and decide what to cut if the total doesn't fit the capacity.

Every line of the deliverable list gets exactly one owner: the person who answers for it, not necessarily the only person who works on it. A line with two owners has none, because each can reasonably assume the other one is on it.

Demo lessons look like a shared job: Roman schedules candidates, Vira watches and judges them. Writing “Vira and Roman” saves a line and creates a gap. Instead, split the line at the hand-off: “demo slots for 15 candidates, owner Roman” and “demo lessons judged, at least 8 passed, owner Vira”. Now each piece has a person who can say whether it's on track.

Two other shortcuts fail the same way. Putting the project lead as owner of everything hides who does the work and makes the lead a bottleneck. Leaving the owner blank “until it starts” is how pieces slip without anyone noticing.

Every item that comes up in planning has exactly one place to live, and putting it in the right one keeps the plan clean.

• A deliverable in the tree: something the project hands over and someone can check, such as the diagnostic test on the platform.
• The project management branch: the plan, weekly status and risk list. The 100% rule puts the lead's own work in the tree too.
• A task on the owner's board: “write test question 14” helps a deliverable but isn't tracked by the lead.
• The out list in the brief: a mobile app for physics isn't in the project at all. What isn't in the tree isn't in the project until Leo decides otherwise.

When an item seems to fit two places, it usually means it's too big (split it) or it hides a decision (take it to the sponsor).

How it fits together: deliverables first, a tree that covers everything once, pieces with one owner and an effort range. Next lesson: what “done” means for each line.