Date, Cost, and Resource Scheduling

Information

• Below you find general explanations and basic information on the calculation component of the PLANTA software, hereinafter referred to as scheduling.
• Detailed description of different use cases as well as of the behavior under different configuration settings with examples can be found here. The program depictions used here are based on an older software status and are to be regarded functionally only.
• In the description of the calculation mechanism for projects, the following abbreviations are used for different project data levels:
  • PR - Project level (DT461)
  • TA - Task level (DT463)
  • TAR - resource assignment level (DT466) (assignment of the resources to tasks)

Data Tables Affected by Scheduling (Excerpt)

Scheduling

Information

• The term scheduling is used as an umbrella term for two types of scheduling:
  • date/time scheduling and
  • capacity scheduling
• A scheduling always carries out calculations for the entire network plan.
• During scheduling, the following work steps are carried out:
  • saving of current project data
  • loading of calendars and resource availability details,
  • unloading of all projects concerned,
  • loading of all required projects,
  • saving of the results
• The results of scheduling include:
  • earliest start and end dates, latest start and end dates and calculated start and end dates on project level
  • earliest start and end dates, latest start and end dates and calculated start and end dates on task level
  • and, if resources are already planned, calculated start and end dates of the assigned resources as well as their loading and capacity adjustment.

Scheduling: Individual Project Calculation and Replanning

Information

• In PLANTA project it is possible to carry out scheduling as single project calculation or as a so called replanning.

Single project scheduling

Replanning

• Replanning is a special calculation procedure which enables the simultaneous calculation of all active projects under consideration of priorities between projects. I.e. in projects which share the same resources, those with the highest priority are loaded first and those with lower priority receive the remaining capacity of the resources in question.
• In replanning, all capacity loading of the resource is completely reorganized in the period data table. For this reason, replanning should be carried out on a daily basis. Depending on the respective runtime, it should be carried out before all important resource adjustments or before taking a look at the utilization diagrams.
  • For the daily replaninng PLANTA recommends that you set up the automated procedure. If you have any questions, please contact your PLANTA consultant.
• Replanning can only be carried out in the Replanning (calculation of all planning objects) module which has been designed especially for this purpose.

Note

• The representation of the overload of the planned resources may vary in one and the same module depending on whether you have carried out a single project calculation or replanning. This can also be attributed to the non-consideration or consideration of project priorities.

Simultaneous Calculation by Several Users

Information

Calculation of Successor Dates

Information

• The network theory and the practical approach are available for determining the start of a task successor.

Network theoretical approach If the network theory method is used, the successor starts on the same day on which the predecessor ends.

Practical approach The successor does not start before the next day.

• in PLANTA project
  • tasks with duration > 0 and EA relationship are planned according to the practical approach, i.e. The successor starts on the following working day
  • tasks with duration = 0 (e.g. milestones) and EA relationship are planned in the following way:
    • If the duration of a task = 0, you can define via the Successor task start +1 day model parameter when its successor is supposed to start.
    • If the successor of a task has a duration of = 0, the successor always starts on the same day as the task itself.

Details

• Requested dates which fall on non-working days (vacation, sickness) remain as such and are taken into consideration.
• Start and end dates are also scheduled on non-working days. The duration, however, is still displayed in working days. The resources are loaded on working days.

Note for the use of the Active today line:

• Tasks which
  • have started (have an Actual start)
  • have not been finished yet (have no Actual end)
  • are supposed to end before today
    • have a calculated end date set to today’s date by the scheduling.

Planning Horizon

Information

• Planning horizon describes the period in which the resources are available for planning in projects. The planning horizon of a resource is defined with the Start period and End period parameters in the Resource Data Sheet module.
  • Periods are single days. Explanation: In order to be able to make assessments on the underloading or overloading of the resources, PLANTA must know the availability of resources. This availability is recorded on a daily basis. One day equates to one period.

Note

• If there are not enough periods available for planning, this has the following effect on the calculation of the schedule:
• If a resource is planned beyond the end of his/her planning horizon (i.e. later than the date of its end period), the effects on scheduling results must be considered.
  • If there is no availability for planned resources due to missing periods, scheduling surmises the availability to be unlimited (7 days week)
    • To the BLD load profile, the following applies:
    • the resource is scheduled for 7 days per week.
  • To the CAP load profile, the following applies:
    • the entire remaining load is planned on one day, i.e. the first day after the period.
    • Since the distribution of the remaining hours on the task are done linearly, this leads to different calculations of calc. end dates of the task and the resource assignment.
  • To all other load profiles, the following applies:
    • loading in accordance with the curve definition
• If you do not want the system to behave in this way, you can proceed as follows:
  • Alternative 1: Prolonging of the planning horizon of the resource in the Resource Data Sheet.
  • Alternative 2: scheduling of the resource using MAN load profile.
• However, to prevent performance impairment, the planning horizon should not be longer than necessary. The planning horizon can be extended if necessary.
• However, to prevent performance impairment, the planning horizon should not be longer than necessary. The planning horizon can be extended if necessary.

Load

Information

• Load is the planning of a project in the existing capacity situation. The term 'loading in' means that
  • a load record is created per resource assignment and day for the entire duration of the task.
  • the sum of all loads of a resource per day (utilization) is saved in the period record.
  • the Loaded project data field is set to activated.
• Loading is automatically a component of scheduling. It cannot be called up separately.

Loading sequence

• The loading between projects is based on:
  • Level
  • Priority
  • Requested end
  • Technical project ID
• The sequence of the tasks within a project structure or within a project is based on:
  • TA Rank
  • PR Priority
    • Cross project links or project structures can cause individual tasks or all tasks of the project with higher priority to be loaded after a project with lower priority. Further information on the influence of cross-project links and structures on the rank, and hence on the loading sequence, can be found here.
  • TA Priority
  • TA Total float
  • TA Planning early = activated
  • TA Planning early = deactivated
  • Technical Task ID

The traceability of the loading sequence is given by the Sequence parameter. The value stored there is calculated taking all above mentioned factors into account.

Load and Utilization

Information

• When the project is loaded, load records are created per task and day for the resources planned in the project. The planned effort is then allocated to these load records according to the load profile used. These “load values” are saved in the Load data table and can be viewed in the Schedule module as well as in the time recording modules.
• The sum of all loads of a resource per day is their utilization. It is saved in the Period data table. The utilization of a resource can either be viewed in the Availability (numeric values) or in different utilization modules (e.g. Utilization ) (in graphical form).

See also: Overview: Load Profiles, Examples and Application Cases of Load Profiles

Unload

Information

• By unloading, a project can be taken out of the current capacity situation.

Details

• Unloading is the opposite of loading. The resources that have been loaded are approved again.
• When unloading,
  • the load records generated by an RS run are deleted (loading records which have been entered manually are retained).
  • the utilization data stored in period records is reduced respectively.
  • calculated dates are emptied on all project levels.
  • the Loaded checkbox is deactivated.
• Unloading automatically forms part of scheduling. However, if a project is to be taken out of capacity scheduling, it can also be selected separately via the Edit Unload schedule menu item.

Example

• A project is in the offer phase and is loaded in for trial purposes to show the additional loads on the resources involved. As long as the project is not an actual order, it should be taken out of the capacity scheduling.

Procedure

• Unload the project via the Edit Unload schedule menu item.
• Remove the planned effort of the resources in order for the project not to be loaded again.

Further cases for the use of unloading

• When you create a template project, a capacity scheduling is carried out in the creation phase and the project is calculated in order to check whether the project plan is correct. After the creation of the creation phase, the project must be unloaded and the Status must be set to Template.
• Projects the status of which is set to = "inactive" or "archive", must be calculated finally and unloaded subsequently.

Planning Strategies

Information

• In PLANTA project, three planning strategies are to be distinguished:
  • Planning with adherence to schedule
    • The loading is done in accordance with the specified dates. Tasks are not moved or extended. If overloads should incur due to the missing capacity, they will be displayed. No capacity adjustment takes place. No float is used.
  • Planning with adherence to total float
    • In case of capacity shortage, a task can be moved within the project float. If sufficient free capacity is available, the task is loaded. If not, the task is loaded at its latest dates (TA Latest start/Latest end). The project end date (PR Requested end or PR Latest end) is not overrun due to capacity shortage.
  • Planning with adherence to capacity
    • Capacity shortage will cause tasks to be extended until sufficient free capacity is available. The PR Requested end date is not taken into consideration. For further information, see the Capacity Adjustment chapter.
• The planning strategy is defined via the Planning type parameter in the Schedule module.

See also: Examples and Application Cases for Planning Strategies

Capacity Adjustment

Information

• During capacity adjustment, the resources are planned in accordance with their availability. This may lead to postponements.
• The settings required for capacity adjustment are:
  • on the project:
    • Planning type = Adherent to capacity or Adherent to total float on project
  • on the resource:
    • Adjustment by effort activated
    • Load limit %
    • Load profile = CAP (on the resource assignment)
• Capacity scheduling uses the earliest and latest dates as key dates for capacity adjustment. However, capacity adjustment recalculates the durations, which may then be shortened or extended.
• Capacity scheduling attempts to load the resource within the available duration of the Remaining duration (required duration + float) task only up to the Max. load/day value. If this proves to be impossible, the remaining effort will be loaded uniformly throughout the available interval, even if this causes the resources to be overloaded in these periods.

Details

• The remaining capacity is relevant for capacity adjustment, i.e. the daily availability of the resource which has not yet been planned. This is calculated as:
  • Available capacity * Load limit % - Utilization
• The remaining capacity is the available capacity the use of which has not yet been planned.

Details of how to use the CAP load profile

• The Max. load/day value is a desired threshold for capacity scheduling. It can be exceeded if necessary, e.g. if duration or requested dates are preset for the respective task.
• If no Max. load/day has been set, the entire available capacity left is available for planning.
• The mere exceeding of the Max. load/day limit does not yet represent an overload, as overload is only determined on the basis of the available capacity of a resource. The resource only has overload when the availability is overrun.
• The capacity scheduling works with the Max. load/day parameter as follows (provided that there are no further restrictions on the resource assignment, like e.g. requested dates):
  • The required duration of the resource assignment used in scheduling is calculated from Remaining effort / Max. load/day.
  • This duration is the starting value for capacity adjustment.

Notes

• The capacity adjustment for tasks with deactivated Planning early checkbox is done reversely, i.e. starting with the Latest start / Latest end toward the Earliest start / Earliest end tasks.
• Capacity adjustment is switched off for a resource if both parameters (Adjustment by effort, Effort summarization) are deactivated.
  • Under the following constellations, no capacity adjustment takes place either (even if the two parameters mentioned above are activated):
    • for tasks with BLD resource assignment. They are always planned with adherence to schedule.
    • for tasks with MAN resource assignment. They are always loaded with adherence to schedule.
    • for tasks with requested dates (Requested start and/or Requested end). Task requested dates override the Planning early parameter, i.e.
      • in planning with adherence to schedule and adherence to total float, the task is loaded with adherence to schedule.
      • in planning with adherence to capacity with CAP load profile, the task may be extended if there is an overload.
    • for tasks with activated Fixing parameter.
    • for tasks with Actual start or Actual end If you want the rest of a task that already has an Actual start to be adjusted after all, it must be splitted. This is done by activating the Splitting parameter.
• Planning With adherence to capacity with Planning early = is treated equally by the scheduling as Adherent to total float with Planning early = .
  • Background: If this was not the case, planning would start at the end of the planning horizon since this is the latest date in scheduling.

Factors which Influence Scheduling

Information

• In the calculation of a schedule, different parameters or factors, or their combination, have an impact on the results. The most important factors are:
  • Links
  • Requested dates (Project, Task, Resource Assignment)
  • Requested dates (Project, Task, Resource Assignment)
  • Calendar
  • Planning early task parameter
  • Fix task parameter
  • Split task parameter
  • Load profile
  • Model Parameters

Dominance Rules within the Task Parameters

Information

• In scheduling, the task parameters take effect in the following sequence: Each one mentioned overrides (dominates) all those mentioned afterwards:
  • TA actual dates (TA Actual start / TA Actual end)
  • TA requested dates (TA Requested start / TA Requested end) with Fix parameter = 1
  • links
  • TA requested dates (TA Requested start / TA Requested end) with Fix parameter = 0
  • Planning early = N
  • Capacity adjustment

Example	Reason
TA actual dates override preset links	In practice, things often do not work out exactly as planned. A task starts later or earlier than planned. If this has occurred, the schedule change is to be considered in any further planning.
TA requested dates override the Planning early = N and the capacity adjustment	If requested dates are set, the task should be loaded in as well if possible. Only links can prevent this. This also applies when the Fixing = 0 parameter is set. When Fixing = 1, requested dates will even override links.

Consideration of Different Calendars in Scheduling

Information

• PLANTA project enables customers to work with multiple calendars.
• You can create calendars in the Calendar module.
• They can be used for multiple purposes in PLANTA project.

Details

• System calendar (up to DB 39 releases "company calendar")
  • If no other calendar is specified, the calendar defined as system calendar is used for scheduling by default. The system calendar is stored in the System calendar parameter (DT345) in the License, System Parameters, and DB Instances module.
• project calendar,
  • For projects, the calendar is stored in the Calendar parameter (DT461). The project calendar precedes the system calendar This parameter is not used in the Standard but can be integrated in the required modules in customized systems.
• Task calendar
  • For tasks, the calendar is entered in the Task calendar parameter (DT463) in the Schedule module. By using a task calendar you can, e.g. Make sure that resource loading for tasks in other countries does not start on a local holiday.
• Link calendar
  • The link calendar is taken into consideration in the interval calculation for subsequent dates. For links, the calendar is entered in the Link calendar parameter (DT465) in the Schedule module.
• Resource calendar
  • For resources, the calendar is entered in the Calendar parameter (DT467) in the Resource Data Sheet module

Attention

• A calendar entry on the resource is necessarily required since it is used for the creation of resource periods.
• If changes are made to the calendar afterwards, they do not have an effect on existing periods of the current resources but only on new periods. If you want changes to take effect on existing resource periods, you have to delete the periods of the respective resources which use the changed calendars and create them anew.
  • Since in PLANTA project some user modules access periods, some, on the other hand, directly access the calendar, this may result in different behavior in modules, if, e.g., the calendar assigned to resources has been changed after the creation of resource periods.

Interdependence of the calendars

• Project:
  • If no project calendar has been entered for the project, then the system calendar will be used as the project calendar.
• Task:
  • If an own calendar is entered on the task, it takes effect regardless of whether other deviating calendars are entered on other objects (system, project, resource).
  • If no own task calendar is entered on the task, the project calendar takes effect. If no project calendar is defined for the project, the system calendar will take effect.
• Resource assignment
  • On the resource assignment, the respective resource calendar always takes effect.
• links
  • If a link calendar is entered, it precedes all other calendars in the date determination of links except the task calendar of the successor. I.e. If the task successor has an own task calendar, this calendar overrides the link calendar.
  • If no link calendar is entered, the task calender of the successor precedes if there is one.
    • If there is no task calendar, the resource calendar takes effect if the successor has a resource assignment,
      • if there is no resource assignment, the project calendar takes effect if there is one. If there is no project calendar, the system calendar takes effect.

Effect of the calendars on dates and durations

• Effect of the calendars on scheduled start and end dates
  • A task requested date on a non-working day is not shifted to the next working day.
  • If a TA Requested start or TA Requested end is on a non-working day, the dates calculated from it (e.g. TA Calc. start / TA Calc. end ) moved to the next working day.
  • If a TA Actual start or TA Actual end is on a non-working day, the dates calculated from it (e.g. TA Calc. start / TA Calc. end) moved to the next working day.
  • if a day in the calendar is a non-working day, the task will be extended by the duration of the non-working time;
  • Resources are not scheduled on their non-working days.

Behavior of the Scheduling in Project Structures

Information

• PLANTA project always includes the currently selected project and its subprojects in scheduling. This is done regardless of whether the subprojects are selected and displayed.
  • If the top project is selected, the entire project structure is scheduled by PLANTA project.
  • If a subproject is selected, it is schedules by PLANTA project including its subprojects.

Principles

• Key dates are adjusted between main and sub projects, independent of the Structure calculation with adjustment.
• Durations and effort are summarized from the subproject to the structure task of the parent project.

Control Data Exchange between Main Project and Subproject

Information

• When planning with project structures, the data exchange between different project levels can be controlled via the Structure scheduling with adjustment model parameter.

Notes

• If model parameters are changed in the project structures area, the entries in Planned duration, Requested start and Requested end must be checked and corrected if necessary.
• For cost calculation purposes, you are advised to enter effort and costs only on one level, like e.g. the subproject level. Entry on both structure task and main and subproject level should be avoided.
• The standard modules do not contain these data items for structure scheduling. If you want to have them displayed, the following data items can be included in the modules individually:
  • DI001123 Structure start , DI001124 Structure end , DI001140 Planned duration/structure , DI001141 Actual duration/structure , DI001142 TA Remaining duration/structure , DI001143 Planned duration/structure DI001143 Planned effort/structure , DI001144 Actual effort/structure , DI001145 Remaining effort/structure , DI001633 Planned costs/structure , DI001634 Actual costs/structure , DI001635 Remaining costs/structure DI001636 Total costs/structure
• The actual start date is not automatically set for structure tasks with subprojects.

SF and FF Links for Structure Tasks

Objective

• To show the effects of SF and FF links on structure tasks

Information

• When carrying out the calculations for project structures, the key dates for the parent task (e.g. TA Earliest start and TA Latest end, depending on the model parameters) are copied to the subproject as its PR Requested start and PR Requested end, so that the subproject can run between these key dates.
• However, in the case of SF and FF links between structure tasks, their TA Earliest start is not known until the calculations are completed for the subproject, which is why these dates cannot be passed down before that point. There is therefore a chicken and egg problem, which causes some other PM systems to simply ban such links. In PLANTA project, SF and FF relationships between structure tasks are possible. They are taken into account as follows:
  • The TA Requested start of the subproject, the parent task of which is a successor of a SF or FF relationship, arise from:
    • The project start date of the higher level project, if there are no other SS or FS links pointing to this task.
    • The TA Earliest start of the parent task, if it is the successor of an FS or SS link.
  • All tasks which have no successor are moved just far enough so that the SF and FF links are complied with.

Consideration of the Cross-Project (External) Links in Scheduling

Information

• The interlinkage of projects via links results in the generation of a total network plan covering all projects involved. Any projects which have XP links to the project selected by the user are automatically included in the calculations. As a result the own project dates (TA Requested start /Requested end, PR Actual start/Actual end) and project priority are considered.

Sequence of project calculation

• In replanning, the cross project links override the the calculation sequence. It may occur that a project with bad priority is calculated earlier due to an existing cross-project links.

Example

• Cross-project links between different main projects
  • There is a cross-project link from task 03 in project 2511 to task 01 in project 2512.

• Result of scheduling
  • TA 01 in Project 2512 cannot take place until after TA 03 in Project 2511 is finished. When the calculations are being performed for Project 2512, Project 2511 will automatically be calculated at the same time. Although the project priority for project 2511 is less urgent, tasks 01 to 03 will be loaded before task 01 from project 2512.

Determine the Rank of a Task with XP Links

Information

• The rank of a task which has a cross-project predecessor is determined as the maximum of its rank within its own project, and the rank of its cross-project predecessor.

Example

• Project A has tasks A1, A2, A3, A4, and Project B has tasks B1, B2, B3. Both projects have the same priority.

• Task (B2) has rank 2 within its project, its cross-project predecessor (A3) has rank 3 within its respective project. As a result, task B2 is given the rank 4 within the Total Network Plan. The rank of its successor will be 5.
• The load sequence is: A1, B1, A2, A3, A4, B2, B3.

Example

• If project B has a less urgent PR priority, then task B1 receives rank 3.

• Loading sequence, taking into account the project priority: A1, A2, A3, B1, A4, B2, B3.

Cost Planning/Calculation

Note

• A detailed description of cost planning and calculation for PLANTA project releases up to 39.5.0 can be found under Cost and Budget Planning up to DB 39.5.0.

Calculation Matrix for Dates, Costs, and Budgets

Module	Button	Scheduling	Cost calculation	Budget calculation	Calculation of benefit and revenues	Calculation of risks and opportunities	Miscellaneous
Schedule (Project)	Scheduling in the toolbar or the menu item of the same name	+	+	-	+	+
Schedule (Program)	Scheduling in the toolbar or the menu item of the same name	+	+	-	+	+
Budget (Project)	Recalculate	+	+	+	+	-
Budget (Program)	Recalculate	+	+	+	-	-
Status (Project)	Create baseline, Create status report, Create final report	+	+	+	+	+
Status (Program)	Create baseline, Create status report, Create final report	+	-	+	-	+
Portfolio	Update portfolio	-	+	+	+	+
Edit Portfolio Period	Update portfolio	-	+	+	+	+
Status (Portfolio)	Create status report						Summarization project status reports
Replanning	Replanning Replanning incl. portfolios	+ +	+ + on PF yearly tranches	+ +	+ +	+ +

Explanations on the individual calculation types:

Note

• For detailed information on cost scheduling and cost and budget scheduling, please click here.