Understanding Tasks App Concepts

The following concepts are used in processes across the pages in the Tasks app. Processes such as creating tasks, identifying constraints, committing to tasks, and adding hand-offs between tasks occur regularly during daily or weekly planning sessions. They can be performed as many times as necessary and in any order.

Planning Period

The Planning Period enables a team of project collaborators to control the window of time that they want to focus on for planning and scheduling their task work. At the task level, short-term planning periods are ideal, such as displaying tasks for only the current week and the following week.

Tasks

Tasks are identified during planning as the physical work to be performed by the tradespeople on the project. Each task has a name, duration, and associated company responsible for performing the work on the task. A user within the assigned company can also be added to the task to indicate individual responsibility. A workspace-level or project-level code can be assigned to a task to help group and sort tasks. Task cards are colored according to the associated company's assigned color. Tasks can be assigned to project activities to view your CPM schedule in greater detail, but this is not required. A variety of indicators are available to ensure that tasks associated with an activity align with the activity's dates and status. Tasks can be public or private. Public tasks are visible to all users with access to the app and the project, regardless of their company assignment. To edit public tasks, users must have the required security privileges. Private tasks are only visible and editable to the user who created them and application administrators. You cannot convert a public task with existing commitments, hand-offs, or constraints into a private task, because that task information is already shared.

There are two task types: Task and Task Milestone. Regular tasks describe work to be performed and can be public or private. Task milestones are used to mark distinct phases of your project and can only be public. They do not have durations or assigned users, and a company assignment is optional.

Tasks without due dates are called unplanned tasks, and tasks with due dates are called planned tasks. A due date is added to a task to indicate when the company expects to complete it. In scenarios where tasks are part of a chain of tasks belonging to multiple companies, a company can propose a new task due date that can be reviewed and accepted by the superintendent and relevant stakeholders. This provides additional control when changing dates that may affect the tasks of other companies. When a company is confident that it can perform the work on a task, it can create a commitment. Due dates, proposed due dates, and commitment due dates can be updated as needed to accommodate changes to the work plan. When work on a task has finished, the task can be marked complete.

Tasks in the Tasks app display icons that indicate different statuses. Several icons can be selected to edit task details. See Task Icon Reference for icon descriptions.

Task Plans

A task plan is a collection of tasks and their associated responsibilities that arranges the planning board by designated swimlanes as a visual aid. A task plan can be added and applied to the planning board on the Work Plan page to help your project team visualize tasks and related activities that need to be accomplished throughout your project's lifecycle. When you add a task plan, you can identify swimlane categories that organize task cards by assigned user, company, activity code, task code, or Work Breakdown Structure (WBS). This will help your team more easily identify responsibilities and use the most efficient workload distribution during the planning phase. You can create multiple task plans to share with your team, and then manage the details of those task plans throughout the project's lifecycle.

To add, edit, or delete a task plan, users must have the project-level security privileges for Configure Task Plan enabled.

Task Plan Swimlanes

Swimlanes arrange task cards on the planning board using horizontal lanes according to the associated task plan settings. Organizing the planning board by swimlane categories enables you to track tasks based on the most relevant attributes for your project and to visualize responsibility in the workflow. You can move existing tasks freely among swimlanes in the planning board or to and from the hopper.

Constraints

During project planning sessions, you will identify a variety of conditions that must be met before work on a particular task can begin. These conditions are known as task constraints. A constraint could be a drawing or specification, mandatory inspection, material delivery, or submittal approval that is associated with a specific task. A constraint may impact the start of one or more tasks, and a single task may have multiple constraints. Using constraint functionality is optional, but it enables you to define your project tasks and their requirements in greater detail. After you identify tasks impacted by a constraint, you can view them in the Constraints grid.

The goal of constraint planning is to ensure all constraints are identified and resolved before the associated task is scheduled to begin. The following steps can be done in any order.

• Identify the issues, materials, or other deliverables that your tasks will require before they can begin. These are your constraints. You can add notes and upload files to each constraint.
• Designate a company and user as responsible for addressing individual constraints.
• Associate one or more public tasks with each constraint to indicate that they will be impacted by the constraint.
• Link a constraint to a package of associated documents in Aconex for greater impact visibility.
• Enter dates on each constraint for its promised delivery by the responsible party and for its necessary resolution. The date by which the constraint needs to be resolved will most likely be before the associated task's start date.
• When the constraint is actually resolved, deliver the constraint.

Commitments

Commitments are optional submitted agreements to assume responsibility for the work to be performed on a public task. The assigned company and user commit to perform the work by a specific date. If the commitment due date is not met, then the task is overdue. Responsible users can recommit to overdue tasks, providing a new due date, and one or more reasons for why the previous commitment was not met, and any additional comments they may have. Task commitment history can be tracked and reported on according to due dates and reasons, and comments. Commitment history enables you to view trends, evaluate performance, and identify issues with companies and users over time, enabling you to make decisions regarding their future use. When a task is committed or recommitted, any proposed due date is removed, and the task due date is updated to match the committed due date. You cannot commit to task milestones.

Hand-offs

A hand-off is a connection between two tasks that indicates the sequence in which the task work should be performed. Work is "handed off" to the next task to be performed after its preceding task has been completed.

Hand-offs are an important tool for accurately modeling the flow of task work during push planning and pull planning. In traditional or push planning, work is planned in sequence from the start of a project or task milestone. Planners "push" work through the sequence according to an established schedule. In pull planning, the sequence of work is determined by responsible parties planning backward from a task milestone or goal. Performers request or "pull" work from their dependencies based on demand for subsequent work to begin and after all prerequisite tasks have been completed. In both methods, hand-offs provide a tool for project stakeholders to properly sequence their tasks.

Tasks can have multiple predecessor and successor hand-offs to accurately detail all of the work dependencies in a project. Hand-off types describe the hand-off relationship between two tasks. Tasks support start and finish hand-off connections, while task milestones only support finish connections. You can create the following hand-off relationships:

• Finish to Start (between two tasks; between a task milestone and a task). Finish to Start types indicate that a successor task should start only after its predecessor has finished. In a Finish to Start hand-off, the due date of the predecessor task cannot occur on or after the start date of the successor task.
• Finish to Finish (between two tasks; between two task milestones; between a task and a task milestone; between a task milestone and a task). Finish to Finish types indicate that the successor cannot finish until its predecessor finishes. In a Finish to Finish hand-off, the due date of the predecessor task can occur on or before the due date of the successor task.
• Start to Start (between two tasks). Start to Start types indicate that the successor task cannot start before the predecessor task has started. In a Start to Start hand-off, the start date of the successor task must be equal to or later than the start date of the predecessor task.

Hand-offs can be created between tasks with the same, different, or no activity assignments. If necessary, you can modify the activity assignment of a task in a hand-off chain without affecting the chain itself. A hand-off chain can also exist across multiple companies. If a hand-off is added between a planned and an unplanned task, the unplanned task is given a due date. Tasks can have multiple hand-offs to describe the variety of relationships a task might have to other tasks. However, two tasks can only have one hand-off between them. You cannot create hand-offs between private tasks.

Hand-off Slack

As your project progresses, and tasks are performed, added, and delayed, additional time may be added to the hand-offs between tasks. This is called slack. There are two types of slack in Oracle Primavera Cloud:

• Dependency slack: The amount of time a task can be delayed before affecting a successor's start date (for Finish to Start and Start to Start relationships) or finish date (for Finish to Finish relationships). It is calculated for every successor task hand-off.
• Task slack: The amount of time a task can be delayed before it affects the start date or finish date of its most immediate successor. The task slack value is a task's lowest dependency slack value.

Slack is a read-only value that can help you determine where flexibility exists between tasks and which tasks may cause delays to your project.

Hand-off Lag

Some tasks in a hand-off relationship require a period of no work between the predecessor and successor task. This is called lag. You can choose to use work days only or work days and non-work days as part of lag. Unlike slack, lag can't be consumed in a hand-off.

In a Finish to Start hand-off, lag is the delay between the predecessor task finish and the successor task start. In a Start to Start hand-off, lag is the delay between the predecessor task start and the successor task start. In a Finish to Finish hand-off, lag is the delay between the predecessor task finish and the successor task finish.

Hand-off Modes

There are two hand-off modes in the Tasks app. Each mode offers different functionality when modifying your tasks.

1. Keep Hand-offs: Use this mode when you want to maintain the relationships and due dates as much as possible, even if slack is affected. In Keep mode, hand-off logic is maintained when due dates are added, changed, or removed. Slack is added or consumed when changing existing due dates. This is the default hand-off mode.

   Adding or removing a task due date will do the same to all other tasks in the chain based on their duration and chain position. For example, if you add a due date to the first task in a chain, the subsequent tasks are given a due date calculated from a combination of the predecessor due date and the duration of the task. You cannot remove a due date from a task in a chain with at least one committed task.

   When modifying an existing due date of a task in a chain, several scenarios are possible. Moving a task's due date backward or forward in time will reduce dependency slack on the hand-offs in that direction until they reach zero. Dependency slack on the hand-offs in the opposite direction will increase as the due date is moved further away. If a task's due date is moved beyond the due date of a predecessor or successor, then the predecessor or successor due date is adjusted to maintain the sequence and a slack of zero.

2. Break Hand-offs: Use this mode when you want to maintain the due dates of surrounding tasks as much as possible, even if relationships are broken. In Break mode, hand-off logic is not maintained when due dates are added or removed. Slack is added or consumed when changing existing due dates until it reaches zero.

   Adding or removing a task's due date will remove the task from any hand-off chains and leave the remaining tasks in the chain unchanged.

   Modifying an existing due date of a task in a chain works similar to the Keep Hand-offs mode, except when a task's due date is moved beyond the due date of a predecessor or successor, the hand-off between the two tasks is broken.

In both modes, if a task's due date is moved beyond a completed task's complete date, then the hand-off is broken. Completed tasks cannot be moved.