Below, you will find descriptions of individual task parameters (task data fields).
DI001098 Task ID
Technical ID of the task. It is generated automatically upon creation of the task and cannot be changed afterwards. This ID is usually not visible in modules, but it can be accessed by users with customizing rights if necessary.
DI060043 Task (functional)
Functional identification number of the task
DI041467 Task
Field in which the task ID is displayed. Here, either the task WBS codes or the functional task ID will be displayed depending on the settings of the Show WBS code instead of ID parameter.
The functional ID in the Task field is generated automatically (copied from the technical Task ID), if you enter the name of the task in the Task name field and click outside the field. The functional ID cannot be changed manually afterwards.
For newly created tasks, the WBS code is only displayed if it has been generated explicitly (depending on the version either by selecting the respective context menu command or by clicking on the Generate WBS code button in the project header line.
either generated automatically (copied from the Task ID), when you enter a task name in the Task name field and click outside the field. The functional ID can be changed manually afterwards.
or initially allocated manually.
Since the field is an output field by default, it must be changed to input field via customizing in order to be able to manually edit it. This must be redone after every database update.
Initially planned effort of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Planned effort is only summarized from the resource assignment (DT466) to the task (DT463) if the Effort summarization checkbox is activated for the resource in question in the Resource Data Sheet.
DI001135 Actual effort
Actual effort of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Actual effort is only summarized from the Resource assignment (DT466) to the Task (DT463) if the Effort summarization checkbox is activated in the Resource Data Sheet.
DI001136 Remaining effort
Remaining effort of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Remaining effort is only summarized from the Resource assignment (DT466) to the Task (DT463) if the Effort summarization checkbox is activated in the Resource Data Sheet.
DI000785 Total effort
Total effort of the task. The value is determined during scheduling as a sum of actual and remaining (manual input not possible).
Initially planned costs of the task. The value is determined (summarized) from the values of the child areas (levels) during scheduling. Manual input is not possible. See calculation/summarization
Calculation/summarization
Task:Planned costs = sum of Planned costs of all resources assigned to the task (except revenue resources).
Resource assignment:Planned costs = sum of all Planned cost values per day of the resource assigned to the task.
Load: Planned costsper day of the resource assigned to the task. On this level, the actual cost calculation takes place.
DI000697 Actual costs
Actual costs of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Structure of the determination of values by areas (levels) from top to bottom:
Task:Actual costs = sum of Actual costs of all resources assigned to the task (except revenue resources).
Resource assignment:Actual costs = sum of all Actual cost values of all resources assigned to the task.
Load:Actual costs per day of the resource assigned to the task. At this level, the actual cost calculation takes place.
DI000698 Remaining costs
Remaining costs of the task. The value is determined (summarized) during scheduling from values of the subordinate load areas. Manual input is not possible. See calculation/summarization
Total costs from the active (last released) status report
DI059703 Total effort (active SR)
Total effort from the active (last released) status report
DI001096 Project ID/ID461
Technical ID of the project. The ID is automatically read out from the corresponding project.
DI001097 Project ID
Technical ID of the project. The ID is automatically read out from the corresponding project.
DI001110 Priority
This parameter serves to define the task priority manually Controls, along with other parameters, the sequence in which tasks are loaded within a project.
Details
The loading sequence of tasks which are parallel in the network and which are not linked via Links is established in accordance with their priority.
If parent and child tasks have the same priority in a structured schedule, the parent task receives the higher priority due to the task’s higher rank.
Example
Summary task A (Priority 2)
Task A.1 (Priority 1)
Task A.2 (Priority 3)
Summary task B (Priority 1)
Task B.1 (Priority 2)
Task B.2 (Priority 4)
The loading sequence for this example is as follows: B, A, A1, B1, A2, B2.
Values
0 or empty: highest priority
1: second highest priority, etc.
Technical details
The value range of the field checks for the @G296 global variable via which you can set the maximum priority value that can be entered.
If you, e.g., want to work with priority values from 0 to 10, you should enter 10 in the variable. Numbers up to 999 are permissible.
In PLANTA standard, the maximum permitted value is preset by default.
The parameter can be edited in the following modules by users with modification rights:
The parameter defines whether the calculated dates result from the earliest or latest calculated dates. Earliest and latest dates only differ if the respective task has a float.
In order to be able to use the Planning early = (deactivated) parameter, you have to enter a requested end date or end dates of the project on the respective tasks, so that there is a starting point for backward scheduling.
A task with deactivated Planning early checkbox is planned at 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 Link total float = 0 (red line).
Planning early parameter has no effect on a summary task. The summary tasks receive their dates from the child tasks. On child tasks, the Planning early parameter has the same effect as on unstructured tasks. If the child tasks have both Planning early = as well as Planning early = , the Calculated start receives the Earliest start of all child tasks from the summary task and the Calculated end receives the Latest end of all child tasks from the summary task.
Successors of tasks with deactivated Planning early checkbox are also moved. See the figure.
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the Entire Schedule module variant (can be displayed in further module variants)
The respective data field is hidden by default and can be unhidden by the user if necessary.
Task in the parameters relevant for scheduling area
Typical application in practice
Certain tasks should be planned as late as possible since they tie up a lot of capital, e.g. purchase, production. Other tasks should be planned as early as possible since adherence to schedule is uncertain, e.g. construction. By proceeding like this, construction has a certain float.
DI001114 Requested end
Requested end date of the task.or of the quality gate You can also specify a requested start date for tasks. Task requested dates determine the start or end of the task unless other restrictions prevent this (e.g. links). For details on requested dates, please see Requested start.
Details on Quality Gates
In the Quality Gates module, a traffic light is stored on the Date (requested end) field which behaves as follows:
As long as the quality gate is not completed by 100%, the traffic light is
red if the desired end date is in the past.
yellow if the required end date is today.
green if the required end date is in the future.
As soon as the quality gate is completed by 100% (entry 100% in the Completed field), the traffic light turns green.
The parameter can be edited in the following modules by users with modification rights:
Requested start date of the task. Task requested dates determine the start and end of the task unless other restrictions prevent this (e.g. links).
Details
Requested dates (Requested start/end) are taken into account during scheduling depending on the settings of the Task requested dates model parameter. They are only adhered to if the structure of the network (i.e. the dates for the predecessors) permits it.
Task requested dates prevent capacity adjustment for the respective task if Req. start and/or Req. end have been entered on the task.
They take priority over the Planning 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 load profile CAP, the task may be extended if there is an overload.
In the PLANTA standard, the requested dates of the tasks are visualized by blue triangles.
You can prevent task requested dates from being shifted by using the Fix parameter.
Midpoint scheduling is an example for the use of requested dates on tasks
It means the planning of a project around a central date (midpoint scheduling).
For this purpose, set a task requested date for the task which marks the central date and schedule the tasks which lie before it for the latest possible date and schedule those which come after it for the earliest possible date.
The parameter can be edited in the following modules by users with modification rights:
Calculated start date of the task. The value is determined during scheduling by taking into account different planning factors, e.g. whether a task is to start on its earliest or latest calculated date, whether there is a requested start date or a predecessor which determines the start date, etc.
DI001120 Calc. end
Calculated end date of the task. The value is determined during scheduling by taking different planning factors into account.
DI001121 Actual start
Actual start date of the task. Task actual dates dominate links, task requested dates, and the Planning early parameter.
Calculation
The actual start date
can be set manually
During scheduling, the task start date is then automatically copied to all resource assignments of the task which have no actual end date yet.
or it is copied from Actual start of the resource assignment during scheduling, provided that they have an Actual start. Otherwise it will be left empty.
If there are several resource assignments with different Actual start, the earliest Actual start will be applied to the task. For the actual end, the opposite is true: the latest Actual end of the resource assignment will be applied to the task.
Note on actual dates
If an Actual end is set without an existing Actual start, then Actual start = Actual end
Tasks with an Actual start or an Actual end behave during scheduling as in calculation with adherence to schedule, i.e. no capacity adjustment takes place. If the remainder of the task is to be adjusted anyway, it must be split with the help of the Split parameter.
Correlation of actual dates and links
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 a successor in an ES link has already started (Actual start is set), without its predecessor having started yet, the predecessor has total float up to the project end after the calculation of the schedule.
A task which has been started even though it possesses a predecessor which has not been started, usually indicates an actual 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 against such infringement of link conditions, i.e. the links which have become meaningless are ignored during 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 this is not desired, you have the following options:
By defining an additional FF link between these two tasks, the buffer time of the predecessor can be influenced.
Activate the Planning early checkbox. The capacity dates are then OK, the float times are not.
Additional links to the successor of the direct successor "for safety purposes". Simple when using standard network plans, otherwise maintenance effort might be high.
Only introduce a new link if you note that the task is kept 'hanging'. Disadvantage: If you ignore this, the planning data will be incorrect.
Use of FF conditions, where the assumption is made that the predecessor will start "soon".
Actual end date of the task. Task actual dates dominate links, task requested dates, and the Planning early parameter.
Calculation
Actual End Date
can be set manually
During scheduling, the task end date is then automatically copied to all resource assignments of the task which have no actual date yet.
or it is automatically set during scheduling if an actual end date has already been set for all resource assignments of the task.
Actual end of the task = latest Actual end of all resource assignments if all resource assignments have an actual end.
Notes on Actual end
If there is an Actual end, the Remaining duration = 0, i.e., if there still is remaining duration when the actual end is set, it will be set to zero (deleted).
Tasks with set Actual end are not considered in some user modules (e.g. My Activities) and are not displayed.
Note on actual dates
If an Actual end is set without an existing Actual start, then Actual start = Actual end
Tasks with an Actual start or an Actual end behave during scheduling as in calculation with adherence to schedule, i.e. no capacity adjustment takes place. If the remainder of the task is to be adjusted anyway, it must be split with the help of the Split parameter.
For quality gates
Date of approval of the quality gate by the portfolio manager. From this point onwards, the quality gate is considered completed. The date is automatically set as soon as the portfolio manager has activated the Approval checkbox on the quality gate.
The parameter can be edited in the following modules by users with modification rights:
Earliest start date of the task. The value is determined during scheduling by taking into account different planning factors and immediately becomes the calculated start of the task if you have selected the Planning early = parameter.
Earliest start date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any). Taking soft links into account may lead to a deviation to the Earliest start date of the task.
DI009344 Earliest end soft
Earliest end date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any). Taking soft links into account may lead to a deviation to the Earliest end date of the task.
DI009345 Latest start soft
Latest start date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any) Taking soft links into account may lead to a deviation from the Latest start date of the task.
DI009346 Latest end soft
Latest end date of the task which is determined during scheduling and in which the soft links of the task are taken into account (if there are any) Taking soft links into account may lead to a deviation to the Latest end date of the task.
DI009351 Start of the successor shift
Date on which the task successor shift starts. A task successor shift can occur when a task has a soft link. For this purpose, see Soft link.
DI009352 End of the successor shift
Date on which the task successor shift ends. A task successor shift can occur when a task has a soft link. For this purpose, see Soft link.
DI009353 Successor shift (days)
Duration of the task successor shift in days. A task successor shift can occur when a task has a soft link. For this purpose, see Soft link.
DI001123 Structure start
Structure start date of the subproject
Calculation
Structure start of the task = Calc. start of the subproject
DI001124 Structure end
Structure end date date of the subproject
Calculation
Structure end of the task = Calc. end of the subproject
DI001131 Planned duration
Initially planned duration of the task in working days. Normally, this field is filled automatically if a value is entered in Remaining duration.
Actual duration of the task in working days. The duration can either be specified by the user or it is determined on the basis of the other parameters during scheduling. As long as no actual start date has been set, the duration entered or calculated here becomes the planned duration and is automatically copied to the Planned duration field.
Details
If a TA duration has been entered or calculated via TA Req. start and TA Req. end), this duration has the highest priority.
you can enter the planned duration manually in the Remaining duration field
or have it calculated
from the requested dates of the tasks
if the task is defined as a hammock task
Calculation overwrites manual input. I.e. requested dates or hammock tasks (without requested dates) have priority, i.e. they overwrite manual input.
from the duration of the resource assignments (calculated from MAN, CAP with max. load or the requested dates of the resource assignment). If there are several resource assignments, the Remaining duration of a task is calculated from the maximum of the duration of the resource assignments.
If there is a remaining duration on the task (entered manually or determined during scheduling) and if there is also a remaining duration on the resource assignment which results from the requested dates and deviates from the task duration, the task duration will be overwritten.
If there is a remaining duration on the task (entered manually or determined during scheduling) and if there also is a remaining duration on the resource assignment which is not determined from the requested dates and deviates from the task duration, the highest of both values is used for the task, regardless of whether it has been entered or calculated.
This only applies if no requested dates are entered on the task itself. Requested dates of the task always override the requested dates of the resource assignments.
the Remaining duration is calculated during scheduling as follows:
Remaining duration = initial Remaining duration - change in Actual duration
the automatically calculated value, however, can be adjusted manually if necessary (e.g. if the duration is determined from the prognoses). Manual entries will not be overwritten during calculation of the schedule, provided that no requested dates exist which may account for a deviating duration.
If there is still remaining duration when setting the actual end, it is set to zero (deleted).
Planning with adherence to schedule:
CAP does not shorten and extend the task duration, but the capacity adjustment within the task duration still takes place.
When working with MAN, it is recommended not to work with manually entered durations but to calculate the duration based on the resource assignment or to predefine requested dates on the task.
Requested dates on the resource assignment will only be taken into account within the task duration. In case task duration = 0, they will only be taken into account within the calc. Start and latest end of the task are taken into account. Logic: Resource planning can only take place within the task duration.
Planning with adherence to total float:
CAP can prolong the task duration up to the latest end of the task.
Planning with adherence to capacity
As hitherto, CAP can extend the task duration up to the planning horizon of the resource.
Percentage share of the actual effort (Actual effort) of the task with respect to the total effort (Actual effort + Remaining effort). The value is determined during scheduling.
If the schedule calculation stops due to a network cycle, this parameter will be activated for every task involved in the cycle (). After the cycle has been removed, this field will be deactivated again in the next calculation of the schedule ().
DI001149 Task release
This field is set automatically during scheduling (cf. the Task release model parameter) or it can be set manually. In order to use the Task approval parameter, individual customizing adjustments to the required modules is necessary. The task approval parameter does not interact with the Task locked parameter. Both are independent of one another.
The parameter can be edited in the following modules by users with modification rights:
The respective data field is hidden by default and can be unhidden by the user if necessary
DI001177 Deviation: req. end - calc. end end
Deviation of the task requested end date from the calculated end date
DI001488 Hammock task
Parameter with the help of which you can "stretch" a task over the entire duration of the project. This is used, e.g., for recurring, project-related activities (basic load).
If the hammock task has no further restrictions, Planned duration and Remaining duration are determined according to the calculated dates of the project.
If the hammock task is embedded in the operation structure via links, it is only stretched over parts of the project.
If the requested end date is in the past, the calculated end date of the hammock task is today (if there is a link to the summary task, the calculated end date is tomorrow).
If the actual start date is not set, the duration calculated initially is retained and the hammock task is completely moved forward, causing a delay.
If the actual start has been set, the duration is reduced in accordance with the date progression.
The respective data field is hidden by default and can be unhidden by the user if necessary.
Task in the parameters relevant for scheduling area
DI002001 Bar: requested dates
Bar for the visualization of the time interval between the requested dates (Requested start and Requested end) of the task
DI002002 Bar: earliest dates
Bar for the visualization of the time interval between the requested dates (Earliest start and Earliest end) of the task
DI002003 Bar: latest dates
Bar for the visualization of the time interval between the requested dates (Latest start and Latest end) of the task
DI002005 Bar: actual dates
Bar for the visualization of the interval between the actual dates (Actual start and Actual end) of the task
DI002086 Bar: actual start - work reporting date
This bar can be used to visualize the progress of the task over time.
DI061285 Bar: MMS large
Bars (Rhomb symbol) for the visualization of the master milestones (gates) in the schedule on the horizontal axis below the scale
Details
The number on the bar represents the time interval (in weeks) to the master milestone or, if no milestone is defined as a master milestone, the time interval to the Calc. end of the project.
The number above the bar is the WBS code of the master milestone.
DI061313 Difference from main milestone date
Time interval to the main milestone or, if no milestone is defined as a master milestone, the time interval to the Calc. end of the project in weeks
DI002346 Number of task-resources
Number of resources which are assigned to the task
DI002379 Number of links
Number of links to successors of the task, i.e. all outgoing links of the task. Here, all link types are counted: internal links, external links, and also external tasks.
Code that signalizes whether the task is a parent task that has a subproject. Is used as a selection and sorting criterion in special modules and serves to hide the parent tasks.
DI002621 Project name
Name of the project. Is automatically read from the main project.
DI002859 Phase
DI002951 Bar: calculated dates
Bar for calculated dates (Calc. start and Calc. end) of the task
DI003681 Duration from requested dates
Duration from requested dates of the task
DI006527 Bar: milestone
Bar for milestone
DI006786 Milestone ID
Code (ID) for the Milestone parameter. For description, see Milestone: text. In standard, the parameter can be found in window 2 of the Schedule module.
DI059007 Milestone
This parameter serves to define whether the task is a regular task, a milestone, a master milestone, or a quality gate.
Values
Empty: No milestone
1: milestone
2: master milestone
3: Quality gate: This value cannot be selected manually for tasks in the Schedule module, but it is automatically set for tasks which are defined as quality gates in the portfolio.
Milestones and master milestones mark event times in a schedule.
Master milestones are used for particularly important events or dates that are important for achieving project goals, for example.
Milestones are used for less important events.
Some analyses in PLANTA project only consider master milestones.
From a technical point of view, milestones and master milestones are treated during scheduling like regular tasks, i.e. they can also have a duration > 0. However, PLANTA recommends that you use milestones and master milestones as event points with a duration of 0 or 1 since this is the common procedure in practice and PLANTA has optimized modules and symbol layouts for the use of this planning model.
If you want to plan milestones/master milestones with a duration = 0, you have to comply with some requirements:
General rule in PLANTA project: If tasks are connected with "EA" links and if the milestone has a duration = 0, the milestone starts on the very day on which its predecessor ends.
At what time the successor of the milestone starts if such a constellation is given depends on the Start task successor + 1 day model parameter.
Example
If Start task successor + 1 day = and the MS duration = 0, both the MS as well as the successor of MS start on the very day on which the predecessor of MS ends. I.e. in this constellation the milestones virtually "shorten" the project duration compared to the constellation without milestones.
Cf.
If Start task successor + 1 day = , and the MS duration = 0, the MS starts on the same day as its predecessor, the successor of MS, however, starts one day later, so that the constellation for the project duration with or without milestones is identical.
In the milestone planning, PLANTA also supports further planning models, like e.g. no links of milestones or milestone duration = 1. As in the examples above, different effects on the overall schedule must be taken into account.
When working with milestone duration = 0, the additional effect of task requested dates is to be taken into account:
If both dates are set, the duration is automatically calculated from these values and can never be = 0.
The parameter can be edited in the following modules by users with modification rights:
Name (text) of the Milestone parameter. For description, see DI059007
DI006800 Functional completed in %
Functional degree of completion of a task in percent. This value can be entered manually by the project manager as an estimation value.
The entered value is compared to the values in the Used (Effort used in %) field, and, depending on whether these values are under- or overrun, the Completed (DI006800 Functional completed in %) field is colored green or red.
The parameter can be edited in the following modules by users with modification rights:
This parameter can be used to flag processes that are intended for a specific group of people, e.g. customers. The Customer Schedule module variant then shows this selected view of the schedule.
Values
- the task is displayed in the Customer Schedule module variant.
- the task is not displayed in the Customer Schedule module variant.
The parameter can be edited in the following module by users with modification rights:
In the calculation of the schedule, information on the parent task, such as duration and dates, is determined automatically from the child tasks.
Caution
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 at this level. This also includes resource planning or time recording directly on the summary tasks. Instead, PLANTA recommends that you carry out your planning exclusively on child tasks.
Reason: Since scheduling detects some parameters of the summary tasks from child tasks, there may be collisions between your own planned values and those detected during scheduling. As a result, there may be values on summary tasks that are incomprehensible at first sight.
Code (ID) of the parent task which is set when structuring the tasks
DI008851 must not be confused with DI001004 Parent task ID on the project, which has the same name but a completely different function. DI001004 Parent task ID is filled with the structure task ID from the parent project when structuring a project.
DI059257 Structure task
The parameter defines whether the task in question is a normal or a structure task.
Values
0 = normal task
1 = structure task
Details
After projects have been structured and the schedule has been calculated, a structure task is created automatically in each parent project. A structure task is a task which connects a parent project to a subproject.
In standard, structure tasks are hidden in all modules in question by default and cannot be unhidden by the user. This is to be observed for individual customizing as well.
In order to hide structure tasks, include DI059257 Structure task in the corresponding data area and set the Filter from = 0 and Filter to parameters = 0 for this DI.
Bar for the visualization of the interval in which the tasks overlap. For more information, see here.
DI009480 Fixing ID
Code (ID) of the Fixing parameter. For description, see DI056886
DI056886 Fixing
Fixing options for requested dates This parameter serves to set how requested dates of the task are taken into account during scheduling. In input mode, a listbox for selection of a fixing position is displayed on the respective field.
Code
name
Meaning
Example
blank:
Without fixing
Requested dates of the task only take effect if no links exist and no capacity adjustment is carried out. Otherwise the task can be shifted, e.g. via links or capacity adjustment.
1
With fixing
The task is scheduled exactly for the requested dates.
The task duration corresponds to the specified requested dates
Links will be ignored.
Capacity adjustment is deactivated.
The resources are planned within the task requested dates. If their capacity is insufficient, they are overloaded.
Active today's line will be ignored.
Only takes effect if at least one requested date is set.
2
Without fixing, adherent to schedule
No fixing, however date-oriented scheduling of task resources within the planned duration of a task.
Links will be taken into account, the task may be shifted.
Capacity adjustment is deactivated.
For Planned duration of the task = 0, the task duration is determined as the maximum duration from all resource assignments.
The resources are planned within the task requested dates. If their capacity is insufficient, they are overloaded.
Loading of Max. load/day for the remaining duration period.
For Planned duration of the task = 0, the task duration is determined as the maximum duration from all resource assignments.
For data logical and data consistency reasons, tasks that have already been defined as hammock tasks (Hammock task parameter is activated) must not be frozen.
The effect of the Fixing parameter is overwritten by the Task requested dates model parameter..
Using the Fixing parameter = 1 in combination with particular other parameters may result in a scheduling problem. For further informations, see here.
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the Entire Schedule module variant (can be displayed in further module variants)
Symbol for the visualization of the temporal progress of the task
Details
If an Actual start has been set for the task, the progress symbol will be blue.
If an Actual end has been set for the task, the progress symbol will be black.
DI057005 TDI: 1
Technical data item. It is used to visualize the number of tasks in different modules. E.g. in the Activities area (Todo items up to DB 39.5.0) in the Dashboard module, the number of process steps is displayed by 4 statuses (late, today, future, without date).
DI057577 Date status
Text for the date status (e.g. today, delayed, etc.) of the tasks
DI057950 Parent task name
Name of the parent task
DI058050 Deviation calc. Start: current - selected SR
Deviation of the calculated start date of the task from the current planning from the calculated start date of the task from the selected status report
Symbols for a note or estimation of the task. For new tasks for which there were no notes or estimates before, no symbols are displayed here initially.
Values
no symbol - no note
- completed
This symbol will automatically be displayed/hidden as soon as the Actual end date has been entered/deleted for the respective task, or can be set/deleted manually. All other symbols are set/removed manually by clicking on the Change note button in the respective task line in the Schedule module ( not in all module variants), in the Task module or in the respective task checkbox in the WBS module.
- very critical
- critical
- being monitored
- very good
- mediocre
- bad
The symbols can be edited by the customizer in the OLEs module.
DI040925 OLE milestone
Rhomb symbol for master milestones or milestones in the WBS module
Values
Light blue rhomb - milestone
Black rhomb - master milestone
DI059707 OLE deviation total effort: current - active SR
DI059708 OLE deviation total costs: current - active SR
Traffic light for the visualization of the deviation of Total costs from the current planning from Total costs from the active (last released) status report in the Dashboard in the Deviations area
DI059020 OLE deviation total costs: current - selected SR
Traffic light for the visualization of the deviation of the Total costs (from the current planning) from the Total costs (from the selected status report in the Deviations module)
DI059021 OLE deviation total effort: current - selected SR
Traffic light for the visualization of the deviation of the Total effort (from the current planning) from the Total effort (from the selected status report in the Deviations module)
DI059022 OLE deviation calc. end: current - selected SR
Traffic light for the visualization of the Calc. end from the current planning from Calc. end from the selected status report
DI059023 OLE deviation calc. Start: current - selected SR
Traffic light for the visualization of the Calc. start from the current planning from Calc. start from the selected status report
DI059710 Deviation total effort: current - active SR
Name of the person responsible for the task. In input mode, a listbox for selection of a person responsible is displayed on the respective field.
If a resource is defined as a person responsible for a task, this task is displayed in the Tasks area of the My Planning Objects module in the Employee Board of the resource.
The parameter can be edited in the following modules by users with modification rights:
By setting a task requested end, a task has no float with respect to its calculated end date
If tasks are planned late (Planning early = ) parameter = Total float = 0.
To get a more exact overview of the latest dates, it may help to activate the display of the latest dates bar from window 9.
Details
To visualize the tasks as critical or uncritical, the traffic light circuit of the task bars is based on the Total float parameter. Thus
regular tasks which have total float < = 0 are visualized as critical.
milestone and master milestone tasks which have total float < 0 are visualized as critical.
Since in PLANTA projecttotal float = 0 can be achieved by setting requested dates on tasks, tasks which do not necessarily lie on the critical path are marked as critical.
If you do not want this to happen, you have to plan with task duration or with task requested start dates and task duration only.
Taking floats into account in different planning types
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 will not be taken into account.
DI001130 Free float
Free float of the task. The free float is determined from the minimum of all successor links.
For tasks without successor, "free float" = "total float”
The latest date on which hours worked were recorded on the task. This date corresponds to the latest time recording date of all resource assignments of a task. If the task has no resource assignments, please take note of the information set out below.
Calculation
If there are no resource assignments,
the time recording date of the task is set to the Actual start of the task if it already exists but no Actual end has been set yet.
the time recording date of the task is set to Actual end as soon as one exists.
the time recording date of the task = 0 if none of the actual dates exists.
DI063726 Deviation: req. end - calc. end end (text)
Absolute deviation of the calculated end date from the requested end date of the task with text specification (delay/float)
DI063937 SAP WBS element
Name of an SAP WBS element. In input mode, a listbox is displayed on the respective field via which you can select an SAP WBS element and assign it to a PLANTA task. This link is required for transferring costs and effort from the project structure in PLANTA project to an alternative structure (e.g. an SAP project structure).
The parameter can be edited in the following modules by users with modification rights:
Schedule (project/proposal) in the SAP WBS elements module variant (can be displayed in further module variants).
Position number of the quality gate within the quality gate template. It is allocated manually upon creation of the template and defines the sort order of the quality gates within the quality gate template.
The parameter can be edited in the following module by users with modification rights:
Checkbox used to approve a quality gate. In the course of this, an Actual end date is set automatically (in the Quality Gates module the field is named Approved on) and the quality gate will be considered completed.
The parameter can be edited in the following module by users with modification rights:
DI064510 Quality gate completed in % (traffic light)
Displays the degree of completion according to percentage values and traffic light colors. The value displayed here is calculated from the degree of completion of the assigned tasks and their priorities.
Values
no traffic light: the degree of completion of the quality gate is lower than 100%.
green: the quality gate is completed by 100%.
The completed value of the quality gate influences the behavior of the traffic light on the Date field.
DI064994 Completed on: Manager
Date, on which the quality gate was completed. Is set by the manager of the respective project. If the field is filled, the Completed on field of the child todo items which have no completed date yet are automatically filled with the date of the quality gate.
DI064760 Time interval
Time interval to the date selected for the calculation of the date of the quality gate selected in the Start field.
The parameter can be edited in the following module by users with modification rights:
Parameter which defines whether the task is to be regarded as critical. The value is set during scheduling.
Tasks the total float of which = 0 are marked as critical and therefore lie on a critical path.
Exceptions: Isolated tasks which have no predecessors or successors (i.e. which are not inter-connected via links) are not marked as critical, even if they do not have total float, unless they determine the project length.
Details
Tasks which are planned late do not have a total float by definition and are critical.
For each requested date (project requested end date or task requested end date) there is a critical path in the project. A task can also belong to several critical paths. If there is project float, a task can be critical anyway if it belongs to a critical path which is generated by a task requested date.
Summary task are marked as critical (however, they are not visualized in the schedule) if at least one child task is critical.
With Server 39.5.25, PLANTA only provides the parameter for the calculation of the critical path. If you want to visualize the new critical path in the schedules, you have to make the respective customizing adjustments individually and embed the parameter in the task bars.
Parameter which defines whether the task lies on the longest critical path. The value is set during scheduling.
The classical critical path (cf. CPM) ends on the project requested date and is therefore always the path with the longest duration.
With Server 39.5.25, PLANTA only provides the parameter for the calculation of the longest critical path. If you want to visualize the longest critical path in the schedules, you have to make respective customizing changes and embed the parameter in the task bar.
Parameter which determines whether tasks are to be broken off (split) in editing
Details
Any task which has been started will be loaded adherent to schedule, starting from its actual start date. 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 there was no actual data. Capacity adjustment can thus also be carried out for the task remainder.
The parameter is activated in PLANTA standard by default ().
Splitting only has an effect on tasks which have already been started (Actual start reported) but are not yet completed (no Actual end reported).
Values
: The task will be scheduled as if it had no Actual start yet. This corresponds to an interruption of the task.
: The task is scheduled continuously from the Actual start.
It can be reasonable to already set particular tasks to Splitting = in planning, if it is known that these tasks are usually interrupted.
If a capacity adjustment is to be carried out for a task that has already started, the setting should be Split = .
If a split task is to be worked on continuously at a later time, Split can be reset to .
Show example of application...
Typical application in practice
A project team member has reported a couple of hours on the Construction 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.
Task before entry of hours worked:
Resource Benjamin Fischer has reported 5 hours of work to the Construction task. The task is not split. After calculating the schedule, the following situation arises:
Work on this task is not to be continued but scheduled for a later point in time. By setting Split = , the rest of the task will be planned according to the network plan. It is also removed 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 a task, then the remainder of the task may be planned at an even later date.
If the parameter of the same name (Split) is activated at project level and Split is deactivated on the task, the project parameter overwrites the task parameter; but not the other way around.
If the parameter is set on a summary task, it causes the Calc. start of the summary task to be the earliest Calc. start of all child tasks. This may cause an unnecessary shift of dates. Cf:
The parameter can be edited in the following modules by users with modification rights:
Checkbox for the selection of a task. The checkbox is used in different user modules, e.g. in the Assign Tasks module.
DI066380 Number of pending/all cards
Shows the number of all pending cards and the total number of pulse cards which belong to a task. Is displayed in the Scheduleif a task has been synchronized with PLANTA pulse and if there are cards on the corresponding board. A link is stored on the field via which you can view the cards in the Task module.
DI066418 Number of cards
Shows the number of all pulse cards which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066416 Number of pending cards
Shows the number of pending pulse cards which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066473 % of pending cards
Shows the percentage of pending pulse cards which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066382 Number of overdue cards
Shows the number of overdue pulse cards (due date lies in the past) which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066422 % of overdue cards
Shows the percentage of overdue pulse cards (due date lies in the past) which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066417 Number of completed cards
Shows the number of completed pulse cards which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
DI066381 % of completed cards
Shows the percentage of completed pulse cards which belong to a task. Is displayed in the Task module if a task has been synchronized with PLANTA pulse.
JavaScript errors detected
Please note, these errors can depend on your browser setup.
If this problem persists, please contact our support.
