Sub-projects

[GTDClone]

Is it ok to have a project(s) inside a project? All are proper outcomes and are not Areas of Focus, Goals and etc. And all have next actions and are not dependant.
Is it ok to have nested sub-projects inside a project or is this somewhat against GTD and you should have only a flat list of projects?
I'm just asking is it ok to keep them nested, of course it's ok to have sub-projects overall.
Are there any cons to this format?
I think that it's perfectly ok btw as long as I review them all and it makes things easier, but would like to know what other people think about this.

Here is an example

project
-sub-project

project
project
project

and etc.

 

[Oogiem]

Is it ok to have a project(s) inside a project? ...
Are there any cons to this format?

It's certainly OK but as I recently found out there are significant cons to that system.

I had a project which was to handle our ditch company financial paperwork. One subproject is to pay the ditch rider for wages, another is to pay the ditch rider for expenses and a third was to file federal wage reports. They were parallel so I could potentially do any of them in any order. However I found that due to being short of cash because people haven't paid their ditch assessments yet we could not pay the ditch rider for his expenses yet. And that stalled the action to file wage reports and I was very nearly late on it. Splitting those out into multiple projects and setting the federal due dates for reports appropriately is much safer.

Be very cautious when setting up sub-projects and decide if it might be better to have many multiple projects in a single area instead.

 

[kglade]

FWIW, I have found that subprojects make the GTD system much more complicated than the value that they bring.
My analytical mind 'wants' there to be a project hierarchy, but I have found in the trenches that just making each subproject its own Project works better. Your mind can connect all the subs together well enough, and better than any software system I've tried. I expect that many others could post of their successes with subprojects in specific software packages, but I am a Lotus Notes user with EProductivity and not looking to change.

 

[Gardener]

I don't like subprojects and I don't like "task groups" in Omnifocus. Hierarchical structures reflect a plan for how I'm going to do a body of work, and that plan can change, resulting in a bunch of untangling of levels. It's the same as the problem with creating long lists of future actions, except it's much harder to clean up.

Even when a project depends on the completion of another project, I prefer to make them both top-level projects and give the dependent project a "waiting for" Next Action that points to the other project. And when the projects are all aimed toward the same goal ("declutter for house sale" "hire stager for house sale", "refresh landscaping for house sale"), I just let the project names reflect that, rather than wrapping them in an outer "superproject" wrapper.

 

[GTDClone]

Thanks for the replies.
I don't see how this format would make the system much more complicated though.

I mean is there really much difference if I can see all my projects anyway and I can assign deadlines to sub-projects separately in the same way as to the projects?

project
-sub-project
project
project
project

or

project
sub-project
project
project
project

Also sub-projects don't reflect planning in my case. It's not going to change, it's not a plan, it's more of an action broken down to a more granular level to make sure it really gets done.
I'd rather say using waiting for in projects to point out to sub-projects would make it more complicated.

"And when the projects are all aimed toward the same goal ("declutter for house sale" "hire stager for house sale", "refresh landscaping for house sale"), I just let the project names reflect that, rather than wrapping them in an outer "superproject" wrapper."

When the projects are all aimed toward the same goal I wouldn't wrap them in an outer "superproject" wrapper" either. I'm not using goals or Areas of Focus as projects.

Also if you are using projects names to reflect that wouldn't it be the same thing as using nested projects? You're just using text to make nested projects

I mean isn't it the same thing:

sold the house.
sold the house. declutter for house sale
sold the house. hire stager for house sale
sold the house. refresh landscaping for house sale
project
project

as

sold the house.
-decluttered for house sale
-hired stager for house sale
-refreshed landscaping for house sale
project
project

except with less text?

Again I wouldn't use Sold the house as project so it's just an example

 

[Gardener]

Hey, I'm not saying that you're not allowed to use subprojects, I'm saying that I don't like them.

Thanks for the replies.
I don't see how this format would make the system much more complicated though.

It might depend on your choice of tool, but I'd say that in any case it's a little more complicated, and I'm not seeing a payoff for me.

I mean is there really much difference if I can see all my projects anyway and I can assign deadlines to sub-projects separately in the same way as to the projects?

This would also depend on your choice of tool, and how easily it lists subprojects with projects.

Also sub-projects don't reflect planning in my case. It's not going to change, it's not a plan, it's more of an action broken down to a more granular level to make sure it really gets done.

Here I think I need examples of how you'd use subprojects. To me, tucking a project one layer down would make it less visible, and therefore less likely to get it done. If your tool doesn't put it "one layer down" in terms of display, I still don't see how it's _more_ likely to get done.

I'd rather say using waiting for in projects to point out to sub-projects would make it more complicated.

I'm not using sub-projects, so this isn't what I'm doing. I'm using parallel projects, some of which are Waiting For other projects to be done. So, for example, I might have:

Project: Irrigation installed in front lawn
Next Action: Ask Jane who she used for her landscaping.

Project: Front lawn perennials planted
Next Action: WAITING FOR Irrigation installed in front lawn

Each of these could be a subproject of Front Lawn Landscaped, but I don't like that.

When the projects are all aimed toward the same goal I wouldn't wrap them in an outer "superproject" wrapper" either. I'm not using goals or Areas of Focus as projects.

Again, I'm not clear on what you're using subprojects for.

Gardener

 

[GTDClone]

Gardener,
Well let's say I'm using just paper, so nested sub-projects don't add any complexity to my list of projects because it's not hard to maintain structure such as

project
-sub-project
project
project
project

the payoff is that it's easier to track visually compared to just a flat list even though it's only a slight difference.

"Here I think I need examples of how you'd use subprojects. To me, tucking a project one layer down would make it less visible, and therefore less likely to get it done. If your tool doesn't put it "one layer down" in terms of display, I still don't see how it's _more_ likely to get done."

I don't do projects anyway, I can only do actions, using nested sub-projects makes it more likely that I will break an action into more granular actions which would help me get things done... Then it would also be easier to visually track outcomes of those actions at the Project level and see that once such sub-project is complete I still have an open loop. Even though the benifit is minimal but I don't see any additional complexity.

"I'm not using sub-projects, so this isn't what I'm doing. I'm using parallel projects, some of which are Waiting For other projects to be done. So, for example, I might have:

Project: Irrigation installed in front lawn
Next Action: Ask Jane who she used for her landscaping.

Project: Front lawn perennials planted
Next Action: WAITING FOR Irrigation installed in front lawn

Each of these could be a subproject of Front Lawn Landscaped, but I don't like that."

"Project: Front lawn perennials planted
Next Action: WAITING FOR Irrigation installed in front lawn"

I wouldn't have this as a project, I would just keep this in project support as a plan/overview because it's dependant/sequential and not a parallel project(yet). If it doesn't have any next actions yet then it's not a project I will track.

btw you have said

I don't like subprojects and I don't like "task groups" in Omnifocus. Hierarchical structures reflect a plan for how I'm going to do a body of work, and that plan can change, resulting in a bunch of untangling of levels. It's the same as the problem with creating long lists of future actions, except it's much harder to clean up.

But then it seems that you actually use projects to reflect your plans somewhat... While I actually don't. Even though I use nested project and you don't, interesting
Btw I wouldn't track "Front Lawn Landscaped" as a project either because it's too big. So depending on how long it takes and how much attention it needs I would either have Front Lawn as an Area of Focus or Front Lawn Landscaped as a Goal.

Again, I'm not clear on what you're using subprojects for.

I use them quite seldom to break an action into more granular actions. So for me Sub-project most of the time is something that was an action in a project but then I decided to make it even more granular.

 

[kglade]

Of course, you may use subprojects, or anything else that makes you more productive.

For me, I would spend too much time recategorizing subprojects. Is "hire stager for house sale" a sub of "declutter for house sale?" Is the next action "throw away sofa" a sub of "staging" or of "declutter?" I tried subprojects a few times, and always dropped the idea because in the end, it doesn't matter is "declutter" is a sub of "stager" or a sub of "house sold." I realized that it doesn't matter if it is a sub AT ALL, so I dropped the complexity.

But if it works for you, or you can figure out a way to make it work, go for it!

What I do, though, is categorize projects by area in the factory (I'm an engineer), and by person delegated to (I'm a manager), so that I can see different views when I need to.

This does add complexity, but is worth the effort to me.

Ken

 

[GTDClone]

For me, I would spend too much time recategorizing subprojects. Is "hire stager for house sale" a sub of "declutter for house sale?" Is the next action "throw away sofa" a sub of "staging" or of "declutter?" I tried subprojects a few times, and always dropped the idea because in the end, it doesn't matter is "declutter" is a sub of "stager" or a sub of "house sold." I realized that it doesn't matter if it is a sub AT ALL, so I dropped the complexity.

But if it works for you, or you can figure out a way to make it work, go for it!

Yeah, it's a good point. The way I use sub-projects though is that a Sub-project most of the time is something that was already an action in some Project but then I decided to make it even more granular.

It doesn't really matter to me if everything is perfectly organized in terms of projects and sub-projects. Everything is just a project 90% of the time and only when it's really just obvious that something should be a Sub-project then I might nest it under it's Project. But I find it useful too.
So far I don't see any cons to this approach for myself but I can see how some people might take this too far and over-organize

"Is "hire stager for house sale" a sub of "declutter for house sale?" Is the next action "throw away sofa" a sub of "staging" or of "declutter?""

Btw I can actually connect a Sub-project to both Projects easily though, I'm not limited by a strict hierarchy.
However I haven't found any case in which I wanted to.
I actually had one next action today which moved muliple projects forward, it happens, but it's pretty rare and I don't track it on purpose

 

[Gardener]

Yeah, it's a good point. The way I use sub-projects though is that a Sub-project most of the time is something that was already an action in some Project but then I decided to make it even more granular.

I definitely agree with the "more granular" part, but I wouldn't break out to a subproject in this case - I'd either put the smaller action(s) in the main project, or I'd make a separate project out of it. Again, this is what I would do, not anything that I'm saying that you should do.

Gardener