All language subtitles for 6. When To Break Down Deliverables Further

Sometimes it's not clear
2

how granular you should go with the WBS.
3

When should you break a deliverable into smaller pieces?
4

There are four basic reasons
5

to break down a deliverable into smaller pieces:
6

one, different parts have differing responsibility,
7

two, to separate out waiting time,
8

three, to create interim deliverables
9

and four, the duration is longer than two weeks.
10

Let's look at these situations one by one.
11

First, breaking down by responsibility.
12

If different project team members are responsible
13

for different parts of a deliverable,
14

it should be divided into separate parts
15

each led by a single person.
16

The basic rule is, one person must be accountable
17

for each deliverable.
18

However, this is not needed if several people work
19

on several pieces of the deliverable
20

as part of one functional team where a single lead
21

represents them all at the project level.
22

In this case, you can keep the deliverable as one output
23

with one representative at the project level
24

and that team can then create their own WBS
25

internally at their level for the deliverable.
26

They may have their own precedence diagram
27

for the deliverable as well.
28

The project management process can nest
29

to as many levels as needed.
30

Here's an example, if a conference plan has three sections
31

each led by different people,
32

then you should break up the plan
33

into different deliverables
34

that can be managed individually.
35

You will likely find out
36

when preparing the precedence diagram,
37

that they also have different inputs and outputs
38

and are done at different times.
39

So, separate identification will be needed then as well.
40

Second reason for breaking down a deliverable,
41

breaking out waiting time.
42

Deliverables that contain waiting time
43

for an external reason or event
44

should break the waiting time out
45

into a separate deliverable.
46

For example, for approvals, procurement time,
47

delivery time, paint drying, et cetera.
48

The waiting deliverable has time,
49

but usually no resources or cost.
50

Separate the deliverable into one
51

for what comes before the waiting time,
52

one deliverable for the waiting time itself,
53

and one for what comes after the waiting time.
54

Then it's much easier to plan and manage
55

and it highlights the waiting time on the precedence diagram
56

and Gantt chart so it does not get lost
57

inside a project deliverable.
58

Usually there is nothing you on the project
59

can do about this delay,
60

so you want it to be separate and very visible.
61

Here are some examples,
62

breaking out waiting time for a facilities approval,
63

procurement cycle and waiting for paint to dry
64

shown as they will be flowcharted later
65

on the precedence diagram.
66

This highlights the delays as separate events
67

outside the project's control.
68

Another reason to break down a deliverable
69

is when it has interim deliveries.
70

Often a deliverable cannot be completed
71

until later in a project, but can be started earlier.
72

In this case, it can be very useful
73

to break it into two parts,
74

with the earlier part starting as soon as possible
75

and the final part completing
76

when all the required input is available.
77

This enables clearer presentation
78

of the logic in the precedence diagram
79

and it results in a faster schedule
80

by starting some of the work as early as possible.
81

For example, it's often the case that user documentation
82

can be started as soon as a product design is ready
83

but only finished when the full build is complete.
84

Therefore, as shown in this example,
85

you can break the product deliverable up
86

into separate design and build components
87

and start the user documentation as soon the design is ready
88

and finish it when the build is complete.
89

This results in a more accurate breakout of the project work
90

in the work breakdown structure,
91

a clearer structure in the precedence diagram
92

and a faster schedule in the Gantt chart.
93

This kind of thing often becomes apparent
94

only when creating the precedence diagram.
95

So, keep the trick in mind during that stage,
96

whenever you notice something can start earlier
97

but not be finished until later.
98

The fourth reason to break down deliverables is by duration,
99

but you don't actually put these pieces on the WBS.
100

The project management best practice is
101

that any deliverable longer than two weeks
102

must be decomposed into pieces called "work packages"
103

of maximum two weeks duration to facilitate later tracking.
104

These don't go on the WBS but do go on the Gantt chart,
105

so every month when you status a long deliverable
106

you can tell how it's doing based on the progress
107

of the individual work packages.
108

This avoids the "everything is going great" answer
109

from your leads on longer deliverables
110

until the very end when it's too late to react
111

because you will have internal checkpoints
112

to accurately determine status as you go along.
113

For example, let's say preparation of a document
114

will take more than two weeks.
115

Then, based on the owner's activity breakdown,
116

see the later estimating section,
117

the deliverable could be divided
118

into the following smaller, more manageable work packages
119

that can be individually tracked
120

to obtain accurate status later,
121

thereby ensuring you have early warning
122

if there are any schedule problems.
123

Now when you status the deliverable progress
124

once the project is underway,
125

if any of these work packages are late
126

then you will know the overall schedule
127

has challenges right away
128

and won't be blindsided by learning it only at the very end.
129

What you do about a schedule slip
130

is a completely different question.
131

The first priority is to know as soon as possible.