Linking Projects, Sub Projects and Next Actions

[djc2008]

I have been working with GTD for about a year now and one of the challenges I have is keeping track of all the discrete next actions associated with projects as well as determining when a project needs to be broken down to "sub projects" with their own sets of next actions.

For example, one of the projects I am leading is the development of a new training program for employees. There are many "fronts" that require attention such as deciding on the vendor who will help us develop the training, estimating the budget, assembling the project team, managing scope with stakeholders, developing a communication plan, etc.

I believe these "fronts" can be seen as sub-projects that have their own set of next actions. I guess it is a matter of experience and personal judgment how broad the fronts should get to avoid getting carried away and have too many or not having enough.

QUESTION: Any useful guidelines on this?

Also, I track most of my projects, sub-projects and next actions in Lotus Notes (on the To Do application). But sometimes find myself capturing next actions in physical project support folders (e.g., work plans, meeting notes, etc). Therefore, I often find myself having to double entry those next actions from physical objects into my Lotus Notes digital tracking system.

Sometimes I find that the "overhead" of logging, ticking and tying all next actions with all the sub project fronts and keeping track of all of them is a bit overwhelming...especially on some days when things are very dynamic and change rapidly (e.g., next actions get completed in rapid succession or change into waiting for's). During these times, it becomes very hard to keep things synchronized and I find my next action list quickly becomes obsolete.

I suppose the risk of not managing all these fronts and associated next actions is that something falls through the crack or "blows up." I know that the Weekly Review is the key activity that helps you manage all of this (or at least keep you aware of the things you need to be aware of). But it does feel like during those really hectic days, "falling off the wagon" is quite easy.

QUESTION: Does anyone have recommendations on what you have done to manage this effectively or have some "leading practice" tips?

Thanks

 

[Todd V]

re: Linking Sub-Projects

It took me awhile to figure out what would work the best for me. I finally came up with a solution that has been working perfectly. It works by using aliases on my computer to link everything. Next actions are aliases linked to their original place in their respective projects.

You can see how it works by watching "What About Sub-Projects?" located here.

In addition to handling next actions and sub-projects, it also allows for navigating the vertical dimensions of my projects, and using tags for keeping the projects list better organized.

That might give you some ideas. I think the key is to get sub-projects out to the main level of your projects list with some system for keeping them linked with their governing projects and regularly reviewed.

 

[sdann]

Re the size of projects. A project should really be the size that is most manageable for you. If a project seems inactionable, then you need to further define it (use NPM) and/or break it down. For me it is also more motivating to finish smaller projects than to have a larger project languish over time.

Re your project lists. I would keep a straight list of projects whether or not they relate to one another. First and foremost, you probably already know which belong together. Secondly, you can keep a nested view of your projects elsewhere. The most important part of a project list is quick overview.

 

[abhay]

... and one of the challenges I have is keeping track of all the discrete next actions associated with projects as well as determining when a project needs to be broken down to "sub projects" with their own sets of next actions.

If you have the habit of working off your next action lists, i. e. you refer to them many times a day, then all you need to do is look at the project support material and ask yourself whether there is an action associated with each of the independent parts of the project. You will usually remember what actions you have put in your action lists by association.

...

I believe these "fronts" can be seen as sub-projects that have their own set of next actions. I guess it is a matter of experience and personal judgment how broad the fronts should get to avoid getting carried away and have too many or not having enough.

As a guiding principle, each major independent outcome in the main project can be taken as a project itself. Just as you say, whether you record it as separate projects or as notes of the main project is up to you. I find it useful to put it all in one. All that matters is that this material should make these outcomes self-evident; it does not hide them. (So I prefer bullet points rather than long paragraphs.)

Also, I track most of my projects, sub-projects and next actions in Lotus Notes (on the To Do application). But sometimes find myself capturing next actions in physical project support folders (e.g., work plans, meeting notes, etc). Therefore, I often find myself having to double entry those next actions from physical objects into my Lotus Notes digital tracking system.

I think what mostly goes in project support or work plans is not discrete next actions to the level GTD recommends putting in next action lists; most of the times they are outcomes that would eventually trigger next actions. Just check whether this is a symptom of overplanning. Apart from that, processing meeting notes and work plans once they are made is the usual GTD processing; and most people usually process their input at least once a day.

Sometimes I find that the "overhead" of logging, ticking and tying all next actions with all the sub project fronts and keeping track of all of them is a bit overwhelming...especially on some days when things are very dynamic and change rapidly (e.g., next actions get completed in rapid succession or change into waiting for's). During these times, it becomes very hard to keep things synchronized and I find my next action list quickly becomes obsolete.

Do you mean to say your software allows to connect next actions to projects? Even if it does, it's not necessary to actually provide the links. The software does not need to know what actions are from what projects. Think of it: If you look at an action in your list, can you not say which project this action came from? (In case the answer is no, just rephrase it to contain little more information.) And if you are working consistently from your action lists, and look at a project, can you not say whether this project has an action? In fact, you will also recall the exact action.

Yes, weekly review is the right place for catching up on most of the projects, but as you say, sometimes a day is hectic or a project is hot. In that case, keeping that particular project with all its outcomes constantly in front of your eyes for that day will help.

Another thing you might want to evaluate is the software, and your way of using it. There are two parts to it: It is ideally a part of working habits to check off actions as you complete them and add next actions as soon as you are about to leave working on it (may be even for a coffee break). Since it's a habit, it will take time to form. Secondly the system that you are using may actually be a hurdle making it difficult to enter these things swiftly. (also see above for the comment about linking actions with projects.) Can you find better way of using the software? Do you need to reconfigure or entirely change your system? More sophistication is bad in my opinion; simplicity and speed is what is desired. (I am assuming typing itself is not a problem for you.)

I suppose the risk of not managing all these fronts and associated next actions is that something falls through the crack or "blows up." I know that the Weekly Review is the key activity that helps you manage all of this (or at least keep you aware of the things you need to be aware of). But it does feel like during those really hectic days, "falling off the wagon" is quite easy.

Feel free to fall off the wagon! Usually after referring to you calendar, and having done a weekly review at the most within the last seven to eight days, you will know what things will explode if not handled well, so go ahead and handle them. Then give yourself time to get back on the wagon, do an early weekly review, and get back on track!

QUESTION: Does anyone have recommendations on what you have done to manage this effectively or have some "leading practice" tips?

Simplicity!

Hope this helps,
Regards,
Abhay

 

[kewms]

Sometimes I find that the "overhead" of logging, ticking and tying all next actions with all the sub project fronts and keeping track of all of them is a bit overwhelming...especially on some days when things are very dynamic and change rapidly (e.g., next actions get completed in rapid succession or change into waiting for's). During these times, it becomes very hard to keep things synchronized and I find my next action list quickly becomes obsolete.

Nothing in GTD requires this degree of logging and tracking. From GTD's point of view, if the overhead is too much then you've got the wrong system.

There are at least two possible approaches.

If you tend to work on a single project for an extended period of time, just record the Next Action when you stop and move on to something else.

If you tend to work on many different projects in quick succession, you might set aside time for a quick daily review, just to make sure that you've captured action items from meeting notes and that your lists are current at the start (or end) of the day.

Katherine

 

[dschaffner]

Sometimes I find that the "overhead" of logging, ticking and tying all next actions with all the sub project fronts and keeping track of all of them is a bit overwhelming...

This seems to me like an indication that your system is too complex.

I think you need to (A) think about ways to simply your system or (B) resolve that you will go off the rails when this happens, and wait until your next weekly review to recover.

- Don

 

[djc2008]

Thanks for the feedback

Thank you all for your helpful feedback. I guess for me another way to describe my challenge is that I am trying to put ALL projects and next actions into one list manager (i.e., Lotus Notes To Do) so that I know everything that I could possibly be doing at any given time.

I recognize that keeping things simple is the key. Most certainly, I am not trying to do any fancy electronic tricks to link every single next action back to their parent sub project or project. I like the idea of ensuring that the next action has enough words in the description that you automatically know which project it refers to.

Yet, it does take practice and time to develop a level of intuition and trust (perhaps even faith?) that the process works such that a) you have identified/captured all projects and b) that all those projects have next actions...and doing it to the point where you need to and not more. I suppose finding that "just right" point for me is the goal/challenge.

 

[abhay]

Thank you all for your helpful feedback. I guess for me another way to describe my challenge is that I am trying to put ALL projects and next actions into one list manager (i.e., Lotus Notes To Do) so that I know everything that I could possibly be doing at any given time.

You have hit the right GTD idea! GTD is having everything externalized in a logically single system/workflow. (Though physically the parts could be separated.)

Just one more remark: There is no one "just right" point; it keeps moving with your experience in GTD, your type of work, and other things which constantly evolve. Just for a metaphor, imagine you are a shepherd and all your projects are your sheep. They will move on their own (because you complete actions) -- some fast, some slow. All you have to do is keep guiding them and keep a watch overall (weekly review!), not let a few of them fall apart and move away from the herd (falling through cracks), and not worrying about their each and every movement. You might also find the following article helpful:

http://www.gtdtimes.com/2008/08/04/this-is-your-elephant-on-gtd-any-questions/

Don't worry about your system not being perfect; it can only be better and better, not the best or ideal. Deal with particular system issues that are nagging you (by making it a project!), and your system will evolve. We all have accepted the cost of having an up to date system, if that can be called a cost.

Regards,
Abhay