What is being calculated?
For every non-validated Checkpoint, its starting date, actual duration and delays are always calculated dynamically every time a Project Line is displayed. As a general rule, Winddle will take care of updating all the dates of your Checkpoints and in most cases, you aren't expected to update the starting dates and ending dates directly.
Those calculations take into account the current day, the constraints sets for each checkpoints and the current company settings for working days.
Validated Checkpoints are however never updated once they have been validated, their starting date, ending date (called due date until it was validated) and durations are all based off their actual validation date.
What is a due date?
When it comes to planning, Winddle only work with days - it is not possible for a Checkpoint to be less than 1 day long.
As a result, it is to be understood that the Checkpoints starting date represents the start of the work at midnight on the day of the starting date and the due date is the final deadline at midnight on the day of the due date. The work should just be performed before the due date and validated on the due date.
Once validated, the due date becomes the ending date of the Checkpoint.
In practice, this is a detail as Winddle's partners are all over the world in different timezones and the concept of day is rather loose - Winddle use UTC as its time reference. Winddle project management accuracy only has a daily granularity, which is enough for large scale projects spanning months or even years.
Note: when a Checkpoint is started and validated on the same day, a duration of 0 days should be expected as per the rules described above. Winddle will automatically normalize this to 1 day but allow for some overlap so that multiple dependent tasks can be completed on the same day by actually setting the starting day to yesterday (which in turns means the ending date is today as the duration is set to 1).
Due date vs actual date
On Winddle, a checkpoint's ending date is called due date until it has been validated, at that point, it becomes the actual (real) date. The ending date of a validated checkpoint will never change, regardless of how the workflow is modified.
The due date of a checkpoint isn't a setting of the checkpoint itself, it's the result of the calculations based on all the other constraints. It is automatically updated over time and doesn't need to be set. Even for Fixed checkpoints, the due date is technically not a fixed, only its starting date - in the case of a company using working days, this could mean a due date which changes over time, even if it always start on the same day.
Project line status: delivery checkpoint
A project line has a due date - it's a fixed date, the target completion date of a project line. In a given workflow, that completion date may not be the last checkpoint, Winddle has thus introduced the concept of a delivery checkpoint. The delivery checkpoint is just a normal checkpoint which has been marked as the reference point for the due date of the project line to calculate the project line status, in that sense, it works exactly the same as milestones.
The delivery checkpoint of a workflow is usually set when applying a template, but it can be modified at any time by updating the delivery checkpoint in the information tab.
The delivery checkpoint is usually marked with the following icon:
Note: when creating a workflow from scratch, the first checkpoint added becomes the delivery checkpoint. Winddle will not move it along with other checkpoints added after that first one - it needs to be done manually from the information tab.
The calculations are fairly simple once all of the edges case described later in this article (actual duration, late checkpoints, early checkpoints) have been understood.
The calculation is done in two steps:
- For all non-validated Checkpoints (those never change) that are either Eager or Fixed, calculate the new optimum starting date based on their parents (and their minimum gap). Winddle first starts with the checkpoints with no non-validated parents (no parents or all parents are validated) and then follow the children dependencies one by one until the end of the Workflow is reached, ignore all the trailing Checkpoints on the way.
- Now that all the non-trailing checkpoints have had their dates updated, it's possible to calculate the optimum date for trailing checkpoints.
Those two steps are repeated until the dates are no longer updated, meaning that all constraints have been satisfied. In case a cycle of dependencies has been created or some constraints (especially involving trailing Checkpoints) cancel each other, Winddle will stop the calculation after a few iterations.
The optimum due date mostly depends on the Checkpoint behavior:
- Eager: the earliest date that is after all of the parents' due date ( + the minimum gap specified by each parent) and the Checkpoint's own duration.
- Fixed: the set starting date for the Checkpoint if possible, if not (due to parent constraints or the date being already passed), the Checkpoint revert to an Eager behavior.
- Trailing: the earliest starting date of its children minus the trailing gap which has been specified for this Checkpoint.
Business duration vs Actual duration
Durations used as settings for a Checkpoint are in business days. Winddle allows to set some days as non-working and/or automatically skip Sunday and Saturday, as a company settings.
When none of those settings are enabled, then all durations can be considered as actual durations.
When that setting is enabled, Winddle will automatically convert those duration into actual duration based on the starting point of the calculation. Duration aren't just the duration of the Checkpoint, they also include the minimum gap between Checkpoints and the trailing distance for trailing Checkpoints.
For example, consider the following workflow:
Design Brief has a duration of 1 business day, which translates to 1 actual day as Monday is a working day. In its settings, a gap of 2 days has been forced, meaning that Material Brief cannot start earlier than 2 working days after the end of Design Brief. In this case, all the durations in business days translate directly to working days as there are no non-working days.
However, if Design Brief was starting on a Friday, then its actual duration would be extended to reflect the fact that it's only due on Monday (midnight) as it starts on Friday (midnight) and require one full day:
The actual duration of Design brief is 3 days instead of 1 but there is still two working days between its end and Material Brief.
If Design Brief is starting on Friday and validated on the same day, then its actual duration is 1 day (with a start on Thursday) as per the rules described above. As a result, the gap becomes 4 actual days for 2 business days:
When a Checkpoint is late, in other words, when its currently calculated due date is in the past, Winddle will automatically extend its duration so that its due date is set to the current day.
The expectation is that any late checkpoint is supposed to be completed as soon as possible (today!). However, when the project manager (or anyone who can update the Checkpoint) already knows that a Checkpoint may not be completed before a certain date due to other external constraints, it is expected that the ending date is updated to reflect the current status and thus allow Winddle to keep calculate correct dates down the line, until the end of the project.
Validating Checkpoints early
When a Checkpoint is validated earlier than its due date, there are two cases to consider:
- The checkpoint is already in progress: the duration of the checkpoint will be the difference between its starting date and the date of validation. This update of the duration is only for this specific Checkpoint and will not impact other Checkpoints using the same Master Checkpoint.
- The checkpoint wasn't even started (its validation date is before its actual due date): in that case, Winddle cannot know how long was spent on the Checkpoint and its duration will be set to 1 day. Winddle will however keep track of how early it was validated to help you further refine your workflows.