Nesting vs. Dependencies vs. Complete in order....

[Steve Kunkel]

Hi All,

I have a question about how best to "feed" the subtasks of a project into my Next Actions list...

The scenario is that I'm a school psychologist and this is my setup for completing educational reevaluations for special needs kids.  

I can "almost" use the "Complete subtasks in order" option that is in Properties > General.  But the problem is that not ALL of the subtasks need to be competed in order.

see image:

The first "Sample Student" uses a hierarchy to feed the sequential parts.  As you can see, "email teachers" and "record review" can be done at any time but testing and report-writing can't happen until parent is contacted, etc.  

The annoying part about the nesting example is that the nested items are sortof in reverse order....  That is, "call parent" is the very first thing to do, but it is at the bottom...  Also, maybe there will be other unforeseen disadvantages of having dozens of multi-level nests in my outline(?).  In that regard, the bottom Sample Student is better because the tasks are all "children of" the Student project, and because the items are shown in logical order in the outline view.  The problem with the dependency setup is that I'm affraid that if I need to add other tasks in there (e.g. "observe student in class") or take some out, then it might disrupt the "chain of dependencies," and there really no visual indication of what item is dependent on what... 

Hence the dilemma.. Which technique to use ...  Which would you guys use?  Are there any unforeseen factors that might throw me a curve ball later??  

Thanks in advance, for any tips. :) 

[Richard C]

Just a quick reply, Steve - I think I would primarily use the list approach but with some nesting.  So for example, if I have understood your dependencies,  I would create a task in the list 'Get parents permission' which would have 'Call home',  'Send permission form' and 'Receive permission form' as children

Richard

[Dwight Arthur]

On Thursday, January 22, 2015 at 5:21:06 PM UTC-5, Steve Kunkel wrote:

Hi All,

I have a question about how best to "feed" the subtasks of a project into my Next Actions list... [...] Hence the dilemma.. Which technique to use ...  Which would you guys use?  Are there any unforeseen factors that might throw me a curve ball later??  

Thanks in advance, for any tips. :) 

Hi, Steve. My thoughts:

The first question, to me, is whether or not Next Actions is the right thing to use. Next Actions is like automatic transmission - it applies a set of rules to decide what tasks are the next things you should work on. If your work "fit" the rules so that it picks the right task almost always, then you should go ahead and use Next Actions. If you find yourself struggling, tweaking your tasks, arguing with the computer and trying to trick it into doing what you want then you need the manual transmission. Use the Active Actions views, and use dependencies, start date/times, tasks in order, closed contexts or other techniques to make everything inactive except for what you should be working on.

The basic tool is "complete subtasks in order" which works well for reasonably short, highly sequential projects. Once the work starts to look a little more complex you need to move up to dependencies. MLO has a pretty advanced implementation of dependencies that cvan be set up to meet most needs.

You need to watch out for the trap of spending your time managing tasks instead of doing them. It's easy to fall into endlessly polishing and revising your dependencies. One way to control that is to build a template. Create a "Templates" folder and mark it "hide in to-do". Create a project called "Sample Student". Add all of the tasks you can think of, get them in the right order and set up the dependencies. If certain tasks arise for some students and not others, include them. When you set up for a new student, follow these steps:

1. Are there any tasks you will need with this new student that are not in the template yet? If so, add them and adjust the dependencies accordingly.

2. Use the "new from template" from the task menu to create the project

3. Are there any tasks in the project that are not needed for this student? If so, mark the tasks completed before you even start.

As the project progresses, if you find that a task is unnecessary, don't delete it. Mark it completed. This will prevent any screwed-up dependencies.

If you have to add a task, my preference is to get the precursor dependencies right (what has to complete in order for this task to start) and not worry about successor dependencies (what can start as soon as this task finishes). Consider a project (A) print contract (B) sign contract (C) mail contract where C is dependent on B which is dependent on A. We need to add (X) make copies after it's signed and before it's mailed. What I would do is to right-click on task B and select "duplicate task(s)" creating task (B') sign contract. Task B' will be dependent on A and nothing will be dependent on B'. Edit task B' to say "(X) make copies". When the project starts A will be active. When A completes, B and X will appear on the active list. You have to use your brain to realize that you want to do the signature first, then the copies. If you mark B complete, X and C will be on the active list. Again, your brain tells you that you want the copies before mailing the original. Once you do X, C will appear on the active list and dependencies will work normally from that point forward.

Make sure that you understand and use delayed dependencies. For example, one week after mailing the contract you might want to check if it reached the recipient. You could create a "verify receipt" task with a one week delayed dependency on the "mail" task. If you learn it was received before the week is up you can still mark it complete and go on; if not then after one week the verify task will appear on the active list.

When setting up dependencies bear in mind the "alternate drop": in order to clean up the "make copies" situation, use the right mouse button to grab task X and drop it onto task C. Select "dependencies" from the popup menu. Task X doesn't move but task C will now be dependent on task X.

One last hint: if you have tasks that remain active a long time you might find that completed precursor tasks get archived which can make the dependencies a but screwy. To prevent this, make sure that the overall activity is marked as being a project, and then go to tools>options>autoarchive and check "Do not archive subtasks of open projects and recurring tasks"

-Dwight

[Steve Kunkel]

Thanks for the awesome responses guys!  I wanted to reply to say 'thanks,' though I'll probably reply again to this thread once I've had more time to practice with my setup, and adjust it...   As you've suggested, it does appear that using "Dependencies" with "Active Actions" (as opposed to Next Actions) will be the way to go--for me at least.  The "nesting" idea won't work.