Please note

• The following description is based on the description of the PLANTA software versions up to 39. At the moment, the update is carried out successively.
• For the time being, the illustrations depict the software status < 39 and should be regarded as illustrative examples only.

Date/Resource Scheduling

General Information on Scheduling

Overview

• Below, the PLANTA project scheduling procedure is described.
• This is not a purely algorithmic description, but rather a description from the user's point of view, which is supplemented with numerous examples.
• It is suitable for both independent study and as a work of reference.

Scheduling Methods

Information

• The term scheduling is used as an umbrella term for two types of scheduling:
  • Time scheduling (TS)
  • Capacity scheduling (CS)
• The scheduling procedures (SCHED) always carry out calculations for the entire network plan.

Example

• Capacity planning strategies in PLANTA project
  • Replanning
    • Rescheduling of all projects
    • Calculation is carried out by priority
  • Capacity adjustment
    • Loading in of a new project taking into account loads that already exist for the resources
    • Consideration of several or all projects (central resource management)
    • Is carried out manually or automatically (for planning with adherence to buffer or capacity)
    • Capacity adjustment by effort (adjustment of freely available capacity)
    • Capacity adjustment by costs

Calculation of Successor Dates

Information

• The user determines the projects for which calculations are to be performed by making a selection of data. The calculations are always performed for all the projects included in this selection. Prerequisite: Every immediate or mediate parent project or subproject also has status = 1.
• If the selection includes parts of several projects, all these projects will be scheduled (including all of their possibly existing subprojects, together with all the projects which interact with these projects through links). The results of the scheduling calculations will be stored in the PPMS database, where they can immediately be accessed by all users.

Modules Used for Scheduling

Objective

• With the PLANTA customizer in the Further module parameters module, you can set whether scheduling is possible in a PLANTA module

Example

• In the Create, Edit, Delete Projects module, time or capacity scheduling is possible.

Note

• The user determines the projects for which calculations are to be performed by making a selection of data. The calculations are always performed for all the projects included in this selection.
• If the selection includes parts of several projects, all of these projects will be scheduled (including all of their possibly existing subprojects, together with all the projects which interact with these projects through links). The results of the scheduling calculations will be stored in the PPMS database, where they can immediately be accessed by all users.
• In module 002858 Replanning (calculation of all projects), all active projects, that is, projects with status 1, are calculated in accordance with the displayed planning sequence. For more information, please see the section on replanning in this manual.

Scheduling Sequence

No.	Calculated parameters	Result	Module
1	Scheduling forward of the earliest start dates	Earliest dates	Time scheduling
2	Scheduling backward of the dates with Planning early = N	Latest dates	Time scheduling
3	Scheduling forward for loading resources with Planning early parameter = Y	Loading of the earliest dates	Capacity scheduling
4	Scheduling backward for loading resources with Planning early parameter = N	Loading of the latest dates	Capacity scheduling
	The network diagram is completed after steps 1-4.
5	Cost calculation	Creation of the cost data	Capacity scheduling
6	Calculation of further dates	Latest end dates, float, date variances.	Capacity scheduling

Note

• Planning with adher. to capacity with Planning early = N is treated by the scheduling like adh. to total float with Planning early = N. Background: If this was not the case, planning would start at the end of the planning horizon since this is the latest date in date scheduling.

Data Tables Affected by Scheduling (Excerpt)

Time Scheduling (TS)

Information

• The purpose of this chapter is to provide a general overview of the date scheduling scheduling type in PPMS. The date scheduling performs calculations for the network diagram on the basis of the estimated task durations and their links, taking into account the calendar details. However, no resource-capacity loading takes place.

General Information on Date Scheduling

Information

• The results of date scheduling include:
  • earliest start and end dates (Earliest start / Earliest end): blue bars
  • latest start and end dates (Latest start / Latest end): small green arrows

Example

Note

• As far as parameter 1 is set deviating from the product standard in the Time scheduling options field in the Model and Model Parameter module, time scheduling behaves as follows:
  • Time scheduling considers the Planning early task parameter and calculates the TA Calc. start and TA Calc. end dates.
  • No cost calculation is carried out.
  • Time scheduling then equates to a capacity scheduling without load, capacity adjustment and cost calculation.

Details

• Time scheduling is initiated via the Edit Scheduling Time scheduling menu items.
• During time scheduling, PPMS carries out the following work steps:
  • save the current project data
  • load the remaining project data
  • load the calendar
  • calculate the network plan
  • save the results

Notes

• It makes sense to perform date scheduling, if e.g.
  • the project is to be calculated without considering the resources.
  • the capacity scheduling is locked by another user and the project is to be updated without considering resources.
• An arbitrary number of users can carry out date scheduling for their projects at the same time.
• In many modules, the display of the earliest and latest dates is switched off to give a clearer overview. They can be moved from window 9 (Bar earliest dates, Bar latest dates).

Visualization of Date Changes

Information

• The visualization procedure is described in the „Multi-Project Management“ manual.

Details

• Make the following settings prior to visualization:
  • Open the Model and Model Parameters module via PM Administration Special Functions.
  • Activate the Consider today parameter.
  • Set Fix today's date to today’s date
  • Deviation controlling =2

Information

• The options for moving dates are described below. The reasons for a move are always in the specified sequence:
  • Date scheduling:
    • 1: Project dates (Actual start or new project requested dates)
    • 2: Today line
    • 3: TA Req. start / Req. end (new Req. start of the cause)
    • 4: duration TS (extension or shortening of the TA Planned duration)
    • 5: Capacity (move due to lack of capacity)
    • 6: Duration CS (change to duration as a result of CS)
    • 7: Actual dates (earlier/later start or earlier/later end as a result of actual dates)
• The possible reasons are determined during time and capacity scheduling and are stored in the cause table.

Details

• Special case soft link
  • If tasks are connected by soft links, the impact of a movement is detected
    • Detection is only based on date scheduling, i.e. capacity scheduling is ignored.

Example

No	Movement	Check	Description	Cause
1	Start date later than planned (movement to the future) Movement without predecessor	Move plan SD Req. start (earlier) earliest start or move Calc. start	Plan start date / Req. start of the moved task is earlier than the earliest start / Calc. start of the moved task	1: project dates 2: today line 3: TA Requested start/Requested end 5: capacity
2	Start date later than planned (movement to the future) Movement without predecessor	Move plan SD or move Req. start</em (earlier) earliest start or move Calc. start	Plan start date / Req. start of the moved task is earlier than the earliest start / Calc. start of the moved task	1: project dates 2: today line 3: TA Requested start/Requested end 4: duration TS 5: capacity
3	End date later than planned (end date in the future) Movement without predecessor	Move plan SD or move Req. start</em (earlier) earliest start or move Calc. end	Plan end date / Req. end of the moved task is earlier than the earliest end / Calc. end of the moved task	Cause: TA1 Cause: 4: duration 5: capacity
5	Start date earlier than planned (start date in the past) Movement without predecessor	Move plan SD or move Req. start (later) move earliest start or move Calc. start	Planned start date / Req. start of the moved task is later than the earliest start / Calc. start of the moved task	Cause: TA1 Cause: 5: capacity 7: actual dates
6	Start date earlier than planned (start date in the past) Movement with predecessor	Move plan SD or move Req. start (later) move earliest start or move Calc. start	Planned start date / Req. start of the moved task is later than the earliest start / Calc. start of the moved task	Cause: TA1 Cause: 5: capacity 7: actual dates
7	End date earlier than planned (end date in the past) Movement without predecessor	Move plan ED or move Req. end (later) move earliest end or move Calc. end	Plan. end date / Requested end of the moved task is later than the earliest end / Calc. end of the moved task	Cause: TA1 Cause: 4: duration 5: capacity
8	End date earlier than planned (end date in the past) Movement with predecessor	Movement with predecessor Move plan ED or move Req. end (later) move earliest end or move Calc. end	Plan. start date / Requested start of the moved task is later than the earliest end / Calc. end of the moved task	Cause: TA1 Cause: 4: duration 5: capacity
9	TA possesses several predecessors, movement by predecessor 1	Move plan SD or move Req. start (later) move earliest start or move Calc. start	If there are several predecessors, the respective main cause is displayed.	1: later project start (actual SD or new project requested dates) 2: active today line 3: new Requested start of the cause 4: duration cause task (= TA1, but can also be sub-PR or summary TA) 5:capacity (extension or movement) Planning late Adjustment by float TAR with CAP TAR with MAN TAR with WAT
10	TA possesses several predecessors, movement by predecessor 1 is replaced by stronger movement by predecessor 2	Move plan SD move Req. start (earlier) move earliest start or move Calc. start		1: later project start (actual SD or new project requested dates) 2: active today line 3: newer Requested start of the cause 4: duration cause task (= TA1, but can also be sub-PR or summary TA) 5:capacity (extension or movement) Planning late Adjustment by float TAR with CAP TAR with MAN TAR with WAT

Influence Factors of Time Scheduling

Links

Information

• For general information on the links and the procedure for creation and deletion, see here.
• For the description of individual parameters of the links, see here.

Project Requested Dates (Requested Start/Requested End) in Time Scheduling

Objective

• To restrict the project execution time by requested start and end dates for the project

Information

• Requested start is the requested start date of the project. It is the start date for all tasks which have no predecessor(s) and no requested dates of their own. The PR Requested start will be adhered to, provided that no other conditions (e.g. consideration of the 'today' line) prevent it. It will also be applied if 'actual' dates have already been entered for tasks.
• For tasks without predecessor(s), the following will be applied as the earliest dates:
  • PR Requested start, if available
  • PR Actual start, if available
  • TA Requested start with Fix
  • Today’s date, provided that the Consider today parameter in the Model and Model Parameter module is activated.
• Requested end is the requested end date of the project. Model parameters can be used to control of the impact the PR Requested end on the float calculation..

Note

• Loads with MAN load profile can be earlier or later than the PR Requested start date. In such cases, the TA may be controlled by the load records of the MAN resources. For more information on this, see the “Load Profile” section in this manual.

Help text of the data item

DI	Name	Description
000085	Project requested dates for float	Option for considering the project requested dates in the float calculation Values The checkbox is activated – consideration The checkbox is deactivated – no consideration, only comparison

Procedure

• This option is available via PM Administration Special Functions Model and Model Parameters
• By setting the Project Requested Dates for Float model parameter, the option is activated.

Example

• The PR Requested end is decisive for the Total float (Project Requested Dates for Float= Y). Since the calculated overall duration of the project is shorter than the time between Requested start and PR Requested end, all the tasks will be given an additional buffer.
• In this example, the Total float has 9 days from TA A and is thus just as long as the project buffer. Because of ist shorter duration the task B has the buffer of 14 days.

Note

• Please note that this DI is not included in the Standard, but can be added by a customizer if required.

Project Requested Dates (Requested Start/Requested End) in Time Scheduling

Objective

• To show the effect of requested dates in scheduling

Information

• Task requested dates determine the start and end of the task unless other restrictions prevent this.

Example

• Initial situation

• The TAs set for TA B Requested start/TA Requested end move TA B to these dates. The blue triangle marks the set Requested start/the manually set Requested end. TA Earliest start is set to TA Requested start by TS.

• A new TA Requested start, e.g. 10/30/08, cannot be met for TA A, since according to the network diagram, the earliest start date is later due to the FS link between TA B and TA A.

• If TA Requested start and TA Requested end are set, TA Remaining duration is calculated by time scheduling. The TA Planned duration is retained for comparison purposes.

Example

• In task TA A, a TA Requested start and TA Requested end are set. TA Remaining duration is calculated.

Note

• You can prevent TA requested dates from being shifted by using the Fix parameter described later in this manual.

Task Requested Dates (TA Req. start/Req. end) with Duration 0

Objective

• To demonstrate the effect of task required dates with Planned duration = 0 in scheduling

Information

• If the task is planned with a Planed duration = 0 and TA Requested start or TA Requested end, the task is loaded adherent to schedule regardless of the project planning type. Background: A task with Planned duration = 0 is regarded by the scheduling as a time task or milestone, which causes the resources to plan adherent to schedule.
  • If only one TA Requested start is set, the task is planned for the requested start date.
  • If only one TA Requested end is set, the task is planned for the requested start date.

Note

• If a TA Requested start is set together with a TA Requested end, the TA has a duration of 1 and thus the behavior described above no longer occurs.

Task Requested Dates And Remaining Duration

Objective

• Display of the effect of task requested dates on the Remaining duration in date scheduling

Information

• After setting an Actual start im Feld Remaining duration, the Remaining duration can be shortened by the user in comparison to the value calculated by the scheduling.
• Entries that extend the date beyond the TA Requested end, are shortened by the scheduling to the maximum Remaining duration in order for the TA Requested end can be adhered to.

Example

• Initial situation
  • A requested end date is set in task 30 and TA 40. TA Remaining duration is calculated with 28 days.

• For TA 30, a shorter Remaining duration is set manually,
• For TA 40, a Remaining duration is set, which would extend the TA Calc. end.

• After scheduling, the shorter Remaining duration of TA 30 is maintained and the Remaining duration of TA 40 is reset to the initial value, in order for the Requested end to be preserved.

Effect of the Fix parameter

Objective

• Requested dates are not to be shifted.

Information

• A task requested date without Fix parameter only has an effect if it is not shifted by links or capacity adjustment.
• The calculated start and end dates Calc. start and Calc. end of a task are calculated as follows:
  • TA Calc. start = Maximum from the dates and TA Requested start detected via links/capacity adjustment
  • TA Calc. end = Maximum from the dates and TA Requested end detected via links/capacity adjustment
• Via the DI009480 Fix data field, you can set for each task how the requested dates are taken into account:

Details

• The duration of the task takes priority.
• If the planned task duration = 0, the task duration is determined as the maximum duration of all resource assignments.
• For each task, a date-oriented loading can be set by the project planning type.
• For CAP load profile, the Remaining duration is calculated (Remaining duration = Remaining effort / Max. load/day); Effort = Max. load/day.

Examples

• Tasks TA 1 and TA 2 are connected via a link of the Type SE (start-end).
• A resource has a Planned effort of 60h.
• Planning with adherence to schedule. Parameter Fix = 0: No fixing, the TA can be shifted e.g. by links or resource adjustment.
  • • TA 2 is moved. The date delay on the requested date of TA 2 is indicated in both TAs by red triangles.
    • The resource is scheduled with adherence to capacity on 9 days from 11/13 to 11/25/2008.

      

  • Fix = 1: The task is scheduled exactly on the requested date.
    • Links are ignored.
    • Capacity adjustment is deactivated.
    • Only takes effect if at least 1 requested date is set.
    • The TA requested dates are adhered to regardless of the planning type. The task duration corresponds to the specifications caused be the requested dates and is 6 working days.
    • The deviation from the normal date of the link without Fix parameter is indicated in TA 1 by red triangles. There is no delay for TA 2 because scheduling is carried out on exactly the requested dates.
    • The resource is scheduled on his/her working days from 11/06 - 11/13/2008 within the task requested dates. If it does not have sufficient capacity, it will be overloaded.

      

  • Fix = 2: no fixing, however date-oriented scheduling of task resources within the TA Planned duration.
    • Links are taken into account, the task may be shifted.
    • Capacity adjustment is deactivated. The task duration corresponds to the Planned duration of 7 days.
    • TAR requested dates outside the task dates have no effect, loading takes place within the task dates.
    • For CAP load profile, the Remaining duration is calculated (Remaining duration = Remaining effort / Max. load/day /Max. load/day).
    • The resource is scheduled on its working days from Monday 11/13 - 11/20/2005 within the task requested dates. If it does not have sufficient capacity, it will be overloaded.
    • Load Max. load/day for the Remaining duration period.
    • If the planned task duration = 0, the task duration is determined as the maximum duration of all resource assignments together.
    • The date delay on the requested date of TA 2 is indicated in both TAs by red triangles.

      

Notes

• The Fix parameter does not have any effect if there is not at least one requested task date.
• Exception when Fix parameter = 0:
  • If Planned duration = 0 and a TA Requested start or TA Requested end has been set, PLANTA regards the task as a point in time and not as a period related task.
  • For this reason, the system carries out date-oriented scheduling rather than capacity adjustment in this situation.

Control Link Behavior via Parameters

Objective

• Control Link Behavior via Parameters

Details

• The link behavior can be controlled via the Cross project link soft and No link on MMS parameters. When you save, a programmed exit checks whether the usage rules are met.

Procedure

• Open PM administration Special functions Model and Model Parameters.
• Activate the Cross project. link soft and No link on MMS checkboxes.
• Save.

Application cases of the usage rule

No	Description	Expected result
1	Create project with 2 tasks, both of them connected to fixed link.	Fixed link possible
2	Create project with 2 tasks, both of them connected to soft link	Soft link possible
3	Create project with 2 subprojects. Create each subproject with 2 tasks. Connect TA2 of Sub-PR1 and TA1 of Sub-PR2 with fixed link.	Fixed link possible
4	Create project with 2 subprojects. Create each subproject with 2 tasks. Connect TA2 of Sub-PR1 and TA1 of Sub-PR2 with soft link.	Soft link possible
5	Create 2 main projects with 2 tasks in each project. Both tasks are connected with fixed links. TA2 of Main PR1 and TA1 of Main PR2 with fixed link.	Fixed link connection for project internal links. No fixed links possible for cross project links.
6	Create 2 main projects with 2 tasks in each project. Both tasks are connected with fixed links. TA2 of Main PR1 and TA1 of Main PR2 with soft link.	Fixed link connection for project internal links. No fixed links possible for cross project links.
7	Create project with 2 tasks, both connected via fixed / soft link. TA2 is a milestone with Milestone type =1	Fixed / soft link possible
8	Create project with 2 tasks, both connected via fixed / soft link. TA2 is a milestone with milestone type = 2 (master milestone)	No link possible

Task Actual Dates (TA actual start date TA actual end date) During Time Scheduling

Objective

• To show how actual dates affect the update of the plan

Information

• Task actual dates dominate the links and TA requested dates.

Example

• Task A has been reported earlier than planned. Actual start is earlier than Calc. start and is not moved by DS. Via the Split parameter in window 9, scheduling of the remaining efforts starts from 10/22/2008..

Note

• If a TA Actual end is set without TA Actual start, the DS TA Actual end = TA Actual start. Advantage: When reporting tasks without duration (e.g. milestones), it is only necessary to enter the TA Actual end .
• Tasks with an Actual start are treated as if they had no predecessors since they can no longer be shifted by their predecessors. This is necessary to ensure that the predecessors can still be planned if the link condition is not satisfied.
• If in a ES link a successor has already started (Actual start is set), without its predecessor having started, the predecessor has a total float up to the project end after DS.
• With the help of parameter DI001112 Split from window 9, the planning of the remaining effort is carried out as if the task had not begun yet. This prevents an early update report from making links invalid. The parameter is active in the PPMS standard system.

Information

• A task which has been started even though it possesses a predecessor which has not been started, usually indicates a break in the link. In practice, such breaks occur time and again (for example, design work is started even though the customer's approval has not yet been obtained).
• PLANTA is stable with respect to such infringement of the link condition, i.e. the links which have become senseless are ignored in the scheduling. In the situation where a task has no other links (constraining it in the forward direction) this may lead to the due-date for the task being the end of the project. This is indeed equivalent to the loss of the successor which defines the due-date, and with it the link. If you do not want the system to behave like this, you have the following option:
  • By defining an additional FF link between these two tasks, the buffer time of the predecessor can be influenced.
  • Activate the Sched. early checkbox. The resource-scheduled dates will then be correct, but not the buffer times.
  • Additional links to the successor of the direct successor "for safety purposes". Simple when standard network plans are used, but otherwise may involve high updating effort.
  • Only introduce a new link if it is noted that the task is kept 'hanging'. Disadvantage: If you overlook this, the plan data will be incorrect.
  • Use of FF conditions, where the assumption is made that the predecessor will start "soon".
  • Split the task (see the appropriate section).
  • If this situation arises frequently, it will make sense to use a suitable combination of these remedies.

Scheduling Without Resource Assignment if an Actual SD is Set Without an Actual ED

Objective

• To use the planning model without resource assignment.

Details

• Via the DI000087 Work reporting date TS model parameter, you can configure how the TA DUP is to be set if resources do not report hours.
  • Work reporting date ZR = J
    • Actual end of the task has not been set
      • DUP = current day
      • Actual duration = current day – Actual start of the task +1
      • Remaining duration = Actual end of the task – Actual start of the task
    • TA AED is set
      • Work reporting date = Actual end of the task
      • Actual duration = TA Actual end – Actual start of the task + 1
  • Work reporting date TS = N (Behavior up to release 3618)
    • If an Actual start- and no Actual end is saved for a task without resource assignment, the Actual duration is always one day.
    • The displayed remaining duration always corresponds to the Remaining duration -1.
    • TA Work reporting date is always set to the Actual start. A manual entry of the TA Work reporting date is therefore always overwritten.
    • The work reporting date is set to the Actual end of the task. If no Actual end of the task is set yet, the Work reporting date is set to the Actual start of the task.
  • The PLANTA Standard setting is Work reporting date TS = Y.

Example

• Initial situation: No Actual start of the task has been set yet:

• Display after scheduling with Consider today parameter = N and Work reporting date TS parameter = N:

• Display after scheduling with Consider today parameter = N and Work reporting date TS parameter = Y:

• Display after scheduling with Consider today parameter = Y and Work reporting date TS parameter = N:

• Display after scheduling with the Consider today parameter = Y and Work reporting date TS parameter = Y:

Notes

• If you want milestones without Planned duration to be displayed, the Actual start is set to the Actual end.

Behavior of TA Requested Dates and TA Remaining Duration when TA Actual Start Date is Set

Details

• The TA Remaining duration is calculated via the Requested end of the task if TA Actual start is set.
• If a TA Actual start is set which is later than the Requested start of the task, the Requested end of the task is kept and the Remaining duration is shortened.
• If a TA Actual start is set which is earlier than the Requested start of the task, then for
  • Split = N, the entire task is brought forward and the Requested end of the task is kept. The task Remaining duration is extended.
  • Split = Y the task planned with the Requested start and the Requested end of the task.

Example date scheduling without resources

• Initial situation

• If a TA Actual start is set which is later than the Requested start of the task, the Requested end of the task is kept and the Remaining duration is shortened.

• A TA Actual start is set which is earlier than the Requested start of the task.
• Split = N:

• The entire task is brought forward and the Requested end of the task is kept. The task Remaining duration is extended.

• Split = Y:

• The task is planned with the Requested start and the Requested end of the task.

Overview of the Data Fields Calculated by TS

DT461 Project
Main PR	PR PED1
Level	PR PSD2
NP cycle	PR PED2
last DS	PR PSD3
Number TAs	PR PED3
Number links	PR PSD4
PR P duration TS	PR PED4
PR A duration TS	PR PSD 5
PR R duration TS	PR PED5
PR RMT	PR dev. SD1
PR FAT	PR abs ED1
PR FET	PR dev. SD2
PR SAT	PR dev. ED2
PR SET	PR dev. SD3
PR Actual SD	PR dev. ED3
PR Actual ED	PR dev. SD4
PR Req. SD (for subprojects only)	PR dev. ED4
PR Req. ED (for subprojects only)	PR dev. SD5
PR PSD1	PR dev. - ED5

DT 463 Task
TA release	TA STRED
TA with cycle	TA PSD1
TA total float	TA PED1
TA free float	TA PED1
TA Actual duration	TA PED2
TA Remaining duration	TA PSD3
TA P duration/STR	TA PED3
TA A duration/STR	TA PAD4
TA R duration/STR	TA PED4
TA R SD	TA PSD5
TA SD position	TA PED5
TA % compl.	TA dev. SD1
TA % compl. date	TA dev. ED1
TA RMT	TA dev. SD2
TA FAT	TA dev. ED2
TA FED	TA dev. SD3
TA SSD	TA dev. ED3
TA FED	TA dev. SD4
TA Actual SD	TA dev. ED4
TA Actual ED	TA dev. ED4
TA STRSD	TA dev. ED5

• As far as DI 022743 Time scheduling options is set to 1, the Calc. start and Calc. end of the task is calculated by the scheduling.

DT 465 Link
Free float GB
Free float FF

Date Scheduling Use Cases

Plan Project

Application case	Procedure	Result
Create project	Create project, fill required fields.	Project is created according to the input.

Information

• Without task data, it is not possible to calculate the project.
• A network plan can only be created if task data is available. The dates and effort of the network plan are cumulated on project level.

Scheduling with Tasks

Information

• The project dates are always calculated
  • The project starts with the requested start date of the project or the start date of the first task.
  • The project ends with the requested end date of the project or the end date of the latest task.

General

Description

• The TA duration has greater importance.
  • If a TA duration is entered (or calculated using Requested start + Requested end ), it has the highest priority.
  • Practical relevance: If the PM defines a TA duration, it takes effect for the calculation of the network plan. The resources are then scheduled within this task duration.
  • Options for calculating the duration:
    • Planned duration
    • Requested start / Requested end of the task
    • Hammock task
  • If no TA duration is defined, the TA duration is calculated on the basis of the resource assignments (MAN, CAP with max. load, TAR requested date, TAR duration) or is 0, if no resource assignments exist.
  • Most important effects:
    • planning with adherence to schedule
      • CAP does not shorten and extend the TA duration, but the capacity adjustment within the TA duration still takes place.
      • Within the TA duration, MAN provides meaningful results if the TA duration is defined. Remaining duration is set automatically.
      • TAR requested dates are only considered within the TA duration. If TA duration =0, they are only considered within the TA Calc. start / TA Latest end considered. Logic: The resource planning can only be made within the TA duration.
    • planning with adherence to total float
      • As before, CAP can extend the TA duration up to TA Latest end.
    • Planning with adherence to capacity
      • As before, CAP can extend the TA duration up to the planning horizon of the resource.
      • New: If no load profile is entered, planning may be carried out with overload, since planning is carried out linearly.

Duration-Oriented Planning

Objective

• To plan tasks depending on a specified task / work package duration.

Overview 1: Planned duration = 0

Application case	Procedure	Result
Plan task without date	Calculate project	Calc. start = Today, if today’s date is active Calc. end = Calc. start
Plan task with Requested start	Enter start date in Requested start Calculate project	Calc. start = Requested start Calc. end = Calc. start
Plan task with requested end	Enter end date in Requested end Enter end date in Requested end	Calc. end = Requested end Calc. start = Calc. end
Plan task from .... to ....	See application cases: Duration oriented planning

Overview 2: Planned duration 0

Application	Procedure	Result
The task has a runtime in days.	Input of the days in the Planned duration field Calculate project	Task is planned with: Calc. start Remaining duration = Planned duration Calc. end = Start date + Remaining duration
Variant: Runtime with defined start date	Input of the days in the Planned duration field Enter start date in Requested start Calculate project	Task is planned with: Calc. start = Requested start Remaining duration = Planned duration Calc. end = Start date + Remaining duration
Variant: Runtime with defined end date	Input of the days in the Planned duration field Enter end date in Requested end Calculate project	Task is planned with: Calc. end = Requested end Remaining duration = Planned duration Calc. start = Calc. end – Remaining duration
The task has a runtime from .... to .... with defined start and end date (basic dates)	Enter start date in Requested start Enter end date in Requested date Calculate project Planned duration has no effect but serves for comparison purposes or is omitted	Task is planned with: Calc. start = Requested start Remaining duration = duration of Req. start up to Req. end in working days Calc. end = Req. end Input in Planned duration is overwritten by the scheduling in accordance with the requested dates
The task is to be shifted if a predecessor is shifted. Runtime either by basic dates or specification in days, Fix = 0	Enter task with start and / or end date and / or Planned duration Link predecessor to task Calculate project	Task is planned with: Start/end dates and Remaining duration according to requirement Shifting of the predecessor causes the task to be shifted.

Note

• In PPMS, durations are always specified in working days, not calendar days.

Duration-Oriented Planning with Parameters

Overview

Application case	Procedure	Result
The task is not to be shifted even if a predecessor is shifted. Runtime either by basic dates or requirement in days.	Plan task with start and / or end date and / or enter Planned duration Set Fix = 1 Calculate project	Task is planned with: Start/end dates and Remaining duration according to the specification Shifting of the predecessor has no effect.
The task is supposed to start as late as possible.	Plan task in accordance with requirements Deactivate the Planning early parameter Calculate project	Task is planned: with the latest possible start/end date and Remaining duration depending on the requirement The duration is calculated from end date on forward
A task that has started is to be further planned without interruption.	Set actual start date Split parameter = N	Task is planned: Start date = Actual start date With the latest possible start/end date and Remaining duration depending on the requirement The duration is calculated from end date on forward
A started task is to be planned further on without interruption	Set actual start date Split = N	Task is planned: Start date = Actual start date Set the latest possible start/end date and Remaining duration depending on the requirement The duration is calculated from end date on forward

Capacity Scheduling (CS)

Overview

• This section provides an overview of the Capacity scheduling PPMS scheduling type, which executes the network diagram calculations on the basis of the estimated task durations, links, and calendars taking account of the available capacities of the assigned resources. The tasks are loaded against the resource capacities.
• This section deals with the terms adherence to schedule, float, and capacity, as well as capacity adjustment.

General Information on Capacity Scheduling

Information

• Result of capacity scheduling are, a.o., the calculated start and end dates (Calc. start / Calc. end) on project, task, and TAR level. Even tasks which have no resource assignment will be given a TA Calc. start / Calc. end dates. The bars for calculated dates use traffic-light functions. Yellow bars represent the critical path in the network plan, while green bars represent non-critical tasks. Red arrow bars indicate date delay.

Example

Details

• Capacity scheduling can be triggered by clicking on the button or selecting the Edit Capacity scheduling menu items.
• During capacity scheduling, the following work steps are carried out:
  • save the current project data
  • load the remaining project data
  • load calendars and resource availability details,
  • unload all the projects concerned,
  • loading in all the required projects,
  • save the results

Notes

• Any required number of users can carry out capacity scheduling at the same time, provided that the particular projects which are being scheduled do not share any resources (cf. the appropriate section).
• Which particular project is currently calculated can be seen at the bottom left of the screen in the product standard.

• It is possible to define the position of the status bar via the View Status bar menu items.
• CS is carried out based onthe following principle: The first to calculate receives the available capacity of a resource. At this stage, the relative priorities of the projects are ignored. Replanning is a special calculation procedure which allows the relative priorities of the projects to be taken into account (cf. the appropriate section).

Planning Strategies (Adherence to Schedule/Float/Capacity)

Objective

• To define the planning strategies and their effects on scheduling

Overview

• When a project is loaded in, it is possible to allow for the fact that other projects are already loaded on the resources in question. In this case, PLANTA can carry out capacity adjustment, i.e. the dates for tasks will be moved if the capacity is insufficient.
• Capacity adjustment can be performed either manually (e.g. by setting a TA Requested start or TA Requested end) or automatically (e.g. in the case of planning with adherence to total float or capacity).
• PLANTA distinguishes three different planning strategies:
  • planning with adherence to schedule
    • Availability of capacity or tasks which have already been loaded are not taken into account when loading tasks. No capacity adjustment takes place.
  • planning with adherence to total float
    • In case of capacity shortage, a task can be moved within its total buffer time. 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
    • A capacity shortage will cause tasks to be moved until sufficient free capacity is available. The PR Requested end is not taken into consideration.
• You can set the planning strategy via the Planning type project parameter.
• An important factor for capacity adjustment is the "Remaining capacity" per day. This is calculated as:
  • Avail.cap. Load limit % - Utiliz.
• The remaining capacity is the available capacity the use of which has not yet been planned.

Example for the calculation of the remaining capacity

• On 11/18/2008, the resource DES/M has 21.60 hours of available capacity. The load from other tasks amounts to 14.67h.

• If the resource load limit set in the resource data sheet for is 120%, this gives a remaining capacity for this day of:: 21,60 1,2 – 14,67 = 11,25h.

Example for planning with adherenc to schedule

• The department resource is scheduled with 300 hours, without a load profile entry on TA A with a Planned duration duration of 5 days. The loading limit of DES-E is 100%. Task A is planned on the earliest date. The total overload is displayed to the right of the bar.

• The project causes an additional overload (= light-colored bar in week 43):

Example planning with adherence to total float

• Task A is scheduled with a Planned duration of 5 days and is shifted to the latest dates as there is not enough capacity available beforehand across the complete task duration:

• The project causes an overload in CW 44. If the task is to be planned with breaks, it is possible to use load profiles (see the respective section).

Example planning with adherence to capacity

• Task A that has a Planned duration of 12 days is moved until enough capacity is available throughout the total duration. The PR Requested end is possible overwritten. Due to the link to TA B, the task becomes delayed:

• Sufficient capacity for scheduling the complete task is only available from the middle of week 43 to week 45, if resource DES-M is not to be overloaded:

Use Cases for Planning Strategies

Premises:

• Active today line, Fix = 0, Planning early, CAP (as far as nothing else is specified)

Description	Adher. to schedule	Adh. to total float	Adher. to capacity
Target	How much overload arises for the employees if the dates are to be adhered to? How much buffer is available?	How much overload arises for employees if the dates are adhered to? How long to tasks last taking account of capacity and requested dates?	How long does a project last with predefined effort and limited capacity (no overload)?
Description of the planning method	Task duration and dates are adhered to. If the task durations are longer than the remaining time horizon, the end date is shifted. Overloads are shown	The project receives a requested end date. The remaining duration of the task is calculated according to the resource effort. Floats are exploited. The overloads are smoothed. End dates are adhered to as far as the remaining time horizon is sufficient for the planned duration of the task.	The duration of a task is determined from Effort Available capacity CAPload profile Option: Planning with max. load/day
Planning	Usually, Planned duration or alternatively Req. start - Req. end are entered (Req. start - Req. end dominates the Planned duration). If no Planned duration has been entered, it is calculated by Req. start - Req. end. Planning without load curves: When inputting the Planned duration of the task, the planned effort of the resource is allocated to the duration evenly. If NO Planned duration of the task is entered, the system calculates the Remaining duration of the task by means of resource effort, CAP load profile and Max. load/day.	Usually, planned duration, or alternatively Requested start - Req. end. If no Planned duration has been entered, it is calculated with Req. start - Req. end. When you enter the Planned duration of the task, the Planned effort of the resource is allocated evenly to the duration. If NO Planned duration of the task is entered, the system calculated the Remaining duration of the task by means of the resource effort, CAP load profile, and Max. load/day Regardless of whether Planned duration has been entered or not, the Remaining duration is extended, as far as the Planned effort cannot be accomplished within the predefined time, or within the available float. The requested date is overrun in consideration of the links if the duration of the tasks is too long.	No input of task duration or TA Req. start/Req. end required. Only input of effort in h for allocated resources. For the parameters, see above.
For tasks with resource assignments:. Extend tasks before MA has reported hours.	In order to extend the task duration in days before hours have been reported, the Planned duration of the task is extended. Alternatively the effort can also be increased if the CAP load profile has been selected. In order to increase the effort, the Planned effort is increased.	Increase of Planned duration, or Planned effort on employee level, provided that the CAP load profile has been selected.	The Planned effort is increased on resource level, provided that the CAP load profile has been selected.
For tasks without resource assignment: Extend tasks without actual start date.	Increase Planned duration on task level.	Increase Planned duration on task level.	Increase Planned duration on task level.
For tasks without resource assignment: Extend tasks with actual start date.	Extend Remaining duration on task level or extend Requested end. New: Remaining duration is calculated regardless of the actual date. Remaining duration = Planned duration – Actual duration , whereas: Actual duration = today - actual date. As before, open tasks remain with 1 remaining day as a reminder.	Extend Remaining duration on task level or extend Requested end. New: Remaining duration is calculated regardless of the actual date. Remaining duration = Planned duration – Actual duration , whereas: Actual duration = today - Actual date. As before, open tasks remain with 1 remaining day as a reminder.

Load

Objective

• Planning a project in the existing capacity situation
• In CS, the Calc. start / Calc. end for which the effort is loaded are calculated. The term 'loading in' means that
  • a load record is created for each day over the Actual duration as well as via the Remaining duration of each resource assignment.
  • the sum of all the loads for each day (the utilization) is stored in the period record, for each PR code and in total, Usually the project number is not stored.
  • the Loaded project data field (Y/N) is set to Y.
• Loading is automatically a component of capacity scheduling. It cannot be opened separately.

Example

• This project is loaded. Calc. start / Calc. end of the task. There are load records for TA 1.

• The project has loaded the DES/M resource as follows:

Objective

• Control the creation of planned load records

Details

• If you do not use planned load records, the data amount can be kept at a low level.
• Via the Deactivate the creation of planned load in the Technical administration System administration System admin. Database Model and model parameters the creation can be controlled.

Procedure

• Open the Schedule Resources module.
• Enter an actual date for the required task of the required resource.
• Save.
• Activate the Deactivate generation of planned load checkbox in the Model and Model Parameters module.
• Save.
• Carry out date scheduling in the Schedule Resources module.
• Reopen the module.
• The planned load records is not displayed for the required task.

Note

• After switching the model parameter from No to Yes, you have to carry out a replanning.
• Planned loads of quit tasks are not created then.
• Possibly available pure planned load records are then deleted.

Loading Sequence

Objective

• To show the sequence in which tasks are loaded, which is applicable to the capacities load of resources

Loading rule

• The sequence in which main projects are loaded is based on:
  • PR Priority for each main project
  • PR Requested end of the main project.
• The sequence of the tasks within a project structure or within a project is based on:
  • TA rank
  • PR priority
  • TA priority
  • Total float (after TS)
  • Planning early = Y
  • Planning early = N

Note

• When efforts are distributed, possibly existing Requested starts and Requested ends of the source resource are transferred to the new resource.
• If the effort is distributed to an already existing TAR, which already has a Requested start and a Requested end, Requested start and Requested end of the target resource are overwritten by Requested start and Requested end of the source resource.
• This behavior cannot be activated or deactivated. Workaround: Subsequently enter the dates manually.
• For further information on this topic, see the Replanning section in this manual.

Calculation of the TA Rank

Rank calculation

• The TA rank is calculated during DS. It is determined by the maximum number of predecessors on any path through the network plan to the task in question. The user does not explicitly see the TA rank value.
  • Rank 0: all tasks which has no predecessors;
  • Rank 1: all tasks with exactly one predecessor on any path;
  • etc.

Example

• Load sequence: A, B, or E, C, D. In the net plan graphic, the rank of the task is identifiable. It corresponds to the column in which the node is displayed.
• Special feature if Planning early =N. Tasks for which Planning early = N is set are given a rank which is modified to its worst possible value, so that during a RS run it will be loaded in later than would normally be the case.

Example

• Task E has been set to Planning early = N. This has the effect of increasing its rank from 2 to 3.

• Load sequence: A, B C, E, D

Special feature for project structures

• If a task has a subproject, and this subproject has the Struc. SCHED = Y project parameter, then all the tasks in the subproject will be given a rank equal to that of the higher-level task plus the rank of the task within the subproject.
• If the task has a successor at the same time, the rank of the latter will at least be equal to the rank of the last task in the subproject +1. This ensures that the subproject will be loaded in before any successor in the main project.

Time Scheduling with SS link and Planning with Adherence to Total Float

Objective

• The duration of a task is extended because of overload, provided that float times are available.

Details

• Planning with adherence to total float
• Two tasks are linked to each other via an SS link.
• Both TA have an FS link to Milestone 1.
• Resources are scheduled with CAP load profile.
• Both tasks are planned with
  • Planned duration 0
  • Remaining duration = Requirement of the effort / Available capacity per day

Information

• The float determined by the date scheduling are used.
  • The durations of the task are automatically increased up to the end of the float period only, in order to avoid this overload. In this example, the duration of the TA 01 task is extended up to Milestone MS 1.

• Date scheduling behavior
  • Task TA 01 does not have a Planned duration.
  • Time scheduling determines the earliest and latest dates.
  • The float is always determined on the basis of the difference between earliest and latest start dates or end dates.
  • The latest start date of TA 01 is determined on the basis of Milestone MS 1 and task TA 02. The links are adhered to.
  • If Requested end and Requested start is deleted by MS 1 (link to TA 02 is maintained), then the Requested end of the project function as a float limit.

Note

• Floats are date floats and are calculated by time scheduling in PLANTA. This means:
  • Time scheduling is run before each capacity scheduling. The dates determined during this run are used for capacity scheduling.
  • Floats are not used in planning with adherence to schedule.
  • When planning with adherence to total float, existing floats are used if necessary.
  • When planning with adherence to capacity, floats and project end date are not considered.
  • The behavior described only applies to planning with adherence to total float and capacity with a load profile that can be optimized by time scheduling, e.g. CAP.

Unload

Objective

• To remove a project from the existing capacity commitments

Information

• Unloading is the opposite of loading in. The resources that have been loaded are approved again.
• When unloading,
  • the load records created by CS are deleted (load records which have been entered manually are retained);
  • the utilization details stored are reduced in the period record.
  • Calc. start / Calc. end is emptied.
  • the Loaded (Y/N) project data field is set to N.
• Unloading is automatically a component of capacity scheduling. However, if a project is to be removed from the capacity planning, it can also be selected separately via the Edit Unload menu items.

Example

• A project is in the offer phase and is loaded in for trial purposes to show the additional loads on the resources involved. Provided that the project is not an actual order, it should then be removed from the capacity planning.

Procedure

• Unload the project (Edit Unload menu item)
• Set the PR status to a value, for example 9, so that in the next replanning run it will not be loaded again (e.g. in the Project Data Sheet module).
• A default project is to be set up. As part of its creation phase, a capacity planning run is also performed, to check whether the project network is correct. After its creation phase, the project is to be unloaded and its PR status to be set to 0.

Replanning

Objective

• To show scheduling of all active projects and completely reorganize the capacity loads

Information

• The Replanning (Calculation of all Projects) module selects all projects of level 0 (main projects) with PR status 1. In this module, the RS procedures calculate the details for all the projects in the sequence indicated by:
  • PR Priority for each main project
  • PR Requested end of the main project.

Procedure for opening the Replanning module

• P41 Project planning Multi-Project Board Replanning (Calculation of all Projects)

Example

Note on planning

• Whether capacity scheduling in a module leads to a complete replanning or not can be set in customizing, using the Other. Parameters module.
• If the field class is filled with 4 and the sub-class with 2, then the button in this module will perform a complete replanning.

Stop

• In these modules, the search criteria must always be set in a way that all active main projects are selected (PR status = 1 and level = 0). Otherwise some of the projects may be omitted from the calculations. This may lead to the utilization diagrams based on total values deviating from the utilization diagrams based on loads, as well as to implausible results from planning with adherence to float or capacity.

Parameters for Capacity Adjustment

Objective

• To explain the other parameters which are important for capacity adjustment

Details

• Apart from the loading method used for the PR, there are yet other parameters which control capacity adjustment.
• In the resource data sheet, the following parameters define whether and how capacity adjustment is carried out for a resource:
  • Adjustment by effort
  • Adjustment by costs
  • Loadability%

Resource Parameter Adjustment by Effort and Adjustment by Costs

Information

• Capacity adjustment can optionally be applied to
  • effort: The available free capacity is compared to the load. This is the normal approach to capacity planning.
  • costs The available free capacity and the load are multiplied by the conversion factors, and only then is smoothing applied.
    • Both parameters are in the resource data sheet
      • Adjustment by effort parameter in window 1
      • Adjustment by cost parameter in window 9.

Example

Details

DI	Name	Description
001243	Adjustment by effort.	Specifies whether a capacity adjustment by effort is carried out for this resource, provided that the other necessary conditions are satisfied.
001528	Adjustment by costs	Specifies whether capacity adjustment with adjustment by cost is to be carried out for this resource, in case the other necessary conditions are satisfied.

Note

• Capacity adjustment is switched off for a resource if both of these data fields (Adjustment by effort, Effort summarization) are set to N.

Load limit % Resource Parameter

Information

• In the Loadability% field in the resource data sheet, it is possible to specify for each resource separately a percentage loading level above which capacity adjustment is to be carried out.

Example

Details

DI	Name	Description
001239	Loadability%	Percentage up to which the resource can be loaded. Capacity adjustment starts at the (Avail. cap.* Loadability%) value Example Loadability% = 120 Capacity adjustment is started starting at a load of 120%, i.e., only then the tasks are moved. Note The Loadability% only takes effect if the Load limit 2 checkbox is activated in the model parameter. otherwise capacity adjustment is always carried out at 100%

Set model parameters

Details

DI	Name	Description
000089	Load limit 2	Specifies whether the value entered in the resource core data under Loadability% is applicable to the capacity adjustment. values The checkbox is activated – the resource ia loaded up to Loadability% as a maximum. The checkbox is deactivated – the resource is loaded up to a maximum of 100%.

Capacity Scheduling after the End of the Scheduling Period

Objective

• To illustrate the scheduling behavior if there are no planning periods for the resource

Details

• If there is no availability for planned resources, 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

Note

• 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.

Planning with Summary Tasks

Attention

• When working with structured schedules, PLANTA recommends that you use summary tasks as structuring elements only, i.e. you should not carry out effort or cost planning, or enter durations on this level. This includes planning resources or reporting directly to the summary task. Instead, PLANTA recommends that you carry out the planning on the subtasks only.
  • Reason: Since the scheduling detects some parameters of the summary tasks, there may be collisions between your own planned values and those detected by the date scheduling. As a result, there may be incomprehensible values on summary tasks.

For further information on summary tasks, see here.

Hammock Tasks

Information on the Hammock task parameter

Consider Load Profiles

Objective

• To control the distribution of loads over the duration of a task

Details

• PLANTA makes a distinction between
  • real load profiles, which distribute loads on a percentage basis.
  • pseudo load profiles which, when they are used, apply a different methodology to calculations.
• Load profiles are specified with the resource assignments, and can be preset as the default value for a resource. Changes of the load profile can be changed manually after they have been assigned to a task.
• As supplied, PPMS includes the following load profiles. New profiles can be defined in the Load Profile module.

Calculation Routine Using Real Load Profiles

Information

• Load profiles are defined in 5% steps. When the loads are calculated by the RS procedures, the value of TA Remaining duration is divided by 20, and for each of the intervals thus generated, the Remaining effort is multiplied by the difference of the load percentage rates for the relevant intervals. This results in the distribution of the load.
• The general rule is: the (task) duration or effort are predetermined, the loads are calculated.

Note

• If, e.g., the E and S load profiles are used, it may occur that the load is distributed over more than one day. If, e.g., the TA Remaining duration is 60, 60 / 20 = 3 load records are generated.

Example

• Each task in the project has a resource assigned to it, in each case with a different Load profiles.

• This produces the following utilization diagrams:
• 3/3

• 5025

• 5075

• GSS

Consideration of actual data for real load profiles

• If the sum of the actual resource load deviates from the planned loads, the DS adjusts the remaining loads to the load profile.

Example

• Starting situation without work reporting

• The Actual effort reported is less than initially planned. The total difference will be loaded on the first day after the work reporting date.

• The Actual effort reported is less than initially planned. in this case, no load will be planned in until the cumulative usage on the original profile is equal to the actual usage so far.

CAP Load Profile

Objectives

• To optimize capacity planning
• To calculate the daily loads
• To calculate the durations when loading in

Information

• The CAP load profile stands for capacity oriented loading..
• PPMS can calculate the daily loads and task duration if the effort is specified. In doing this, account is taken of how much remaining capacity the resource still has available.
• This approach can be used to solve the following problem:
  • The effort for a task is known, and it is required to calculate the duration of the task. In doing so, account is to be taken of the existing loads from tasks which have already been loaded in (including those from other projects), and of the available capacity of the resource.
  • The daily loads are to be carried out in accordance with the availabilities. This may sometimes result in tasks being interrupted by more important tasks, or tasks being shortened if sufficient free capacity is available.

Typical application in practice:

• Person-related planning

Information

• Resource assignment parameters which control the planning:
  • Entry of CAP in the Load profile field
  • Max. load/day data field (optional) The prescribed load is the maximum that will be planned in on any day. This value is used as the starting point for the calculation of the Remaining duration (= Remaining effort / Max. load/day). If no entry has been made, the loads will be planned up to the total remaining capacity. It is also possible to enter a higher load than that defined in the resource data sheet. In this case, this value is used for planning purposes.
  • Max. load/day data field (optional) For each day, a load at least equal to this prescribed value will be planned in. Use of the resource will then only be planned in if it has available capacity for at least the prescribed level of load, or if an overload is unavoidable.
• The CAP planning method is only applied if the resource has Adjustment by effort or Adjustment by cost = Y. Otherwise RS will ignore the "CAP" entry.

Example

• The KON-M resource has 40 hours (= 8hrs/day x 5 employees) of available capacity.. A task which has an effort of 80 hours will, when planned with CAP, have a duration of at least:
  • 2 days, if all employees work on it (Max. load/day = empty)
  • 10 days, if all employees work on it (Max. load/day = 8)

Planning with Adherence to Schedule with CAP

Information

• Planning with adherence to schedule by specifying the TA Planned duration or Max. load/dayTag with optimized task loading.
• If no Planned duration is specified, the TA Remaining duration is calculated from
  • Max. load/day set: TA Remaining duration = TAR Remaining effort / Max. load/day
  • Max. load/day not set: TA Remaining duration = max. (TA Planned duration - TA Actual duration or 1)
• The available capacity is planned for each day, if it is not restricted by a Max. load/day or Min. load/day. The loads on individual days may differ.
• If no Max. load/day has been set, and if it is possible to plan in the total effort within the unused capacity, the Remaining duration may be reduced. This can lead to very high daily loads.
• If it is not possible to plan in the total effort within the available capacity, the overload is distributed equally across all load records to days on which the resource is working.

Note

• Even with due-date oriented planning, the resource-capacity will be optimized within the TA Remaining duration. Practical experience has indicated that by simply setting "CAP" in conjunction with planning with adherence to schedule, overloads can be significantly reduced. This positive effect is found particularly when the deployment of individual employees is being planned.

Example

• The Sample10 project is planned as follows:
  • Parameters: PR Prio = 1, TAR Planned effort with 150h with Load profile = CAP
  • PR Requested start 11/24/08, no PR Requested end, TA Planned duration 25 days, hence float up to the planning horizon.
  • Max. load/day = 4 h results in TA Remaining duration from 150/4 = 37,5, hence 38 days. Due to the low Planned duration, the 150h Planned effort could not be planned within the remaining capacity. They have been distributed evenly and do not cause an overload since there is no Requested end in both TA and PR.

• The utilization diagram for this case is:

• Max. load/day = none results in TA Remaining duration from TA Planned duration. If no Planned duration and no Max. load/day are preset, the total load is loaded on one day. The resource is overloaded.

• The utilization diagram for this case is:

Note

• If the PR or TA has requested end dates or the TA has a planned duration and the resource cannot be planned within this period, the overload is distributed evenly across all load records on the resource’s working days within the specified period, if date-oriented planning is used.

Planning with Adherence to Total Float with CAP

Objective

• Planning with adherence to total float by presetting the TA Planned duration or the Max. load/day with optimized load

Details

• TA Remaining duration is calculated just as with date-oriented planning, but it may be extended up to the end of the total float time or the planning horizon if there is insufficient capacity.
• TA Calc. start is moved to the first day with remaining capacity, provided that its start is yet earlier than the TA Latest start. Otherwise, TA Calc. start = TA Latest start applies.

Example

• The Adherent to total float+CAP project is planned as follows:
  • Parameters: PR Priority = 1, TAR Planned effort with 150h with Load profile = CAP
  • PR Requested start 11/24/08, PR Requested end 01/19/09, as a result float up to this date, TA Planned duration 25 days.
  • Max. load/day = 4 h results in TA Remaining duration of 150/4 = 37,5, hence 38 days. Due to the Project Requested end, the scheduling can extend the task up to the end of the float. (Remaining buffer = number next to the project bar.)
• The task is extended no further than the end of the buffer.

• The utilization diagram for this case is:

• Without a Max. load/day, the resource is scheduled with the maximum load per day specified in DI000804 Def. max. load in the resource data sheet.

• The utilization diagram for this case is:

Note

• If the Planned effort cannot be scheduled within the remaining capacity of the float since the float is too small, the overloads are distributed evenly across the loading-in period.

Planning with Adherence to Schedule with CAP

Information

• The resources are loaded independent of one another, and calculated durations and dates are summarized to the task.

Notes

• If the resources assigned to a task include some with CAP and some without, then the CAP resource assignments take precedence, i.e. the TA duration is determined from the CAP resource assignments. The non-CAP resources are planned on the basis of the calculated TA duration and no resource capacity adjustment is carried out for them.
  • Exceptions:
    • Remaining effort = 0 (CAP is not considered in the calculation of the TA duration)
    • MAN load profile (cf. respective section).
• When planning with adherence to schedule and total float is carried out with CAP, overloads are distributed equally across the resource’s working day on all the load records.

MAN Load Profile

Objective

• To show the new behavior of the MAN load profile.

Details new behavior

• Load records of MAN resources have an effect similar to that of an actual date. The planning data is fixed and is not moved as a result of scheduling.
• Actual dates do not change the MAN planning either.
  • Example:
    • Non-agreement of Calc. start and Actual start
      • MAN planning on 11/04/
      • Actual load, e.g. of a CAP resource on 11/5
      • Result:
        • Calc. start 11/4.
        • Actual start 11/05
• MAN load profile is only set manually and not by the date scheduling.
• Load sequence in scheduling: Actual date, MAN, CAP, TAR Requested start/Requested end, all other load profiles.
• TA Req. start/Req. end are considered as long as the MAN dates are not infringed. In comparison to the MAN period, you can shift the Calc. start of the task forward (= earlier) and the Calc. end backward (= later).
• If planning only uses MAN, the length of the task bar extends from the first to the last plan, even if several resources are assigned to the TA.
• The TA can, e.g., be extended for example by planning with CAP resources. The duration of the task is not reduced by CAP planning. The minimum task duration is the timescale of the MAN dates.
• TAR Requested start/Requested end They are ignored for MAN.
• TA parameter Fix = 1 and deviating MAN period:
  • Example:
    • TA Requested start/Requested end 09/07 - 11/25
    • Fix parameter =1:
    • MAN dates 09/01 - 09/15
    • Result TA Calc. start / Calc. end 09.07. - 09/15
• This does not automatically make the task adherent to schedule as soon as a MAN resource is assigned to it. The TA can be shifted until it reaches MAN dates.
• The Active today line, which can be configured by the administrator via the DI000158 Consider today, does not shift dates planned with MAN.
• Links: take effect until they reach MAN dates. (e.g. for multiple resource planning with MAN and CAP)
  • The impact when one resource is set with MAN and others with different load profiles for Hammock tasks or BLD, is similar to that described above.
    • The dates of the MAN planned resources are not shifted.
• Duration Hammock task or Summary task MAN period
  • Earliest start MAN first date
  • Latest end MAN last date
• In the case of several resources with MAN, the earliest and latest dates of all MAN resources are used to plan the TA.
• Via TA Req. start, the task can only start earlier than the earliest MAN planning.
• As a result of TA Req. end, the task can only start earlier than the latest MAN planning.
• Splitting parameter = Y: The parameter has no effect on MAN resources. For resources not planned with MAN, this parameter has the same effect as before.
• Load records of MAN resources can only be deleted manually.

Details of new behavior for reporting hours

• Planned hours of the MAN load profile that are before the first update report are deleted and not distributed to future loadings.
• Reporting of hours worked with a different value than planned do not affect the other load records.
• Update reports do not change the scheduled hours.
• Hours planned for task resources using the MAN load profile are not shifted by scheduling.

Example task duration

Description	Result
Creation of TA with Planned duration = 0 and RES with MAN load record.	TA stretched from first MAN planning to last MAN planning.

Example TA Requested start is not considered

Description	Result
Creation of TA 02 with Planned duration >0 and Res. with MAN load record. Setting of a TA Requested start before the first MAN load record.	TA Requested start is not considered. Calc. start is the earlier MAN planning.

Example TA starts at TA Requested start

Description	Result
Creation of TA with Planned duration >0 and Res. with MAN load record. Setting of a TA Requested start before the first MAN load record.	TA starts at TA Requested start. The planning of the resource is carried out on the MAN date.

Example behavior for CAP and MAN plannings, part 1

Description	Result
Creation of TA with Planned duration 5T and Res. with CAP and load record. Setting of PR Requested start on 11/03/which is later than the TA Requested start on 06/01/08 DS	TA starts on PR Requested start. The resource planning is carried out on the CAP date of the PR Requested start

Example behavior for CAP and MAN plannings, part 2

Description	Result
Conversion of some resources from the above example to MAN, Retention of a CAP resource. DS	The TA starts at the TA Requested start, not at the PR Requested start. The planning of the CAP resource is carried out at the TA Requested start CAP date, which is to the TA Requested start and not at the PR Requested start. The planning of the MAN resource is carried out on the other dates of its load records.

Note

• As far as no TA Requested start has been set, the task starts at the PR Actual start.

Example TAR Requested start is not considered

Description	Result
Creation of TA with Planned duration >0 and Res. with MAN load record. Setting a TA Requested start before the first MAN load record. Setting of a TAR Requested start on the MAN resource before the first load record but after the TA Requested start.	TA starts at TA Requested start. The planning of the resource is carried out at the MAN date. TAR Requested start is not considered.

Note

• When planning with MAN resources, resource dates override the other planning requirements. This also applies for the project key dates.
• As soon as a MAN resource is assigned to a task, scheduling of the resources is based on the TA requested date and not on the PR requested date. The project basic dates are thus overrun.

Objective

• Specifically preset loads per day.

Procedure

• The user chooses the MAN load profile for the resource and enters the required loads in the Rem. load field in existing load records. This generates a discrete load distribution. It is also possible to set up new load records.
• Appropriate module designs permit loads to be entered in the Gantt chart, directly below the bars. If the load is being displayed in summary form on a less detailed time scale (e.g. by week), then after the values have been input they are automatically distributed across the individual days.

Example

• The weekly loads below the bars or the daily loads below the resource assignments can be edited.

Typical application in practice:

• Free capacity load distribution across the task duration.
• Manual distribution of loads to achieve capacity adjustment.
• Project meetings on fixed dates

Procedure

• The MAN load profile is set manually for the resource.
• Effort is entered in the Rem. effort field in the load record.
• The old value in the Rem. load of the load record is retained and can be changed manually.
• TAR Remaining effort = the sum of the R load values for all the associated load records, i.e. the loads are cumulated upwards. The value of TAR Planned effort is retained for comparison purposes.
• The TA Remaining duration = 0, if an actual end date is set.

Notes

• Date shifts can result in the weekly loads shown under the bar being different from those shown previously. This is because loads are stored to the day, but are only shown to the nearest week.
• For MAN resource assignments, no capacity adjustment is carried out. Such tasks are loaded in on an adherense to schedule.

Objective

• To show the behavior of manually scheduled dates in update reporting.

Details

• Planned hours of the MAN load profile which are earlier than the first hour reported are deleted.
• Reporting of hours worked with a different value than planned do not affect the other load records.
• Planned hours that are earlier than the last reported hours are not distributed to future loadings.
• Update reports do not change the scheduled hours.
• Hours planned for task resources using the MAN load profile are not shifted by scheduling.

Notes on duration changes

• Changes to the TA Planned duration or TA Remaining duration has no mutual influence if there are actual dates. The TA Planned duration is retained (initial value for comparison purposes) and the TA Rem. duration is obtained by calculation. If it is required to change the duration of the task, there are two possibilities:
  • Manual entry of new load records, following on from the existing ones. The next capacity scheduling run calculates a new TA Remaining duration .
  • Empty the Load profile data field, change the TA Planned duration, CS. After this, specify the new loads.

Notes on redoing manual load requirements

• Clear the Load profile field for the resource planned with MAN and run CS.
• Enter a new load profile and run CS.

BLD (Basic Load) Load Profile

Objective

• To carry out resource deployment planning for ancillary activities (basic load, project management, etc.)

Information

• The Basic load (BLD) load profile can be used to distribute loads evenly across the entire float time of a task. In doing this,
  • the daily load can be specified (using Max. load/day) or
  • the daily load can be calculated from the Planned effort.

Typical practical application

• Basic load projects (e.g. 1 hour/day for service activities)
• Project management (e.g. 1 hour/day throughout the duration of the project, or 100 hours distributed across the entire project duration)

Specialties

• If a BLD load profile is assigned to a task and no TA Planned duration is available, the Remaining duration of the task is calculated by the TA Earliest start (= TA Calc. start) up to the TA Latest end (= TA Calc. end).
• A TA Planned duration or TA Remaining duration is taken into consideration.
• If a value is entered in the Max. load/day field, the Remaining effort = Max. load/day * Remaining duration is calculated.
• If a value is entered in the Max. load/day field, the Remaining effort is distributed evenly over the Remaining duration
• Tasks with a BLD resource assignment will always be planned with adherence to the schedule. Capacity adjustment will therefore not be applied to them.
• Resources are not scheduled on their vacation.
• The task can be stretched across the complete product duration if DI 001488 Hammock task has been activated (e.g. for project management or basic load projects).
• A Hammock task can be extended across particular project tasks. For example, the link predecessor can be the Project kick-off milestone and the successor can be the End of planning phase milestone. The hammock task will be stretched between these two tasks if it is connected to both tasks by links.
• The duration of the task and thus the scheduling of BLD resource assignments can possibly be set to the duration of the subproject. This depends on the settings in the model parameters. Depending on the value in the DI000095 Str. sched. w. adjust. system parameter field, the duration of the task may be calculated on the basis of the subproject. More information on this is available in the section on planning with project structures.

Example project management

• For project management, a load of 1 hour/day is planned in over the entire duration of the project. For this, 1 hour is entered in the DI001467 Max. load/day field, and DI 001488 Hammock task is set to Y.

• For project management, 100 hours are planned, distributed evenly over the entire duration of the project. For this, no entry is made in the DI001467 Max. load/day field, and 100 hours are entered in the DI001410 Planned effort field, and DI001488 Hammock task is set to Y.

Example construction planning

• For TA 2110 Design: load-bearing structure, 80 hours are planned over a period of 15 days (planned duration).

• If this TA is to use the complete float time, resource assignment BLD is used and DI001488 Hammock task is set to Y. The task may now last 38 days instead of 10. This means that the task uses up its buffer completely. Scheduling then ignores the Planned duration of 10 days.

• If the predecessor tasks are delayed, the duration of task 2110 will be reduced accordingly.

Example with low load

• VGCH project, MEETING task
• A task has several resources that have a total planned load of 250h.
• The task is always loaded for a week (10/05 - 10/09/08)
• Two other tasks (MGT, DAE) which have a similar structure, are expectedly loaded over a long period.
• Checked:
  • TA Requested start, Requested end : none
  • TA Fix = N
  • The resources are all set to CAP load profile, and are quite overloaded. Suggestion: the overload extends to the end of the periods. Tip: Set Load profile 0 (linear)

Objective

• Task planning for each resource with preset planning values per day

Procedure solution (provided approach for this case of use)

• Planning the task with the _Stretch_`= Y (stretch task = Y)
• Planning of the resources with load profile = BLD

Example PPMS Standard:

• The project is planned with Requested end up to 05/31/09, adherent to capacity
• TA Meeting is a hammock task, resource planning 0,6h/day, BLD load profile

Note on effort oriented planning:

• Without specification of Planned effort, PPMS can only calculate a duration if
  • TA = Hammock task is used
  • BLD load profile in conjunction with
  • specification of the daily load (Max. load/day)
• the duration of the hammock task is determined by
  • PR Requested end or
  • PR Calc. ED, if it is later than PR Requested end
• The duration of the hammock task can also be influenced by connecting it to a successor TA, which has a defined Requested end, e.g. a milestone with Requested end.

• The duration calculation for effort controlled tasks (here TA 02, 03, 04) is carried out with the help of the following parameters:
  • CAP load profile
  • Daily load (Max. load/day)
  • Planned effort or Remaining effort (if the resource has already started to work)
• If there are no other restrictions by dates, successor, etc., the task with the highest effort is calculated first since it has the lowest float.
• For CAP, the TA duration only serves to calculate the „date frame“. I.e. within the calculated duration, the resource is planned where there is availability. If no availability can be found up to the end of the resource calendar, planning is carried out at the earliest possible date after the end of the planning horizon. In the above mentioned example, hence on 06/01/09 (=1 working day after the end of the project)

The WEEK, MONTH, QUARTER, YEAR Load Profiles

Objective

• To show the loading behavior with WEEK load profile

Details

• Only one load record is created per week.

Information

• For planning with WEEK load profile, the date of the first planned load record corresponds to the Calc. start.
• The date of the last planned load record corresponds to the Calc.. end.

Example

Notes

• The new behavior applies to the MONTH, QUARTER, and YEAR load profiles analogously.

Objective

• To speed up the long-term analyses (e.g. utilization diagrams) by reducing the load records

Details

• Optionally, the load records can be summarized to the level of:
  • WEEK (load on Wednesdays only)
  • MONTH (load on the 15th of each month only)
  • QUARTER (load on the 15th of mid month only)
  • YEAR (load on July 15th of a year)
• Definition of the date limits for the start or end of each summary period:
  • WEEK: Monday to Sunday
  • MONTH (load on the 15th of each month only)
  • QUARTER: 01/01 up to 03/31, 04/01 up to 06/31, etc.
  • YEAR: 01/01 up to 12/31
• The date of the last planned load record corresponds to the Calc.. start.
• The date of the last planned load record corresponds to the Calc.. end.

Behavior of the scheduling

• Loading
• The calculation of the load records is carried out to the day.
• Before they are saved, the load records are summarized to the points in time specified above:
  • Loads between TAR Calc. start and summarization start: TAR Calc. start
  • Loads between summarization end and TAR Calc. end: TAR Calc. end
• Unload
• The summarized load records are expanded to the day
• Unload

Example

• A task with a duration of 9 days and a resource assignment which has a WEEK load profile begins on a Thursday and ends a week later on a Tuesday.
• The 1st summarized load record contains the data from Thursday – Friday and has TAR Calc. start (=Thursday of the first week) as a date.
• The 2nd summarized load record contains the data from Monday – Friday and has the Wednesday of the second week as a date
• The 3rd summarized load record contains the data from Monday – Tuesday and has TAR Calc. end (= Tuesday of the 3rd week).
• The number of load records is thus reduced from 9 to 3.

Notes

• There can be inaccuracies in the summarized values as a result of the totaling or disaggregation operations. It is recommended that replanning is carried out cyclically.
• The grid for the analyses (e.g. for utilization diagram) should be equal to, or greater than the summarization time grid; e.g. if the display is shown to the day for a summary on an annual time grid, all loads would appear on 07/15.

"E” Load Profile, Load at the End

Objective

• To show the loading behavior for load profile E.

Details

• The loading is carried out at the task end
• One load record is created for each 20 days of the task duration.

Example

• Example for the distribution of the load to more than 1 load record for E load profile.. For task B, the load is planned for 2 days.

Cause

• Calculation procedure
  • The real load profile work with a time interval with steps in an increment of 5%. Thus in the example of the E profile, one record is created for each 20 days of the task duration.
    • Remaining duration = 21 days/ 20 = 1,05 days
    • 1.05 > 1 ---> PPMS creates 2 load records
    • The load is distributed in accordance with the time interval steps. Therefore, the load of task B with a task duration of 21 days has a load of 4,76 (=100/21) hours and a second load of 95,24 hours.

Linear Load Profile

Objective

• Display of the linear load profile

Details

• The linear load profile allocates the Remaining effort linearly to the remaining Remaining duration of the task.
• Overloads are not adjusted but only identified.
• The linear load is selected if DI 001452 Load profile is empty.

Example

• Remaining duration = 10 days
• Remaining effort 100 hours
• Hence, load 100/10=10 hours per day

Influence Factors of the Capacity Scheduling

Planning early TA parameter

Objective

• To plan tasks in at the earliest or latest possible point

Information

DI	Name	Description
001111	Planning early	Planning early The Planning early task parameter controls whether a task is planned by the CS at the earliest or latest dates. The Planning early checkbox is deactivated by default when creating tasks. Values The checkbox is activated - Planning at the earliest dates: TA Earliest start/Earliest end becomes TA Calc. start / TA Calc. end The checkbox is deactivated – Planning at the latest dates: TA Latest start/Latest end becomes TA Calc. start / TA Calc. end

Typical application in practice:

• Certain tasks are to be planned in at the latest possible time since they tie up a lot of capital, e.g. purchasing, manufacturing. Other tasks are planned in as early as possible, because adherence to their due-dates is less certain, e.g. design. This approach can be used to give the buffer to design activities.

Example

• All tasks with activated Schedule early checkbox

• For task TA 20, the Schedule early checkbox is deactivated. Task TA 30 is automatically displaced to the same extent. The preceding task TA 10 is given the whole buffer. As a result, TA 20 and TA 30 no longer have a buffer and are critical.

Notes

• Successors of tasks with deactivated Schedule early checkbox are moved along.
• The capacity adjustment for tasks with deactivated Schedule early checkbox is carried out reversely, i.e. starting with the TA Latest start / TA Latest end toward the TA Earliest start / TA Earliest end tasks.
• A task with deactivated Schedule early checkbox is scheduled for the latest dates (TA Latest start/TA Latest end). As a result it will be shown as critical ((TA Total float = 0)). It is, however, only on the critical path if at least one link leads into it which has Free total float = 0 (red line).
• If the total throughput time for a project is to be reduced by shortening task times, the tasks to be shortened should be those which lie on the critical path. This will not always be the case for tasks with deactivated Schedule early checkbox which are shown as critical.
• For structure tasks which have a subproject, the Schedule early parameter will be ignored.

How Project and Task Requested Dates Affect CS

Objective

• To show the effects of requested dates for projects or tasks in resource-capacity scheduling.

Information

• The behavior of requested dates for projects and tasks is the same as when carrying out date scheduling.
• Task requested dates prevent capacity adjustment for the respective task if Requested start and/or Requested end are entered on the task. They take priority over the Scheduling early parameter, which means that the task is loaded with adherence to schedule and total float. In the case of planning with adherence to capacity with CAP load profile, the task may be extended if there is an overload.

Typical application in practice:

• Planning a project around a central date (mid-point scheduling).
  • For this purpose, the task which marks a key date is given a TA Requested start and the redecessor tasks are planned as late as possible, and the successor tasks as early as possible.

Example

Frozen Task Requested Dates (Requested start/Requested end)

Objective

• Requested dates are not to be moved when links are set.

Information

• A task requested date without the Fix parameter only has an effect if it is not shifted by links or capacity adjustment.
  • The calculated start and end dates Calc. start and Calc. end of a task are calculated as follows:
  • TA Calc. start = Maximum from the dates retrieved via links and TA Requested start.
  • TA Calc. end = Minimum from the dates retrieved via links and TA Requested end.
• Via the DI009480 Fix data field, you can set for each task how the requested dates are taken into account:

Example

• Tasks TA 10 and TA 20 are connected via an SE (start-end) type link.
• A resource has a Planned effort of 60h.
• Planning with adherence to schedule.
  • Fix parameter = 0: No fixing, the TA can be shifted, e.g. by links or resource adjustment.
    • Task 20 is moved.
    • In both tasks; the date delay on the requested date of task 20 is indicated by red triangles.
    • The resource is scheduled with adherence to capacity on 11 days from 10/29 - 11/11/08.

• Fix = 1: The task is scheduled exactly on the requested date.
  • Links are ignored.
  • Capacity adjustment is deactivated.
  • Only takes effect if at least 1 requested date is set.
  • The TA requested dates are adhered to regardless of the planning type. The task duration corresponds to the specifications caused be the requested dates and is 7 working days.
  • In task 10, the date deviation from the normal date of the link without the Fix parameter is indicated by red triangles There is no delay for the task 20 because scheduling is carried out on exactly the requested dates.
  • The resource is scheduled on his/her working days from 10/20 - 10/24/08 within the task requested dates. If it does not have sufficient capacity, it will be overloaded.

• Fix = 2: no fixing, however date-oriented scheduling of task resources within the TA Planned duration.
  • Links are taken into account, the task may be shifted.
  • Capacity adjustment is deactivated. The task duration corresponds to the Planned duration of 10 days.
  • TAR requested dates outside the task dates have no effect, loading takes place within the task dates.
  • For CAP load profile, the Remaining duration is calculated (Remaining duration = Remaining effort / Max. load/day /Max. load/day).
  • The resource is scheduled on his/her working days from 10/24 - 11/06/08 within the task requested dates. If it does not have sufficient capacity, it will be overloaded.
  • Loading of Max. load/day for the Remaining duration period.
  • If the TA Planned duration = 0, the task duration is determined as the maximum duration of all resource assignments together.
  • In both tasks; the date delay on the requested date of task 20 is indicated by red triangles.

Note

• The Fix parameter does not have any effect if there is not at least one requested task date.

How TAR Requested Dates Affect CS

Objective

• As soon as TAR requested dates have been set, the resources are automatically loaded with adherence to schedule. This takes place regardless of the project planning type or the TAR load profile. There is no load adjustment for overload.
• TAR requested dates are based on top-down planning in scheduling.
  • Scheduling first determines the calculated start and end dates of the task.
    • As far as the TAR requested dates lie within the TA Calc. start and TA Calc. end, they are planned on the TAR requested date with adherence to schedule and are possibly overloaded with each planning type.
    • As far as the TAR requested dates lie outside the TA Calc. start and TA Calc. end, they are loaded with respect to TA Calc. start and TA Calc. end. The TAR requested dates of the resource are ignored.
  • If there is only one TAR Requested start and no Requested end, the resource is not scheduled earlier than the TAR Requested start, provided that the TAR Requested start lies within the calculated start and end dates of the task.
  • If there is only one TAR Requested end and no Requested end, the resource is not scheduled earlier than the TAR Requested start, provided that the TAR Requested end lies within the calculated start and end dates of the task.
• This applies to all TAR requested dates, regardless of the planning type for the project (adherence to schedule, buffer, capacity).

Example

• Setting of TAR requested dates

Notes

• Links may cause tasks to be shifted and fall outside the TAR requested dates. In this case, they are ignored. If you want the resource to be used and Fix on the days in question, you have the following options:
  • Set the Fix parameter for the task and enter the TAR requested dates within the fixed period.
  • Use the MAN load profile for this resource.
• Via the TAR requested dates, it is possible to have resources working on a task at different defined points in time.

Example

• A number of resources work on a task at different points in time.

Planning with TAR Requested Start

Information

• A TAR Requested start only takes effect if it lies just as early or late as the TA Requested start.

Example

• Due to the later TA Requested start TAR Requested start cannot be adhered to..

Example

• Due to the PR Requested start, the task does not start on the TAR Requested start, but instead on the PR Requested start, provided that this is not prevented by other parameters such as links or TA requested dates. As a result of the TAR Requested start lying outside the TA Requested start and TA Requested end, it is not considered by the scheduling.

Information

• If more than one resource is planned, TA Remaining duration applies to all tasks without TAR requested start. Resources that have a Requested start, receive a shortened duration from TA duration– (TAR Requested start – TA Earliest start).
• If the resource has a Remaining effort and a Max. load/day, the Remaining duration of this resource is calculated from Remaining effort / Max. load/day. If the Remaining effort = 0, at least a Remaining duration of 1 applies.
• If the Schedule early is activated for the task and a resource has a remaining TAR Requested start within the TA Calc. start/TA Calc. end, this resource starts on this date, while all others start at the TA Earliest start. The plan for the task will automatically be adherence to schedule.

Example

• As a result of the TAR Requested start, resource R1 has a reduced scheduling duration of 2 days. The effort for 16 hours will be distributed across the two days and the resource is overloaded. For resource R4, scheduling is distributed over three days without overload.

• If the task is scheduled with Sched. early and with adherence to schedule, the TA Requested start will be ignored.

Example

• Since the task is scheduled late and adherent to schedule, TAR Requested start is ignored. The resource is scheduled on three days.

• If the task is adherent to total float or capacity and scheduled lately, a resource with a TAR Requested start is only adjusted up to this date; while all others are adjusted as before at the TA Earliest start.

Example

• Although resource R1 is overloaded, the adjustment of the resource is not carried out at the PR Requested start, but only up to the TAR Requested start.

• If a task has started, the resource which has a TAR Requested start will start on this date; while all others have the same start as before. For splitting, the maximum of TAR Requested start and link date is applicable to the Earliest start.

Example

• Resource R1 has a TA Actual start on 10/16/08, but only starts with the remaining loading at the TAR Requested start. This is determined by parameter DI001112 Split. = Y in window 9. This only takes effect if the task has started but not yet ended.
• Resource R8 starts, as before, at the ‘today’ line.

Planning with TAR Requested End

Information

• If only one resources is assigned, the task ends (TA Earliest end) on the TAR Requested end if date-oriented planning is used, provided that there is no overload and the TAR dates are within the TA dates. Otherwise, TA duration = Planned effort / Max. load/day. For example, in loading with adherence to capacity, the TA is also extended.
• If more than one resource is planned, the task duration applies; the resource with a TAR Requested end receives a shortened duration of TA Remaining duration – (TA Earliest end – TAR Requested end).
• If the resource has a TAR Requested end, it ends on this date if date-oriented planning is used; all others end on the TA Earliest end.
• If Sched. late is set for the task, it automatically becomes adherent to schedule if a TAR Requested end has been assigned.
• If the task is adherent to float or capacity, and Schedule early is set, then any resource with a TAR Requested end will be smoothed up to this date. All others are adjusted at the TA Latest start + TA Remaining duration.

Planning with TAR Requested Start and TAR Requested End

Information

• If the resource has a TAR Requested start and a TAR Requested end and no Max. load/day, in planning with adherence to schedule the duration is detected from the requested dates.
• For loading with adherence to capacity, the TA is also extended.

Notes

• TAR requested dates are only considered by the scheduling if they lie within the TA requested dates. If the TAR requested date is outside the TA requested dates, it has no effect on scheduling, as planning does not lead to the desired aim at this point in time. This also applies if a task is shifted, for example as a result of a link, so that the TAR requested dates do not lie within the TA Calk. start/TA Calc. end.
• If no TA requested dates exist, TAR requested dates are only considered within the TA Calkc start/TA Calc. end.

Example 1

• TA Requested start 06/01/08 TA Requested end 08/31/08
• TAR Requested start 09/10/08, TAR Requested end 09/15/08
• Result: TAR requested dates are ignored.

Example 2

• A link shifts the above-mentioned task as follows:
  • TA Requested start 09/051/08 TA Requested end 10/5/2008
  • The TAR requested dates remain unchanged:
  • TAR Requested start 09/10/08, TAR Requested end 09/15/08
• Result:
  • The previous planning of the TAR requested dates are ignored.
  • Planning of the TAR does not have to be done from 09/10 - 09/15/08.

The Effect of Actual Dates on CS

Objective

• To show how actual dates affect the update of the plan

Information

• Actual dates reported to tasks or resource assignments are taken into account by the CS routines. They take precedence over the links, requested dates and any instruction to schedule early/late.

Typical application in practice:

• Input or calculation of the actual dates. Actual dates can be input for either tasks or resource assignments. They are taken into account by the CS as follows:
  • Reporting in the task
  • No resources have been assigned.
  • TA Actual start and TA Actual end are entered automatically.
  • Resources have been assigned
• Input TA Actual start.
  • If no resource assignment possesses a TAR Actual start, the TA Actual start is copied to all TAR Actual start. If at least one TAR Actual start exists, the TA Actual start is not copied to any resource assignment, but the TA Actual start results from the earliest TAR Actual start.
• Input TA Actual end.
  • The input is overwritten by the CS. The update report must be entered against the resource assignment.
• Reporting in the resource assignment
  • Input TAR Actual start. The TA Actual start results from the earliest TAR Actual start. If there is already an earlier TA Actual start, it will be retained.
  • Input TAR Actual end. The latest TAR Actual end is copied to the TA Actual end if all resource assignments possess a TAR Actual end. I.e. the task is finished when all the resource assignments are finished.

Examples

• For TA 1, a TA Actual start has been entered. It is copied to all TAR Actual start fields.

• The two resource assignments have different Actual end dates. The latest TAR Actual end is reported to the task.

• Calculation or input of the TA Remaining duration

Help text of the data item

DI	Name	Description
001133	Remaining duration	Remaining duration of the task in working days Calculation TA:: General: If no TA Actual start is set: TA Remaining duration = TA Planned duration If TA Actual start is set: TA Remaining duration = TA Remaining duration – Change of the TA Actual duration If TA Actual end is set: TA Remaining duration = 0 If TA possesses a subproject and the model parameters are set accordingly: TA Remaining duration = TA Remaining duration/Stru Note Input takes priority over calculation (this does not apply to tasks with subprojects).

Notes

• For tasks with TA Actual start or TA Actual end, no capacity adjustment is carried out. If it is necessary to apply smoothing to the rest of the task, it must be split.
  • This is carried out via DI001112 Split, which is set to Y.
  • The DI001112 Split field is in window 9 and is preset with Y in the standard PPMS system.
• A task has Remaining duration = 1, although nomore Remaining effort exists. In PPMS, a task is not finished until an Actual endhas been set. This can be effected either by entering the TAR Actual end , or by the hours recording routine (compl. = Y). DS copies the end dates to the TA Actual end. As long as no TA Actual end has been set, the task is at least planned with Remaining duration = 1.
• After a TA Actual start has been set, changes to the planned effort does not affect scheduling. Changes that affect the system are made by changing the input in the Remaining effort field.

Example

• The reporting of actual dates to the task is to be undone. E.g. TA Actual start or TA Actual end are emptied automatically. However, after SCHEDuling the data fields will again contain values.

Remedy

• The DS processes actual data from the bottom upwards. If a TAR Actual start or TAR Actual end has been entered, the date is summarized to TA Actual start and TA Actual end.
  • Empty the TAR Actual start, TAR Actual end, and possibly also TAR Actual effort data fields on the resource assignment
  • Execution of a CS.

Notes

• If incorrect reportings of actual hours worked have already been applied to the project by the scheduling, they can be removed again as follows:
  • Deletion of the actual hours record
  • Empty the TAR Actual effort, TAR Actual start, TAR Actual end, TA Actual start, TA Actual end of the respective resource
  • Scheduling
• The task then no longer has any actual dates and the actual hours are empty.

Example

• If a TA Actual end is set, it will be cleared again by DS if not all of the resource assignments have been reported in full.

Remedy

• Enter the actual end date into the data field TAR Actual end in the resource assignment record, and then carry out RS.

Scheduling for update reports with Compl. flag

Information

• Scheduling calculates the TAR Actual end from the maximum TAR update reports if
  • all TA resources in the schedule have a Actual end

• The Compl. flag has been set to Y in at least one record of the TAR reports. This code can be made available, e.g. in the Employee Board, by customer-specific customizing.
• The TA Actual end is calculated from the maximum of the corresponding TAR Actual end.
• If changes are made to the Actual end, scheduling recalculates the report date. This date is determined from the maximum of Actual start and the last reports of the resource assignments.

Calculation of the report, start, and end dates

Note

• If you want to prevent the TA Actual end from being shifted by reportings, you can make customizing settings to prevent the reporter from being able to set the Compl. flag to Y.

Actual Effort and Actual Loads During CS

Objective

• To show how actual effort affect the scheduling calculations

Note

• Actual effort can be entered in the resource assignment or load records, if these fields are made ready for input through customizing settings. When the reporting of hours worked is entered into the load records, the entries in the resource assignments are overwritten.
• CS considers actual effort and actual loads as follows:
  • A TA resource Actual effort sets the TAR Actual start to the date for which the reporting was made, in case there is no earlier reporting date for this task. This means that there is never an actual effort without an actual start date.
  • The date of the last reporting of hours worked is stored in the TAR Load reporting date field (= date of reporting).
  • If a Actual load is entered on a load record, the TAR Actual effort results from the sum of all Actual load.
  • Changes in the reporting dates can be used to alter the distribution of actual effort.

Calculation/Input of the Remaining Effort (TAR Remaining Effort)

Details

DI	Name	Description
001423	Remaining effort	Remaining effort of the resource assignment (in units of the resource) Calculation TR: Behavior when the posting resource is assigned to the task. If no TAR Actual start exists: TAR Remaining effort = TAR Remaining effort planned when TAR Actual start and no TAR Actual end exists: TAR Remaining effort = TAR Remaining effort – Changes to TAR Actual effort When TAR Actual end exists: TAR Remaining effort = 0 For MAN load profile, the following applies: TAR Remaining effort = sum of the remaining loads Notes TAR Remaining effort can be changed manually, if you take note that, e.g., more (or less) hours are required, after you have already reported actual hours. Depending on the cases described above, the value can be overwritten by DS. The behavior of the Remaining effort calculation with parent resources is described further below. For this purpose, see also the Practical application 1 section

• If the report results in the creation of a new resource assignment (e.g. as a result of entering hours worked), the TAR Remaining effort is calculated for the existing resource assignments in the following way:

	Requirement	Behavior TAR Remaining effort
1	Task did not have a resource assignment before	No reduction
2	The load record has entered a different resource in the Work for resource field, which is also assigned to the same task.	Reduction for the resource which is in TAR Remaining effort
3	Reporting resource = planned in resource	Values Remaining effort > 0 - reduction up to a minimum of 0. Remaining effort = 0 - case 4 analogously
4	End of work reporting resource ≠ planned resource: A resource is assigned to the task, which is located above the reporting resource in the resource structure.	Values Yes - Reduction for parent resource No - No reduction
5	Resource assignment which does not correspond to any of the rules 1-4	No reduction

Notes

• CS applies these rules in the sequence specified above..
• Using this procedure, it is possible to report hours employee-related, regardless of whether planning is carried out with adherence to department or employee. The Work for res. field is used to define which remaining effort is to be reduced if there is any uncertainty.

Example

• Resource R1 has reported 8 actual hours to Task 10. Up to this point, the higher level resource (IT) was assigned to the task. The reporting of hours worked now automatically causes resource R1 to be assigned to the task.
• After CS of the project, the TAR Actual effort is visible for resource R1. The TAR Remaining effort for the IT resource has been reduced to 42, because in the resource structure, R1 blongs to IT.

Practical application 1

• Service orders are scheduled with adherence to department.
• Employees in the department post hours, which reduces the remaining effort .
• If employees from other departments post to the task, contrary to planning, this is regarded as unplanned additional effort, which should not reduce the remaining effort budget of the task.

Examples

• Case 1:
  • The effort is planned for the department.
  • Employees of the department report hours, the remaining effort of the department is reduced in accordance with these reported hours.
  • Corrections to actual effort lead to the remaining effort being adjusted accordingly.
    • Posted actual hours reduce the remaining effort of the resources or parent resource.
    • Corrections that reduce the actual hours increase the Remaining effort following the same logic.
    • If Remaining effort = 0 is reached, no further changes are made to remaining effort.
• Case 2:
  • Hours are reported by employees who do not belong to the department for which the task is planned and who are not assigned to the task.
  • The system regards this as unplanned additional effort for this task. The total effort is increased accordingly.
  • The remaining effort is not changed. The sam applies if corrections are made to the postings of this resource.

Practical application 2

• costing/booking corrections to the entry of hours worked
• Load records which have been created manually with no entry for Actual load, Expenses, or CM will be deleted by DS. If a load record has no entry for Actual load but does have one for Expenses or CM, it will be treated as an actual load record, i.e. its TAR Actual start will also be set.

Notes

• You are advised to reduce the required hours on incorrect load records manually, if working with cancelation postings is not required in this area. This can also be done by entering the value 0 if the posting was made to the task by mistake. In these cases, scheduling corrects the data, e.g. the Remaining effort
• If the posting record is physically deleted manually by the user, scheduling has no point of reference for correcting the effort data. If the record is manually deleted, therefore, the data may need to be manually corrected by the user.

Cancellation of Load Postings

Objective

• To show the cancellation of load records that are formed as a result of effort being reported by resources

Procedure

• For the procedure, see here.

Split Task Parameter

Objective

• To interrupt (split) tasks which are being edited

Information

• Any task which have started already will be loaded with adherence to schedule, starting from TA Actual start. However, if you do not want to continue to work on the task without interruption, the task may be split.
• The effect of this is that the remainder of the task (Remaining duration, Remaining effort) will be planned as if no actual data had been reported. It is thus also possible to carry out capacity adjustment for the residual task.
• This is made possible by the DI001112 Split = Y parameter.
• In the standard PPMS system, the parameter is in window 9 and is preset with Y.
• It only takes effect if the task has started but has not yet ended.

Help text of the data item

DI	Name	Name
001112	Split	Split Started tasks can be splitted. Splitting only has any effect on tasks which have been started (TA Actual start reported), but not yet ended (no TA Actual ED reported). Werte The checkbox is activated: The task will be scheduled as if it had no TA Actual start. The Remaining duration is calculated. It represents an interruption in a task. The loading of Actual effort is carried out up to the work reporting date. The checkbox is deactivated: The task will be edited from „today“ for the Remaining duration, regardless of any links. For today line = N, the task is edited from the reporting date for the Remaining duration. Note For tasks with subprojects, the split does not take effect.

Typical application in practice:

• A project team member has reported a couple of hours on the Design task using work reporting. However, these activities are only to allow some provisional orders to be placed for long lead-time components of assemblies, and the actual design work will not be carried out until later.

Example

• Task before work reporting:

• Resource R1 has reported 5 hours of work to the Design task. The task is not split. After RS, the following diagram is produced:

• Work on this task is not to be continued, but planned in for a later time. By setting Split = checkmark (Y), the rest of the task is planned according to the network plan. It is also moved by requested dates.

• If the project planning type is changed, e.g. from adherent to schedule or float, and, e.g. the CAP load profile is assigned to the a task, then the remainder of the task may be planned in at an even later date.

Notes

• Split only has an effect on started tasks (TA Actual start set). Tasks which have been finished, or not yet started, are unaffected by it. It can make sense to set Split = Selected (Y) for certain tasks, even at the planning stage, if it is known that these tasks are usually interrupted.
• The default scheduling in standard PPMS is Split = Y.
• If capacity adjustment is to be carried out for a started task, Split = checkmark (Y) must be set.
• If, at a later time, a splitted task is to be continually worked on, split can be reset to "N".

PR Split Project Parameter

Objective

• To interrupt (split) complete projects

Information

• Via the Split parameter you can split entire projects. If Split = Y is set, then all the tasks in this project will be handled as if they were split.

Help text of the data item

DI	Name	Name
002833	PR Split	Project Split Serves to split individual projects. Values Y: The project is to be splitted. All tasks of this project are treated as splitted tasks in DS. The project is not to be splitted. The task splitting can, however, be set on the tasks individually. Notes The project splitting takes priority over the task splitting. For PR structures, a shift (splitting) of the entire project structure can be carried out easily via the PR WAT (if later than PR IAT) on main project level and PR splitting on sub project level .

Note

• The PR split is to be preset individually for subprojects.

Example

• If there is an earlier work reporting and the PR Requested start 08/02/08 with PR Split = Y, the effect is that the project will be interrupted and then resumed on 08/02/08.

Dominance Rules for the Task Parameters

Information

• The task parameters described above have the following order of dominance when they are applied in the CS routines:
  • TA actual dates (TA Actual start / TA Actual end)
  • TA requested dates (TA Requested start / TA Requested end) with Fix parameter = 1 (DI009480)
  • links
  • TA requested dates (TA Requested start / TA Requested end) with Fix parameter = 0 (DI009480)
  • Planning early = N
  • Capacity adjustment

Example	Reason
Ta actual dates overwrite preset links	In practice, things often do not work out exactly as planned. Actual dates which have been input should be taken into account in subsequent plans.
TA requested dates overwrite 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 or actual dates may prevent this if the Fix parameter = 0 is set.

Calculation RMT for work = N

Objective

• To illustrate the behavior for update reports during vacation.

Information

• If a resource has reported hours worked for periods which he/she has set as vacation, Work = N is ignored to detect the reporting date.
• The date of the most recent work reporting of the TAR is applied as work reporting date if Work = N is entered for this resource.

How Calendars Affect Scheduling

Information

• This section deals with planning with with several calendars and the effect the different calendars have on scheduling.
• PPMS supports working with several calendars.
• Only users with technical administrator rights (in standard: roleP20) can create and maintain calendars. The procedure is described in the „Technical Administration“ manual.

Details

• Basic calendar
  • Basic calendars contain information on non-working days and working days. Several basic calendars, for example those showing different public holidays in different countries, can be managed in PPMS.
• Company calendar
  • A particular basic calendar can be defined as the company calendar. This is used as standard for scheduling when no other calendar is specified.
• project calendar,
  • A specific project calendar can be assigned to the project via DI001016 PR calendar. This takes precedence over the company calendar for the project in question. The DI001016 PR Cal. field from DT461 can be made available in the modules through customer-specific customizing.
• Task calendar
  • The calendars defined in PPMS can also be assigned to tasks. This prevents loading in for tasks in other countries that start on local public holidays. For this, field DI000269 TA calendar must be dragged from window 9 to window 1 or 2, and the relevant calendar must be selected.
• Link calendar
  • An individual calendar can be assigned to a link. This is taken into consideration when calculating the interval for subsequent dates.
• Resource calendar
  • A resource can be assigned to an arbitrary basic calendar. The working days and non-working days of this calendar are copied to the resource calendar. The resource calendar can be individually adapted by entering vacation and absence. The required basic calender is assigned to the resource in the resource data sheet in the DI001229 Calender.

Notes

• If the Calendar field is active field is activated in the resource data sheet, the working days of the resource are determined on the basis of the resource calendar.
• If it is not activated, the working days are determined from the company, project, or task calendar. The vacation days entered for the resource, for example, are not taken into consideration.
• The entry (checkmark or no checkmark) in the DI001364 Work checkbox defines whether a resource can be planned in by the scheduling on the appropriate day. This entry has priority over the task or project calendar. DI001364 Work receives its entries from the assigned basic calendar.

• Scheduling takes the non-working days into account individually for each resource, even if several resources with different non-working days are assigned to one task.
• If the DI001241 Calendar is active resource parameter is set, scheduling does not plan any load on non-working days.
• Which calendar is used for planning a task depends on the following factors:
  • A valid calendar has been entered in the TA calendar field in the task. This calendar will apply for the task regardless of whether or not resources have been assigned. This calendar can be any of the basic calendars that were created.
  • When no task calendar has been entered for the task, and
    • No resources have been assigned. The project calendar is applied, or if this has not been defined for the project, the company calendar applies. Customizing settings can be made to make the project calendar available in the relevant modules.
    • A resource has been assigned with
      • activated Calendar is active checkbox. The resource calendar will apply to the
      • deactivated Calendar is active checkbox. The project calendar will apply.
    • several resources have been assigned and
      • exactly one resource has the activated Calendar is active checkbox. The resource calendar will apply.
      • several resources have the activated Calendar is active checkbox. The relevant resource calendar will apply.
  • Interaction between task calendar and resource calendar:
    • The task calendar applies to the task, the resource calendar to the resource. If the Planned duration is 10 working days and the task calendar has defined five normal working days in this period as non-working days, the task will need three weeks.
    • A resource to which a standard calendar is assigned will complete task processing in two weeks. This is the case regardless of whether the task has scheduled three weeks because of the non-working days.
    • If you do not want the resource to work on the five non-working days of the task, you have the following options:
      • The task calendar is assigned to the resource. As a result, he/she will not work on this or any other task on the above mentioned non-working days of the task.
      • Assignment of the MAN load profile and manual definition of the working days. Date scheduling does not carry out optimization for this TA in this period.
      • Setting of TAR Requested start and Requested end.

Notes

• The general rule is: If no project calendar has been entered for the project, then the company calendar set by the model parameters will be used as the project calendar.
• Effect of the calendar on scheduled start and end dates
  • A TA requested date on a non-working day is not shifted to the next working day.
  • if a calculated start or end date of a resource falls on a non-working day, it will be 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; the RS calculations will not produce any load on the capacity on such a day.
  • Resources are not scheduled on their non-working days.
  • Start and end dates that have been input:
    • 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.
• links
  • If there is no value entered in the Link calendar data field, the calendar of the project applies to the date detection of the link of the calendar of the project.
  • For the calculation of the time interval between two tasks, the
    • earliest dates of the predecessor of the calendar of the task are applicable.
    • latest dates of the successor of the calendar of the succesor are applicable.

Note

• Changes to the basic calendar do not take effect until PPMS is restarted. Replanning is recommends after changes are made to calendars.

Example

• Task 1001-01 with a duration of 12 working days is extended because of a public holiday which the resource has defined as a non-working day in its calendar and because of two weekends, i.e. the TA Calc. end is later:

• If a resource with CAP load profile is assigned to a task, which works on the holiday (10/30/08), TA Calc. end may be earlier if the resource planning permits it.
• In the calendar for this resource, the holiday on 10/05/07 is a working day (Work checkbox is activated).

Note

• For resources with other load profiles, e.g. linear load, the task is not shortened.

Link Calendar

Objective

• To use individual calendars for calculating subsequent dates

Information

• An individual calendar can be assigned to a link. This is taken into consideration when calculating subsequent dates.

Application procedure

• Enter the calendar you have created priorly in the DI007348 Link calendar data field. The Link calendar field is hidden in PLANTA project Standard (Window 9).

Application example:

• 7 working days are estimated for shipping a turbine. You therefore enter a time interval of 7 days in the link. However, if no link calendar is used, the successor starts 7 working days later, not 7 calendar days. The task is therefore scheduled with a delay.

• If you use a calendar without work-free days as a Link calendar, the task is scheduled as desired.

Overview of selected application cases:

• Note: Due to the large number of cases with links, only few can be represented here.

Application case	Procedure	Result
A task with successor, end-start = 0	Create 2 tasks, with link, with FS = 0	Successor starts on the next working day, provided that its duration is at least one day.
A task with successor end-start = 0 Task and successor task = TA calendar with working days Mo-Fr Link calendar = 7 days week	Create tasks, with link, with FS = 0 Set „7 days week“ link calendar	Successor automatically starts on the next working day, provided that its duration is at least one day Link calendar has no effect since the link itself has no duration.
A task with successor end-start = 15 Task and successor task = TA calendar with working days Mo-Fr Link calendar = 7 days week	Create tasks with link with FS = 15 Set „7 days week“ link calendar	Successor starts after 15 calendar days. Link calendar takes effect

Note

Date Scheduling Use Cases

Linear Planning with Planned Duration and Resources

Principle of linear planning

• Planned duration requirement
• Load profiles not used, i.e. the load is distributed evenly over the available period without overloads being taken into consideration. Resources are not loaded in on non-working days (public holidays, vacations, ...).
• Where possible, resources are loaded in as a block (in one go).

Overview

Application case	Procedure	Result
Planned duration is specified Planning with resources Linear planning without load profiles Planning type: adher. to schedule	Create project/TA with several TAR Planning type = 0 (adher. to schedule)	Planning along the duration without considering Overloads. Where possible, scheduling is carried out as a block, i.e. without interruption. Exception: Vacation: The resource is not planned during vacation.
As above, but planning type: Adh. to total float, i.e. as early as possible, but exploitation of float times for reduction of overloads	Create project/TA with multiple TAR Planning type = 1 (adh. to total float)	The planning is carried out along the duration without considering overloads, but with exploitation of float per resource that is overloaded. If there are still hours to be planned but the float is exhausted, the planning is carried out at the next possible date. The project requested end date is not overrun.
As above, but planning type: adher. to capacity	Create project/TA with multiple TAR Planning type = 2 (adher. to capacity) possibly remove entry in load curve	Standard: scheduling without consideration of requested durations and requested project end dates, no overloads, no scheduling on non-available days. Exception: If PPMS does not find any available capacity up to the end of the planning period for the resource, loading is also done at the earliest point with overload (like adherence to schedule).

Note:

• Overload and availability for planning with adherence to capacity:
  • If PLANTA project cannot find any available capacity by the end of the planning period of the resource, loading is carried out as early as possible, even if there is an overload.
• Resource on vacation for the complete duration of the task:
  • Scheduling is carried out with the respective overload on the first day of vacation, if the whole task falls within the resource’s vacation period.

Example: overload in planning with adherence to capacity without resource vacation

• Planned duration = 10 days
• Planned effort = 100h
• available resource cap. per day = 8h
• the requirement cannot be fulfilled at any time. The resource is overloaded evenly.

Plan with Requested Dates of the Resource

Rule

• Resource requested dates must always be within the requested or calculated dates of the task.
• Requested dates set on task level:
  • TAR Requested start TA Requested start or TA Calc. start
  • TAR Requested end TA Requested end or TA Calc. end
• Requested dates not set on task level:
  • TAR Requested start TA Calc. start
  • TAR Requested end TA Calc. end
• Requested dates not set at task level and resource requested dates outside the calculated TA dates
  • ignored

Overview

• Planning with adherence to schedule with linear load profile

Application case	Procedure	Result
Plan resource without dates	Assign resource to task Enter effort Calculate project	TAR Calc. start = TA Calc. start TAR Calc. end / TA Calc. end Resource duration = task duration
Plan resource with Requested start	Assign resource to task and enter effort Enter start date in Requested start of the resource (TAR Requested start) Calculate project	TAR Calc. start = TAR requested start TAR Calc. end = TAR Calc. start + duration Note The planning time of the resource is possibly shorter than the length of the task.
Plan resource with Requested end	Assign resource to task and enter effort Enter end date in Requested end of the resource (TAR Requested end) Calculate project	TAR Calc. start = TAR Calc. end – duration TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task.
Plan resource with TAR Requested end	Assign resource to task and enter effort Enter end date in Requested end of the resource (TAR Requested end) Calculate project	TAR Calc. start = TAR Calc. end – duration TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task.
Plan resource from .... to ....	Assign resource to task and enter effort Enter start or end date in resources (TAR Requested start/Requested end) Consider task date limits Calculate project	TAR Calc. start = TAR requested start TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task.

• Planning with adherence to total float

Application case	Procedure	Result
Plan resource without dates	Assign resource to task Enter effort Calculate project	TAR Calc. start = TA Calc. start TAR Calc. end / TA Calc. end Resource duration = Task duration If float is required, the task duration or the planning period of the resource can be extended.
Plan resource with Requested start	Assign resource to task and enter effort Enter start date in resources (TAR Requested start Calculate project	TAR Calc. start = TAR requested start TAR Calc. end = TAR Calc. start + duration Note The planning time of the resource is possibly shorter than the length of the task. If float is required, the task duration or the resource load can be extended backward.
Plan resource with TAR Requested end	Assign resource to task and enter effort Enter end date in resources (TAR Requested end) Calculate project	TAR Calc. start = TAR Calc. end – duration TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task. If float is required, the task duration or the resource load can be extended forward.
Plan resource from .... to ....	Assign resource to task and enter effort Enter start or end date in resources (TAR Requested start/Requested end) Consider task date limits Calculate project	TAR Calc. start = TAR requested start TAR Calc. end of the resource = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task. no float exploitation by the resource within the task period.

• Planning with adherence to capacity

Application case	Procedure	Result
Plan resource without dates	Assign resource to task Enter effort Calculate project	TAR Calc. start = TA Calc. start TAR Calc. end = TA Calc. end Note Planning time of the resource = task duration If float is required, the task duration or the planning time of the resource can be extended.
Plan resource with Requested start	Assign resource to task and enter effort Enter start date in resources (TAR Requested start) within the calculated start and end dates of the task. Calculate project	TAR Calc. start = TAR requested start TAR Calc. end = TAR Calc. start + duration Note The planning time of the resource is possibly shorter than the length of the task. End dates are possibly not considered.
Plan resource with Requested end	Assign resource to task and enter effort Enter end date in resources (TAR Requested end) within the calculated start and end dates of the task. Calculate project	TAR Calc. start = TAR Calc. end – duration TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task. Start dates are not considered.
Plan resource from .... to ....	Assign resource to task and enter effort Enter start or end date in resources (TAR Requested start/Requested end) Consider task date limits Calculate project	TAR Calc. start = TAR requested start TAR Calc. end = TAR Requested end Note The planning time of the resource is possibly shorter than the length of the task. Float is used if necessary. End date is not considered.

Effort-Oriented Planning

Objective

• To plan commitments for employees, depending on the effort.

Requirements:

• Planning with adherence to schedule:
  • Field Load profile = CAP
  • Max.load/day field is filled with a value > 0
  • Resource assignment with planned hours
• Planning with adherence to total buffer and capacity:
  • Field Load profile = CAP
  • Resource assignment with planned hours
  • Optional: Field is filled with a value > 0

Details

• The Remaining duration is calculated
• Planning with adherence to schedule:
  • Remaining duration = planned hours / max. load
  • The effort (planned hours) is distributed across the calculated duration
• Planning with adherence to total float
  • The Remaining duration is dependent on the available capacity of the basic period (value from resource data sheet) and on the available float of the time scheduling.
  • The effort (planned hours) is distributed across the calculated duration
• Planning with adherence to capacity:
  • The Remaining duration is dependent on the available capacity of the basic period (value from the resource data sheet). Loading in takes place without overloads.
  • The effort (planned hours) is distributed across the calculated duration

Note

• Optionally, the Max. load/day parameter may also be used for planning with adherence to total float and capacity. The Remaining duration will be calculated as for planning with adherence to schedule.

Example: Planning with adherence to schedule

• Max. load/day = 5.5 hours
• Planned hours = 60 hours
• Remaining duration = 60 / 5,5 = 10,9 days, rounded = 11 days since calculation only works with whole days.
• Distribution of hours: 10 days @ 5.5 hours, 1 day @ 5 hours

Example: Planning with adherence to total float

• Max. load/day = empty
• Planned hours = 60 hours
• available capacity of the basic period = 8 hours – 10% base load = 7.2 hours
• Remaining duration = 60 / 7,2 = 8,3 days, rounded = 9 days since calculation only works with whole days. If the resource is overloaded, the remaining duration will be extended up to the point where the overload no longer occurs
• Distribution of hours:
• without overload: 8 days @ 7.2 hours, 1 day @ 2.4 hours
• with overload: dependent on the Remaining duration. Cannot be determined in advance because of capacity adjustment.

Frequently Asked Questions on Capacity Scheduling

The Effect of Capacity Adjustment on Other Projects

Information

• If the impact on other projects is to be considered in the capacity adjustment, then all affected projects which have a lower priority than the one of interest must be included in the calculations. The replanning procedures (see section concerned) do this automatically.

Capacity Adjustment Appears to be Incorrect

FAQ - Question/Answer

• If in a capacity adjustment, adjustment appears to be carried out incorrectly, or if there is still utilization in utilization, the reason is often merely a presentational problem since PPMS plans to the day and the utilization diagrams are often only regarded to the week.
  • Remedy: view the utilization diagrams in daily format.
• If the effort specified for a task is so high that it cannot be planned in any period, then the Adjustment limit parameter comes into effect.

Help text of the data item

DI	Name	Name
000088	Adjustment limit	Specifies whether the capacity adjustment of the capacity adjustment takes place within the capacity periods created by the user (= planning horizons), or whether it is shifted beyond that period further in the future. This only applies if the task cannot be loaded within the planning horizon. Values Y: The task will be planned within the planning horizon, even if this creates an overload. N: The task will be moved to the end of the planning horizon and planned at that point.

Changes to the Resource Data Sheet

FAQ - Question/Answer

• Changes to the Resource Data Sheet have no impact on the work periods, and are, e.g. not visible in utilization diagrams.
• After the planning horizon has been changed, the vacation plans are no longer correct.

Information

• If data is changed in
  • Resource Data Sheet or in the
  • Basic calendar of the resource is changed, hence these changes only apply to periods which are created anew afterwards. All the periods which are already in existence when the changes are made remain unchanged.
• If you delete the dates in Start and End period in the Resource Data Sheet module, all working periods are deleted. Any individual changes, such as the holiday plans, will then be lost.

Procedure

• If you want to change the available capacity within the existing planning horizon while retaining the holiday and absence plans, you have use the Resource Availability module to change individual periods.
• If changes to a resource are to be applied to all periods with the loss of the vacation and absence plans, then the following procedure must be used:
  • Empty the Start and End period fields in the Resource Data Sheet.
  • Save.
  • Enter the Start and End period in the Resource Data Sheet.
  • Save.

Notes

• Changing the Start and End period data fields. and causes the periods to be created or deleted in DT468. When periods are created, they will automatically be preset with the values from the Resource Data Sheet.. Existing periods within the planning horizon will not be changed.
• Input of Vacation and Absence are individual changes to existing working periods. These changes will normally differ from the values in the basic calendar for the resource.
• After changes have been made to period records, replanning must be carried out.

Unexplained Overload in Planning with Adherence to Capacity

FAQ - Question/Answer

• A resource shows high overloads even though it is supposed to have been planned in with adherence to capacity. What checks should be carried out?
  • Is the Adjustment by effort code or Adjustment by costs set to Y for the resource? If adjustment is set to N then there will be no capacity adjustment for the resource, but instead the calculations will be planned with adherence to schedule.
  • Do all projects to which the resource is assigned have a priority greater than the value for Adherent to total float up to Priority (see the model parameters)? Projects for which this does not apply will be planned on adherence to schedule or buffer, and may cause resource overloads.
  • Have requested dates or actual dates been entered for any of the tasks to which the resource is assigned? When these are taken into account by the scheduling procedures, they may prevent capacity adjustment. * If the task lies beyond the planning horizon of the resource, the system assumes that there is unlimited capacity, but the loading will nevertheless be defined as an overload.
• Certain tasks may continue to cause overloads although all of the above points are met. What else should be checked?
  • These tasks may lie beyond the planning horizon for the resource. The system then assumes there is then unlimited capacity, but the loading in will nevertheless be defined as an overload.
  • The load (per period) can be so large, that the available capacity is not sufficient in any period.
  • Summary tasks and hammock tasks cause planning of resources with adherence to schedule. This also applies in some cases for structure tasks. For more information, see the corresponding sections.

Example

• For a task with Planned duration of the task = 10 days, an effort of 100 hours is entered. This corresponds to a load of 10 hours/day. For an employee resource, however, the available capacity is only 7.75 h. As a result, the task duration would have to be extended to 13 days.
• Remedy:
  • enter the CAP load profile for the affected tasks in the Resource assignment to task.
    • In planning with adherence to total float, the TA float is used.
    • Set the planning type to Adherent to capacity. As a result, as much capacity as available in the period is used when loading in and the duration is extended for the task until the entire effort is loaded in.
• A resource is loaded in with adherence to capacity, but many gaps remain in which nothing is loaded in. Here, remedial action is taken by entering the CAP load profile in Resource assignment to task. Enter CAP for all resource assignments of the task. This will achieve optimal utilisation of the resource. However, it should be noted that doing this may extend or shorten the prescribed task durations.

Overload with Planning with Adherence to Capacity and Different Load Profiles

FAQ - Question/Answer

• A task loads in resources for different lengths and apparently overloads a resource unnecessarily.

Details

• Planning with adherence to capacity
• Planned duration = 10 days
• Planned effort 100 hours
• No requested dates
• A resource with CAP load profile is loaded in without overload and for longer than 10 days.
• A resource with a linear load profile (i.e. the load profile field is empty) is loaded in for the specified 10 days and is overloaded.
• The following behavior is desired:
  • A resource with CAP is optimized and scheduled without overload.
  • A resource with linear load is also scheduled with overload in accordance with the Planned duration specifications.

Example

• R1 is scheduled without overload from 11/25 - 12/12/08.
• R8 is scheduled and overloaded for the specified duration of 10 days.

Capacity Adjustment and Task Requested Dates

FAQ - Question/Answer

• Tasks are moved by capacity adjustment, although task requested dates are set for successor tasks.
• This is only the case when planning with adherence to capacity with Fix parameter = 0.

Examples

• TA 100 is overloaded.
• Planning with adherence to schedule: TA Requested start is considered. Overload of 42 hours is indicated.

• Planning with adherence to total float TA Requested start is considered as well.

• Planning with adherence to capacity: Capacity adjustment of TA 100 moves TA 200, although the latter has a TA Requested start. The deviation from TA Requested end of TA 100 is indicated as a date delay in the bar for TA 100.

• If a TA Requested start. is set for TA 200 with Fix parameter = 1, the requested date of TA 200 is adhered to. The deviation from TA Requested end of TA 100 is indicated as a date delay in the bar for TA 100.

Unexpected Overload from Planning with Adherence to Capacity with CAP

FAQ - Question/Answer

• In spite of using planning with adherence to capacity with CAP, overloads still appear.
• The following points should be checked in this case.
  • When using planning with adherence to date and total float: All TA Requested start and TA Requested end are deleted. Otherwise, these tasks will be scheduled on an adherence to schedule.
  • Actual dates available? Tasks with a TA Actual start will be loaded in on a date-oriented basis (i.e. their remaining requirements). If appropriate, please work with Split = Y, so that the remaining resource requirement can be subject to capacity adjustment.
  • In the Resource Data Sheet, set Adjustment = Y for the respective resource.
  • Check the planning horizon. Ensure that resource periods have been set up for all the periods where capacity adjustment is to be applied. This is carried out in the Start period and End period fields in module 001343 Resource Data Sheet. There is no availability data and thus no adjustment for period for which period records are no longer available. But: do not make the planning horizon excessively long (e.g. 4 years). This costs unnecessary computation time, but usually does not yield any results of practical value.
  • Check the available capacity: Where appropriate, use Max. load/day in the resource assignment for a task to ensure that a 'mammoth task' does not tie up an employee's entire capacity for week after week, but only imposes a load of, say, 3 hours per day.
  • When planning with project structures: The project priorities must be set for subprojects in a way that causes them to be scheduled with adherence to capacity.
  • Sched. late for tasks to be calculated with adherence to capacity can lead to different results in capacity scheduling than the Schedule early standard parameter and should be avoided.

Task Requested Dates are Ignored

FAQ - Question/Answer

• Tasks are not scheduled for the TA Requested start.

Details

• The project has no Requested start.
• The task has a Requested start that is before today’s date.
• The task is scheduled from today’s date and before the TA Requested start.
• Background: Scheduling starts the calculation from the PR Requested start and if this does not exist, as of the earliest realistic date, today’s date.

Example

• TA Requested start 10/08/08
• Calc. start is the current date, 10/23/08

Notes

• If this data is available, the TA Requested start is taken into consideration:
  • PR Requested start
  • PR Actual start
  • Active today line
  • Fix parameter =1:
• In these cases the scheduling is oriented to this data and the TA Requested start.

Planning of the Resource is far Beyond the Requested Dates

FAQ - Question/Answer

• In planning with adherence to capacity, a resource with overload is planned far outside the requested dates.

Details

• A special case for multi-calendar calculation with different non-working days for task and resource.
• Parameters:
  • Planning with adherence to capacity
  • PR Requested start/Requested end is preset
  • TA Requested start / Requested end, and Planned duration are not preset.
  • A resource with a linear load profile is assigned to the task.
  • The normal company calendar has defined the period from Good Friday 04/10/09 up to and including Easter Monday 04/13/09 as non-working days.
  • The resource
    • has only defined the period from Mar. 26 up to and including March 28th, 2005 as non-working days.
    • is planned with a Planned duration of 10 h.
    • has not yet been scheduled for all of March.

Examples

• There is no Planned duration preset for the task, therefore scheduling assumes one day as the value for the Planned duration and Remaining duration.
• The resource is scheduled on two days outside the project requested dates on 04/10/09 and 04/14/09, as the task does not have any requested dates. In this case, the project requested date is used for information only.
• Scheduling copies the working days of the company calendar for the calculation of the TA Remaining duration. This indicates only one working day for the period from Good Friday 04/10/09 up to and including 04/13/09.
• The resource a preset Planned duration of 10 h. The work cannot be completed on one day with a specified daily availability of 7.2 hours. The resource is scheduled on the basis of the resource calendar and can work for two days in the aforementioned period from Good Friday from Good Friday 04/10/09 up to and including 04/13/09., while the company calendar-dependent task only indicates the duration of one day.
• As a result, the
  • task duration one working day as per company calendar and
  • resource planning without overload restrictions are met.
• This behavior is desired for the multi-calendar calculation. Different resources have different availabilities and are planned accordingly.

Note

• If this behavior is not desired, a requested date or sufficient Planned duration can be set for the task. In this case, date scheduling is based on this data when planning resources.

Capacity Adjustment and Maximum Links

FAQ - Question/Answer

• When capacity adjustment is applied, it can happen that maximum links are ignored.
• This is a topic which is currently the subject of research for the definition of results at universities.

Inexplicable Float when Planning with CAP

Problem

• After capacity scheduling, a project has an inexplicable float.

Details

• After date scheduling, the latest end dates of the tasks are after (later than) the requested end date of the project,
• Capacity dates are earlier than the PR Requested end.

Cause

• This problem only arises in planning with CAP load profile if date scheduling has already resulted in an overrun of the PR Requested end. The subsequent use of CAP planning can cause the TA durations, and hence the entire project, to be shortened to such an extent that it eventually becomes possible to meet the PR Requested end, on the basis of the capacity available.
• If the Earliest start / Earliest end bar is made visible from the Invisible window and a time scheduling is carried out, this behavior becomes evident.

Notes

• Capacity scheduling applies the earliest and latest dates from date scheduling as key dates for capacity adjustment. Capacity adjustment recalculates the durations, which may be shortened and may thus bring forward the times/dates, which can then result in buffers that are not immediately identifiable.

Example

• For a TA Planned duration of 10 days and Planned effort = 16h (with CAP), date scheduling will start by assuming a 10 day throughput time. However, if it is possible to plan the 16 hrs into 2 days, the duration will be reduced by 8 days, and an additional buffer of 8 days would then be indicated.

Remedy

• Instead of using TA durations and CAP, it is better to only use CAP with max. load. If, as in the above example, 16h are to be distributed over 10 days, it is more expedient to set Planned effort = 16 and max. load = 1,6 and Planned duration = 0.

The Maximum Load/Day is Apparently Ignored

Problem

• Max. load/day is apparently ignored:

Details

• Date scheduling loads a task with more than the Max. load/day value.
• In doing so, the scheduling routines put loads in periods even though they have no available capacity.
• Although scheduling thereby overloads the task, no overload is shown.

Cause

• Expected software behavior

Notes

• The Max. load/day value > is a desired limit for scheduling, which is overrun if necessary.
• If the Max. load/day limit is exceeded, does not yet represent an overload, as this only occurs if the available capacity of a resource is exceeded.
• Scheduling works with the Max. load/day parameter as follows:
  • The required time scheduling duration of the task is calculated from effort/ Max. load/day.
  • This duration is the starting value for capacity adjustment.
• Scheduling attempts to only load the resource up to the Max. load/day value within the available duration (required duration + float).. 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.

FF Links and Capacity Adjustment

Problem

• If in planning with adherence to capacity, 2 tasks are connected by an FF 0 link, they will be treated as FS 0, if
  • the successor task has a resource with the CAP load profile
  • the successor has a TA Planned duration = 0.

Cause

• Movement of the successor due to capacity adjustment
• The CAP load profile requires an initial duration for the adjustment. This duration is usually the TA Planned duration.
• For an FF link, the following calculation is performed:
  • Detect the end date (Earliest end) from the end date of the predecessor.
  • Detect the start date (Earliest start) from Earliest end – duration.
  • If duration = 0, this means that Earliest start = Earliest end
• Capacity adjustment with CAP load profile now carries out the adjustment by working forwards from this ESD.

Work-around

• The successor has a TA Planned duration = 0.

Notes

• An FF link conflicts with planning with adherence to capacity, because a task which is loaded with adherence to capacity may be delayed or stretched out (CAP) up to the end of the planning horizon, and does not have to finish at the time implied by the FF link.
• Under the conditions set out above, only an SS or SF link is meaningful; these result in the following calculation. E.g. SS:
  • Earliest start successor = Earliest start predecessor
• Capacity adjustment starts from the Earliest start and moves or stretches the task to achieve a complete adjustment, regardless of the predecessor task’s end date.

Processing of Regular Projects/Basic Load Projects

FAQ - Question/Answer

• How can I effect that
  • regular projects are processed in good time.
  • Basic load projects are treated subordinately.

Details

• Initial situation:
  • The tasks of the projects are planned in good time with Planning early
  • Basic load projects
    • have a load from 01/01 to 12/31 of the respective year
    • the tasks are planned with Planning late with adherence to capacity
    • The resources have the CAP load profile
  • As a result, the resources at the end of the year are completely planned, and resources are not planned between today’s date and the end of the year.

Example

• It is desired that the basic load is loaded evenly and without overload instead of being loaded all at once at the end of the year.

Example

Information

• The CAP load profile in connection with the Planning with adherence to capacity planning strategy enables the load of the resources with respect to their capacities.
• Here, PPMS is oriented to the available capacity of the resource.
• The Linear load load profile loads the resources with the same number of hours per, however, it is not used for load adjustment. For this reason, it is not suitable for the Load without overload requirement.

Procedure

• An option for solving the above mentioned requirement is the following:
  • The regular projects are planned as before.
  • The basic load project(s) is (are) planned with:
    • Planning early
    • Planning with adherence to capacity
    • Lower project priority than the regular projects in DI001015 PR Prio.
    • The tasks receive no Planned duration.
    • The resources receive a maximum load per day, e.g. 4 hours

Example

• Due to the higher project priority of the regular projects are loaded first. The basic load project and its tasks are only loaded later.
  • Possibly, the resources will not be loaded at the end of the year.
  • If you move / extend the regular projects, the basic load project is also moved:

Example

• If there are still remaining capacities available after you have planned the regular projects, then they are used up to the defined maximum load per day by the basic load project.
• Planning with adherence to capacity prevents overloads. The requested date of the basic load project is possibly overrun. As a result, the resource planning which is too high becomes visible and respective measures can be derived, e.g. to increase the maximum working time per day for the tasks of the basic load project or move tasks to the following year.

Example

After DS, Update Reports which had been Deleted Reappear

Problem

• After the next scheduling, actual load records which had earlier been deleted reappear.

Details

• If a scheduling run is performed after actual load records have been input, then the actual loads will be cumulated to TAR Actual effort and TAR Remaining effort .
• After the actual load records have been deleted, a further DS automatically creates new actual load records, which makes the user believe that the actual records which he/she had just deleted have reappeared.

Cause

• There are several possible procedures for entering actual effort.
  • Daily work reporting by entering actual load records.
  • Reporting of working hours via TAR Actual effort (as total);
  • Automatic work reporting; This method of update reporting can be set in the Resource Data Sheet.
• When actual load records are deleted, a corresponding change is made to the TAR Actual effort, but the TAR Remaining effort is not altered.
• If all actual load records for a resource assignment are deleted without the actual data items being reset (TAR Actual effort, TAR Actual start and TA Actual start), the scheduling procedures assume that update reports have been entered via the TAR Actual effort, and creates new actual load records.

Work-around

• If the amount by which the Actual effort has been changed is to be taken into account by the scheduling routines as a Remaining effort, the value for TAR Remaining effort must be amended manually.
• If the dates, after the load has been deleted, result in an unwanted extension of the actual duration, the following data fields must be adjusted manually:
  • TAR Actual start
  • TAR work reporting date
  • TA Actual start
  • TA work reporting date

Note

• Changes to the TAR Actual effort can only be seen after reselection of the data.

Moved Loadings

Problem

• Work reports are loaded in at an incorrect time in the periods of a resource assignment.

Cause

• The first period in the calendars for the company and the resources are different. Recommendation: The company calendar starts earlier and ends later than the resource calendar. The company calender should start as of the date of the first posting, at the latest.
• It has occasionally happened that an incorrect loading-in date was determined due to the deviating number of resource and calendar working periods.

Work-around

• If this problem arises, correct loading in can be achieved by setting the same date for start periods of the company calendar and of the resources.

Notes

• This problem can occur if
  • several resources are assigned to a task.
  • a resource is assigned for which the Calendar is active data field is set to N.

Negative Load in the Utilization Diagram

Details

• In utilization modules, the utilization diagram starts below the zero line for individual resources.
• If the Summarize periods resource parameter = Y, the negative utilization of the resource or a sub-resource is retained, even though load records with a negative actual load were deleted.

Example

Cause

• Software

Procedure/Workaround

• Open the required resource in the Resource Data Sheet module.
• Change parameter Summarize periods to N
• Save.
• Change parameter Summarize periods to Y
• Save.
• Carry out a replanning.
• Close PPMS and then open it again:

Behavior of TA Update Report Date After Deletion of TA Actual End

Details

• If an Actual end is removed, scheduling initializes the date for update reporting and then recalculates it.
• The date for work reporting is determined from the maximum from Actual start and the last work reportings of the resource assignments.

Example

• Initial situation

• Task 1 now receives a TA Actual start and a TA Actual end. Result of scheduling

• If the TA Actual end is emptied, scheduling has the following results:
  • The date for update reporting is deleted and the task is given a remaining duration of 7 days according to the actual duration.

Retaining Planned Load Records

Details

• Behavior up to Release 3618
  • Scheduling deletes planned load records if the task resource has not carried out update reporting (hours, expenses) and no remaining effort exists.
  • Scheduling also deletes all planned load records if the Actual load of the child resource is greater than the Remaining effort of the task and a TA Actual end exists.
• Behavior from Release 3619
  • If resource assignments exist in which TAR Remaining effort = 0, TAR Remaining effort is not equal to 0 and no Actual load is saved in the load records, scheduling creates the load records itself:
    • The number of load records per resource is determined from the TAR Actual start up to TAR Actual end and TA Actual start up to TA Actual end.
    • The total of Planned load of the load records of a TAR corresponds to the Planned effort for this TAR.
    • Actual load and Remaining load are each set to 0.
    • The planned, actual, and remaining costs are calculated in the same way.

Example

• Initial situation

• For TAR R1, the project manager deletes the Remaining effort and sets TAR Actual start and TAR Actual end.
• For TAR R3, the project manager deletes the Remaining effort and sets TAR Actual start and TAR Actual end.
• Scheduling creates load records with a total planned load that corresponds to the original planned load:

Notes

• The Deactivate creation of planned loads parameter must be deactivated in P49 Special Functions Model and Model Parameters before.
• Scheduling does not create load records for the MAN load profile. If necessary, users must create this data themselves.

Planning of TA Calc. SD by milestones

Details

• Successor tasks start on the day of the Predecessor calc ED if:
  • Duration = 0
  • TA Requested end not set.
  • Link time interval = 0

• Successor tasks start on the day of the _Predecessor calc ED + 1 if the following applies to the successor task:
  • Duration = 0
  • TA Requested end is set.
  • Link time interval = 0
  • or
  • Duration > 0
  • Link time interval = 0

Simultaneous CS by Several Users

Information

• During capacity scheduling, no other user can access the same resource capacities to also plan them. This is automatically prevented by PPMS.
• When capacity scheduling is started, if any of the resources involved is used in the capacity scheduling which is already in progress, the following message will be displayed:

• In this case, capacity scheduling is not performed although the contents of the window may be refreshed. Only when the RS run which is in progress ends can the requested RS run be restarted.

• PPMS controls simultaneous capacity scheduling using two parameters, CS currently active and CS active.

Details

DI	Parameter	Remark
000075	CS active DF type: N	Capacity scheduling is active Values -1 = Replanning 0 = No CS active 1-n = Number of the active CS As long as „CS active“ is set to „-1“: no (further) capacity scheduling can be started no changes must be made to capacity period data If a capacity scheduling is aborted, the code must be set to „0“ manually and the „CS active“ in the resources must be set to „N“.
001269	CS active DF type: Y	Capacity scheduling is active The CS requires each resource exclusively which is addressed by the calculated projects. This is because the CS checks the availability and corrects it accordingly during loading. The CS sets the “CS active” code to “Y” upon start and to “N” upon end. If the program exits during capacity scheduling, the code must be reset manually. This is carried out with the Edit Scheduling Status module (user P49). Several capacity schedulings can only run simultaneously if there is no resource overlapping caused by the projects.

“Scheduling Currently Active” Dialog Message

Details

• When scheduling is triggered, the Scheduling is currently active dialog message is displayed.

Cause

• Option 1: Rescheduling is actually running, triggered by another project manager.
• Option 2: Rescheduling that was started earlier has been terminated as a result of the program being closed.
• In both cases, the RS currently active status flag is set.

Procedure

• After an appropriate time (normal duration of a DS), check whether the CS currently active code has been set to zero (no entry). In this case, a replanning can be started.
• If the flag has not been set to zero yet, it must be set manually from–1 to zero and saved:
• P49 PM Administration Special Functions Edit the scheduling status.

Procedure after Capacity Scheduling Terminates Erroneously.

Procedure

• Open the Edit Scheduling Status module

• Reset the CS currently active data field to 0
• Reset the CS active data field to N for every resource

Notes

• In the module Edit scheduling status, the Copy field to column drag&drop option is preset, so that the CS active data field can be changed to "N” more quickly.
• If ALT+F4 (= terminate program) is used to exit from an CS run (e.g. replanning), the CS run will continue on the PPMS server. The server process does not shut down until it attempts to report the result back to the client, and discovers that the client process no longer exists.
• If the scheduling parameter mentioned above is reset again before the server process ends, this can result in a number of CS running simultaneously. These may mutually inhibit each other, leading to an endless loop (deadlock) or to completely nonsensical results. The scheduling parameters should only be reset if it is certain that there is no server process running with a CS.

Overview of the Data Fields Calculated by CS

• In addition to scheduling, the capacity scheduling routines calculate values for the following data fields:

DT461 Project
Loaded	PR Planned costs
PR Calc. start	Actual costs
PR Calc. end	Remaining costs
PR Planned effort	Total costs
PR Actual effort	PR dev. Planned costs
PR Actual effort	PR dev. Planned costs %
PR dev. budget	PR dev. planned effort
PR dev. planned budget	PR dev. planned effort %
PR dev. planned budget %	PR % completed
PR dev. total budget %	PR % completed date
PR dev. total budget %	PR % cost budget

DT463 Task
TA calendar scheduled	TA Remaining costs/structure
TA Calc. start	TA Total costs/structure
TA Calc. end	TA Planned costs
TA Planned effort	Actual costs
TA Actual effort	TA Remaining costs
TA Remaining effort	TA Total costs
TA Planned effort/structure	TA dev. planned costs
TA Actual effort/structure	TA dev. planned costs
TA Actual effort/structure	TA dev. planned effort
TA Planned costs/structure	TA dev. planned effort %
TA Actual costs/structure

DT466 Task/Resource
TAR % completed	TAR dev. planned effort
TAR % completed - date	TAR dev. planned effort %
Overload code	TAR Planned costs
TAR R date input	TAR Actual costs
TAR calc. load (only if MAN)	TAR Remaining costs
TAR MAN loaded	TAR Total costs
TAR load - DUP	TAR dev. planned costs
TAR DUP loaded	TAR dev. planned costs
TAR Actual start	BCWP
TAR Actual end	BCWS
TAR Calc. start	ACWP
TAR Calc. end	ACWS
TAR planned duration loaded	DEV BCWP-BCWS
TAR Actual duration loaded	DEV BCWP-BCWS
TAR Remaining duration loaded	DEV BCWP-A-COST
TAR Actual effort	Effectivity (%)
TAR Remaining effort	Projection
TAR Actual effort old	Remaining effort overload
TAR Remaining effort old	Actual effort overload

DT472 Load
PR C (no)	Date load
Planned load	Actual load loaded
Actual load	Remaining load loaded
Remaining load	Load overload code
Planned load-costs	Load overload.
Actual load-costs	Load Remaining overload
Remaining load-costs	Load CSD +
Total load-costs	Actual load old

DT 468 Period
Utilization	Summarized load
Planned	Summarized used
planned PRC 1	summarized used PRC 1
planned PRC 2	summarized used PRC 2
planned PRC 3	summarized used PRC 3
planned PRC 4	summarized used PRC 4
planned PRC 5	summarized used PRC 5
% utilization	Summarized planned
Used	summarized planned PRC 1
used PRC 1	summarized planned PRC 2
used PRC 2	summarized planned PRC 3
used PRC 3	summarized planned PRC 4
used PRC 4	summarized planned PRC 5
used PRC 5

Application Examples

Information

• A few application examples are provided below to illustrate the relationship between different factors that influence scheduling.

Note

• Unless stated otherwise, the examples are based on the settings of the standard installation and the linear load profile. (= The DI001452 Load profile data field is empty)

• If the parameter settings are different, the results may vary accordingly.

Examples

• Overview and short description of application cases:

No.	Application case	Result
1	Planning with adherence to schedule with several resources Task with several task resources The Planned duration of the task is preset. Planning type = adherent to schedule	The planning is carried out by the scheduling along the duration of the task. Overload is not prevented by scheduling. Overloads are not displayed.
2	Planning with adherence to total float with several resources Task with several task resources The Planned duration of the task is preset. Planning type = adherent to total float	The planning is carried out by the scheduling along the duration of the task. Overload is not prevented by scheduling. The float of overloaded resources is used: Resource 1 with overload: Float is used Resource 2 without overload: Starts at the earliest start date.
3	Planning with adherence to capacity Task with several task resources The Planned duration of the task is preset. Planning type = adherent to capacity	The planning of the task by the scheduling is carried out without consideration of the Planned duration of the task. Resources are not overloaded. The float of overloaded resources is used: Resources are not planned on non-working days.
4	Resources with vacation, planning with adherence to schedule Resource with vacation Linear load The vacation duration is shorter than the task duration. Planning type = adherent to schedule	The planning is carried out in a block by the date scheduling. The resource is not planned by the scheduling during its vacation. On working days, the resource is possibly planned with overloads.
5	Resources with vacation < task duration, planning with adherence to schedule Resource with vacation Linear load The vacation duration is longer than the task duration. Planning type = adherent to schedule	The planning is carried out by the date scheduling before or, the latest, at the beginning of vacation. Due to the unavailability of the resource, the load is marked as overload during vacation. If the entire task is during vacation, loading begins on the calculated start date of the task.
6	Planning with vacation Vacation is entered for a resource, Linear load profile The vacation duration is shorter than the task duration. Planning type = adherent to total float	The planning by scheduling is carried out in a block outside the vacation time. Available float is used. If the float s used, the resource is overloaded by the scheduling. The resource is not planned during vacation. The planning is not splitted.
7	Planning with adherence to capacity with vacation Vacation is entered for a resource, Linear load profile The vacation duration is shorter than the task duration. Planning type = adherent to capacity	The planning by scheduling is carried out in a block outside the vacation time. Available float is not planned during vacation.
8	Planning with adherence to total float with Requested end and Fix = 0 Task with several task resources. The Planned duration is preset. Requested end on a task Fix TA parameter = 0 The vacation of a resource is shorter than the task. Planning type = adherent to total float	The planning of the task is carried out by the scheduling at the Requested end. By setting the Fix parameter = 0, the Requested end is overrun if necessary. No consideration of float and possible overload since it is loaded with adherence to schedule due to the input of a Requested end. The task is not moved.
8.1	Planning with adherence to total float with Requested end and Fix = 1 Task with several task resources. The Planned duration is preset. Requested end on task Fix TA parameter = 1 The vacation of a resource is shorter than the task. Planning type = adherent to total float	The planning of the task is carried out by the scheduling at the Requested end. By setting the Fix parameter = 1, the Requested end is met and loaded with adherence to schedule. No consideration of float and overload. The task is not moved.
8.2	Planning with adherence to total float with TAR Requested start Task with several task resources Tasks with FS-relationship Tasks without resource, with Planned duration Last task with 2 resources without Planned duration with Requested start CAP load profile Max. load/day =7,2h Planning early = N TAR Requested start of resource 1< TAR Requested start of resource 2 Planning type = adherent to total float	The task planning is carried out from the PR Requested start or from TODAY. The last task is planned as late as possible, hence at the Requested end of the project. The Requested start on the last task cannot be met due to Planning early = N.
9	Planning with adherence to total float with Requested end and Fix = 1 Task with several task resources. The Planned duration is preset. Requested end on task _Fix_ TA parameter = 1 Planning type = adherent to capacity	Using the Fix = 1 parameter, the task is loaded with adher. to capacity. Overloads may occur.
10	Planning a task, which has a predecessor, with adherence to schedule, Requested start and Fix = 0 Vacation is entered for a resource Linear load profile The vacation duration is shorter than the task duration. Task with predecessor and Requested start, Fix = 0 Planning type = adherent to schedule	The task does not start at the Requested start, but after the predecessor has finished. The vacation of the resource is taken into consideration. Remaining duration = Planned duration
11	Planning with adherence to total float with effort > Availability Task with several task resources The Planned duration is preset. The capacity required for the desired duration exceeds the available capacity Planning type = adherent to total float	The scheduling uses available float. If there is no more float available, planning is carried out in a block at the latest time possible.
12	Planning with adherence to capacity with effort > Availability Task with several task resources The Planned duration of the task is preset. The capacity required for the desired duration exceeds the available capacity. Planning type = adherent to capacity	Scheduling uses available float. Scheduling is delayed until loading in is possible in a block. Possibly the project end date is exceeded. The resource is not planned during vacation, the task is not splitted
13	Planning with adherence to total float of a task with predecessor, Requested end and Fix = 0 Vacation is entered for a resource Linear The vacation duration is shorter than the task duration. Task with predecessor and Requested start Fix TA parameter = 0 Planning type = adherent to total float	The task does not start at the Requested start, but after the predecessor has finished. The vacation of the resource is taken into consideration. Remaining duration = Planned duration Float is not used since a task with date is always loaded with adherence to schedule automatically.
14	Planning with adherence to capacity of a TA with predecessor, Requested end and Fix = 0 Vacation is entered for a resource. Linear The vacation duration is shorter than the task duration. Task with predecessor and Requested start Fix TA parameter = 0 Planning type = adherent to capacity	The task does not automatically end at the Requested end, but after the predecessor has finished. The vacation of the resource is taken into consideration. Remaining duration = Planned duration Float is not used since a task with date is always loaded with adherence to schedule automatically.
15	Calc. start when several task resources report Planning of several resourcen to one task and reporting of hours: just as planned earlier than planned later than planned	The resources are planned with their remaining effort from the TAR Actual start by the scheduling. If the day after the Actual start is no working day, the resource is planned on the next working day. The resource is possibly overloaded.
16	Reporting during vacation several resources are assigned to a task. A resource is on vacation over the complete task duration, however he/she reports hours.	The planning of the resources without vacation is carried out by the scheduling according to the default specifications. The resource which has reported during vacation is planned for the first working day after the report. The resource is possibly overloaded.
17	Planning with adherence to schedule with different load profiles Planning of several resources with different load profiles. The Planned duration is preset. Load profiles: Linear BLD WEEK CAP Planning type = adherent to schedule	The resources are planned according to their effort and the preset task duration. Vacation is taken into consideration, the duration is met. The resource with CAP load profile is possibly optimized.
18	Planning with adherence to total float with different load profiles Planning of several resources with different load profiles. The Planned duration is preset. Load profiles: Linear BLD WEEK CAP Planning type = adherent to total float	The resources are planned by the scheduling in accordance with their effort and the preset task duration. Float is used if necessary. Vacation is taken into consideration. The duration is met if the float is not required. The duration extends up to the latest end date of the task if the float is required.

Information

• Below, the application cases specified above are displayed in detail with examples.

Planning with Several Resources

Objective

• Impact of planning with adherence to schedule with several resources on time scheduling

Details

• A project is created with several tasks and several task resources.
• The Planned duration of the tasks is preset or calculated from Planned effort / Max. load/day.
• The planning type is always adherent to schedule.
• The resources are planned with the CAP load profile.

Information

• * The planning is carried out by the scheduling along he duration of the task.
• Overloads are marked and won’t be distributed.
• The resources are planned by the scheduling according to PR Requested start.

Example

• The project starts on 10/31/08
• Resource R1 is planned in TA 01 with overload due to insufficient availability:

Notes

• In order for the scheduling not to overload the respources, the CAP load profile is required. In this case,
  • the available float can be used optimally for planning with adherence to total float
  • the project can be moved according to the available capacity for planning with adherence to capacity.

Planning with Adherence to Total Float with Several Resources

Objective

• Impact of planning with adherenc eto total float with several resources on time scheduling

Details

• A project is created with several tasks and several task resources.
• The Planned duration of the tasks is preset.
• Planning type is adherent to total float.

Information

• The available float is used resource-related by the scheduling if necessary.
• A resource with overload is moved by the scheduling according to the available float.

Example

• A project starts as planned on 11/25/08
• Resource R1 has sufficient free capacity in CW48. An overload occurs. The available float is used and the Calc. start is moved.
• The loading of resource R2 without overload remains unchanged. Calc. start for resource R2 starts on the earliest start date.
• The duration of task TA 01 is extended:

Planning with Adherence to Capacity

Objective

• Impact on the capacity planning of the time scheduling

Details

• A project is created with several tasks and several task resources.
• The Planned duration of the tasks is preset.
• The planning type is adherent to capacity.

Information

• Resources are planned without overload by the date scheduling
• In the case of resource shortage, the task is extended even beyond the Requested end.

Example

• PR Requested start: 10/31/2008
• PR Requested end: 12/31/2008
• Planning is carried out by the scheduling without considering the task duration.
• No overloads are created.
• Resources are not scheduled on days on which they are unavailable.

Example

• The PR Requested end of the project specified above is brought forward to 12/19/08 in order to simulate a resource bottle neck.
• Resources are planned by the scheduling without overload as required.
• The PR Requetsed end is overrun by 6 days:

Resources with Vacation, Planning with Adherence to Schedule

Objective

• To show the impact of vacation on the time scheduling when planning is carried out with adherence to schedule.

Details

• Vacation is entered for a resource.
• The planned editing period of the task does not lie completely within the vacation of the resource.
• Planning is carried out with adherence to schedule.

Information

• Scheduling is carried out along the task duration.
• Vacation is taken into consideration.
• Scheduling is possibly carried out with overloads.

Example

• Resource R2 has four days of vacation in CW45:

• Resource R2 is not planned by the scheduling during vacation. The load of resource R2 is decreased in the week of vacation CW45 accordingly, the effort of the remaining weeks is increased.
• Overloads are displayed.

Vacation Longer than Task Duration, Planning with Adherence to Schedule

Objective

• To show the impact of vacation that is longer than the task duration on the time scheduling.

Details

• The planned processing period of the task lies completely within the vacation of the resource.
• Planning is carried out with adherence to capacity and with linear load profile.

Information

• Planning is carried out by the scheduling at the time available for the task.
• Planning is carried out on the first day of vacation.

Example

• The vacation of resource R2 starts before the end of task TA 01 and extends completely across the duration of task TA 2.

• Planning of resource R2 for task TA 01 is carried out up to the start of the vacation.
• For task TA 2, it is carried out completely at the start of the vacation, as the whole task falls within the vacation period. The resource is overloaded.

Planning with Adherence to Total Float with Vacation

Objective

• To show the impact of resource planning with adherence to total float with vacation on the time scheduling

Details 1

• Vacation is entered for a resource.
• The planned editing period of the task does not lie completely within the vacation of the resource.
• Planning is carried out with adherence to total float with a linear load profile.

Information

• Planning is carried out along the duration of the task taking account vacation and float, if available.
• If the float is used up, it is overload.
• Resources are not scheduled during vacation.

Example

• Resource R2 is on vacation in CW 46 and is not scheduled during this time.
• As the available capacity is insufficient even when the float is used, resource R2 is overloaded:

Planning with Adherence to Capacity with Vacation

Objective

• To show the impact of planning with adherence to capacity with resource vacation on date scheduling.

Details

• Vacation is entered for a resource.
• The planned editing period of the task does not lie completely within the vacation of the resource.
• The available capacity of the resource is greater than the required capacity.
• The Planned duration of the task is preset.
• Planning with adherence to capacity is used with a linear load profile.

Information

• Resources are planned by the scheduling with adherence to capacity.
• Resources are overloaded if there is not sufficient capacity due to the preset duration.
• Resources are not scheduled during vacation.

Example

• Planning is carried out by the scheduling along the duration of the task, taking account of vacation.
• Resource R2 is not scheduled during its vacation in CW 48.
• Scheduling of R2 is carried out with overloads due to the specified duration:

Planning with Adherence to Total Float with Requested ED and Fix = 0

Objective

• To show the impact of planning with a non-fixed Requested end on date scheduling.

Details

• The Planned duration of the task is preset.
• The task has a Requested end.
• DI009480 Fix TA parameter = 0
• Planning is carried out adherent to total float and with linear load profile.

Information

• The initial task duration is retained.
• Resources are not scheduled during vacation, which can be seen for R2 in CW 48 in the example below.
• Float times are ignored since loading is carried out with adherence to schedule due to the set Requested end. Scheduling is carried out with overloads, if necessary.
• TAR Calc. end 12/11/08 is later than the Requested end 12/05/08 if this cannot be prevented due to the task duration.

Example

• Due to the preset task duration, the Calc. end is later than the Requested end
• The deviation from the Requested end is displayed for task TA 01.
• Resource R1 is overloaded.
• Resource R2 is not scheduled during its vacation in CW 48.

Planning with Adherence to Total Float with Requested ED and Fix = 1

Objective

• To show the impact of planning with a non-fixed Requested end on time scheduling.

Details

• The task has a Requested end.
• DI009480 Fix TA parameter = 1, the task is therefore fixed to the date.
• Planning type is adherent to total float.

Information

• TA Requested end is not moved.
• Resources are not scheduled during vacation.
• An overload is scheduled if required.
• A long duration of a task with fixed Requested end may lead to the Calc. start being earlier than the Calc. start of the project. Calc. start of the project is therby brought forward. This only applies if the ‘today’ line is not active.

Example

• TAR Calc. end corresponds to the Requested end
• The task duration is not extended.
• The resource is overloaded.
• Resource R2 is not scheduled during its vacation in CW 46.

Note

• Task dates with Fix parameter = 1 have a similar effect to actual dates, i.e. they are not shifted by the active ‘today’ line if Requested start or Requested end are entered.

Planning with Adherence to Total Float with TAR Requested Start

Objective

• To display the impact of planning with adherence to total float of TAR Requested start on time scheduling

Details

• Scheduling of several tasks.
• Several task resources are assigned to a task with Requested start.
• The task resources have different TAR Requested start.
• Planning type is adherent to total float.

Information

• Resources are overloaded if necessary.
• Resources are not scheduled during vacation.
• The planning of the resources is carried out on the TAR requested dates, as far as they lie within the period from Calc. start to Calc. end.

Example

• Scheduling loads in the resources for the time available.
• Resources R3 and R4 are overloaded:

Notes

• The TA Requested start with fixing has a higher priority for scheduling than the TAR Requested start.
• In the case of planning with adherence to float and late planning, Requested start dates are ignored and Requested end dates are taken into consideration.

Planning with Adherence to Capacity with Requested ED and Fix = 1

Objective

• To show the impact of planning with adherence to capacity with Requested end without fixing on date scheduling.

Details

• The task has a Requested end.
• DI009480 Fix TA parameter = 1
• The planning type is adherent to capacity.

Information

• The Requested end is not overrun by the scheduling.
• Floats are ignored.
• Scheduling is carried out with overloads, if necessary.
• Resources are not scheduled during vacation.

Example

• Float is ignored since due to Requested end with Fix parameter = 1 loading is carried out with adherence to schedule.
• Overloads are scheduled so that the Requested end can be met:

Planning with Adherence to Schedule of a TA with Predecessor, Requested End and Fix = 0

Objective

• To show the impact of planning of a task with adherence to schedule with predecessor, Requested end with Fix parameter = 0 on date scheduling.

Details

• Several task resources are assigned to a task with predecessor and non-fixed Requested start.
• The planned editing period of the task does not lie completely within the vacation of the resource.
• The processing of the predecessor takes longer than planned.
• The planning type is always adherent to schedule.

Information

• Scheduling may also shift the task and plan resources with overloads.
• The deviation from the Requested start is displayed.
• Resources are not scheduled during vacation.

Example

• The predecessor takes longer than planned.
• The successor starts later, the task duration is not extended. The task is scheduled with overloads.
• The deviation from the Requested start is displayed for task TA 02 by the interval between the triangle and the start of the bar.
• Resource R2 is not scheduled during its vacation in CW 49.

Planning with Adherence to Total Float Higher than the Availability

Objective

• To show the impact of planning with adherence to total float with effort higher than availability on date scheduling.

Details

• The Planned duration of the tasks is preset.
• The effort is higher than the availability of the resource in the planned processing period.
• Planning is carried out with adherence to total float and with linear load profile.

Information

• The float of the overloaded resource is used:
• Scheduling is carried out at the latest possible point in time.

Example

• The Planned effort of 150h within 15 days exceeds the available capacity of the resource. Task 01 is therefore scheduled at the latest point possible:

Planning with Adherence to Capacity with Effort Higher than the Availability

Objective

• To show the impact of planning with adherence to capacity with effort higher than the availability on date scheduling.

Details

• The Planned duration of the tasks is preset.
• The effort is higher than the availability of the resource in the planned processing period.
• Planning is carried out with adherence to capacity and with linear load profile.

Information

• Resources are not scheduled during vacation.
• Scheduling shifts the task until it can be planned in a block. This means that the project end date may also be moved.
• Scheduling evenly distributes the effort within the Planned duration across the task duration. The resource is overloaded.
• The float is ignored, the task duration is not extended.

Example

• Scheduling shifts the task until it can be planned in a block.
• Resource R2 is not scheduled during its vacation in CW 45.
• Resource R1 is overloaded.
• PR Requested end is overrun:

Note

• If the CAP load profile is used, available float is taken into consideration.

Planning with Adherence to Capacity of a TA with Predecessor, Requested End and Fix = 0

Objective

• To show the impact of planning with adherence to total float for a task with predecessor, Requested end and Fix parameter = 0 on date scheduling.

Details

• Several task resources are assigned to a task with predecessor and non-fixed Requested end.
• Planning type is adherent to total float.

Information

• Scheduling shifts the task if the predecessor takes longer than planned.
• The deviation from the Requested end is displayed.
• The resource is overloaded, if necessary.
• Resources are not scheduled during vacation.

Example

• Task 01 is linked to task 02 via an FS link.
• Since task 01 is delayed, task 02 is shifted beyond its Requested end. A deviation of 17 days is displayed.
• The resources are planned with overload.
• Resource R2 is not scheduled during its vacation in CW 48.

Planning with Adherence to Capacity of a TA with Predecessor, Requested ED, Fix = 0

Objective

• To show the impact of planning with adherence to capacity of a task with predecessor, Requested end and Fix parameter = 0 on date scheduling.

Details

• Several task resources are assigned to a task with predecessor and non-fixed Requested end.
• Planning is carried out with adherence to capacity and with linear load profile.

Information

• Scheduling shifts the task if the predecessor takes longer than planned.
• The deviation from the Requested end is displayed.
• If necessary, the resource is overloaded since the Requested end causes the planning to be carried out with adherence to schedule.
• Resources are not scheduled during vacation.

Example

• Task 01 is linked to task 02 via an FS link.
• Since task 01 is delayed, task 02 is shifted beyond its Requested end. A deviation of 24 days is displayed.
• The resources are planned with overload.
• Resource R2 is not scheduled during its vacation in CW 48.

Calc. SD for reporting of several task resources

Objective

• To show the impact of reporting with planning with adherence to schedule without requested dates and with several resources on date scheduling.

Details

• Several task resources with CAP load profile are assigned to a task.
• No TAR Requested start and Requested end set.
• The planning type is always adherent to schedule.
• Split parameter = Y

Information

• Calc. start of the task and all task resources is shifted to the next working day after the latest work reporting.
• Late work reporting can thus lead to a shift of the Calc. end.

Example

• Resource R2 is on vacation in CW 49.
• Dates before reporting of hours:

• After reporting to 11/10/08 by R1 and carrying out a date scheduling, the Calc. start of task 01 is shifted from 11/04/08 to 11/10/08:

Work Reporting on Vacation

Objective

• To show the impact of hours reported on vacation on time scheduling.

Details

• Several task resources are assigned to a task.
• A resource is on vacation for the whole task duration and reports actual hours for the vacation period.
• The resources are planned with a linear load profile.

Information

• Resources are not scheduled during vacation.
• Resources that report hours for the vacation period receive the remaining effort on the next working day after reporting. The resource may be overloaded.
• Scheduling of resources without vacation is carried out in accordance with regular planning.

Example

• Resource R8 is on vacation from 11/05/08 to 12/16/08. The total effort for task 01 is scheduled on the first day of the vacation and the resource is overloaded:

• Hours are reported during the vacation period. At task and task-resource level, scheduling reduces the reported hours from the remaining effort and overload.
• The remaining effort is scheduled on the day after work reporting:

Planning with Adherence to Schedule with Different Load Profiles

Objective

• To show the impact of planning with adherence to schedule with different load profiles on date scheduling.

Details

• Resources with different load profiles are assigned to a task.
• The planning type is always adherent to schedule.
• TA 02 is planned with Sched. late.

Information

• The resources are scheduled in accordance with their effort along the specified duration of the task.
• The task duration is adhered to, the resources are overloaded if necessary.
• Resources are not scheduled during vacation.
• For resources with CAP load profile, scheduling may optimize the utilization.

Example

• Resources are not scheduled during vacation and may be overloaded:

Notes

• For the WEEK load profile, the overload is calculated depending on effort, duration, and available capacity of the resource to be scheduled over the entire period. Utilization on the day to be scheduled is not relevant.
• After planning vacation or other non-availabilities of resources with WEEK load profile, replanning is recommended.

Planning with Adherence to Total Float with Different Load Profiles

Objective

• To show the impact of planning with adherence to total float with different load profiles on date scheduling.

Details

• Resources with different load profiles are assigned to a task.
• Planning type is adherent to total float.

Information

• The resources are scheduled in accordance with their effort along the specified duration of the task.
• The task duration is extended to the end of the float.
• Resources are not scheduled during vacation.
• For resources with CAP load profile, scheduling may optimize the utilization.

Example

Notes

• For the WEEK load profile, the overload is calculated depending on effort, duration, and available capacity of the resource to be scheduled over the entire period. Utilization on the day to be scheduled is not relevant.
• After planning vacation or other non-availabilities of resources with WEEK load profile, replanning is recommended.

Critical Chain Method with PPMS

Planning Model

Information

• The critical chain method expects all tasks of the project to be planned with the shortest minimum runtime. For this purpose, a float is planned (as an own task) between the last task and the end of the project.

Procedure

• Plan a float (as an own task) between the last task and the end of the project.

Example

• The project float is visible at the top right of the project bar. The duration of the project float is specified behind the bar.

Details

• The project float is also illustrated in the Create, Edit, and Delete Projects and Project Overviews with Utilization modules.

Float in the Create, Edit, and Delete Projects module

Float in the Project Overview with Utilization module

Further Information on Scheduling

Overview

• This chapter contains additional information related to PPMS scheduling.

Creation and Modification Date User by DS

Information

• The Creation and modification date fields, and Creation and modification user fields are information fields on the records, which serve to indicate which users have edited the records and when. These fields are not changed by the scheduling routines, so that this important information is not lost!

Stop

• Exception: When scheduling creates load records, they receive the date of creation and the user who created them.

Automatic Work Reporting

Details

• If the DI001238 Autom. work reporting code is set in module MOD001343 Resource Data Sheet, scheduling carries out an automatic work reporting.
• This function is intended for those who do not want to carry out reports themselves but whose effort still needs to be recorded in the projects.

Information

• In an automatic update report, the effort is calculated as follows:
  • TAR Actual effort = (TAR Planned effort) * (TAR Actual duration) / (TAR Planned duration)
  • TAR Remaining effort = (TAR Planned effort) * (TAR Remaining duration) / (TAR Planned duration)
  • If TAR_Actual end_ is set, TAR Remaining effort is set to 0 by the date scheduling.

Example

• An Actual start which is earlier than the date of the first planned load record is entered and scheduling is carried out. Scheduling creates an actual load record with the originally determined Actual start for each day up to today with the Actual load detected initially.

Notes

• Upon automatic update report,
  • load profiles are ignored. Exception: WEEK, MONTH, YEAR
  • Manually entered values in Remaining load and Remaining effort overwritten by the scheduling
  • Changes to the effort are edited by specifying a Planned effort_
  • Actual effort is loaded in daily until the Actual end is set. This may mean that the posted effort exceeds the planned effort.
• A mix form of automatic and manual reporting is not intended.

Projects with Project Status Other Than 1

Objective

• To show the behavior of scheduling and projects with a project status other than 1.

Details

• Unlike projects with status 1, all projects with DI001042 PR Status <>1 are not calculated by scheduling.
• If project structures are used, all projects assigned to a project with a status <> 1 are not calculated by scheduling.
• It is necessary to unload the projects before setting a status <> 1. If this is not done, an information message is displayed.

Impact

• No scheduling of resources for projects with status <>1.
• For projects with status <> 1, only the actual bars and no remaining bars are displayed in window 3.
• The cost and effort data of projects with status <> 1 are not updated.

Example

• After successful loading, the project status can be changed.
  • Unloading is done via

• • Setting status <> 1

• • If unloading has not been carried out, the following information message is displayed:

• • After completed unloading, the project status can be changed.

Calculation of Date Position

Objective

• Calculation of dates based on the practical approach.

Details

• The network theory and the practical approach are available for determining the start of a task successor.
  • Network theoretical
    If the network theory method is used, the successor starts on the same day on which the predecessor ends.

• • Practical approach
    With the practical approach, the successor starts on the next day.

• PPMS plans on the basis of the practical approach.

Information

• Requested dates and actual dates which fall on non-working days remain as such and are taken into consideration.
• Start and end dates are also scheduled on non-working days. The duration, however, is still shown in working days. The resources are loaded on working days.
• The successor of a Finish-Start relationship with a time interval of 0 starts
  • on the following working day, if the TA duration is greater than 0
  • on the same working day, if the TA duration equals 0 (milestones).

Example 1

• The TA Requested start is on Sunday, 11/9/08, a non-working day.
• Resource R8 is on vacation from 11/10/2008 to 11/14/2008. It is not scheduled during its vacation.
• Task TA 01 is scheduled on the Requested start
• TA 02 starts on the next working day.

Example 2

• The Requested start of a task is in the period in which the predecessor’s task resource is on vacation.
• Resource R1 is on vacation from 11/6/08 to 11/14/08. Resource R1 completed task 1 on 11/05/08 by setting the Actual end.
• Task 2 is scheduled on the next working day after the predecessor ends.

Note when using the Active today line model parameter:

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

Model and Model Parameters

Information

• This module provides an overview of the parameters for date scheduling.
• A license can contain a number of models but only the activated model is active (Active checkbox is activated).
• You can insert a further model to the license via the right mouse button and selection of Insert Model parameter. After you have entered the name, a model number is assigned automatically. Here, you can activate or select parameters which are different to the parameters in the already existing model.

Note

• The other data fields in Hidden do not have a function yet.
• See DT 401

Planning with Project Structures

Overview

• This chapter shows the possibilities for planning with project structures. It explains scheduling behavior from simple planning with project structures down to the various possibilities for exchanging data between project levels.

Simple Planning Using Project Structures

Objective

• To break a project down into subprojects and to exchange information about dates, effort and costs between the project levels.

Information

• PPMS always schedules the project which is currently selected and its subprojects. This is done regardless of whether the subprojects are selected and displayed.
  • If the highest level project is selected, PPMS will schedule the entire project structure.
  • If a subproject is selected, PPMS will schedule this subproject and any subprojects it includes.
• Calculation via project structure can either be date scheduling or capacity scheduling.

Principles

• Key dates are reconciled between main project and subprojects dependent on the model parameters.
• Durations and effort are summarized from the subproject to the structure task of the parent project.

Enhanced Planning Using Project Structures

Information

• When planning with project structures, the data interchange between the project levels is controlled by the administrator via the Model and Model Parameters menu.

Parameters for Scheduling Project Structures

Objective

• Control data interchange between the main project and subproject.

Information

• The calculation of project structures is influenced by the DI000095 Str. calc. with adjust. parameter.

Details

• Str. sched. w. recon. = 0: Do not adjust drtns & dates between main & sub-PR
  • There is no adjustment between main and subprojects. In the structure tasks of the main project, the data of the subprojects is transferred e.g. to the TA STRSD and TA STRED fields of the structure task for comparison purposes:
  • This corresponds to the previous N setting.
  • In the cost overview, only the sum of the costs of all structure tasks is displayed in the main project. The individual amounts are not summed up in the main project, i.e. amounts which are posted to the subproject are only shown as a sum in the subproject, not in the main project.
• Str. shed. w. recon. = 1: Auto.adjust. drtns & dates between main and sub-PR
  • Durations, effort, dates, and costs are automatically adjusted between main and subprojects. As a result, data entered manually such as actual start dates are overwritten.
  • In the cost overview, the costs of all tasks of the main project are summarized.
  • The requested dates on the structure task of the subproject dominate the requested dates on the subproject.
  • The calculated dates of the subproject are transferred to the main project.
    • If the Calc. end of the subproject is earlier than the Calc. end of the structure task, the Calc. end of the structure task is overwritten by the values of the subproject.
    • This can cause the Calc. end of the main project to be moved in the same way.
  • The requested dates of the main project are for information purposes only.
  • The requested dates for main project, subproject, and structure task are not changed.
  • If the project manager wants to specify requested dates, he or she can enter them directly in the subproject.
  • This largely corresponds to the previous Y setting.
• Str. shed. w. recon. = 2: Adjust main PR & sub-PR, key dates from main PR
  • The following data is adjusted between main and subprojects:
    • DI001119 Calc. start of the structure task is transferred to DI001019 Requested start of the subproject.
    • DI001120 Calc. end of the structure task is transferred to DI001020 Requested start of the subproject.
  • Other data, such as Duration X/STR and DI001123 TA STRSD, is transferred to the main project and can be displayed there for comparison purposes.
  • In the cost overview, the costs of all tasks of the main project are summarized.
  • The requested dates of the structure task of the main project have priority and are passed on from the main project to the subproject.
• Str. sched. w. recon. = 3: Do not adjust main PR key dates with sub-PR
  • The main project manager can directly specify the key dates of the subproject in the Requested start and Requested end fields of the subproject.
  • The project requested dates are transferred to the requested dates of the higher-level structure task. All other durations and dates of the subproject are transferred to the main project for your information only and can be displayed for comparison purposes there.
  • No key dates are transferred from the main project to the subproject.
  • In the cost overview, the costs of all tasks of the main project are summarized.

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.
• The standard setting for Str. sched. w. adjust. in the model parameters is = 2 Adjustment of MP key dates between MP and SP.
• 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 they are to be displayed, the following data items can be included in the modules via customizing:
  DI001123 TA STRSD
  DI001124 TA STRED
  DI001140 TA Planned duration/structure
  DI001141 TA Actual duration/structure
  DI001142 TA Remaining duration/structure
  DI001143 TA Planned duration/structure
  DI001143 TA Planned effort/structure
  DI001144 TA Actual effort/structure
  DI001145 TA Remaining effort/structure
  DI001633 TA Planned costs/structure
  DI001634 TA Actual costs/structure
  DI001635 TA Remaining costs/structure
  DI001636 TA 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 PPMS, SF and FF links between structure tasks are possible, and 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.

Cross-Project Links (XP links/external links)

Consideration of the XP Links in Scheduling

Objective

• To explain the calculation procedures for XP links

Information

• When the scheduling calculations are performed, the interlinkage of projects due to any IP 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 in which the Project Details are Calculated

Notes

• If several projects are selected for scheduling (e.g. for replanning), then the sequence in which the calculations are performed will give precedence to the XP links over the sequence in which the selection is sorted. This may result in a project with a lower PR priority being scheduled earlier than its sort sequence would require, because it has XP links.

Determining the Rank of a Task with XP Links

Information

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

Example

• Project A has tasks A1, A2, A3, A4 and Project B has tasks B1, B2, B3

• Within its own project, task B2 has rank 2. Its IP predecessor (A3) has rank 3 within its own project. As a result, task B2 is given the rank 4 within the Total Network Plan. The rank of its successor will be 5.

Information

• The sequence in which tasks are loaded during capacity scheduling when there are several projects is determined by:
  • 1. Their ranks, 2. PR priority, 3. TA Priority, 4. TP (TS), 5. Planning early = Y, 6. Planning early = N.
• The loading type (adherence to schedule, buffer, capacity) remains unchanged. To ensure that projects with greater PR priority values are the first to be planned in, projects which have a lower priority have their ranks adjusted to the highest possible value.

Example

• If project B has a less urgent PR priority, then task B1 will be given the rank 3.

• Load sequence: A1, A2, A3, B1, A4, B2, B3.

Notes

• XP links are possible both between and within project structures. It can happen that cycles are formed within the (total) network plan, which are not detected until a SCHED run. They can be detected and eliminated by means of the Cycle Search module. In PPMS standard it is user P20 1. PM administration Special functions Cycle search.

Example

• XP links between different main projects
  • There is an XP 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 from it will be loaded in before Task 01 from Project 2512.

• The cross-project link is displayed in window 3 as a blue line.

Example

• XP links between subprojects of a main project
  • Project 1001 contains a subproject, in which all the important payments are represented as tasks. These are linked to tasks in other subprojects:

Frequently Asked Questions About Planning with Project Structures

Incorrect Calculation of the Level Field

Problem

• Different calculation of the Level field.

Details

• If project structures are manipulated in a module, and if then a scheduling run is performed in this module, the levels may not be calculated in the correct sequence.

Cause

• As part of the scheduling procedures, the software always carries out a sort by level and PR Requested end. As neither a level nor a PR Requested end exists is available for the subprojects, the projects are potentially not sorted and calculated individually in the usual sequence at first. This leads to the determination of a different level.

Work-around

• After the 2nd scheduling run and each subsequent one, the levels will be calculated correctly.
• If the calculations are done in a module which only performs them for the main project, e.g. the project data sheet module, the levels will be determined correctly as well.
• In the case of complete replanning, the levels will also be determined correctly.

Note

• This behavior can lead to different analyses, if report details are selected or sorted using the Level field.

Sched. Early = N Has no Effect on Tasks with Subprojects

Problem

• Planning early = N has no effect on tasks with subprojects.

Cause

• In the case of tasks with subprojects, the duration and position of the task is defined by the subproject. If, for example, a task has a TA Requested start in the subproject, then this TA Requested start should be adhered to. However, this contradicts to the idea < with the intention of Planning early = N in the parent task. Consequently, a parent task will always be planned with Planning early = Y.

Work-around

• Each task can be forced into the late position by having a predecessor for which Planning early = N is set. To do so, you can e.g. create a milestone task with Planned duration = 0, Planning early = N and a link: FS time interval = 0 to the task which is to be planned late.
• The same effect can be achieved by setting Planning early = N for all the tasks in the subproject which have no predecessors.

Notes

• Once a subproject has been started (i.e. there is an entry for its PR Actual start), the effect of Planning early = N can again be forced by splitting the task.
• Requested dates for a task in the subproject will again disrupt any attempt to move the project to the latest possible dates.

Set Project Status 9 for Archiving

Objective

• Optimum representation of costs and effort when projects or subprojects receive PR status 9 Projects to be archived.

Notes

• All dependent projects and subprojects are to be set to status 9 at a particular point in time.
• If this is not possible, only projects that do not have any active subprojects are to be set to status 9.
• It is advisable to first calculate the whole project before setting it or its subprojects to status 9 after unloading. This updates the cost and effort data to the current situation.

Planning with Resource Structures

Overview

• This chapter shows the possibilities for planning with resource structures. It deals with possible strategies for planning and work reporting.
• In PPMS, it is possible to define resource structures with any required depth. Resources at a higher level in a structure (= main resources) can be used to produce summary utilization diagrams and for planning purposes. This makes it possible to produce overviews of the utilization for the main resources and their component (lower level) resources.

Example of a resource structure

Summarization of Resources

Information

• The available capacity of a resource and the loads on the resource will be summarized along the resource structure in an upward direction if the Summarize periods checkbox is activated for the main resource in the Resource Data Sheet.

Example

Details

• Summarization of the available capacity
  • If the resource availability is changed, the available capacity per period will be summarized upwards through the resource structure when the details are saved. The result is saved in the Summ. avail. cap field for each period of the main resource.
• Summarization of capacity loads
  • Scheduling summarizes the capacity loads on the subresources up to the main resource level and saves the details in the Summarized utilization field for that resource.

Example

• Utilization diagrams which show summarized values (e.g. the Resource Utilization by PR Code module) can be opened on any level in the resource structure with very short runtimes.

Notes

• If it occurs that a Summ. avail. cap. value is calculated incorrectly, you can proceed as follows:
  • Deactivate the Summarize periods checkbox for the main resource. Save. The summarization along the resource structure is now canceled.
  • Deactivate the Summarize periods checkbox for the main resource. Save. The summarization along the resource structure will now be reinstated.
• Such corrections can most rapidly be made in the Resource Overview module. It may be required to have the Summarize periods data field displayed in Window 1 or 2.

Planning on the Lowest Resource Level Only

Information

• The simplest case is when planning is done on the lowest resource level and the utilization diagrams are displayed for main resources. The main resources should be defined in the following example:

Example

• The main resource has:
  • no availability of its own (Units/day and Factor amount are blank)
  • period records (there are entries for the Start period and End period). Reason: The summarized data must be stored on each period.
  • The Res. to be planned checkbox is deactivated. This prevents this resource to be planned.

Note

• The checkbox can only be deactivated if the resource is not planned in any task.

Example of a summarized utilization diagram

Planning on Main Resource Level Only

Information

• A planning situation which frequently arises is that only main resources (e.g. departments) are to be planned. In this case it can be difficult to determine and update details of the available capacity (holiday, absence, etc.) at main resource level.
• Here, PPMS provides a simple solution: The sub-resources are set up for holiday and absence planning. Their available capacity is summarized up to the main resource level, at which the planning is being carried out. This means that the available capacity details at the main resource level are always up to date.

Notes

• Capacity adjustment can also be carried out for main resources.
• The main and sub-resources should be defined as in the following examples:

Example of a main resource

• The main resource has:
  • no availability of its own (Units/day and Factor amount are blank)
  • Period records (there are entries for the Start period and End period); Reason: The summarized data of the subresources must be stored on the periods.
  • The Res. is being planned checkbox is activated. This allows the system to plan this resource.

Example of an associated subresource

• The sub-resource has:
  • Periods (Start period and End period) are filled; Reason: the holiday and absence times are saved for each period.
  • The Res. is being planned checkbox is deactivated. This prevents the system from planning this resource. Scheduling does not consider the periods of these resources, so that even if there are many such resources, they will have no detrimental effect on the runtimes of the scheduling routines.
  • The Summarize periods checkbox is activated.

Example of a summarized utilization diagram

• There are only loads on the main resources. At sub-resource level there is only available capacity.

Planning of Main Resources and Subresources

Information

• It is possible to use main resources and sub-resources in planning.

Practical application 1

• A department may wish to plan on individual employee level. At the time the plans are being drawn up, the project manager may still be unsure which employee will be doing a particular item of work. For this reason the manager will only plan at level of the main resource (=department). Fine planning at the level of the employees will only be done later, for example by the department manager.

Notes

• Capacity adjustment can also be carried out for main resources.
• The sum of the utilizations of the subresources does not have to equate to the utilization of the main resource. There may be additional loads on the main resources which will possibly have to be distributed across the subresources at a later stage.
• It is recommended to either plan department or employees only within one time period.

Example 1

• Summarized Resource Utilization by PR Code utilization diagram before capacity adjustment

• Summarized Display cause utilization diagram after capacity adjustment

Information

• If employees and department are planned simultaneously in a period, this can lead to overloads.

Details

• Rescheduling recalculates the summarization of resource loads.
• The capacities of the individual resources to be planned are loaded separately and re-summarized after scheduling has been completed.
• As a result, summarization may lead to overloads.

Example, part 1

• Planning with adherence to capacity
• Initial situation: Department A and its 3 employees have not yet been planned in and therefore each have capacity of 100 %.
• The department takes its summarized free capacity from the free capacities of its employees.
• Project A
  • Planning of department A for TA 1 at 50% on October 18th of this year.
  • In task 2, the 3 employees in department A are scheduled as follows on October 18th:
    • 1 at 100%
    • 2 at 50%
    • 3 at 0%
  • As a result, the department has a remaining availability of 50 % and the individual employees have remaining availability in accordance with their individual plans, since the availabilities have not yet been re-summarized.
  • The system determines the following remaining availabilities if the unsummarized individual resources are looked at separately and before scheduling is carried out again:

Resource	Remaining availability	Calculated remaining availability on department level (unsummarized)
Department A	50%	50%
Employee 1	0%	0%
Employee 2	50%	0.5*1/3 of dept. capacity => 16.67%
Employee 3	100%	1/3 of dept. capacity => 33.33%

• In project B, which has a lower priority,
  • department A is planned for a further 25% for task 1 on the same day.
  • Since the utilization of the department has not yet been summarized, scheduling determines that department A still has 50% available capacity, and loads it at 25 %.
• After summarization of the plannings, department A has a total utilization of 125% on 10/18/08:

Resource	Load	Load with regard to department
Department A	50% from A and 25 % from B = 75%	75%
Employee 1	100% from A	1/3 of dept. capacity => 33.33%
Employee 2	50% from A	0.5*1/3 of dept. capacity => 16.67%
Employee 3	0%	0%
Total		125%

Example, part 2

• Project B from the example (part 1) above is unloaded.
• Accordingly, the planned summarized capacity of department A is only the 100% from project A.
• Capacity scheduling is only triggered for project B.
• On the basis of the new summarization, capacity scheduling finds that department A is utilized at 100% in project A, and then loads the department at the end of project A, on October 19th 2008.
• On October 18th, the utilization of the department amounts to 100% of project A and on October 19th it amounts to 25% of project B.

Notes

• When planning with departments, scheduling cannot tell which department employee is intended for a task.
  • In the first example above, scheduling cannot automatically tell whether employee 3 is to perform the full 25% of the department planning for project B, or whether the activities are to be split somehow between employee 2 and 3.
  • Planning on department and employee level at a particular point in time or within a period is not reasonable and is therefore not recommended.
• If the behavior described above is not desired, you are advised not to plan departments and employees at the same point in time.
• It is generally not possible to plan one department on department level, and a different department on employee level in the same period.

Runtime Aspects in Defining the Resource Structure

Objective

• To optimize the runtime performance of the scheduling routines

Information

• The number of planning periods is an essential determinant of the main memory requirements and computing time of the scheduling routines.
• The proportion of resources with no planning periods should be kept as large as possible; for example they could be:
  • resources for which no capacity planning is carried out, but which nevertheless (e.g. for analysis purposes) are assigned to the tasks (e.g. the "Purchase” resource);
  • resources for which, although they are in the upper part of the hierarchy, no resource capacity unloading is to be carried out (e.g. the "Complete factory” resource);
  • resources which represent employees, required only for the purpose of reporting hours worked, and which are not used in planning.
• Resources which have planning periods should therefore be only those for which
  • capacity planning is actually to be carried out.
  • utilization diagrams are to be created.
  • availability planning (e.g. holidays) is to be carried out for individuals (employees).
• Exception: Employee resources with Res. is being planned = N. They have no negative effects on the runtimes or main memory requirements for scheduling.
• It is essential to specify a realistic planning horizon which is as short-term as possible: each resource requires one period record in the database for each day. If precise details of the available capacity are known, say, for one year ahead, the planning horizon can be advanced on a rolling basis, e.g. every quarter.
• The total number of planning periods is calculated from:
  • the number of resources subject to capacity planning * planning horizon
• The memory space required for them is then calculated approximately from:
  • the total number of periods * 0.2 kbytes.
• If hardware capacity is limited, it is recommended that planning for the availability of individual employee is initially ignored, and planning is done on department level.

Medium- and Long-Term Resource Planning

Objective

• To optimize the execution time of the scheduling routines by reducing the number of planning periods

Information

• If long-term resource planning (e.g. over the next 5 years) is to be carried out, it is recommended that this is performed for the main resources only.
• The following planning horizons are then recommended:
  • employee resources, e.g. 1 year (= short- and medium-term planning);
  • department resource, e.g. 5 years (= long-term planning).
• The resources should then be defined as in the following example:

Example

• Employee resources:
  • Start period: 1/1/08
  • End period: 12/31/08
• Department resource:
  • Start period: 1/1/2008
  • End period: 12/31/2008
  • no availability of its own
• department resource:
  • Start period: 1/1/2006
  • End period: 12/31/2009
  • Availability: 2 employees
• To achieve this, you must make the entries in the appropriate resource data sheet and save them. While saving the appropriate records are generated for the specified period.
• The records are created additively.

Example

• From 01/01/06 – 06/30/06, a resource has an availability of 4 hours per day.
  • Unit/day = 4
  • Start period = 01/01/08
  • End period = 6/30/08
• From 07/01 – 31/12/06, this resource works 8 hours per day
  • Unit/day = 8
  • Start period = 01/01/08
  • End period = 12/31/2008
  • Save.
• As a result of this, the availabilities are generated as specified above.

Note

• For this special case, the entry in the Start period field must not be changed; only the entry in the End period field should be changed. otherwise the existing data will be deleted and only the complete, redefined period is filled with the new data.

Resource Planning with Skills

Overview

• This chapter shows the possibilities for planning with skills.
• Skills can be assigned to resources in order to determine which employees are available with a particular qualification (=skill). These skills can also be used to carry out a capacity planning.
• Therefore, the following is required:
  • a skill must additionally be set up as a resource (= skill resource);
  • the skill resource must be assigned to the skill as well.

Example

• In the Edit Skill (MOD000522) module, the skills are defined.

• The skill customizer has been set up and resources have already been assigned

• In addition, a skill resource of the same name is created which has no availability of its own but possesses periods on which can be loaded.

• The skill resource is also assigned to the skill.

• The skill resource can be assigned to tasks.

• The utilization diagram of the skill shows the sum from the planned skill and the utilization of the employees to whom this skill is assigned.

Possibilities in skill planning

• Skills can be planned in a convenient way.
• The utilization diagram shows a comparison of the demand for the skill and its availability.
• Utilization diagrams for skills take a long time to be created because data is always summarized at runtime.
• It is not possible to perform capacity adjustment via skill resources because they do not have available capacities of their own. As a result, overloads are always shown for the resource assignment.