When you’re first starting out with LiquidPlanner, it can feel a bit like you’re taking your hands off the wheel.
Typically, project schedules are built out by charting planned start and finish dates and working backward to adhere to that plan as much as possible. LiquidPlanner turns this around by factoring in the realities that projects face and calculating these dates for you.
You aren’t able to set start and finish yourself: the schedule is driven by the priority and the estimated effort of your work, along with the availability of the resources taking it on.
While these are the primary factors that define a project plan in LiquidPlanner, there are a few other tools that allow you to fine-tune and define when work will be happening.
A common scenario that we see, especially as teams are getting started, is that a project is added but isn’t planned to start right away. If you only have just one project in your workspace, it will be viewed as the highest priority and, in turn, will fall into the schedule immediately. Even with many projects in your workspace, this may still be a situation you find yourself running into.
Delay Until Dates
Anytime you see an expected start date, or Start [E], that is earlier than when you’ll actually start the project, you can set a Delay Until date. Setting this on a container like a Project will apply the rule to all the tasks within.
It is important to note that while a Delay Until date will ensure that work won’t start before a certain time, it does not guarantee that work will start on that date.
Your work will schedule as soon as possible after that date based on the three factors mentioned above: the priority and estimated effort, as well as the availability of the resources taking it on. This will allow you to see what re-prioritizing or re-assigning needs to be done now to get the schedule that you want.
While setting Delay Until dates can be very useful for driving the calculated start dates of your work, they aren’t the only tool at your disposal.
Since LiquidPlanner looks to the availability of all resources assigned to work in a project independently, it can schedule everyone’s work to happen all at once. This generally isn’t the case as work will sometimes need to change hands or follow a natural course through a few departments as it changes phases.
Dependencies are the best fit for these situations when work will be changing hands from one task or phase to another. A benefit to using dependencies to stagger out the work rather than with Delay Until dates is that they will be maintained if there are any other unexpected changes to the plan.
For instance, if you build out a project and set Delay Until dates to help drive the beginning of different phases you’ll have to update each of these individually if there are any delays. Dependencies will automatically adjust the timing of this work as realities change so you don’t have to comb through and change the entire schedule repeatedly.
You can now look to your expected finish date, tracked as Finish [E]. This will let you see when you can count on finishing. This date is again driven by the same methodology that calculates the schedule throughout LiquidPlanner and represents when it is 50% likely that the work will be completed.
In other words, once you hit this date, it is more likely than not that you’ll be done with the work you’ve modeled. If that is not quite certain enough for you the 90% and 98% likelihoods are also displayed.
Usually, you have at least one stakeholder who is interested in seeing work completed at a very specific time. Those hard deadlines are best tracked separately from the Finish [E] as a Deadline.
With one set you can always measure how you’re tracking against that date, and if things start to fall behind schedule an alert will be flagged. Deadlines can also be set on a Sub-folder or Task level to ensure you’re on track with key objectives within a project. Once again, changes need to be made to a priority or an assignment of work in the plan to change the expected finish date.
Once a project has moved from the planning to execution phase, we begin to move away from these calculated dates. You’ll quickly notice that the Start [E] date never displays a point in the past. It’s most accurate to think of this as the date work is expected to start or for work to resume.
Started On Dates
To see when work was actually started on an item, there is a different field to look to. The Started On date is displayed in an item’s Edit Panel and can be pulled up in the personal column display. It represents the date time was first logged to a task.
The Started On date for a container like a sub-folder or a project will show the earliest started-on date from the tasks within. Once a task has been started, you’ll notice that the schedule bars begin to turn grey to show how progress is tracking.
Similar to the start, Finish [E] stops being calculated once an item has been marked done. This is tracked in retrospect as the Date Done field.
As you work through the project, you’ll see your schedule bars showing the planned blue schedule to span the dates that work is expected to take place and turning grey to represent what has actually happened.
The Started On and Date Done fields can be manually changed to better reflect the course of your project. On the Projects tab, you can change your focus on the schedule bars to look at any point in time. Beyond that, all of these dates, calculated and actual, are surfaceable in reports throughout the application.
Whether you are looking to the past or the future, LiquidPlanner has a bit of a different approach to letting you pick the start and finish dates. Through this methodology, we empower you to work with the realities of your project plan upfront so you can make the best decisions about prioritizing and assigning out the work your team has to do.