Can you assign a task to more than one project?
It's possible that a single task could impact more than one project. Say for example that I'm building a bookshelf and table. For both projects I'll need nails. They would each have "Buy nails" as a task. I would like to be able to have the same task impact both projects. In the To Do List I would like "Buy nails" to show up once rather than twice for each project. Then when I check it off and update the next task appears for both projects.
Is this really necessary?
While conceptually this makes sense (assigning a task to 2 projects), and I have some empathy for it, practically why does it matter? The key thing is that you buy nails.
Many of my tasks could be allocated to different projects, including different TLI's. I just pick the one that the tasks seems to most "fit", or is more important to, and move on.
If you were using a paper-based system to achieve the same end as LB, would you really write "buy nails" twice as part of your projects' plans, or would you just note on your to-do list that you need to buy nails for your table & bookshelf projects? And in that may be your answer: maybe "buy nails" isn't actually part of either project, but is a necessary precondition for both projects to proceed.
Yes, this is necessary. You
Yes, this is necessary. You don't wish to see the tasks dependent on having nails until you have gotten the nails.
Try "complete subtasks in order" for simple dependencies.
You could use "complete subtasks in order"
* woodworking projects <-- complete subtasks in order
** get nails
** make shelves
** make table
After you've got the nails, you can even switch the parent project to not be "complete subtasks in order if you want to make shelves and tables at the same time... maybe you are really good and can do that. Me, I would want to do one project and then the other.
It all depends. There's almost always a way to structure your project. And you can change settings around during the project, too, if you suddenly realize you got the wrong kind of nails, and have to return them to the store... and so forth.
Projects nearly always evolve as you do them. We don't recommend putting a task under more than one project because it mostly just complicates the structure with very little real benefit. Pick the project it most contributes to, and then do the task.
Best wishes,
--Catherine--*
Try "complete subtasks in order" for simple dependencies.
You could use "complete subtasks in order"
* woodworking projects <-- complete subtasks in order
** get nails
** make shelves
** make table
After you've got the nails, you can even switch the parent project to not be "complete subtasks in order if you want to make shelves and tables at the same time... maybe you are really good and can do that. Me, I would want to do one project and then the other.
It all depends. There's almost always a way to structure your project. And you can change settings around during the project, too, if you suddenly realize you got the wrong kind of nails, and have to return them to the store... and so forth.
Projects nearly always evolve as you do them. We don't recommend putting a task under more than one project because it mostly just complicates the structure with very little real benefit. Pick the project it most contributes to, and then do the task.
Best wishes,
--Catherine--*
I often have several large
I often have several large projects that share a task in the middle, not the beginning.
Another reason it would be useful
On a paper-based system, you're right, you wouldn't write it twice. But one nice think about LB is that it keeps track of the effort you expend on TLIs and tries to balance it out.
To offer another example, suppose a parent has a TLI of "Maintain good relationships with each of my children" and another TLI of "Maintain good health." A task of "Play basketball with my son for 1hr" could count towards both TLIs.
You could go in and put separate tasks ("Exercise 1 hr" and "Spend an hour with my son doing something he likes"), but it would be nice if you had the option to kill two birds with one stone.
I'm glad to see this suggestion
I know that it is probably very difficult to implement, but I'll add my vote to it's being useful. I find myself wanting to rank my sewing projects both by how important it is to have the finished product and by how important it is to have the raw materials/ incomplete project no longer taking up space in my home.
Interesting case...
You know, in that particular case, you might really be reacting to the fact the you do have TWO activities in play. I think that you might find it helpful to set it up with something like the following structure. This is worded vaguely, not knowing the exact projects involved.... so, I've also made up a specific example to try to get the idea across that they ARE separate activities involved, and so making a separate task can definitely be appropriate!
- Under whatever project that created the need for the item (Fix up the house...)
-- put created item into service for its specific use (Decorate living room with new sofa cushions.)
And....
- project to create item (make new sofa cushions)
-- get raw materials for sewing project
-- do the sewing project stuff
-- clean up after sewing project stuff
K.I.S.S.
Regarding the dependency issue, I'd just put the nails in the more important project (or the one I wanted to start on first).
Regarding the credit issue, I'd put it in the branch I've been neglecting more. But with the specific basketball example, I've got a TLI of "Care" that includes both taking care of myself and other people, because I tend to neglect both at the expense of work-related tasks, so it wouldn't matter anyway.
As a general rule, I don't plan projects out too "deep" within LB. If I need proper project management tools for a large complex team effort at work, I just transfer the next few actions on my plate into LB as I go along. I keep my brainstorming ideas and reference notes separate anyway (in Evernote), and just keep current (with some lapsed and someday) action items in LB.
FWIW, I think the KISS principle applies not only to the need to keep LB as lean and stable as possible, but also to the relative amount of time I spend (WASTE) tweaking my task management system, compared to actually getting things done.