LayerClock
All articles
Product

Why Four Levels? Adding the 'Deliverable' Layer

Try a few WBS tools and the structure tends to rhyme. There's a "project" at the top, and "tasks" hanging off it. The more careful ones slip a "phase" or a "list" in between, making three levels. LayerClock adds just one more layer beyond that: a "deliverable," sitting between the phase and the task, for four levels total.

More levels aren't automatically better. The deeper you go, the more there is to fill in, and plenty of situations run more smoothly when the structure stays shallow. I added one anyway, for a reason — and this article is about that single added layer, nothing else. Why phases and tasks alone weren't enough, what changes in the plan when you slip a deliverable in, and what a good deliverable cut looks like, in that order.

There's a Hole Between the Phase and the Tasks

I used to freelance on contract work, then spent years as an engineer at a large company, and now I do security consulting. The role and the setting kept changing, but I ran into the same scene everywhere: someone builds a beautiful WBS, and partway through, no one looks at it anymore. It becomes an ornament.

There are several reasons a WBS ossifies. But structurally one is clear to me: the unit that says "when is this chunk actually done?" has fallen out of the plan.

Let's look concretely. In a three-level tool, you make a "design" phase for a project. Under it you hang tasks: "write the screen flow," "decide the tables," "handle review comments," "investigate the auth." At a glance, it's decomposed fine. But something's missing. Within the design phase, what exactly do you have to finish before design is done — a "basic design document"? "a full set of screen mockups"? "an API spec"? That thing-to-be-produced slips through the gap between the phase and the tasks.

Proceed with it missing and here's what happens. A phase is too big to tell when it ended. A task is too small — cross one off and you can't say which part of the whole moved. Without a unit in between that lets you say "once this is built, that's a milestone," progress can only be told as "how many tasks did I close." "Design phase, 3 of 7 done" — that number expresses busyness, not completion. If the remaining four are light, design is nearly finished; if the remaining one is the main event, the basic design document, you're not even halfway. Counting erases that distinction.

Slipping a "Deliverable" into the Gap

So LayerClock put a "deliverable" between the phase and the task. For a design phase, that's "basic design document" or "screen mockups." For an implementation phase, "login feature" or "checkout feature." A unit that, once built, you can hand to someone or send to review. Tasks become the fine-grained steps for producing that deliverable, hanging beneath it.

Let me rebuild the earlier example with this layer in. Under the design phase, first place the deliverables "basic design document" and "screen mockups." "Write the screen flow" and "decide the tables" go under the basic design document; so does "investigate the auth." Now progress reads as "basic design document 80%, screen mockups not started" — told in units of completion. Not by count, but by how much of a hand-off-able thing is finished.

With that one layer, first, how you estimate changes. Not one coarse "40 hours for the whole design phase," and not a fine stack of per-task figures, but how many hours each deliverable takes. That's probably the unit people naturally think in at work: "three days for the basic design document, two for the mockups" lands better than "forty hours on the design phase." Not too big, not too small. The granularity that's just right for placing an estimate lives here.

How you read the actuals changes too. The time your timer stacks up is rolled up per deliverable, so you can read "the screen mockups took twice the estimate." Next time you estimate a similar deliverable, that one line is your evidence. Phase-level is too coarse — you can only say "design ran long"; task-level is too fine — "47 minutes on this function" just scatters. The deliverable is the right-sized chunk you can look back on and reuse.

Good Deliverable Cuts, Bad Ones

That said, told to "place a deliverable," at first you're unsure where to cut. Three things I use as a guide.

One, can you write it as a noun? "Design," "test" are verbs — those are phases or work. "Basic design document," "test result report" are nouns — those are deliverables. When you want to write a verb, that's a sign it isn't a deliverable yet.

Two, can completion be judged? Not "roughly done" but a line you can assert: "this is done, ready for review." Something you can't draw that line on is too big or too vague to be a deliverable. "Frontend" can't be judged; "login screen" can.

Three, can you hand it to someone / show it? A deliverable is, boiled down, "a unit of passing the baton." A design doc goes to a reviewer, a feature to a tester, an article to an editor. Cut at a unit where you can picture who receives it, and the granularity roughly lands. Conversely, work that stays inside your own head and passes to no one is better hung below as a task, not a deliverable.

The classic bad cut is copying a phase straight into a deliverable. Placing one deliverable named "design" under the "design" phase splits nothing. When phase and deliverable become one-to-one, that's a sign you're not using the deliverable layer — try to split the inside of the phase into two or three "hand-off-able" things.

This Isn't Just About Web Development

Say "deliverable" and you picture design docs or code modules, but the idea doesn't care about your profession. From contract dev to enterprise engineering to the security consulting I do now, the thing I handle changed, but this one move — "cut at a hand-off-able unit" — worked at every site.

In design, the phase is "visual production" and the deliverables are "homepage comp," "logo set," "five banners." In writing, the phase is "drafting" and the deliverables are "outline," "body draft," "final for submission." In video, "main cut," "thumbnail," "teaser." Even in the security assessments I do now, with the phase "assessment" and deliverables like "assessment report," "retest results," "executive summary" — cutting by the unit you're expected to hand over suddenly tightens both estimate and progress.

What they share is that every kind of work has some "once this is built, a chunk is finished." It's not an engineer-only concept; any work that delivers something usually has this unit. Whether you can bring it into the plan is, I suspect, what decides whether a WBS becomes a living tool or an ornament the moment it's made.

That Said, You Don't Have to Fill All Four Every Time

Honestly, four levels is headroom — "you can split this far if you need to" — not a mandate to always split that far. For a small solo job, just lining up deliverables is enough; for exploratory work where the deliverable isn't clear yet, forcing one is what stalls you. I start shallow myself and only split deeper where the coarseness starts to bother me. Which depth suits you is something I wrote up separately in who actually needs "hierarchy" in a time-tracking tool, so I'll leave it there.

What this article was about isn't how to choose the depth — it's the one thing before that: can you bring a "unit of done" into the gap between the phase and the tasks? The deliverable layer is unglamorous, but it's the single tweak that most reduced the moments where I feel a WBS is "about to become decoration." If I was going to add a level, this is the one I added.

Related articles

The four-level WBS in this article (project, phase, deliverable, task) is the idea at the heart of LayerClock. You place an estimate on each deliverable and read back the actual time your timer stacks up, per deliverable. This four-level structure and the timer stay free, for good.

Try LayerClock →