Tasks Scheduling (CCPM)

Defining Tasks and the WBS

The goal of the task definition step is to identify all the tasks or phases required to complete the project.

If the project team does not have an established scope statement, WBS, or a sufficient scope definition, you may need to host a workshop or two to gather the requirements and further develop the project schedule.

At this point in the project, all the project details are often still unknown.

Task characteristics:

  • A single owner – every team member should know who is responsible for each task

  • No intermediate result – the task doesn’t need another task to be executed

  • A duration that can be monitored

The WBS (Work Breakdown Structure) is the Process of subdividing tasks into smaller pieces in order to obtain a project outline that subsequently is to be used to organize the project.

Usually, the project managers use this method to simplify the project execution. In WBS, much larger tasks are broken down into manageable pieces of work. These pieces can be easily supervised and estimated.

WBS is not restricted to a specific field when it comes to its application. This methodology can be used for any type of project management. Identifying the main deliverables of a project is the starting point for deriving a work breakdown structure.

This important first step is usually done by the project managers and the team member experts involved in the project. Once this step is completed, the team member experts start breaking down the high-level tasks into smaller pieces of work.

In the process of breaking down the tasks, one can break them down into different levels of detail. While one person could detail a high-level task into ten sub-tasks, another could detail the same task into twenty sub-tasks.

Therefore, there is no hard and fast rule on how you should breakdown a task in WBS. The level of breakdown is simply a matter of the project type and the management style utilized for the project.

The efficiency of a work breakdown structure can determine the success of a project. The WBS provides the foundation for all project management work, including planning, cost and effort estimation, resource allocation, and scheduling.

Therefore, creating a WBS is a critical step in the process of project management.

Note

It is a good idea to end the project with a milestone task representing project completion.

When tasks are first entered into a project manually, all tasks are entered at the same highest level. The Indent (IndentGrey) and Outdent (OutdentGrey) buttons enable users to create different task levels. The relationships of tasks to each other in a WBS are known as Parent-Child relationships in which the parent task works as a summary task to all its children, or lower-level tasks.

Sciforma provides up to 10 levels in the WBS that can be formatted and coded. Level 0 is the highest level representing the project, while level 10 is the lowest level. It is possible to have more than 10 levels in the WBS, but the Outline Code and spreadsheet formatting only recognize up to 10 levels. A task at the lowest level of the WBS is where the actual work takes place. Level 0 of the WBS is primarily reserved for the Project Title assigned when a new project is created.

Estimating Tasks Duration

Once you have broken the project down into manageable tasks, the next step is to estimate the amount of time required to execute each task. When determining the duration of tasks, you will consider only the tasks at the lowest level of the WBS: the Elementary tasks or Children tasks.

Tasks at the lowest level represent the actual work of a project, and tasks at the highest levels (Parent tasks) summarize this work.

When identifying the amount of time required for each task, a project manager might use several methods to calculate duration. This can be derived using historical data, simply taking an estimate given by management, or using PERT analysis.

Project Planning is done by people and not machines. Therefore, duration estimates can vary; the human factor and how it affects duration estimates is very well described by Doctor Eliyahu Goldratt in the CCPM methodology (a.k.a. Critical Chain).

Time Estimation

When your project manager asks you to estimate a task duration, think about the example below:

Thinking about the work you have to do, you estimate a task duration of 5 days. You think again about this task and assume that the task could be more complex than it could be and issues could occur. You increase the duration to 8 days. Finally, you want to be sure that you are not giving too optimistic an estimate and say to the project manager that the task could be executed in 10 days.

You have a task duration of 10 days including a safety buffer of 5 days. We consider this duration as a low risk because the task is entered as a 10-day task with a 5 days buffer for task risk.

It is important to note that in estimating task duration, such a safety buffer is not an error. It is perfectly reasonable to take into account all the factors in play and the project context. After all you don't want to be the one who will jeopardize the project’s duration!

Student Syndrome

The student syndrome is the phenomenon of starting a task as late as possible before the set deadline. Doing so eliminates any potential safety margins and puts the person under stress and pressure.

Do not forget that procrastination and Murphy’s Law are closely linked!

Murphy's Law is a popular adage that states that "things will go wrong in any given situation if you give them a chance", or more commonly "whatever can go wrong, will go wrong".

Parkinson’s Law

Parkinson’s Law: “Work expands to fill the time available for its completion.”

This means that if you give yourself a week to complete a two-hour task, then (psychologically speaking) the task will increase in complexity and become more daunting, so as to fill that week. The task may not actually require more work and extra time to complete, but just the stress and tension about having to get it done slows its progress down. By assigning the right amount of time to a task, we can work within a reasonable time constraint, and the complexity of the task will not be significantly magnified (and take longer).

Multi-tasking

For the most part, managing many projects at the same time is the rule of business.

We have all encountered situations in which we have had to stop a task to execute another, one related to a different project because the other project had a higher priority.

This multi-tasking is understandable. Project Managers have more than one project to execute at a time and they are responsible for the deliverables and deadlines.

Customers can be internal or external. They are demanding. They think that their projects must have the highest priority and want to see significant progress.

If we remove multi-tasking in favor of a task execution/completing each task sequentially (resource assignments), project quality is improved and resources are more efficient and less stressed.

Defining Tasks Relationships

The last step required for planning a preliminary schedule is identifying the sequence of tasks, and the dependencies between the tasks. In all projects, there is an order in which the tasks should take place.

Many tasks can be worked on in parallel to each other, but there are tasks that absolutely cannot start until other tasks are completed.

In establishing task relationships, you need to ask three questions for each task in your list.

  1. Which tasks should be finished before the task starts?

  2. Which tasks should start before the task starts?

  3. Which tasks should be finished before the task finishes?

Two definitions

  • A Predecessor is a task that another task is dependent upon—the “from” task.

  • A Successor is a task that depends on another task—the “to” task.

Four Task Relationships in Sciforma

Task relationship

Definition/Example

FS_link.png

FINISH-START (FS): The successor task cannot start until the predecessor task has finished.

Example: After digging a hole, you can plant trees.

SS_link.png

START-START (SS): The successor task cannot start until the predecessor task has started.

Example: After starting the software design, you will be able to start coding.

FF_link.png

FINISH-FINISH (FF): The successor task cannot finish until the predecessor task has finished.

Example: After you have finished the testing, you will be able to finish writing the documentation.

SF_link.png

START-FINISH (SF): The successor task cannot finish until the predecessor task has started.

Lead & Lag

  • Lead: An overlap in the relationship that allows the successor to be scheduled earlier than the predecessor would normally allow. A Lead is reflected as a negative number.

  • Lag: A gap in the relationship that causes the successor task to be scheduled later than the predecessor normally would allow. A Lag is reflected as a positive number. For example: A delay of two days is necessary between the application of two coats of paint.

Task Relationship

Lag

Lead

FINISH-START

FS_lag.png
FS_lead.png

START-START

SS_lag.png
SS_lead.png

FINISH-FINISH

FF_lag.png
FF_lead.png

START-FINISH

SF_lag.png
SF_lead.png
Note

The Finish-Start relationship with zero lead or lag is the default task relationship Sciforma uses when a task relationship is initially created.

Warning

We strongly recommend creating task relationships only between children tasks. Parent tasks should not be linked.

Introducing Date Constraints

Although the basic sequence of tasks in a project is determined by the predecessor-successor relationships defined, there are situations where schedule constraints could override the task sequencing.

Start No Earlier Than is a task field that allows project managers to enter a date on which a task can start no earlier than. This ensures that regardless of when its task predecessors(s) are scheduled to finish, the task starts no earlier than the Start No Earlier Than date.

Example: The contractor who is scheduled to work on a task does not start until a certain date, so this task cannot begin until the contractor arrives.

Must Start On allows project managers to specify a date on which work must begin for a task. This date will override all other restrictions on the start of a task with the exception of an Actual Start Date.

One example would be a workshop that has taken a long time to arrange and involves lots of participants. Other examples are training courses where the tutor is already booked; or work requiring machinery only available for a specific time.

The Required Date allows project managers to enter the target completion date for a task. If the Scheduled Finish date for a task or a key milestone extends beyond the Required Date, Sciforma will display a negative float value.

Introducing Scheduling Types

All the tasks that have been entered so far in Sciforma all have a default task type of As Soon As Possible (ASAP) in the schedule, based on their defined dependency relationships. This is due to a field that is called Schedule Type.

Other schedule type options are also available.

As Late As Possible (ALAP) is the second option available and is used to schedule a project as close to the project end date as possible. This task schedule type is commonly used for tasks that have available float. When ALAP is set to those tasks with float, those tasks are scheduled at the end of the float period and not at the beginning.

Buffer - A task can be designated as a buffer task. Typically, the project will have one or more strategically placed buffer tasks, each having a predecessor relationship with a task that needs to be protected or with a critical milestone, such as the scheduled finish date of the project. The tasks that would normally be predecessors to the milestone task are instead configured as predecessors to the buffer task. The size of the buffer task is then set manually.

The Hammock task type schedules tasks based on the start date of the predecessor tasks and the end date of the successor task. The Hammock task is hung between the start date of the predecessor task and the end date of the successor task, and the duration of the Hammock task is calculated as the time between those two tasks. The duration of the Hammock task changes if there is a change in the start or end date of the related tasks. In order for a Hammock task to be performed as described, it must have only one predecessor and one successor. The best example of the use of a Hammock task is for tasks that last the duration of the project, such as Project Management tasks. If a predecessor or successor is not assigned, the duration of the Hammock task is determined by its parent task start date and finish date.

Note

The Feeding and Project buffers Scheduling Types are used when using the Critical Chain methodology.

Shared Safety

A key element of Critical Chain project management is that the workers must give unpadded time estimates for each task. The time they would have used for padding the estimates gets consolidated into various buffers that are placed in key points throughout the project schedule. If anyone needs extra time to finish a task, the extra time comes out of one of these buffers.

Obtaining the cooperation needed to schedule a project in this way requires a change in both individual and organizational behavior. Everyone must be involved in understanding that their hidden safety is not being removed and discarded. Instead, that hidden safety is being exposed and pooled as a project resource as opposed to a hidden task-level resource. Both management and the project team must be convinced to embrace uncertainty rather than believe that they can defeat it with better estimating techniques. When safety is removed from a task, stakeholders must accept the fact that the task has a good probability of exceeding the time estimate. This is not a bad thing — it is normal. Task actuals can no longer be compared to baseline estimates for the purpose of discovering discrepancies and treating them as problems. If this happens, team members will adjust their behavior to the measurements and put generous amounts of hidden safety back into their next estimates, defeating the Critical Chain method entirely.

A work environment must be fostered that does not consider missing a time estimate as a failure. Innovation is messy — an environment that tries too hard to contain and suppress the inherent messiness is unknowingly suppressing innovation.

The goal is to obtain task estimates that have a 50% chance of being met. This means that there is also a 50% chance that the task will take more time than estimated. And it means that there is also some chance that the task will take less time than the estimate.

Instead of asking team members for an estimate that has a 50% chance of being correct, they should be asked to provide estimates based on the following assumptions:

  • All material and information needed for the task is on hand

  • They will be able to focus on the task without any interruptions

  • There won't be any surprises that cause additional work

Of course, these assumptions will seldom all be true throughout a project. But they will result in workers arriving at an estimate that has close to a 50% probability without the need to introduce workers to statistical mathematics.

Sciforma's Critical Chain methodology enables two durations to be entered and tracked. The Duration field contains the duration that has a 50% probability of being met. Then Sciforma uses parameters specified by the project manager to calculate a Safe Duration, which has about a 90% probability of being met. The Safe Duration is the value that is published to the outside world, while the Duration is the value used internally to manage the project.

Scheduling as late as possible/scheduling backward

An important characteristic of Critical Chain projects is that their tasks are scheduled to start as late as possible in the schedule. Scheduling this way places the work as close as possible to the end of the schedule—just the opposite of the way Critical Path scheduling works.

There are many benefits to delaying project work as late as possible and one drawback.

  • Using a production analogy, scheduling as late as possible minimizes the work-in-progress (WIP) and avoids incurring costs earlier than necessary. From the project manager's viewpoint, there is better focus at the critical start of the project because there simply aren't as many tasks scheduled to start. Also, in projects involving complex knowledge work, knowledge increases as workers progress into the project, as discoveries are made. By scheduling tasks as late as possible, teams capitalize on this increasing knowledge and therefore minimize the need for rework.

  • The single drawback of ALAP scheduling is that, in traditional Critical Path terminology, all tasks are critical once the project is switched into tracking mode. Increasing the duration of any task pushes out the project end date by a corresponding amount. The Critical Chain solution to this problem is to insert time buffers at key points in the project plan. These buffers act as shock absorbers to protect the project end date against task duration increases. The buffers need to be sized to provide adequate protection against the uncertainty in any project.

  • Because scheduling takes place backward from a desired finish date, Sciforma enables Critical Chain projects to be scheduled backward from the end. This does not mean that the last task must be entered first and the entire schedule worked backward. Rather, it means that as tasks are entered and linked and durations specified, the task starting date is computed while keeping the finish date fixed. Tasks can continue to be entered in any order as needed.

In this section