Dependency Status

Dependency status

dependencies v. dependents

LiquidPlanner allows you to create two different types of relationships between tasks: dependencies and dependents.

Adding a dependency to a task implies that the highlighted task (say, “dry laundry”) will not start until the items added as dependencies finish, e.g. adding “wash laundry” as a dependency of “dry laundry” implies that drying laundry will only happen after the laundry is washed.

Dependents, on the other hand, are items that cannot start until the highlighted item (again, “dry laundry”) finishes. In this case, you might add “fold laundry” and “put laundry away” as dependents of “dry laundry.”

broken dependencies

There are several ways to break dependencies. You’ll know at a glance if you have a broken dependency because the icon will turn red and a status message will appear under the dependency tab of the work detail pane.

same owner

You simply don’t need to make items owned by the same person dependent on one another. Tasks owned by the same person are scheduled according to how the items are prioritized (listed), with the first item in the list scheduled first. All successor tasks to the first work item will be scheduled after the first item is expected to complete, creating an implicit dependency.

circular

Two tasks cannot be dependent on the other task finishing or starting. This would mean neither could ever start, or finish, or start…you get the idea. It’s broken.

on inactive

You could be waiting a very long time if you put a dependency on an unscheduled task.

on deleted

You’ll be waiting even longer if your task or project is waiting on something that’s been deleted. Like, maybe forever.

on later project

Adding a dependency to a project that is scheduled after the project you’re working on will cause a broken dependency. That would imply the later project needs to get done first. If that’s the case, re-prioritize it by dragging and dropping it where it belongs and you’ll be good to go.

I’ve just tried it out and the dependency option works great!! Much better than using “delay until” setting.

Thanks LiquidRon! Glad you’re pleased with the feature. And thanks again for your patience.

The implied dependency of one item to the next for a given owner makes simple, linear dependency task entry much simpler. It also makes it confusing how to set up parallel tasks. I have one project (P1) with an earliest start date in late May; that is when the project begins. I have another project (P2) that can start now and is predicted to finish by mid-May, prior to when P1 can start. But if I place P2 above P1, my tasks in P2 can’t start until sometime in June, well past my promise date, because of the implied dependency on tasks in P1. I really have to list P2 above P1 to make this work, or am I missing something?

We’ve started work on a feature called “flow around” for lack of a better name. It will allow lower priority work to flow around higher priority work if the higher priority work is delayed. This will be useful in a number of different ways. A simple example is that you can create a project folder at the top of the project tree for Events and Vacations and model out things that need to happen at an exact time. Is this what you are looking for?

We are also working on a feature to allow part-time work on tasks (ie 20% effort). This will be for modeling background tasks and activity that you might want a per-day cap on.

We are hoping to make both of these available in the June site update.

I’ve just started using LiquidPlanner and I like many of the features but without the ability to do what you are calling “flow around” I don’t think I can create a project schedule that works. I’m glad to see that this is a feature you are implementing. Is there anyway that I can simulate this behavior now so that my schedule comes out correctly? I have two projects, one can’t start for a month. The other is lower priority and can start now. I’d really like both to be in my plan but as things stand now the lower priority project is held off until the higher priority project completes.

The ability to allow part-time work on tasks is also something that I would find very useful as we frequently have these types of tasks in our development group. I guess this is a form of multitasking and I know your feeling on that but there are many times when multitasking makes sense. For example I have two tasks that need to be completed. One is for the development of a new feature, the other is support for existing features. I know from experience that 20% of the developers time will be to handle support issues. I could inflate the time it takes to do the primary task by 20% but that doesn’t really capture what is happening. Also if I should decide that the new feature must be completed sooner I could pause the support task which would make 20% more time available.

Reviewing your forums I’ve determined I can simulate the part-time tasks but this simulation really doesn’t allow me to see the work done on the task, it just allows me to list it so the task isn’t lost.

I would also like to see the ability to assign multiple people to the same task for things like bug fixing or when we have a several short development tasks that any of the team members can handle and we just want them to pick up the next available item.

While I like the implied dependency of one item to the next based on owner I find it to be somewhat brittle. Consider the case where I have task A, B and C. All three tasks are assigned to the same person so the dependency flows correctly because of how I have prioritized them. Also task B must be completed before task C can start. If I reassign task B to another person than task C is no longer dependent on task B and gets scheduled to start once task A is complete. In a simple project this is easy to notice but in a more complicated project it seems like this dependency could easily be missed. But if make task C dependent on task B now I get an alert that the two tasks are assigned to the same person.

Multi-tasking happens and if there is a way to model it easily, we’ll figure it out. The flow forward feature will go a long way. Until that arrives, the work around is to break things into smaller work packages and prioritize accordingly.

We will probably remove the “same owner” dependency alert; it’s advisory at best and is just ignored until the task is assigned to a different person.

Multiple people on one task needs design thought.

Hi Charles, Good to see that flow around will be implemented. One note on this feature that might bite in the future. I suggested this feature to Melinda in a separate email. Flow around is essentially the behaviour that occurs in thread scheduling. There is always something ready to run even when high priority tasks become blocked. However there is one subtle error that can occur in implementing such a scheduler. Because you will still have a global priority queue as defined by the top to bottom ordering in the project you can engineer a problem called priority inversion. The problem can be outlined as below.

Three tasks in priority order highest at the top, lowest at the bottom.

Task A depends on C
Task B
Task C

High priority task A cannot start until low priority task C is complete so it becomes blocked and the the medium priority task B will run. This scenario is however wrong because B has a lower priority than A and A does not have a dependency on B. B should never be scheduled before A. The solution to let C be scheduled first so that it can be completed and then let A be scheduled.

In general the solution raise the priority of task that has dependents to priority of the highest priority task in it’s the upward chain of dependents. This way you can preserve the general case that the priority ordering of tasks can be implicitly viewed as a dependency chain on viewed otherwise when explicit dependencies are put in. Without handling priority inversion you may find users adding in more explicit dependencies to force the schedule back into correct shape.

Regards

Brad

I read the last sentence I posted and it hardly seems like english :) I’ll try again.

In general the solution is to raise the priority of a task that has dependents to the priority of the highest priority task in it’s chain of dependents.

I think that sounds better.