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 -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mylifeorganized. To view this discussion on the web visit https://groups.google.com/d/msgid/mylifeorganized/29ffaf23-33e0-46d2-b3f0-ca186968e737%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
