• If you are new to these Forums, please take a moment to register using the fields above.


No announcement yet.

When to Spawn Sub-Projects

  • Filter
  • Time
  • Show
Clear All
new posts

  • When to Spawn Sub-Projects

    Just curious about when/where people spawn sub-projects - rule of thumb or something. E.g., I'm working on a project (3 months probably) to integrate an accounting system, so that's a project, and today' I'm trying to build a schema for something on that project that will proably take a week's worth of tasks.

    In this situation do people add a project to their project list called "Build Schema for Integrate Accounting Project", or just put that in their outline for their project.

  • #2
    On large projects, I fire up Mind Manager and create a fairly detailed project plan. I then transfer the Next Physical Action to my Next Actions Lists and go to work.

    Because I'm consistent with my Weekly Review, I never seem to have any problem using the plain GTD System to manage even my larger projects.

    For me, the key is regular interaction with my Projects List and the Mind Map I create for the larger projects. In fact, it's all pretty intuitive at this point.


    • #3
      I would track it within the larger project.


      • #4
        You could make a "master" project and folder for it, which would contain your highest-level plans - sub-projects, deadlines, etc. Then then make a project for every multi-step piece that can/should move independently.


        • #5
          re: When to Spawn Sub-Projects

          I developed my own philosophy about sub-projects with the Ready-Set-Do! GTD-program I designed for the Mac. It's even got a Quicktime Video devoted specifically to sub-projects.

          Essentially I treat sub-projects as "projects" without the "sub" by putting them at the main Projects list, and leaving a marker in the main project indicating it has been pushed out to the main level. This allows sub-projects to be treated as what they are -- multi-step actionables (i.e. projects). And secondly, it keeps from spring-loading too much complexity within any given project (i.e. making one project look huge compared to the rest because of all of its "nested" -- and therefore, hiding -- sub-projects). This creates a much larger list of projects at the main level, but it provides a more proportional horizon of your multi-step tasks (no one project looks bigger than the others) and is an accurate inventory of the commitments you've agreed to with your projects. I think for those who work with outliners for brainstorming projects, something like this is a much better approach to sub-projects, whereas those who prefer mind-mapping can just work off of their mind-maps to break things down further.

          This is what's working for me.
          Last edited by Todd V; 07-01-2011, 10:49 PM.