"Tasks must be completed in order" only works for tasks under one branch of a tree.
Task dependency can be used to set up more complex and dependencies such that any task can be made dependent on one or more otherwise independent tasks which could be in totally different branches if you want, or to build a tree consisting of a number of self-contained "in-order" branches where some of those tasks are also dependent on tasks in other branches also having been completed. It doesn't give you the gantt-chart type of time dependencies and scheduling of Project Management software, but it does allow you to at least hide tasks you can't do until something else has been done. This allows you to have a fairly complex "project" (whether you define it as project in MLO or not) whereby some tasks can be done in parallel, but the order of others matters. e.g. If I'm going to paint some a new door frame, I will need to: Buy some primer Buy some undercoat Buy some gloss paint Apply the primer Apply the undercoat Apply the gloss I'll also need to sand before each coat, and wait for each layer of paint to dry before I can sand ... but I guess you probably wouldn't create a Wait for paint to dry task! And I haven't even mentioned starting with knotting compound ;-). Clearly, I must buy each type of paint before I apply it (assuming I don't already own enough to complete the job), I must sand the frame before applying each coat of paint, and I must apply each type of paint in the right order, but it doesn't matter whether I buy the gloss paint before or after I apply the primer and undercoat, as long as I have it by the time I want to apply the gloss layer. Similarly, it doesn't matter whether I sand before or after buying the paint, but I can't apply the paint until I've both sanded AND bought the paint, so applying each type of paint can be made dependent on BOTH buying the correct paint AND sanding the door frame ready for that layer of paint, but the buying and sanding can be done in parallel (i.e. in either order - or both at the same time if you delegate either the shopping or the sanding ;-).). Julie On Saturday, November 24, 2012 11:21:11 PM UTC, Dwight Arthur wrote: > > Richard, others have already thoroughly covered what MLO does and does not > do with dependencies. I want to add 2¢ about why this is a good idea. > > When I went looking for a task manager (and found MLO) dependencies were > at the top of my wishlist. MLO offered the best dependency functionality > among the personal-level task managers. Another thing I was looking for was > a way to spend less time dealing with my backlog of uncompleted work by > pushing tasks further on out the calendar. For the latter, MLO introduced > me to GTD, where I learned that I had not been scheduling my _*plan*_ to > get my work done, but rather I was documenting my fantasy of when I would _ > *like*_ to get the work done. > > GTD taught me to stop fussing about when I would get my projects done, and > to focus instead on what I should be doing next. I have found this a great > approach as it definitely cut the amount of time I spend organizing my > tasks versus getting them done. > > MLO is built to support this approach. In order to do a creditable job of > rescheduling tasks based on dependencies, a task manager would need > accurate estimates of how many hours each task in the hierarchy will take a > schedule of how many hours of work can be accomplished each day. It needs > to understand dependencies and it needs a methodology such as CPM for > determining which of the available tasks should be scheduled first. It’s > complex and only works well if the estimates of task effort and effort per > day are quite precise. > > Instead, MLO deals with the question of what I should work on next. If a > task has unsatisfied dependencies, it should not be a candidate to be the > next step. When the last dependency gets satisfied it should become a > candidate. That’s what MLO’s dependency process facilitates. > > -Dwight > > *From:* [email protected] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Richard Collings > *Sent:* Wednesday, November 14, 2012 6:13 PM > *To:* [email protected] <javascript:> > *Subject:* RE: [MLO] Just when I thought I was a power user, I found > dependencies > > > > I used dependencies for a while when they were first introduced but > haven’t used them for a while – partly for the reasons you identified – so > I am not an expert. > > > > But from recollection, the effect of making task B dependent on task A is > that Task B can only become active once Task A is completed. > > > > And I can answer A: essentially the dependencies feature is a more > sophisticated version of Tasks must be completed in order. The additional > capabilities it brings are (for example), the ability for the completion of > one task to ‘make active’ more than one task, or to make active a task in > a different branch. > > > > As you point out it doesn’t affect due dates (or start dates) of the > dependent tasks (I think this is true) and for this reason, there is > limited value in having a lag option. > > > > If we ever get a calendar/planning facility where you can clearly see > dates when you plan to start work on a particular task, then I could see > the dependency feature becoming much more valuable provided that a) the > start and/or due dates (not sure which) of the dependent tasks are made > dependent on the preceding task; and b) a lag option was introduced. I > suspect that both of these are quite challenging to implement. > > > > Richard > > > > *From:* [email protected] <javascript:> [ > mailto:[email protected] <javascript:>] *On Behalf Of *Michael > Emerald, CFA > *Sent:* 14 November 2012 6:35 PM > *To:* [email protected] <javascript:> > *Subject:* [MLO] Just when I thought I was a power user, I found > dependencies > > > > Hi. > > > > Imagine my amazement when I found yet another feature, dependencies! > > > > Having used it about 30 seconds, I have these questions: > > > > 1. What’s the difference between setting dependencies and selecting > “Tasks must be completed in order”? > > 2. Once I told task B that it was a dependency of the task A above > it, in the project, I expected its due date would instantly change to the > same as the task A it depends on. It didn’t. More generally, I should > never be seeing a lower level task starting BEFORE the project task above > it. > > > > Any advice? Do you use dependencies? After all, I’ve gone 6 months > without knowing they even exist. > > > > > > *Michael Emerald, CFA* > > > > *Facebook:* > > http://www.facebook.com/michael.emerald > > > > *Boston Plein Air Artists Group: * > > http://painter.meetup.com/84/ > > > > *Art Blog:* > > http://emeraldartandphotography.blogspot.com/ > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To view this discussion on the web visit https://groups.google.com/d/msg/mylifeorganized/-/0Pv-K60iNw0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
