About Tasks

Types of Tasks

A typical task is an activity that needs to be accomplished within a defined period of time or by a deadline. In addition, there are other types of tasks:

• Phase. A project can consist of multiple phases (for example, Define, Implement, Industrialization, etc.).
• Gate. Gates usually occur between phases and are basically high-level milestones. Gates usually represent a decision point and typically require a meeting and a checklist to determine if the project can move on to the next phase.
• Milestone. Milestones can appear anywhere in the task structure, but in a Phase->Gate project, they are usually associated with the phase. Milestones are zero-duration tasks and only represent an event within the phase.

Rules for Task Fields

The task structure for a project template does not contain % complete or start and finish fields, so these rules generally do not apply. The duration for tasks does roll up to the parent task and project template level.

Because the values roll up to the parent task, it is generally best to edit the values for the lowest-level subtasks and then let the system calculate the parent task's values.

When entering and modifying dates, note the following:

• If a predecessor or successor of a task conflicts with the entered date, the entered date is set as a constraint date and the date is set as the maximum allowed date by the predecessor and successor tasks.
• Parent task constraints are applicable to child tasks as well. If a parent constraint conflicts with the entered date, the entered date will be set as the constraint date and an alert message shows the conflicting parent task information.
• Summary task dates are derived from child tasks; if you change the date of a summary task an alert message displays information about the conflicting child task.

Results of promoting and demoting a task:

• If a subtask is promoted to In Approval and all its sibling subtasks are in at least In Approval, then the parent task advances to the In Approval state.
• When a task is demoted to a state and its parent is at a higher state, the system demotes the parent to the task's state. For example, if a top-level task is demoted from In Approval to In Work, the project is also demoted to In Work.
• A summary task’s state cannot be changed. It is always non-editable.
• When a task is promoted from the Draft state to the To Do state, its subtasks are not automatically promoted to To Do.
• When a subtask is promoted to In Work, the parent task advances to the In Work state, if it not already In Work.

Restrictions on promoting and demoting a task and project:

• A task cannot be demoted from In Work to To Do when one of its subtasks is In Work or beyond.
• A project cannot be demoted to To Do when it has tasks that are In Work or beyond.
• A task cannot be promoted to In Approval unless all of its child subtasks, including optional and mandatory subtasks, are promoted to at least In Approval.
• A project cannot be promoted to In Approval unless all of its tasks are at least at the In Approval state.
• When a project is promoted to the To Do state, tasks are not promoted to the To Do state. If you want to promote all the tasks to To Do, you can use the Mass Update function.
• A task cannot be promoted to Completed unless all of its child subtasks, including optional and mandatory subtasks, are promoted to Completed.
• If a task is associated with a DHF element, task completion is not allowed unless the task has a deliverable attached.
• A Completed gate cannot be demoted.

A project cannot be promoted to Completed unless all of its tasks are Completed.

About Percentage Complete Calculations

The system calculates the % Complete for a project using the following formula:

Sum of (% Complete * Duration) for all subtasks divided by the sum of 
subtask days

The system then rounds that value down to the nearest value available for % Complete: 10, 20, 25, 30, etc. Similarly, the system calculates the % Complete for a task by averaging the % Complete values for all of its subtasks. A project cannot be promoted to Completed unless all of its tasks are Completed.

About Percentage Complete Rules

Changing a task to 100% Complete promotes the task to In Approval, if the task has the "Needs Review" attribute set to "Yes". Because a task cannot be promoted to In Approval unless all of its subtasks are at least at In Approval, you cannot change a task to 100% unless all of its subtasks are at least In Approval (100% Complete).

Similarly, you cannot change a project's % Complete to 100% unless all tasks are at least at the In Approval state (100% complete).

About Start, Finish, and Duration

When you create a task, you enter the duration for that task. Project and DHF Management then calculates the estimated start and finish dates based on dependencies, where in the task structure the task was created, and the project's start or finish date (depending if the project is scheduled from the start or finish of the project).

For all estimated start and finish dates, any defined dependencies and parent task schedules are used to calculate the start/finish dates for tasks. See About Task Dependencies for more details.

The duration, start, and end dates roll up to the parent task and to the project level. For example, the duration for a parent task is the duration of the longest subtask, assuming there are no dependencies and all subtasks occur in parallel. If there are dependencies, the system takes them into account when calculating the duration. The end date for the parent task is the end date for the subtask having the farthest end date and the start date for the parent task is the start date for the subtask with the earliest start date.

When changing dates for tasks, Project and DHF Management recalculates that task and subsequent tasks to calculate a new project finish date when scheduling from the project start date. When scheduling from the project finish date, Project and DHF Management recalculates the task and all prior tasks to calculate a new project estimated start date. Note that the duration stays the same when either the start or end dates are changed. To change the task duration, you must change the duration manually.

A user can also manually enter the actual start date and end date for a task while in edit mode. If the project preference is set for the schedule to be based on actual dates, the project schedule is recalculated each time a user enters an actual date.

Beyond the Draft state, a task's estimated start date cannot be changed manually. However, the system internally can modify dates to satisfy dependencies or constraints applied on a task.

Following are some points about manually entering a start or end date:

• When you manually enter the actual start date for a task in the Draft or To Do state, the task will be promoted to In Work state.
• When you manually enter the actual start date for a task in the In Work, In Approval or Completed state, the Actual Start Date will be replaced by the newly entered date.
• When you manually enter the actual start date, the system promotes the task to Completed. If the task is manually promoted to Completed, the system automatically enters the Estimated date as the Actual End Date.

Scheduling Based on Project Start Date

When a project's schedule is based on a start date, Project and DHF Management does not have a fixed project end date and pushes out that date if an added task, based on dependencies and the critical path, requires it.

The start date for a task is based on prior tasks and dependencies. If a task is added and a dependency on the prior task is defined, Project and DHF Management uses the estimated finish date of the first task as the estimated start date for the added task.

If a project is scheduled from its start date, the project's estimated start date and estimated end date is re-based on the constraints and dependencies applied to its tasks. In this case, the project's estimated start date may or may not be same as the project's constraint start date (date given at the time of project creation). However, the project's constraint date remains constant.

When working with task dates, these rules apply:

• Once any of the tasks reach the In Work state, Project Leads can no longer change the estimated start date for the project. Before any tasks are In Work, the project start date can be changed. When it is changed, tasks that have the same start date as the project are changed to match the new project start date.
• The system skips weekend days, so if you add a task with a duration of 2 days and set its start date for a Friday, the system automatically sets the finish date for Monday.
• The duration and estimated end dates are linked so if you change the duration, the system changes the end date so it is that specific number of days beyond the start date. Conversely, if you change the end date, the constraint type "Finish No Earlier Than" is added to the task, a constraint date (new estimated end date) is added to the task, and the estimated start date moves according to the new estimated end date and duration.
• The duration, start, and end dates roll up to the parent task and to the project level. For example, the duration for a parent task is the duration of the longest subtask, assuming there are no dependencies and all subtasks occur in parallel. If there are dependencies, the system takes them into account when calculating the duration. The end date for the parent task is the end date for the subtask with the farthest out end date and the start date for the parent task is the start date for the subtask with the earliest date.
• You can only change the estimated start date for tasks that are in the To Do state. Tasks that are In Work already have been started. If you change the estimated start date, the constraint type "Start No Earlier Than" is added to the task, a constraint date (new estimated start date) is added to the task, and the estimated end date moves according to the new estimated start date and duration.
• When changing the estimated start date for a task in the To Do state, you cannot change to a date that is earlier than the parent task's estimated start date. The only exception is if the parecalculatednt task is also still in the To Do state, then the subtask's start date can be changed to an earlier date. Then the system changes the parent task's start date to that earlier date.

Scheduling Based on Project Finish Date

When a project's schedule is based on a finish date, Project and DHF Management uses an "as late as possible" method to determine task start dates. For example, if a project is defined to schedule from a project finish date of 6/20/2008, and you create a task at the end of the project with a task duration of 3 days, then the estimated start date for the task is 6/17/2008.

If a task is inserted as a sibling at the project level somewhere in the middle of the task structure, Project and DHF Management works back from the finish date, keeping task dependencies in mind, to recalculate the estimated start and finish dates for all tasks.

If a task is inserted as a child of another task, Project and DHF Management uses the finish date for the parent task as the estimated finish date for the inserted task, and uses the task's duration to calculate the estimated start date.

If a task is added and a dependency on the prior task is defined, Project and DHF Management uses the estimated finish date of the added task (and its duration) to re-calculate the task start/finish dates all the way back to the project estimated start date.

If you change the finish date for the project, Project and DHF Management re-calculates the finish dates for all tasks except tasks that have already started (are in the Draft state). When scheduling from the project finish date, you can change the project estimated end date if the project is in the Draft state. In the In Work state, the estimated end date can only be postponed.

If a project is scheduled from its finish date, the project's estimated start date and estimated end date is re-based on the constraints and dependencies applied to its tasks. In this case, a project's estimated end date may or may not be the same as the project's constraint end date (date given at the time of project creation). However, the project constraint date remains constant.

When working with task dates, these rules apply:

• Once any of the tasks reach the In Work state, Project Leads can no longer change the estimated finish date for the project. Before any tasks are In Work, the project finish date can be changed. When it is changed, tasks that have the same finish date as the project are changed to match the new project finish date.
• The system skips weekend days, so if you add a task with a duration of 2 days and set its finish date for a Monday, the system automatically sets the start date for Friday.
• The duration and estimated starts dates are linked. If you change the duration, the system changes the start date so it is that specific number of days before the finish date. Conversely, if you change the estimated end date, the constraint type "Finish No Later Than" is added to the task, a constraint date (new estimated end date) is added to the task, and the estimated start date moves according to the new estimated end date and duration.
• You can only change the estimated start date for tasks that are in the To Do state. Tasks that are In Work have already been started. If you change the estimated start date, the constraint type "Start No Later Than" is added to the task, a constraint date (new estimated start date) is added to the task, and the estimated end date moves according to the new estimated start date and duration.
• When changing the estimated start date for a task in the To Do state, you cannot change to a date that is earlier than the parent task's estimated start date. The only exception is if the parent task is also still in the To Do state, then the subtask's start date can be changed to an earlier date. Then the system changes the parent task's start date to that earlier date.
• You cannot change the project finish date to a date earlier than the finish date of any tasks in the project. Change the task with the latest finish date (and any other affected tasks) to an earlier date, then you can edit the project finish date.

About Task Constraints

Users defining a task within the task structure have the option to set the task constraint type to one of the following:

Even though constraint types and dates may be defined on a task, the task scheduling is still based on dependencies unless the dependencies cause the task start or finish date to conflict with its constraint at which the task constraint type overrides the dependencies.

The default constraint type for a task is based on whether the project is "scheduled from start" or "scheduled from finish." If the project is set to schedule from the start, the default constraint for a task is "As Soon As Possible." Otherwise, the default constraint for a task is "As Late As Possible." A user is able to override the default value.

The constraint type has an effect on the task estimated start and finish dates. The following use cases describe the task start and finish dates depending on how the task constraint is configured. Based on the overall project dates of 9/28/09 to 11/3/09, the use cases describe the start and finish date of each task based on the constraint type.