PROJECT MANAGEMENT FOR TELECOMMUNICATIONS MANAGERS CHAPTER 4 docx

WORK BREAKDOWN STRUCTURE In this chapter, we discuss the Work Breakdown Structure, a critical project management tool.. The Work Breakdown Structure is a methodology for determining proj

WORK BREAKDOWN STRUCTURE

In this chapter, we discuss the Work Breakdown Structure, a critical project management tool The Work Breakdown Structure is a methodology for determining project activities by systematically breaking the project into deliverable-oriented packages It is a systematic analysis of the full scope of the project, defining all the deliverables, and all of the activities required to produce the deliverables The team identifies all of the project activities by creating a Work Breakdown Structure When they finish they will have a picture of the full project Then the team can proceed with the work,

ensuring that all aspects of the project are covered If any activity is not in

the Work Breakdown Structure, it is not in the project Therefore no one

on the team should be working on it So everything that is to be done to complete the project must show up in the Work Breakdown Structure – commonly known as the WBS This includes all activities related to delivering the product as well as all activities related to managing the project Be sure to keep this in mind as the WBS is being built The PMBOK® Guide gives the Time Management Processes as follows:

The WBS is a breakdown of the project into deliverable-oriented groupings These groupings eventually turn into action items

The purpose of the WBS is to assess WHAT is to be done (Activity Definition), and WHAT is to be produced It must include everything that is included in the project, whether it be something for the project - in fact, all the project management must be included,- or something to create the product The WBS shows all of this - the WHAT of the project But only the WHAT

The WBS is created by breaking the project into deliverables, and then further breaking down these deliverables DO NOT think about the time The times will be determined later Of course the dates are critical But they are not part of the WBS The WBS just gives all the activities that we will need

to consider when we eventually do get to consider the timing But when creating the WBS, we want to focus on the deliverables So we leave all the timing till later The dates will eventually appear later in your project plan Another common mistake is breaking the work down by department or function While this can certainly be done, proceeding this way has a higher risk of missing some project aspects So do not work with departments or functions Instead break the project down into deliverables

The first level of breakdown is a set of major deliverables These will probably already be listed in the charter, and if not, there should be such a list in the scope statement Next, one by one, each of these deliverables is further broken down into more detailed deliverables

It is not necessary, or even advisable to be rigid in the placement of the project specific content into the WBS There are many acceptable ways in which any project can be broken down If some system works for the team and those who need this information, that system should be used However, there are some rules, which should be followed in creating the breakdown: The WBS in totality identifies all project components and deliverables The WBS ensures there are no gaps or overlaps

The top levels must be deliverable-oriented

Elements must integrate to project whole

There should be no ‘single children’

The bottom level of the WBS shows activities, which are assignable All boxes are numbered in defined patterns

Cardinal rule: If it’s not in the work breakdown structure, it’s not in

the project

What does this mean?

1 The WBS in totality identifies all project components and deliverables The content of the WBS must include everything in the project So we will start with the full project, and break it into major deliverables Then each of these will be further broken down We must do this in such a way that no part of the project, no deliverable and no activity is missed The breakdown must be very thorough to ensure that all project and product deliverables are covered

2 The WBS ensures there are no gaps or overlaps

Every deliverable, and every activity, is included in the WBS once, and only once To have every activity included once, we need to ensure that we include all deliverables at every step When any deliverable is broken into sub-deliverables, the sub-deliverables must ‘add up’ to completely describe the initial deliverable When using an org chart type format for the WBS,

this means that the set of boxes immediately below any box completely

describes the box above

To ensure that each activity is included only once, we have to sift through the WBS to ensure that nothing appears twice It often happens that a project has activities that appear to be the same, when in fact they are different If

we have a program and also a meeting, and we want to write documentation

of each, documentation under the program is quite different from documentation under the meeting deliverable Both can be included because they are different However when two deliverables such as this occur, they should be named is such a way that they can be clearly differentiated Therefore, do not call them both ‘documentation’ Call one ‘program documentation’ and the other ‘meeting minutes’ to differentiate

3 The top levels must be deliverable-oriented

As discussed above, there are many ways in which the project could be broken down, but the recommended decompoition is into deliverables, to keep the thought process addressing what is to be proudced, and what is to

be done

4 Elements must integrate to project whole

This will happen if each box is broken down carefully to include all components

5 There should be no ‘single children’

When decomposing a project, it is likely that at some point a deliverable will be decomposed into a single deliverable This does not actually make sense Either there are more than one sub-deliverables or activities making

up the upper box, or the lower box is in fact the same as the upper box So, either there will be more than one deliverable below, or there is no need for further decomposition

6 The bottom level of the WBS shows activities, which are assignable

At some point in the breakdown, the deliverables actually turn into activities At this point a verb can be added to the deliverable The bottom level activities must be assignable to a single individual or unit Until this can be done, further breakdown is required The bottom level activities will

be used to build the project schedule, and it is these activities that will be monitored So they need to be clear, and the accountability for each must be definable

7 All boxes are numbered in defined patterns

There are some acceptable formats for the WBS, as shown in the examples Regardless of the format there is an accepted numbering convention – also shown in the examples The deliverables must be numbered according to this convention

Cardinal rule: If it’s not in the work breakdown structure, it’s not in the project

The WBS is the CORE of the project plan Everything else is built around the WBS Without it the project plan cannot be properly completed However, it is not necessary to be rigid in the way the WBS is created There are some standard formats that need to be followed and also some rules which essentially point people to use deliverables rather than functions or time, as just described But within this, any set of deliverables can be the top level, etc

There is only one caution – include only work that is to be done as part of

the project Anything done after the project is not part of the project and

should not show up in the WBS This might sound silly, but if the scope has not been clearly defined, sometimes items, which should not really be part of the project, work their way into the WBS In the case of our sample project here, suppose that we had not excluded the product sales, or the establishment of prices Some groups might have included activities related

to these two deliverables in the project This happens easily when the people who are responsible for such functions are project team members They are aware that they have to do the follow-up functions, and they sometimes include these activities in the project work, not realizing that they are not required deliverables – from the project perspective

Once we have the WBS the activities are defined The PM can then assign people, time, dollars, etc to each one

The WBS can be in chart form, along the lines of an organization chart,

as shown in Figure 1 or it can use the same format as the table of contents for a book The WBS in Figure 1 is not complete, but some of the deliverables have been decomposed to illustrate the technique

As discussed, the creation of the WBS starts with the high level deliverables which are listed in the charter These are then broken into smaller deliverables, gradually working down to smaller pieces, until the

‘bottom level’ is reached The bottom level elements are actually activities Instead of expressing them as deliverables (the what) it is possible to include

a verb, expressing them as activities These activities must meet certain criteria They must be

assignable independent measurable schedulable budgetable suitable size What does this mean?

Assignable – the activities must be something that can be assigned to one person or group If the work spans more than one unit, further breakdown is required The reason that we want to assign to one unit is that the bottom level activities will be used to set up the project resource allocation, the schedule and the budget The project manager will monitor these activities to ascertain that the project is on track It is necessary to know who is responsible for each item in order to manage the completions

Independent – each activity must be independent to facilitate management of the items If interdependencies exist, it will be difficult to determine where problems lie Finger pointing might become a problem Measurable – in order to determine whether or not the activities have been completed satisfactorily, the activities should be measurable This will allow the team to specify the required levels for satisfactory completion, and the PM to determine when these have been reached

Schedulable – the activities will be used to build the project schedule, so

it must be possible to assign a start and end date to each Therefore ongoing work cannot be included in the WBS All work must be broken into units to

be scheduled

Budgetable – the project budget will be determined by assigning costs to the bottom level elements, and adding these up to determine the cost of each deliverable, and finally the cost of the full project So it must be possible to determine the cost of each of the activity elements

Suitable size – while there is no strict definition of what a suitable size might be, the size of the bottom level elements must be suitable for monitoring An activity that lasts for 6 months might meet all of the above criteria, but for the PM to allow an activity to proceed for 6 months before

declaring completion would leave open too great a possibility of missed due dates Therefore large items should be broken into smaller components to allow better control of the project A length of something in the order of 2 weeks is generally considered to be reasonable for an activity But there will

be cases where somewhat longer or shorter is acceptable This will depend

on the project, and on how critical items are

Even at the bottom level, elements can still be broken down further, but this is not necessary for the WBS Elsewhere in the project documentation the team should provide the detailed information for elements, which would benefit from further definition Any tasks will be specified in this description, which is sometimes called a xxx dictionary

Some people wonder why the project management activities should be included in the WBS Hopefully the discussion above will clarify the reasoning behind this It is quite possible that in the project charter, and maybe even in the scope statement, project management was not mentioned

as a deliverable That is probably fine for these two documents They are usually focused on the product However, given the only those items in the WBS will be included in the budget, the resource allocation and the schedule, how can the project be fully resourced if these critical activities are not included? Obviously they are part of the project, they will use time and resources, so they need to be included

In fact, not showing them also has the effect of giving the impression that the management is in fact either easy or unimportant Neither of these is true The project management activities should be given the same respect as the product related activities

When the WBS is complete, we will then move to the next steps, which are:

+ Add duration and dependencies so we can build the logic network + Add the calendar to the logic network to give the schedule

+ Add resource names to each activity

+ Add dollars to each activity

This will allow us to calculate the budget, and also, using the schedule, to plot out the cash flow – which might in turn influence changes in the schedule We will be able to determine the flow of work, and using that along with the activity durations, build the project schedule

This next step is a systematic analysis of the full scope of the project, defining all the deliverables, and all of the activities required to produce the deliverables In this step we will identify all the project activities by creating

a Work Breakdown Structure When we finish we will have an analysis of the full project and all the activities that comprise it Then the team can proceed with the work, ensuring that all aspects of the project are identified and covered If any activity is not in the work breakdown structure, it is not

in the project Therefore no one on the team should be working on it So everything that is to be done to complete the project must show up in the work breakdown structure – commonly known as the WBS This includes all activities related to producing the product as well as all activities related to managing the project Be sure to keep this in mind as the WBS is being built

The WBS is a breakdown of the project into deliverable oriented groupings These groupings eventually turn into action items

The purpose of the WBS is to assess WHAT is to be done, and what is to

be produced

It must include everything that is included in the project, whether it be something for the project - in fact, all the project management must be included,- or something to create the product The WBS shows all of this ­ the WHAT of the project But only the WHAT

The first level of breakdown is a set of major deliverables These will probably already be listed in the charter, and if not, there should be such a list in the scope statement Next, one by one, each of these deliverables is further broken down into deliverables, continuing until tasks of an appropriate level are reached A common mistake is breaking the work down

by department or function While this can be done, proceeding this way has a higher risk of missing some project aspects So do not work with departments or functions Instead break the project down into deliverables

DO NOT attempt to schedule tasks at this point The times will be determined later, as shown in Chapter 8 Of course the dates are critical, but they are not part of the WBS The WBS just gives all the activities that we will need to consider when we eventually do get to consider the timing But when creating the WBS, we want to focus on the deliverables So we leave all the timing till later The dates will appear later in your project plan

It is not necessary, or even advisable to be rigid in the placement of the project specific content into the WBS There are many acceptable ways in which any project can be broken down If some system works for the team

and those who need this information, that system should be used However, there are some rules that should be followed in creating the breakdown:

The WBS in totality identifies all project components and deliverables

The WBS ensures there are no gaps or overlaps

The top levels must be deliverable oriented

Elements must integrate to project whole

There should be no ‘single children’

The bottom level of the WBS shows activities that are assignable All boxes are numbered in defined patterns

What does this mean?

1 The WBS in totality identifies all project components and deliverables The content of the WBS must include everything in the project So we will start with the full project, and break it into major deliverables Then each of these will be broken down We must do this in such a way that no part of the project, no deliverable and no activity is missed The breakdown must be very thorough to ensure that all project and product deliverables are covered

2 The WBS ensures there are no gaps or overlaps

Every deliverable, and every activity, is included in the WBS once, and only once To have every activity included once, we need to ensure that we include all deliverables at every step When any deliverable is broken into sub-deliverables, the sub deliverables must ‘add up’ to completely describe the initial deliverable When using an org chart type format for the WBS, this means that the set of boxes immediately below any box completely describes the box above

To ensure that each activity is included only once, we have to sift through the WBS to ensure that nothing appears twice It often happens that a project has activities that appear to be the same, when in fact they are different If

we have a program and also a meeting, and we want to write documentation

of each, documentation under the program is quite different from documentation under the meeting deliverable Both can be included because they are different However when two deliverables such as this occur, they should be named is such a ay that they can be clearly differentiated

Therefore, do not call them both ‘documentation’ Call one ‘program documentation’ and the other ‘meeting minutes’ to differentiate

3 The top levels must be deliverable oriented

As discussed above, there are many ways in which the project could be broken down, but the recommended decomposition is into deliverables, to keep the thought processes address what is to be produced, and what is to be done

4 Elements must integrate to project whole

This will happen if each box is broken down carefully to include all components

5 There should be no ‘single children’

When decomposing a project, it is likely that at some point a deliverable will be decomposed into a single deliverable This does not actually make sense Either there are more than one sub-deliverables or activities that make

up the upper box, or the lower box is in fact the same as the upper box So there will either be more than one deliverable below, or there is no need for further decomposition

6 The bottom level of the WBS shows activities that are assignable Accountability for bottom-level tasks must be clear

At some point in the breakdown, the deliverables actually turn into activities At this point a verb can be added to the deliverable The bottom level activities must be assignable to a single individual or unit Until this can be done, further breakdown is required The bottom level activities will

be used to build the project schedule, and it is these activities that will be monitored So they need to be clear, and the accountability for each must be definable

7 All boxes are numbered in defined patterns

There are some acceptable formats for the WBS, as shown in the examples Regardless of the format there is an accepted numbering convention – also shown in the examples The deliverables must be numbered according to this convention

- Cardinal rule: