A checkpoint is a step in a project, they are not to be confused with milestones and tasks which are also used on Winddle as separate features. Each checkpoint is a collaboration area which is meant to be separated from the main collaboration area that is the project line. They are the building blocks to go from the start of the project line to its completion: they need to be validated, in sequence, and are the basis for planning on Winddle. Checkpoints are defined by their name, duration and various dependency (given them a place in the workflow as well as a starting/ending date) and other settings which control their behavior and functionalities.
Note: in most cases, their starting/ending dates is computed by Winddle and not set directly by the users. The main exception would be the starting date of Fixed checkpoints and of root (without any parents) Checkpoints.
Project, Project Line and Checkpoint form the basic trifecta of the Winddle project management structure.
In very simple projects, Checkpoints may be used to represent an actual concrete action but when there are many partners and steps involved, it may be easier to think of Checkpoint as representing an issue, a deliverable or a general phase. Tasks can then be used to break it down further if needed. Striking the right balance between having Checkpoints representing too broad of a concept and having Checkpoints representing a single phone call isn't easy. Winddle recommends to try to keep the overall breakdown into Checkpoints to maximum 50 checkpoints and 5 checklists.
Checkpoints in a Project Line get their name and some of their behavior from a Master Checkpoint defined in the company settings. Master Checkpoints are available to everyone in a given company and this allows a simple way to ensure that the names and behaviors of similar Checkpoints are coherent within the company.
Additionally, Master Checkpoints belong to a Master Checklist and selecting a Master Checkpoint will actually ensure the same Checkpoint is grouped in the same Checklist in every project line.
Note: renaming a Master Checkpoint will thus automatically rename every Checkpoints in the company.
In addition to its Master Checkpoint (giving a name to the checkpoint), a Checkpoint is also defined by its duration in business days, its starting date, its direct dependencies (parents/children) and some more advanced behavior settings.
There are three main dependency behavior:
- Eager (default): the checkpoint will start as soon as possible, i.e., when its parents are all validated. This is only relevant for Checkpoints with at least one parent, otherwise, the Checkpoint will behave as a Fixed Checkpoint.
- Fixed: the checkpoint will start at a Fixed date. This date must be in the future and must be after the earliest allowed date based on its parents constraints, otherwise, it'll behave as an Eager Checkpoint.
- Trailing: this behavior is very different from the other 2 as it is related to the children of the Checkpoint. A trailing Checkpoint will always be a few days (the trailing gap) ahead of its children: if for some reason, a child of a trailing checkpoints moves, the trailing Checkpoint will follow along. This is useful to setup Checkpoints which must always happen X days before another Checkpoint starts, regardless of when that Child checkpoint is starting.
Additionally, it's possible to set a minimum gap in business days between a parent and a child, which will always be respected, regardless of the 3 dependency behavior described above.
See the Workflow calculation article for more details on how the due date of a Checkpoint is computed given all of those settings.
Attempts and indexes
A Master Checkpoint may be reused multiple times in a Project Line. When adding a Checkpoint with the same Master Checkpoint in the same project line, both Checkpoints each get a number, called an index, as part of their name. This is useful to get an idea of which came first in other parts of Winddle (statistics, filters, etc) when only the name is available.
When a Checkpoint with the inspection behavior enabled is failed and then retried, a new attempt is created (See Checkpoint details for more details about this feature). The attempt is also a number, counting each attempts of a given Checkpoint.
Below is a contrived example showing both behaviors:
In this example, Ok Final Inspection has been added twice, shown as (1) and (2). The first Ok Final Inspection has however failed once and has been re-attempted. As a result, there are now 3 Ok Final Inspection in this project, but their index and attempts number allow to understand the ordering and the historic of what happened at a glance.
Checklists in a Project Line are useful to group Checkpoints together. The grouping in checklist doesn't impact the workflow calculation or collaboration rules, it's merely a visual grouping to separate Checkpoints into meaningful phases or meaningful concepts.
Just like Checkpoints, when adding a Checklist to a Project Line, the project line manager needs to actually select a Checklist from the list of Master Checklists available the company. The list of available possible Checkpoints for a given Checklist also come from those company settings as described in the Master Checkpoints section.