As an FYI, I do a lot of project management. More than I would like... I prefer software architecture and hacking code, but frequently what I end up doing is project management. I'm actually a PMI certified "Project Management Professional" (PMP) which means that I end up managing lots of multi million dollar projects... Lots of critical path analysis, earned value calculations, etc...
Dependencies are a vital part of project management. There are several types of dependencies typically used in project plans, but the most common is a finish-to-start relationship. In essence this means that one or more tasks must be completed before another can start, or before a milestone is achieved. So if tasks A, B, and C must complete before task D can start, there is a dependancy. In a simple project, there is often cascading dependencies: B depends on A, C depends on B, D depends on C, etc.
This clip from MS Project shows cascading dependencies. They are indicated by the "Predecessors" colum as well as in the Gantt chart.
If you are doing personal task management, you might have lots of "multi step tasks" that have a single goal and a handful or more of "next actionable steps". To help me stay focussed I often like to see the ultimate multi-task goal as a TLI, and I have SLI's for the sub-steps. I use David Allen's GTD methods, and have a lot of this built into a GTD template in Ecco. I used to use my own Ecco Helpers to help manage this, but the "Depends" function in eccoext is superior since it is "real-time", i.e. as soon as a task is completed the "next actionable task" pops up! I don't have to wait for the next timed run of EH or use a workaround by keeping the queue filled with the next 3 actionable tasks...
So, here's how "depends" works...
First I'll open Ecco using eccoext and open a new blank Ecco file: (see the Quick Start page)
As soon as I enter an item, several new folders appear... The important ones for this discussion are "Depends" and "Dependents".
I can add those new folders as columns so that I know what is happening...
Now I right click on one of the items to see the "context" menu, and choose:
Depends > Assign/Copy ID# ==> Clipboard
You'll notice that there is now yet another new folder called "ItemID".
Behind the scenes, the item has been assigned a unique ItemID, and that ID has been stored in the clipboard.
I've added the ItemID folder as a column so that I can see what is going on... You can see the unique ID that has been created for the item.
[Note! if you are following along exactly, you might have lost your clipboard. You might need to go and grab the ID again if you did any other cutting and pasting in Windows...]
Now I put my cursor in the an item that depends on Task A and right click.
I then choose:
Add Depends ID# <== Clipboard
This copies the ItemID from the clipboard into the Depends folder/column for Task B.
What this does is make Item B dependent on Item A. You can also see that Task A now has Task B's ItemID in its "Dependents" folder/column.
By looking carefully at the ItemID numbers in the three columns you can see the "depends" relationships.
OK, so what!? What good it this?
In order to benefit, you need to create a "rule"...
What we will do is create an "Action" folder that will hold our "next actionable tasks", and when any item is marked "Done" we will assign any dependent tasks to the "Action" folder...
I've created an "Action" folder, and what we need to do is create a rule for the folder. Any time an item in Ecco changes, all of the rules will be checked to see if the rule should be applied as a result of the changed item.
Right click the "Action" folder and click "Auto Assign Rules..."
The new eccoext auto assign rules dialog will open. Click "New" and enter the rule...
When I clicked "New" a blank template rule appeared in the list of existing rules for this folder (in the bottom half of the dialog) and also in the rule edit window (the top half). The blank template rule was:
++::/*value*/:/*condition*/
Let's look at this carefully. The first "++:" is how every rule begins. Anything between "/*" and "*/" is a comment and does nothing. So our blank rule really is just:
++:::
To be more complete and perhaps more helpful for total beginners, it could say:
++:/*flags*/:/*value*/:/*condition*/
In fact the value and condition can both be fairly complex expressions. (If the "L" flag is present, they could even be replaced by programming code in the Lua language!)
Now let's look at the rule we entered:
++:D+::[@Done]
The "++:" at the beginning signals the beginning of a rule.
The "D+" is two flags: the "D" means that this rule only applies for a depends check, the "+" indicates that the folder that this rule is attached to will be set with the value expression if the condition expression is true and the folder currently doesn't have a value.
You will notice that the "/*value*/" comment has been removed, so the value expression is blank, we just see two colons "::". Since "Action" is a CheckMark folder, it will just be checked in this case, i.e. the item that changed will be "put into" or "assigned a value" in the "Action" folder.
The last part of our rule is the "condition expression" which is "[@Done]". The square brackets indicate that we will check a folder or column value on the item that changed. In this case the folder we will check is the "Done" folder. The "@" means that rule will not act on the item that changed, but instead will act on items that depend on the item that changed.
This might be a little confusing, so here it is again from a slightly different angle. When the "Done" folder of Task-A changes, the items that depend on Task-A will be modified by the value expression. Since this rule is attached to the "Action" folder, all of the dependent items will become associated with the "Action" folder...
When we close the auto-assign dialog and hover over the folder, we see that the "Action" folder now has this new rule... (the hover help is another really cool feature of the eccoext add-on...)
So now going back to our data, we see that "Task A" is item#7845522 and it has a dependent item#7619342. If we look at "Task B" we see that it is item#7619342 and that it depends on item#7845522.
What do you think will happen when you click the "Done" column? Think about it!
OK, time's up, pencils down, pass your blue books to the center aisle...
When Task A is given an assignment in the Done folder, the Task A item is changed. This causes all of the auto-assign rules to run for the item that changed.
Our rule on the "Action" folder will fire and will see that it is watching for changes in the "Done" folder value for an item. This is indeed true, so our condition expression evaluates to true. We should apply the value part of our rule to the appropriate item. In this case, it isn't the item that changed, but we apply it to the item that "depends" on the item that changed! Item B depends on Item A so the value part of our expression is applied to the "Action" folder for Item B. Since Item A is now done Item B has become actionable.
This might SEEM like a lot of steps, but in reality it's very easy to use. You don't really need to look at the ItemID, Depends, and Dependents columns. Once the rule is set up, you can easily grab an item's ID with two clicks, select another item and paste the ID as a dependency with another two clicks.
This is *HUGE* if you have a team of programmers working on tasks and there are dependencies between the tasks. As a PM, I can assign the tasks and set the dependencies. When one programmer finishes something that someone else is waiting for, it automatically shows up in their task list. When implementing GTD, I can set up all of the actionable steps in a multi-step task, and my "Action" list stays uncluttered. I have the multi-step task or goal as a TLI and the detailed steps as SLI's. As each task is completed the next becomes visible, until the last is done and then the goal disappears as well. I will soon create a rule to mark the goal done as soon as all the sub-tasks are done... Since I organize my actions by the context in which I can perform the action, the dependencies will remove the goal from view if the next actionable task associated with that goal needs to be performed in another context. Pretty slick!
As always, edit this page to your heart's content. My goal has been to make it as clear as possible for the persistent and highly motivated non-technical reader.
=DaveG