Work breakdown structure (WBS) in project management is a method for completing a
complex, multi-step project. It's a way to divide and conquer large projects to get things done
faster and more efficiently.
The goal of a WBS is to make a large project more manageable.
Breaking it down into smaller chunks means work can be done simultaneously by different
team members, leading to better team productivity and easier project management.
(PMI) defines WBS as "a deliverable-oriented hierarchical decomposition of the work to be
executed by the project team to accomplish the project objectives and create the required
deliverables."
Each WBS level represents a new and increasingly detailed definition of work needed to
complete the project.
WBS formats:
1. WBS spreadsheet: WBS can be efficiently created in a spreadsheet, noting the
different phases, tasks, or deliverables in the columns and rows.
2. WBS flowchart: WBS can be created as in a diagrammatic workflow. Most WBS
examples and templates are in the form of flowcharts.
3. WBS list: WBS can be structured as a simple list of tasks or deliverables and subtasks.
This is the most straightforward approach to make a WBS.
4. Work breakdown structure Gantt chart. WBS can be structured as a Gantt chart
that represents both a spreadsheet and a timeline. With a Gantt chart-structured WBS,
we can link task dependencies and show project milestones.
Construction of a WBS:
Task No.: This is a numerical listing of the deliverable, which is
further distinguished as you drill down deeper from task to subtask by
decimal points to make sure you know exactly where in the process
you are.
Task Description: This section details what the deliverable is and
also goes into the task and the subtasks necessary to complete it.
Task Owner: Every deliverable, task and subtask needs an owner to
make sure the work is getting done, and that person is noted in this
column.
Dependency: Some tasks cannot be started until the task before them
has been completed, which means it’s dependent on that task and they
should be linked. This is the space where you can note task
dependencies.
Resources Needed: Whatever the task needs in terms of people,
equipment, materials, etc., is listed here.
Task Status: This is where you can track the status of a specific task
or subtask. The drop-down menu gives you the option of marking the
task as unassigned, assigned, in progress, late or complete.
Cost: Note the financial commitment needed to get the deliverable
done.
Start Date: When did work on the deliverable begin? Mark it here.
Estimated Completion: The estimated amount of time allotted for
the completion of the deliverable should be noted here.
Finish Date: When the deliverable is done, note the end date here.
Notes: This column is for any data that doesn’t fit in the previous
ones.
Example of WBS( what to include in rows and column)
Module 2 Project Scheduling
A project manager and team usually develop as much of the schedule as they can based upon the
information in the work breakdown structure (WBS). The communication plan, requirements
traceability matrix, and scope statement are often either complete or at least in draft form at this
point. Once a project is scheduled, the budget can be formulated, resource needs can be identified
and resources assigned, risks can be identified and plans developed to deal with the identified risks,
and a quality management plan can be created. In many projects, these are not all treated as discrete
activities, and some of them may be performed together. However, for clarity, each of these planning
processes will be described individually. The building blocks of a project schedule are activities. An
activity is “a distinct, scheduled portion of work performed during the course of a project.” For
activities to be useful as schedule building blocks, they should have the following characteristics:
• Clear starting and ending points
• Tangible output that can be verified
• Scope small enough to understand and control without micromanaging
• Labour, other costs, and schedule that can be estimated and controlled
• A single person who can be held accountable for each activity
The Project Management Institute (PMI) has divided project time management into the following
seven work processes.
1. Plan schedule management—the process of establishing the policies, procedures, and
documentation for planning, developing, managing, executing, and controlling the project schedule
2. Define activities—the process of identifying the specific actions that need to be performed to
produce the project deliverables
3. Sequence activities—the process of identifying and documenting dependencies among the project
activities
4. Estimate activity resources—the process of estimating the type and quantities of material, human
resources, equipment, or supplies required to perform each activity
5. Estimate activity durations—the process of approximating the number of work periods needed to
complete individual activities with estimated resources
6. Develop schedule—the process of analysing activity sequences, durations, resource requirements,
and schedule constraints to create the project schedule
7. Control schedule—the process of monitoring the status of the project activities to update project
progress and managing changes to the schedule baseline to achieve the plan.
Purpose of a Project schedule:
Projects are undertaken to accomplish important business purposes, and people often want to be able
to use the project results as quickly as possible. Many specific questions such as the following can be
answered by having a complete and workable schedule:
• When will the project be complete?
• What is the earliest date a particular activity can start, and when will it end?
• What activity must begin before which other activities can take place?
• What would happen if a delivery of material was one week late?
• Can a key worker take a week of vacation the first week of March?
• If one worker is assigned to do two activities, which one must go first?
• How many hours do we need from each worker next week or month?
• Which worker or other resource is a bottleneck, limiting the speed of our project?
• What will the impact be if the client wants to add another module?
• If I am willing to spend an extra $10,000, how much faster can the project be completed?
• Are all of the activities completed that should be by now?
Historical Development of Project Schedules
Throughout history, projects have been performed, but many early projects such as cathedrals in Europe
took decades or longer to complete. As competition drove the need for more rapid completion,
systematic methods were developed for scheduling projects. In the 1950s, two project scheduling
methods were developed:
program evaluation and review technique (PERT) and critical path method (CPM).
The critical path method (CPM) is “a method used to estimate the minimum project duration and
determine the amount of scheduling flexibility on the logical network paths within the schedule model.”
Both CPM and PERT were founded on the concepts still in place today of identifying activities,
determining their logical order, and estimating the duration for each. Networks representing the
activities were developed and the schedule calculated. Each of the techniques also boasted a capability
the other did not possess.
PERT was developed in the Navy’s Special Program Office because the Navy was developing the large
and complex Polaris Weapons System. To complete it as quickly as possible, many activities needed to
be worked on simultaneously. Furthermore, many aspects of the Polaris used unproven technology.
There was considerable uncertainty regarding how long some of the new technology would take to
develop. PERT enabled project managers to estimate the most likely amount of time needed to complete
a project, and the level of confidence in completing it in a particular time. This has proven to be useful
in research and development projects involving individual activities that are hard to estimate precisely.
CPM was developed in the Engineering Services Division of DuPont. DuPont needed to plan large
projects when it built and refurbished enormous plants. Planners using CPM estimated the time for each
individual work activity using a single time estimate. The focus was on understanding the longest
sequence of activities, which determined how long the project would take. CPM enabled project
managers to ask what-if questions such as “If the project needs to be finished three weeks early, which
activities should be speeded up and how much will it cost?” This proved to be useful in the construction
industry where delays such as rain often necessitate the acceleration of a project.
How project schedules are limited and created
One way to understand project schedules and how they are constructed is to understand that
five factors may limit how fast a project can be completed:
1. Logical order: The first factor is the logical order in which activities need to be
completed. For example, one needs to dig a hole before cement can be poured in it.
2. Activity duration: The second factor is how long each individual activity will take. It
includes methods for estimating durations, problems with estimates, and remedies to those
problems.
3. Resource availability: The third factor is how many key resources are available at specific
points in the project. For example, if six rooms were available to be painted at the same time,
and fewer than six painters were available, progress would be slowed.
4. Imposed dates: The fourth factor is imposed dates. For example, a project working on a
government contract may not be able to start until the government’s new fiscal year, which
starts on October.
5. Cash flow: The fifth and final factor is cash flow. Projects may not start until money is
approved, but progress may also be slowed until enough revenue arrives to cover expenses.
Creating a realistic project schedule is an iterative process.
A common method of developing the schedule is to first identify all of the activities
and then determine the logical order by creating a network diagram.
Once the order is determined, resources are assigned to each activity and an estimate of
the time required for that activity is made.
If the assigned resource is not available when the activity is scheduled, then an
adjustment of some type is made. The schedule can be computed with all of this
information.
Next, it is time to compare the emerging schedule with any imposed dates and cash
flow estimates. Any inconsistencies may cause the team to adjust the schedule.
Other factors often need to be considered, such as quality demands and risk factors.
When all of these have been planned, the final schedule can be approved.
Uncertainties in Project schedule
Two-Pass Method
The two-pass method is used to determine the amount of slack each activity has. To perform
this method, two logical passes should be made through the network.
The first pass is called the forward pass. The first pass is then used to calculate the early finish,
which is the early start plus the estimated duration (ES + Duration = EF). In this case, 0 + 5 = 5 means
the activity “Determine new product features” can be completed after five days. Each activity that is
a successor can start as soon as its predecessor activity is complete. Therefore, the next two activities
can each start after five days. To calculate the early finish for each of these activities, add its duration
to the early start of 5, for early completion times of 25 and 15, respectively. The difficult part of
calculating the first pass comes when an activity has more than one predecessor. For example,
“Perform sales calls” cannot begin until all three preceding activities (“Produce prototypes,” “Design
graphics,” and “Conduct marketing”) are complete. Therefore, its early start is 45. This is true even
though “Produce prototypes” and “Design graphics” have earlier finish times, because “Conduct
marketing” cannot be completed until day 45. The later time is always taken. The results of the first
pass are shown in Exhibit 7.12. Note that the earliest the entire project can be completed is 70 work
days.
The second pass is sometimes called the backward pass. The backward pass is “a critical path
method technique for calculating the late start and late finish dates by working backward through the
schedule model from the project end date.” 24 When performing the backward pass, teams start at
the end and work backward asking, “How late can each activity be finished and started?” Unless there
is an imposed date, the late finish for the last activity during planning is the same as the early finish
date. In our example, we know the earliest we can finish the entire project is 70 days, so we will use
that as the late finish date for the last activity. If the activity “Perform sales calls” must end no later
than 70 and it takes 25 days, then it must start no later than day 45. In other words, calculate the late
start by subtracting the duration from the late finish (LF – duration = LS). The confusing part of
calculating the second pass is when there is more than one successor. In Exhibit 7.13, one place this
occurs at the first activity, “Determine new product features,” since two activities are immediate
successors. Enough time must be left for all of the successors, so whichever one must start soonest
dictates the late finish date of the predecessor. In this example, “Design marketing campaign” must
start no later than after day 5; therefore, five days is the late finish for the first activity.
Lead and lag
Exhibit 7.6 shows the most common type of logical dependency, finish-to-start (FS), which is
“a logical relationship in which a successor activity cannot start until a predecessor activity has
finished.” 10 That means, in this example, that the marketing plan must be completely designed
before the graphics design starts. However, maybe the graphics design could start five work days
before the marketing campaign design is complete. This could be modeled as a lead, which is “the
amount of time whereby a successor activity can be advanced with respect to a predecessor activity.”
11 With this lead of five work days, the arrow connecting design marketing campaign and design
graphics would Arranging adhesive notes on a wall allows team members to arrange project tasks in
predecessor– successor relationships. © Yuri Arcurs/Shutterstock.com EXHIBIT 7.5 ACTIVITY LIST FOR
PRODUCT UPGRADE PROJECT • Determine product features • Acquire prototype materials • Produce
prototype • Design marketing campaign • Design graphics • Conduct marketing • Perform sales calls
Chapter 7 Scheduling Projects 179 still represent a finish-to-start relationship, only with a five-day
overlap during which time people could work on both activities. Leads are helpful if a project needs to
be completed quickly since they show how a successor activity can be overlapped with its predecessor
instead of waiting until the predecessor is completely finished. Perhaps in the example, the sales
people are more effective if the design graphics are completed 10 days before they start performing
sales calls so they have extra time to better understand the graphics. This could be shown by a lag,
“the amount of time whereby a successor activity is required to be delayed with respect to a
predecessor activity.” 12 In this example, the arrow connecting design graphics and perform sales calls
would still represent a finish-to-start relationship, only with a 10-day gap during which no one could
work on either activity.
Dependencies
Dependencies can be either mandatory or discretionary. A mandatory dependency is “a
relationship that is contractually required or inherent in the nature of the work.” 8 A discretionary
dependency is “a relationship that is established based on knowledge of best practices… where a
specific sequence is desired.” 9 A mandatory example is “the hole must be dug before concrete can
be poured into it” and a discretionary example is “past experience tells us it is better to delay designing
product graphics until the marketing plan is complete.” The team needs to include all of the mandatory
dependencies and use its judgment on which discretionary dependencies to include. Most teams
include no more dependencies than necessary since more dependencies give the project manager
fewer choices as the project progresses.