In this lesson, we'll learn about sequencing and dependencies, specifically discussing:
To create a schedule, the project manager must put the tasks from the WBS into sequences. However, due to dependencies and other issues, tasks may not flow smoothly one after the other.
For each activity in the WBS, the project manager should attempt to place the activity and the tasks under the activity into logical sequences. If a task must be completed before another task, then it will be first in the sequence.
You must build the supports in a bridge before you place the roadwork down.
Often, when the project manager is sequencing tasks, new tasks are defined, or tasks are broken down into smaller tasks. As this occurs, the project manager will need to update the WBS with the changes.
When documenting activities, tasks, and dependencies, it's typical to number them according to this system:
Use whole numbers (1.0, 2.0, 3.0, etc.) for activities until all activities in a project have been numbered sequentially.
Each task under an activity is then numbered with the activities number. The value after the decimal changes based on the order in which the work will proceed.
The tasks under activity 2.0 would be number 2.1, 2.2, 2.3, and so on. If the task order changes, be sure to update the number to reflect the new sequence.
It is important to note that tasks without dependencies can be done in tandem with other tasks as long as the resources are available to complete all the work at the same time.
When tasks have a logical sequence, one task becomes dependent on another. It is critical for the project manager to identify the dependencies in a project schedule since issues with dependencies are a primary cause of schedule slippage.
Determining all dependencies might require the project manager to review the schedule a number of times. Once all dependencies have been found, the project manager's next responsibility is to document the dependencies along with their associated tasks and activities.
Dependencies can impact the timing between tasks, and there are two important concepts a project manager should consider when working with a schedule:
Lag time is the time delay between two tasks, and is either caused by an issue with dependencies, or an issue with the resources allocated for the task.
If one task is complete, but the next task must wait two days until a resource is done with other work, those two days are considered lag time.
A more complex situation might involve tasks that have multiple dependencies.
Imagine you are building a chair. The legs and the seat must be complete before the chair can be assembled. However, if the legs are done in three days, and the seat is done in five days, the assembly of the chair must wait five days before it can start. That means there is lag time between the leg creation and the chair assembly.
Lag times can lead to resources sitting on their hands while they wait on other work to be done, which is inefficient for a project.
Lead time indicates that a second task can start once a previous task is only partially complete.
A new road only needs to be partially complete before other workers can start painting the traffic lines.
Once the project manager has worked out all of these details, the project schedule should reflect the overall project time. This is the time from the project’s start date to its end date (when all tasks and deliverables are complete).
Consider projects you’ve worked on in the past. Did you experience lag and/or lead time during any of these? If so, how did this affect the project’s total time?
If you were to experience lag time on a project in the future, how might you approach this issue in order to minimize its impact on the schedule?
In this lesson, you learned how to sequence activities and tasks and how it's important to number the list with decimals to indicate priority.
Project manager must understand dependencies, lag time, and lead time because of their significant impact on the project’s total time.
Source: This work is adapted from Sophia Author Jeff Carroll.
Logical relationships between activities and between tasks.
The time delay between two tasks within a project schedule.
The time required before a successor task can begin.