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, you will be scheduled to start your next task as soon as your current task is expected to finish.
In LiquidPlanner, dependencies are most often created between tasks owned by different people. They can also be used to model 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.
Filtering can be used to quickly locate plan items with the following statuses: all dependencies satisfied, items with dependents, and broken dependencies, so you can efficiently manage your schedule and resources.
Finish-To-Start Dependencies
All dependencies in LiquidPlanner are finish-to-start dependencies. To create dependencies between plan items, simply hold down the ctrl 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 link to be taken to the Dependencies section.
Consider the simple example below. In this first screenshot, Megan is scheduled for her task, Paint 3D Printer before Nadia completes her task assignment to Design 3D Printer.
Since that’s impossible, we need to make the Paint 3D Printer task dependent on the Design 3D Printer task.
Dependencies can be created between containers 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 dependency and its Expected Finish date, or the dependent task and its Expected Start date. Click on the name of that task within the pop-up to jump to it in the plan.
A dependency relationship is satisfied when the first task is marked done. When that happens, the dependency icon on the dependent task will turn gray, indicating that the dependency has been satisfied. Hover over the Start [E] or Finish [E] date to see if the schedule is impacted by wait time.
Dependency Alerts
On My Work, when an item on your Upcoming Tasks list has an unsatisfied dependency, a purple informational 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.
If an item has a broken dependency, a schedule input error alert (blue triangle) will display next to it on the Projects tab as well as in its Edit Panel above the Summary section.
Dependency Status
You’ll notice in the edit panel that a dependency will have a status of “satisfied“, “active,” or “broken.” Items that have satisfied dependencies are marked “satisfied.” Items are considered “active” if they have unsatisfied dependencies. Broken dependency indicators include:
Broken dependency cause: On hold
Explanation: One of the tasks in the dependency relationship is on hold
To resolve it: The task on hold needs to be taken off hold
Broken dependency cause: Circular
Explanation: Your dependency is dependent on a dependent task. For example, if the Phase 2 sub-folder for a project is dependent on a higher priority Phase 1 folder, and one of the Phase 1 tasks is dependent on a Phase 2 task, it will create a circular dependency.
To resolve it: Remove one of the dependency relationships
Broken dependency cause: Unassigned
Explanation: One of the items in the dependency relationship is not assigned to anyone.
To resolve it: Assign the unassigned item
Broken dependency cause: Item is in Inbox
Explanation: One of the items in the dependency relationship is in the Inbox. Items in the inbox are not scheduled.
To resolve it: Move the item out of the inbox and into the active project plan.
Broken dependency cause: Item is deleted
Explanation: One of the items in the dependency relationship is in the workspace trash.
To resolve it: Undelete the item. If the deleted item is no longer needed in the dependent relationship, delete that dependency from the active item’s edit panel.
Wait Time
If you have a task that cannot begin until a certain number of days have passed since the first task was completed, you can enter Wait Time to model this delay.
For example, you finish designing a part and now you have to wait two weeks for a machine to produce it. In order to model this delay, as well as free up your availability while you wait, you can set a Wait Time on the dependency.
To set a wait time on an existing dependency, go the Dependencies section of the Edit Panel for either task in the dependency relationship. 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)
Note: Wait time does not roll up as 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.
Important Notes
- 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.
- If a plan item with a fixed date, such as a milestone or an event, is dependent on a task, the Start [E] of the fixed-date plan item will not be automatically updated to the Finish [E] date of the first task.
- 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.