Granularity of Project List for Complex projects

[Y_Lherieau]

I've read the book multiple times and this is something that's never really been clear to me - how many "sub-projects" and "sub-sub-projects" do you normally put on your Projects list all at once? Let's use the example of selling my house this year as my complex project. Within the final outcome of selling and moving there are a number of subprojects I need to complete, such as:

• Get fireplace repaired and in working order
• Get kitchen sink replaced
• Repaint baseboard trim
• Get carpets shampooed
• List house for sale
• Pack and Move

In reality, each of those includes multiple projects underneath them, for example getting the kitchen sink replaced will require:

• Choose plumber (research local plumbers, call each to request a quote, choose the one that fits best)
• Choose and purchase replacement sink (take measurements, research options, purchase the sink and hardware)

How many of those projects, subprojects, and sub-subprojects go on your list typically? Do you list "Sell House" on your Projects list in this case, AND "Replace Kitchen Sink", AND "Choose plumber", AND "Choose and purchase replacement sink"? Do you put "Sell House" on a different list of large projects and then only the subprojects go on the active list? Some other approach?

Thanks!

You’re not missing anything — if I got you right, you’re simply trying to “lock in” structure before the GTD process has had the chance to do its work.

In my experience, clarity around project/sub-project hierarchy never comes from theory — only from running the GTD workflow properly.

Here’s how I handle it in my own system:

1) The Natural Planning Model reveals the right granularity — every single time.

When I run the NPM all the way — especially the brainstorming step — the structure becomes obvious on its own.

After dumping all the moving parts, some items simply “cluster together” and emerge as genuine outcomes. Those become child projects.

If nothing emerges? Then I don’t create sub-projects.

I’ve learned the hard way that forcing structure early only creates friction and guilt.

2) In my system (Todoist), sub-projects are frictionless — so I only promote what truly deserves it.
My personal rule of thumb:

• If it needs its own outcome,
• its own set of actions,
• or its own waiting-for,

→ it becomes a sub-project.

Otherwise, it stays as a Next Action.

Examples from my own practice:

• “Choose plumber” → usually not a project
• “Replace kitchen sink” → yes, a project
• “Sell the house” → the parent project

Trying to elevate every micro-step to project-level would just turn my Projects list into noise.

3) I often use ‘product design thinking’ to clarify structure

GTD meets systems thinking — extremely effective. I imagine the whole thing as if I were shipping a product.
The “deliverables” tell me what needs to exist as independent, trackable components.

For your example, here’s how I’d frame it:

Parent project

• Sell House

Child projects (major independent deliverables):

• Replace Kitchen Sink
• Repair Fireplace
• Repaint Trim
• Carpets Shampooed
• List Property
• Pack & Move

Inside Replace Kitchen Sink, I’d keep almost everything as actions:

• Take measurements
• Research sinks
• Research 3 plumbers

Only if a component requires multiple decisions or dependencies (e.g., coordinating quotes, timing, payment) would I promote it:

• Small sub-project (if justified): Choose plumber

But notice what I wouldn’t elevate:
“Choose and purchase replacement sink.”
That is simply a sequence of actions, not an outcome.

Bottom line — the way I apply GTD

• If it has a meaningful outcome and lives across time → project
• If it’s just several steps → actions
• If it’s too early to tell → go back to the NPM; don’t force clarity

Every time I’ve followed this, the system stayed clean, flexible and friction-free.

 

[gtd solo-studente]

You’re not missing anything — if I got you right, you’re simply trying to “lock in” structure before the GTD process has had the chance to do its work.

In my experience, clarity around project/sub-project hierarchy never comes from theory — only from running the GTD workflow properly.

Here’s how I handle it in my own system:

1) The Natural Planning Model reveals the right granularity — every single time.

When I run the NPM all the way — especially the brainstorming step — the structure becomes obvious on its own.

After dumping all the moving parts, some items simply “cluster together” and emerge as genuine outcomes. Those become child projects.

If nothing emerges? Then I don’t create sub-projects.

I’ve learned the hard way that forcing structure early only creates friction and guilt.

2) In my system (Todoist), sub-projects are frictionless — so I only promote what truly deserves it.
My personal rule of thumb:

• If it needs its own outcome,
• its own set of actions,
• or its own waiting-for,

→ it becomes a sub-project.

Otherwise, it stays as a Next Action.

Examples from my own practice:

• “Choose plumber” → usually not a project
• “Replace kitchen sink” → yes, a project
• “Sell the house” → the parent project

Trying to elevate every micro-step to project-level would just turn my Projects list into noise.

3) I often use ‘product design thinking’ to clarify structure

GTD meets systems thinking — extremely effective. I imagine the whole thing as if I were shipping a product.
The “deliverables” tell me what needs to exist as independent, trackable components.

For your example, here’s how I’d frame it:

Parent project

• Sell House

Child projects (major independent deliverables):

• Replace Kitchen Sink
• Repair Fireplace
• Repaint Trim
• Carpets Shampooed
• List Property
• Pack & Move

Inside Replace Kitchen Sink, I’d keep almost everything as actions:

• Take measurements
• Research sinks
• Research 3 plumbers

Only if a component requires multiple decisions or dependencies (e.g., coordinating quotes, timing, payment) would I promote it:

• Small sub-project (if justified): Choose plumber

But notice what I wouldn’t elevate:
“Choose and purchase replacement sink.”
That is simply a sequence of actions, not an outcome.

Bottom line — the way I apply GTD

• If it has a meaningful outcome and lives across time → project
• If it’s just several steps → actions
• If it’s too early to tell → go back to the NPM; don’t force clarity

Every time I’ve followed this, the system stayed clean, flexible and friction-free.

@Y_Lherieau

Thank you for posting: "If it’s too early to tell → go back to the NPM; don’t force clarity"

Don't force clarity seems especially GTD worthy:

As such, appropriate Disengagement, aka, Reflection, is often more important than what seems like appropriate Engagement even if the actual appropriate Engagement could actually be increasing Clarification at the easier subconscious level which might be why Might Mind Like Water can be as optimally GTD efficacious as GTD can be ?

As you see GTD fit. . . .