Understanding Project Task Scheduling

To manage a project successfully over a period of time, the project manager must be able to create a project schedule that accurately reflects the time that is required to purchase and manufacture products that are needed to complete the project. Effective time and resource management is a high priority in today's business environment. Accordingly, JD Edwards EnterpriseOne Engineer to Order enables you to:

Schedule projects using standard project constraints, such as task dependencies, fixed tasks, and resource availability.
Import or export to Microsoft Project.

As you add tasks to the WBS for the project, you must indicate how much time is required to complete each task. For summary tasks, you must enter durations manually. For work orders, the system retrieves the duration from the level lead time that is defined for the item in the Item Branch program (P41026). It calculates the start and end dates for the task by using the duration and the system's scheduling function.

You use task dependencies to specify the sequence in which the project tasks must be performed. The types of available task dependencies enable you to schedule overlapping tasks; that is, the earlier task (predecessor) can still be incomplete when the next task (successor) starts. You can use lag time in addition to the dependencies to structure the sequence of tasks. These four types of task dependencies are available:

Finish to Start (FS). The predecessor task must be finished before the successor task can start.
Finish to Finish (FF). The predecessor task must be finished before the successor task can be finished.
Start to Start (SS). The predecessor task must start before the successor task can start.
Start to Finish (SF). The predecessor task must start before the successor task can be finished.

When defining task dependencies in JD Edwards EnterpriseOne Engineer to Order, you must observe these rules:

You can establish dependency links between parent tasks, but not between parent and related child tasks.
You can create a dependency between a parent task and a child task that is not related to the parent task.
You cannot create a reverse link between tasks that are already linked. This rule helps you avoid creating a circular relationship.

You define task dependencies for subtasks that are on the same level. In this case, the planned start and end dates depend completely on the defined task dependencies.

The system enables you to modify the predecessor and successor in task dependencies, as well as enter and revise other fields relating to the task dependencies. Task dependencies are accessible in the Edit Task Dependency region of the Edit Tasks and Edit And Lock All Tasks forms in Project Workbench.

When you select a task in the project, it then appears as the successor task in the Edit Task Dependencies region. You define predecessors for the chosen task either by typing in the predecessor task number or by using a search button.

The system validates dependencies during entry to check for invalid dependencies. This functionality is similar to the functionality of MS-Project. Validation occurs when you press Tab to move out of the dependency line that you created. The system issues an error message for invalid dependencies. This table lists the dependency types that are validated:

Dependency Type	Definition
Indirect circular dependency	Indirect circular dependencies are created when a circular dependency exists across the level. Indirect circular dependencies occur: While you are creating the dependencies for the tasks in the dependencies form. For example, two parent tasks have a dependency defined between them. Another dependency is defined between one of the parent tasks and the other parent's child task. The implicit dependency between a parent and child is considered as a bidirectional dependency. While you are moving the task from one place to another. For example, two parent tasks have two children tasks. A dependency is defined between the two parents. A dependency is also defined between the two child tasks. If one of the child tasks is moved to the other parent, an indirect circular dependency is created. Any dependency between two tasks that results in a circular dependency is an invalid dependency.
Direct circular dependency	Direct circular dependency occurs only while you are creating the dependencies for the tasks in the Edit Task Dependencies region of the Edit Tasks and Edit And Lock All Tasks forms in the Project Workbench. A direct circular dependency is created when a circular dependency is on the same level or irrespective of the levels. This works for the first level but not the other levels. Direct circular dependency can occur when two child tasks of two different tasks have dependency defined twice. That is, one dependency is defined as Predecessor-Successor and another is defined as Successor-Predecessor. Another example of a direct circular dependency is the dependency that is defined between task A to B, B to C, C to D, and D to A.
Parent-Child dependency	An explicit dependency exists between a parent task and its child task. Explicit dependencies between parent and child occur: While you are creating the dependencies for the tasks in the Edit Task Dependencies region of the form. While you are moving the task from one place to another. Consider that two parent tasks are in a project. One of the child tasks has an explicit dependency with the other parent. If the child task is moved in to the task that has an explicit dependency, then it creates an implicit dependency between the tasks that leads to a parent child dependency error. Both an implicit and explicit dependency cannot exist between two tasks. The system issues an error message to the user that an error occurred while the user was creating the task dependency that is parent/child.
Duplicate dependency	Two dependencies cannot be identical.
Self dependency	The predecessor and successor task cannot be the same.

Project Workbench enables you to define the type of tasks that pertain to scheduling. You can mark individual tasks as fixed or non-fixed to lock down an individual task. Fixed tasks have to be scheduled in the time window that is assigned and cannot be manipulated outside this boundary. Forward and backward scheduling respect the constraints that are related to task types as well as honoring dates and duration when scheduling the project.

This table lists the task types:

Task Type	Definition
Non-fixed Task	This task's position in time has not been set. Its dates can be changed either by the user or moved by the system when scheduling the project.
Fixed Task	Only the individual task is fixed. It is permanently set at a particular instance in time. The task cannot be automatically moved by the scheduling algorithm, and can be changed only by the user making manual modifications to the start and end dates of the task. A fixed task behaves differently at different levels. For a task which is at the lowest level, a fixed task means that both the start and end dates are set. However, for a task which is at a higher level and has at least one child, a fixed task means that only the task start date (in case of forward scheduling) or task end date (in case of backward scheduling) is set. The other date has to be calculated based on scheduling dependencies and the requirement that the parent task has to span the combined duration of all its children. Designating a task as a Fixed Task only causes no restrictions on the movement of its child tasks as long as they remain within the span of the parent task.

Task Type

Definition

Non-fixed Task

This task's position in time has not been set. Its dates can be changed either by the user or moved by the system when scheduling the project.

Fixed Task

Only the individual task is fixed. It is permanently set at a particular instance in time. The task cannot be automatically moved by the scheduling algorithm, and can be changed only by the user making manual modifications to the start and end dates of the task.

A fixed task behaves differently at different levels. For a task which is at the lowest level, a fixed task means that both the start and end dates are set. However, for a task which is at a higher level and has at least one child, a fixed task means that only the task start date (in case of forward scheduling) or task end date (in case of backward scheduling) is set. The other date has to be calculated based on scheduling dependencies and the requirement that the parent task has to span the combined duration of all its children. Designating a task as a Fixed Task only causes no restrictions on the movement of its child tasks as long as they remain within the span of the parent task.

Forward scheduling enables the project manager to schedule tasks from a given start date. With forward scheduling, tasks are scheduled according to their duration and dependencies so that each task begins on its earliest possible start date.

JD Edwards EnterpriseOne Requirements Planning, which generates messages that recommend work order start dates based on backward scheduling, usually agrees with dates that are created by the backward-scheduling function of the Project Workbench program. With backward scheduling, a project manager can enter an absolute date by which the project must finish and schedule backward to determine the start date on which it must begin.

For both forward and backward scheduling, the Project Workbench program uses the task dependencies that you establish for each task to suggest correct start and end dates.

You can use the options on the Edit And Lock All Tasks form for forward and backward scheduling. If you change the dates or duration of a task, the system reschedules all tasks that depend on this task.

When you designate task types and perform scheduling, rules are in place to avoid infeasible schedules. This table lists the rules:

Task Level	Task Type	Rules
Parent Task	Fixed Task	The task start date, end date, and duration can be modified for a fixed task. The duration of a fixed parent task should be greater than or equal to the highest duration of any of its children tasks. If any direct child tasks are fixed, the fixed parent should span to encompass the span of all its fixed child tasks. Only the task start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.
Child Task	Fixed Task	The task start date, end date, and duration can be modified for a fixed task. If the direct parent task is fixed, the span of the child task should be encompassed within the span of the fixed parent task. If a parent task at any level above is marked as Fixed Structure task type, the span of the child task should be encompassed within the span of this fixed task. Note: A task can be a parent and a child at the same time, so both the preceding conditions can apply simultaneously. If the child task is at the lowest level in the WBS, both task start and end dates are set and cannot be modified by the scheduling algorithm. If the child task has other child tasks underneath, only the task start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.

When you move tasks within a WBS and perform scheduling, rules are in place to avoid infeasible schedules. This table lists the rules:

Move Task	Rules
Move existing Fixed Task to make it a parent task.	The start date, end date, and duration can be modified for a fixed task. The duration of a fixed parent task should be greater than or equal to the highest duration of any of its child tasks. If any direct child tasks are fixed, the fixed parent should span to encompass the span of all its fixed child tasks. Only the start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.
Move existing Fixed Task to make it a child task.	The start date, end date, and duration can be modified for a fixed task. If the direct parent task is fixed, the span of the child task should be encompassed within the span of the fixed parent task. If a parent task at any level above is marked Fixed Structure, the span of the child task should be encompassed within the span of the fixed task. If the child task is at the lowest level in the WBS, both task start and end dates are set and cannot be modified by the scheduling algorithm. If the child task has other child tasks underneath it, only the task start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.

Move Task

Rules

Move existing Fixed Task to make it a parent task.

The start date, end date, and duration can be modified for a fixed task.
The duration of a fixed parent task should be greater than or equal to the highest duration of any of its child tasks.
If any direct child tasks are fixed, the fixed parent should span to encompass the span of all its fixed child tasks.
Only the start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.

Move existing Fixed Task to make it a child task.

The start date, end date, and duration can be modified for a fixed task.
If the direct parent task is fixed, the span of the child task should be encompassed within the span of the fixed parent task.
If a parent task at any level above is marked Fixed Structure, the span of the child task should be encompassed within the span of the fixed task.
If the child task is at the lowest level in the WBS, both task start and end dates are set and cannot be modified by the scheduling algorithm.
If the child task has other child tasks underneath it, only the task start date (for forward scheduling) or task end date (for backward scheduling) is pivoted. This prevents the user from having to manually balance the span depending on the duration of all its child tasks, which can be extremely cumbersome.

You can forward and backward schedule a project with fixed tasks. These rules apply to both forward and backward scheduling:

Scheduling includes a new return status to indicate the presence of infeasible schedules.
Scheduling does not modify both the start and end date of a fixed task that is at the lowest level and does not have any children.
Relationships between two fixed tasks are not honored, as the relationships has no meaning.

For forward scheduling:

Scheduling should not modify the start date of a fixed task that has children underneath it. However, the system can manipulate the task end date to honor the requirement that the date span of the parent must span the combined date span of its children.
The project start date could be affected due to the presence of fixed tasks.

When you are backward scheduling, these rules apply:

Scheduling should not modify the end date of a fixed task that has children underneath it. However, it can manipulate the task start date to honor the requirement that the span of the parent must span the combined span of its children.
The project end date could be affected due to the presence of fixed tasks.

The scheduling that is set up for fixed task scheduling must be validated. You can analyze the setup by clicking the Check for Conflicts button on Edit Tasks and Edit And Lock All Tasks. If you do not analyze the setup, the system performs the analysis when you save the schedule or perform scheduling.

The system determines whether the start and end dates of each task violate any explicit or implicit dependencies with another task on which the current task depends. The system also determines whether the task violates any time span rules resulting from fixed tasks. If the system finds a violation, the violating task is moved so that it no longer violates the dependency. However, if the system does not find any feasible direction to move without violating at least one of the dependencies, an infeasible schedule status is returned.

You run the scheduling algorithm by clicking the Schedule button on the Edit And Lock All Tasks form. If an infeasible schedule condition is met at any time during the scheduling process, the process stops and an error message appears. When the scheduling algorithm runs, it changes dates and durations of tasks, but only in cache, not to tables. If an error is found, the dates and durations that were changed in cache are changed back to their original values and are not saved to tables. The Scheduling Error Report displays the changed dates and durations so that you can compare them against the original values to get an idea of what caused the error. This is accomplished by saving the dates and durations that were changed into the Scheduling Error Report (F31PUI01) table before changing the values in cache back to their original values. The Scheduling Error Report runs over this table and deletes the contents for the user and project when the UBE has finished. The use of the Scheduling Error Report is controlled with a processing option in the Project Workbench (P31P001) program under the Scheduling tab.

After you set up project information in the Project Workbench program (P31P001), you can export the WBS to a third-party software program, such as Microsoft Project. You can use Microsoft Project to work with task durations and dependencies. You can then import task revisions back into the Project Workbench program. If you add or delete tasks in Microsoft Project, you cannot import these changes into the Project Workbench program.