Priority-based scheduling generally eliminates the need to create dependencies between tasks that are owned by the same person. That’s because in the absence of any delays or dependencies, the earliest start date of a task you own automatically equals the earliest finish of your previous task in the priority order.
In LiquidPlanner, dependencies are most often created between tasks owned by different people or, when modeling wait time between tasks. The wait time feature sets a delay on the dependency so the next task cannot begin until a certain number of days have passed. This is helpful when you’re waiting on client feedback, or for a machine to produce a part, and time spent waiting shouldn’t be included in a project’s remaining effort.
All dependencies in LiquidPlanner are finish-to-start dependencies. To create dependencies between plan items, simply hold down the control or shift key to multi-select the tasks in question, then right click > create dependencies. Another way to create or edit a dependency is via the Edit Panel. Open the edit panel for an individual item and click on the Planning jump link to be taken to the Dependencies section.
Consider the simple example below. In this first screenshot, Dinah is scheduled for her task, Edit site copy before KaraR completes her task assignment to Write site copy.
Since that’s impossible, we need to make the Edit site copy task dependent on the Write site copy task.
Dependencies can be created between containers of work as well. For instance, between phases of a project:
The Dependency Icon
Click on the blue dots dependency icon to see the name of the predecessor or dependent task. Click on the name of that task within the pop-up to jump to it in the plan.
A dependency is satisfied when the predecessor task is marked done. When that happens, the blue dots icon on the dependent task will turn gray and the completed task will have a checkmark on it.
On My Work, when an item on your Upcoming Tasks list has an unsatisfied dependency, an orange warning alert will display below the title of the dependent item. This allows you to see at-a-glance whether you can begin working on the task.
In the stand-alone Edit Panel, a warning alert will also display above the Summary section of the dependent item. Click on the dependency name linked in blue to open that plan item’s edit panel. Note that this alert does not display in the edit panel on the Projects tab.
You’ll notice in the edit panel that a dependency will have a status of “good“, unless there is a problem with that dependency. Broken dependency indicators include:
On Hold – one of the tasks in the dependency relationship is on hold.
Circular – you have a circular dependency. For example, let’s say that a Phase 2 folder is dependent on a higher priority Phase 1 folder. If you make a Phase 1 task dependent on a Phase 2 task, that’s a circular dependency.
Unassigned – one of the items in the dependency relationship is not assigned to anyone.
Item is in Inbox – one of the items in the dependency relationship is in the Inbox. Items in the inbox are not scheduled. Move the item out of the inbox to resolve the issue.
Item is deleted – one of the items in the dependency relationship is in the workspace trash. Undeleting the item will resolve the problem. If the deleted item is no longer needed in the dependent relationship, delete that dependency from the active item’s edit panel.
You may have a task that cannot begin until a certain number of days have passed since the preceding task was completed. In this case, set a delay on the dependency, or wait time. This is helpful for when you’re waiting on client feedback or for a machine to produce a part and you don’t want that “wait time” or “lag” to roll up to the remaining effort on your project.
If you need the wait time to roll up as effort, or need to model more complex wait time scenarios, see this article on Modeling Wait Time Scenarios.
To set a wait time on an existing dependency, go the Dependencies section of the Edit Panel for the predecessor or the dependent item. In the “Wait Time” field, select the number of days or business days you want to delay the dependency.
- “Days” are calendar days (includes weekend days)
- “Week Days” are Monday through Friday (excludes weekend days)
Take a look at the example below. Anne and Beth are working together to build a website for a client. Before Beth starts coding the website, Anne needs to first send the wireframes to the client for a few days for review. Beth knows this process will take at least 5 days, so she will set the wait time on her “Code site” task to 5 days:
Now, the “Code site” task will not be scheduled to start until at least 5 days after the Wireframes task has been completed.
When the “Wireframes” task is marked done, the dependency is satisfied and LiquidPlanner will begin counting down the 5 days of wait time. LiquidPlanner will use the number of days entered in the dependency Wait Time field and set a Delay Until date on the subsequent task. This is why the delay until icon (arrow) is displaying in front of the schedule bar for the “Code site” task below. Once 5 days have passed, Beth will be scheduled to start this task if she has no other higher priority work.
If you need to change the wait time duration after the predecessor task has been marked done, you can do so by selecting a new date in the Delay Until field of the edit panel.
- When a milestone or event is the predecessor in a dependency with a delay, the wait time will start based on the event or milestone Finish [E], regardless of when the event or milestone is marked done.
- Milestones and events are fixed date plan items. When a fixed date plan item is dependent on a plan item such as a task or container (package, project, subfolder) you will be alerted when the expected finish date of task or container pushes past the milestone date or event start date. You will need to manually move the milestone or event if it should start after the task or container’s expected finish date.
- It is not necessary to create dependencies between fixed date plan items such as events and milestones.
- When there’s wait time on a task with a dependency, the person who marks the predecessor task done is the one who “sets” the delay until date on the dependent task. In the dependent task’s History you’ll see that person’s name, and the Delay Until date.
- When a milestone or event has a dependency with wait time, after the end date of that milestone or event has passed, the dependent task’s History will show that the System set the Delay Until date on the task.