Gantt task scheduling
The project schedule is developed from the scope and the creation of a list of task and dependencies.
As the tasks and dependencies are created and adjusted (start, finish dates, duration, dependencies etc, they can be either be automatically (default) or manually scheduled. This is defined by enabling the appropriate column in the Gantt view and ticking the task to be manually scheduled Refer to Select Display Columns . Events that are manually scheduled are not affected by the automatic rescheduling process, they are meant to be adjusted manually by the user.
The Gantt scheduling engine will update start and end dates of automatically scheduled events based on their constraints, links and position in the task hierarchy. The Gantt scheduling engine will update start and end dates of automatically scheduled events based on their constraints, links and position in the task hierarchy. This means that the start date and end date will be validated and might be recalculated as soon as the event is added or loaded to a project.
It is possible to manually schedule a task so that the task will not be changed by any of its incoming dependencies or constraints.
Project direction
The Gantt engine supports both forward and backward scheduling. In a forward scheduled project (the default), the Gantt engine schedules events as soon as possible (ASAP). For such projects, the start date is mandatory and sets an implicit Start no earlier than constraint (see constraint details below) inherited by all tasks. This means any task having no restrictions will fall back to that date.
The end date of a forward scheduled project is a calculated value equal to the latest end date of its tasks.
Inactive tasks
Please note that any task can be excluded from the scheduling process by deactivating it. This can be done by setting it as inactive and do not push their linked tasks nor do they roll-up their attributes to parent events. Refer to Select Display Columns.
Propagating changes through task dependencies
When an task is created or edited, its linked tasks will be rescheduled automatically. In forward scheduled projects, successors react on their predecessor changes and in backward scheduled projects, the predecessors react to changes made in their successors.
How dependent tasks will be updated after a modification depends on the dependency type. The Gantt engine supports the following four types of dependencies:
The default type of a dependency is "Finish-to-Start" (FS). This type of dependency restricts the dependent task to not start earlier than the end date of the preceding task.
With this dependency type, the succeeding task is delayed to not start earlier than the start of the preceding task.
The succeeding task cannot finish before the completion of the preceding task.
The finish of the succeeding task is constrained by the start of the preceding task. The successor cannot finish before the predecessor starts.
Task scheduling mode
Unlike the dependencies and constraints affecting the task position on the time axis, the scheduling mode specifies how the tasks own properties depend on each other. It defines which properties are fixed (provided by user) and which ones should be calculated.
There are four scheduling modes available in the Gantt engine:
- Normal (default mode).
- Fixed Duration
- Fixed Effort
- Fixed Units
There is also an additional effort driven control allowing you to fix the task effort value. When set, it tells the task to preserve its effort value and instead recalculate other properties.
Normal
In the Normal mode (default), the task is scheduled based on information about its start / end dates. The task effort and assignments are not calculated in this mode.
This mode is always used for summary tasks.
The effort driven control is not used in this mode.
Fixed Duration
Fixed Duration mode means that the task has fixed start and end dates and duration, but its effort is computed dynamically based on the assigned resources.
A typical example of such an task is a meeting. Meetings typically have pre-defined start and end dates and the more people are participating in the meeting, the more effort is spent on the task. When the duration of such task/event increases, its effort gets increased too.
Changes to the effort of such a task will cause assignment units recalculation and vice-versa (assignments change will cause recalculation of the effort).
Enabling effort driven control for a task will change that behavior and force the event to always recalculate its assignment units whenever the event changes its duration or effort.
NOTE: calculations provided by this mode work only if the task has at least one resource assigned.
Fixed Effort
Fixed Effort mode means that task has a fixed effort and a computed duration. The more resources are assigned to the task, the less the duration will be.
A typical example is a "paint the walls" task - several painters will complete it faster.
Enabling the effort driven control makes no sense in this mode.
NOTE: calculations provided by this mode work only if the task has at least one resource assigned.
Fixed Units
Fixed Units mode means, that the task has fixed assignments and computed duration or effort.
Changes to the effort of such a task will cause duration recalculation and vice-versa (duration change will cause recalculation of effort).
Changes of the assignment of such a task will cause effort recalculation and duration recalculation if the effort driven control is enabled.
NOTE: calculations provided by this mode work only if the task has at least one resource assigned.
Dependency lead and lag
A dependency can have a lag (or lead) value which can delay the succeeding event by the number of lag units specified.
Lead (or "negative lag") will accelerate the succeeding event by the number of time units specified.
Please note, the lag value specifies the amount of working time. The calendar controlling which time to use is defined by the calendar field. By default, the successor calendar is used.
Please note, the lag value specifies the amount of working time. The calendar controlling which time to use is defined by the calendar field. By default, the successor calendar is used.
Event constraint effect on the scheduling
An event constraint defines boundaries for the scheduled date range of an task and it is taken into account when the engine schedules the project tasks.
A constraint is a combination of two task properties: constraint type and constraint date. The date range specified by a constraint, restricts the task start / end dates to be not earlier than, not later than or equal to the provided constraint date.
A task having no restrictions is scheduled on the project start for forward projects (and on the project end date for backward projects). When a task is manually dragged by a user in a Gantt chart, the Gantt enforces the position by setting a constraint on the task. In a forward scheduled project it uses:
- Start no earlier than (SNET) constraint when the task is moved by changing its start date
- Finish no earlier than (FNET) constraint when the task is moved by changing its end date.
The way a constraint affects an task depends on its type. There are two group of constraints available:
- Inflexible constraints.
- Semi-flexible constraints.
Inflexible constraints
There are two constraint types in this group: Must start on (MSO) and Must finish on (MFO). They force a task to start / finish exactly on the date provided.
Semi-flexible constraints
These constraints share the same priority with task dependencies. They all work together respecting the task working time:
- Start no earlier than (SNET) - restricts the task to start on or after the specified date.
- Finish no earlier than (FNET) - restricts the task to finish on or after the specified date.
- Start no later than (SNLT) - restricts the task to start before (or on) the specified date.
- Finish no later than (FNLT) - restricts the task to finish before (or on) the specified date.
Effectively, the task start/end dates are calculated as aggregated values taking into account both dependencies and such constraints. The earliest start date for an task is computed as the latest of the earliest start allowed by its constraint and the earliest start allowed by its dependencies.
An example: Task A has two incoming dependencies which don't allow it to start earlier than 18/1/2022 and the task has a SNET constraint which forces it to start not earlier than 17/1/2022. In this case, the resulting earliest start date of the task is 18/1/2022. If we change the constraint date to 19/1/2022 the resulting earliest start date will become 19/1/2022.
Taking into account the project hierarchy
When scheduling tasks, the Gantt engine takes the hierarchy into account by following these two principles:
- Each task inherits its parent (summary) task restrictions (dependencies and constraints).
- A summary task start date and end date should match the minimum start date and maximum end date of its children respectively. Its effort equals the sum of the effort values of all its children. The % completed value of a parent task is derived from its children, summarising the completed duration divided by the total duration of all children.
FYI: calculation of % done for parent tasks can be disabled.
Following the above rules, the Gantt engine recalculates summary tasks when their children are updated. The same goes for the reverse case, child tasks will react to changes to constraints and dependencies of their parents.
0 Comments
Add your comment