Prerequisites for Project Planning

Project planning can become very complex. It is therefore important to know the model on which a planning process is based.

Plannable and non-plannable items

The system distinguishes between plannable and non-plannable items. Only plannable items are displayed in the Gantt chart. Plannable items are of the item type “Task” or other item types with the type flag “Task”. If you want to be able to fix milestones in terms of dates, it is recommended to create an item type “Milestone” with the type flag “Task”.

Items that cannot be planned are taken into account in the resource load, but are never displayed in the Gantt chart. These are, for example, tickets that come in from the outside, or action items that result from meetings.

Plan and Base Plan

The system supports two plans to some extent:

  • The actual plan (“plan”)

  • A base plan, also to be understood as a plan specification or wish plan

The plans differ only in the attributes described in the following table. The same items exist in both plans with the same relationships, the same assigned resources and agents, and all other attributes not listed in the table.

To work with baselines, the top-down check box must be selected in Administration > Server Administration > Server Configuration > Other.

Plan Attribute

Baseline Plan Attribute

Description

Start

Schedule request start

Start date of an item

End

Appointment request end

End date of an item

Duration

Requested date duration

Duration of an item, i.e. end minus start minus non-working time

Planned

Budget

Expenditure in working hours or working days and other expenditure, e.g., for external services

Duration

The duration of an item is determined by the start time minus the end time minus the non-working time defined in the calendar of the agent assigned to this item. If a group is assigned to an item, the available capacity is calculated from the total capacity of the group members. Agents who already belong to a group may not be assigned again directly or via other groups.

If the duration is zero, the item is interpreted and displayed as a milestone.

The following graphic shows three items, indicated by the colors red, blue, and green. The red item starts on Wednesday at 8am and has a duration of 16 hours. Therefore, it ends on the following day at 17:00. The blue item starts on Wednesday at 13:00 and has a duration of 8 hours, ending the following day at 12:00. The green item has a duration of 16 hours and extends over a non-working weekend. Everything in this case is based on an agent calendar with 8 hours of work per day and working hours from 8:00 to 17:00, interrupted by a one-hour break.

../../_images/duration.png

Scheduled

“Planned” refers to the time expenditures and other costs of the plan. The conversion from work days to work hours is based on the assigned workspace calendar.

The values for “planned” of collective items result from the summed values of the subordinate items.

Budget

The “budget” describes the estimated time expenditures and other costs of the baseline plan or the plan target. The “planned” values must be within the budget.

Budgets are not added up, but provide a framework. It is common to carry out budget planning only for higher levels in the hierarchy and not as detailed as the actual planning with “planned”.

The conversion from working days to working hours is based on the assigned workspace calendar.

Rest

“Remainder” refers to the estimated remaining effort to complete an item. This remaining effort is ideally the value for “planned” minus the effort already made (“current”).

The conversion from working days to working hours is based on the assigned workspace calendar.

Hierarchical behavior

You can configure the hierarchical behavior of date attributes (see Item Attribute Types). The recommended default setting is Fit parent. This will calculate the values for start and end from their subordinate items. In this case, the following rules apply recursively:

  • The start is the earliest start date of all directly subordinate items.

  • The end is the latest end date of all directly subordinate items.

  • The planned value is the sum of the planned values of all directly subordinate items.

If you work with baselines or task lists, the following additional rules apply recursively:

  • The start date request for each directly subordinate item must be at or after the start date request of the parent item.

  • The finish date request for all directly subordinate items must be before the finish date request of the parent item.

  • The budget of a parent item must be greater than or equal to the sum of all budgets for all directly subordinate items.

The system alerts you of conflicts between the base plan values and the plan values, but they are not prevented. Only if you have authorizations to read both the base plan values and the plan values you will receive information about such conflicts.

Date values without time

You can configure date values so that they appear on the input screens with or without time specifications (see:ref:fieldTypes). If you have displayed the date values without time, the working time start of the item is assumed to be the start of the agent’s working time and the end of the agent’s working time, for example, from 8:00 to 17:00 for an employee with an eight-hour working day and a one-hour break.

Fixed dates for individual items

You can configure item types so that their items can have fixed dates explicitly. To do this, you must set the item attribute FixedDate to fix the date values of the task list and the item attribute FixedTDDate to fix the date values of the baseline task list and activate the corresponding corresponding checkboxes.

Fixed dates for milestones and via filters

You can fix items based on a filter. To do this, create a public filter with the corresponding conditions (e.g., (start more than X days ago 0 OR state is Done)), save it (e.g., under the name GanttFixFilter), and specify the name of the filter in the property gantt.fixFilter=GanttFixFilter in the extended configuration file GeneralSettings.properties (see Configuration Files). This example would fix all items that have already been completed or whose start is in the past.

Unfixing individual deadlines

You can temporarily remove the fixing of individual appointments using the context menu, so that they can be moved.