The next logical step after defining scope is to identify smaller chunks of work from the requirements. These chunks of work are called work packages. These are self-contained, measurable pieces of scope that can be cost-estimated and scheduled.
Later in this post you will see that there will be control-accounts associated with work packages to get a hierarchical view of cost and schedule.
As an example, your organization’s accounts department can calculate the cost for implementing Accounts Payable module of the accounting package your team is building for the customer.
Now the question is,
Why do we really need a Work Breakdown Structure
Scope is a coarse much grained piece of requirement to assign to a team member. This needs to be broken down into smaller pieces, and is done as a hierarchical structure, where each level of the hierarchy breaks deliverables into more accurate and measurable chunks. And this is called Work Breakdown Structure, or WBS in short.
Many a times even this level of granularity is not good enough to assign to team member for work. For this we have Define Activities process. The lowest level of WBS is called work package.
There is another advantage of creating WBS. With this structure you ensure that all of the requirements are guaranteed to be delivered to customer.
How?
Consider this. The next step after creating WBS is to break it down into tasks (or activities) that can be assigned to team members to work on. Thus WBS is an essential link between scope and corresponding tasks. Completing all of these activities will mean that all of work packages, and hence all of the requirements are delivered.
WBS lets you organize your deliverables into logical units of work.
Whats needed?
Take a pause and guess the what would you need for this project management activity.
If you guessed (and I am reasonably sure that you did) the plan to manage scope, requirements documentation and project scope document – you’d be perfectly right! While the first one tells us how to go about creating work breakdown structure, next two give us inputs about the actual work that needs to be categorized into a structure.
You could also use templates in the organization and sample work breakdown structure from earlier similar projects as reference.
The ‘How’ of it
How would you break down work form monolithic pieces of scope? By separating project deliverables into smaller, more manageable components – by decomposing them.
Decomposition breaks scope into work packages. Work packages are further broken into activities in Define Activities process.
Scope is broken down into multiple hierarchical levels, each one successively breaking the scope into level that is more granular. Scope can be broken down based on deliverables – for example, in Kathy’s landscaping project first level might be broken based on deliverables such as Parks, Common areas and Walkways. Next level being a bit more granular.
Let us take an example and a sample WBS. We saw few posts earlier about Kathy’s project of landscaping the gated community project. Here is one way she could create WBS is:
Figure 1: Sample WBS using major deliverables
What is ‘100% rule’?
A completed WBS represents all the deliverables of the project – including the outcome of project management activities, such as documents and plans. If you are at the leaf node of the structure (one that does not have further child nodes) and roll up all of the nodes into their parent, and roll up parents into their parents, till all the way up – it would cover ALL of the work that project team ever does. Hence this technique ensures that team does only requirements related work, nothing more, nothing less. This is called ‘100% rule’.
Another way of breaking down scope is based on project phases, such as design, development, testing, user-acceptance and so on for a software project.
Keep in mind not to break scope into work packages that are too fine-grained. Work packages should be coarse-grained enough so that you can assign control-account identifiers to them and calculate cost and benefit numbers at work package level.
You get help from experts for this project management activity. This is in fact not isolated from decomposition because expertise in the subject help you judge information and break scope into WBS in a right manner. If project manager does not possess the necessary technical expertise then someone from the organization or an expert outside the organization is approached and her services are sought for creating WBS.
In some cases you could send an appropriate person for training on the subject matter so they get the knowledge and insight necessary to break scope down into work packages.
In certain industries, like Kathy’s landscaping project, there might be industry specific templates that can be used to create work breakdown structure.
What do you produce with this project management activity?
Scope baseline.
A baseline is an authorized point of reference of a project artifact. Scope baseline contains –
- Project scope document
- Work Breakdown Structure
- Related information for each of the lowest components in WBS (dictionary)
Scope baseline is a component of project management plan. Whenever there is a change to scope, this baseline is to be updated AFTER a corresponding change request is approved using change control process.
Let us look at these constituents bit closely.
Project scope document includes information such as project description, major deliverables, milestones, assumptions, cost figures, constraints and so on.
Work Breakdown Structure or WBS. We have seen that WBS can be structured by project phases or by major deliverables. The example above shows WBS by deliverables. Each node of this structure is independently verifiable.
Level of decomposition is governed by complexity of the deliverables. Some deliverables may need only one level while some others may need multiple.
Though most common type is a hierarchical organizational structure, the WBS can be represented as a fishbone diagram, or simple outline, or some other method that is convenient.
Additional work package information – each work package has a corresponding additional information section. It contains all the information required to do work such as code of account identifier, description, responsible organization, resources required, milestone, cost estimates, quality requirements, acceptance criteria. Just the work package without WBS dictionary is not very useful.
During this project management activity, requirements documentation and project scope documents can also be updated.
WBS is a baselined document, and any changes to it will require change request to be raised and run through change control process. These are the outputs of Create WBS process. Let us look at couple concepts you need to understand about WBS.
What is Rolling Wave planning?
At times, some of the deliverables would not have enough details to be able to break down into work packages. In such cases, details are left out from the WBS exercise till more details are known. When sufficient details are available, WBS for them are created. This is known as rolling wave planning.
Mammoth Construction Company was not clear about what theme should chosen for common walk ways, and waiting for the inputs from marketing research department. Hence during initially WBS exercise Kathy skipped this requirement, and kept a placeholder (refer to the figure above).
What is a control account?
Control account represents a node in WBS hierarchy at which scope, budget, actual cost of work and schedule can be calculated and compared to the earned value to measure project performance. (more on earned value in Control Scope process). Control account has a unique id assigned to one or more work packages in the WBS hierarchy where cost, schedule and resource information of that work package is calculated. This unique identifier comes from organization’s code of accounts, and is used by organization’s accounting system.
For instance, if you had a control account at node “2.2 Community park” in the figure above, the accounts department would use a unique identifier to calculate schedule and cost for all the work that goes into constructing the community park.
As a rule, one control account can have any number of work packages, while a work package is associated with only one control account. They share one-to-many relationship.
Figure 3: One control account can have multiple work packages, but a work package is part of only one control account.
Project document updates
Most probable document to be updated during this process is requirement documents.
Exam pointer: WBS is a baselined document, and any changes to it will require change request to be raised and run through change control process.
Points to consider while ‘WBSing’
- Make them delivery-oriented. Do not include any administrative or other types of work that does not go towards satisfying customer requirements.
- Do not get too detailed. If possible do not try to break them to the extent where you can assign them. This will create a too large WBS structure, that needs constant maintenance each time there is some change to the task or new ones are discovered. There is a separate process for that . Keep the level of clarity at a bit high level where you have a logical chunk. Else you will end up spending lot of time and going back and forth between high level scope and low level tasks.
- Do not get too broad. If you keep the detailing at high level, you end up spending more time during Define Activities process again doing some level of breaking down to task level.
- Focus on ‘what customer will get’ rather than ‘what a team member will work on’. When you are done with the structure each node of your structure should indicate what the customer will get. And not what is that a team member will work on. Level of detailing in WBS should be ‘customer facing’.
Creating WBS is an exhaustive as well as satisfying exercise for the project manager. When you cross this stage you will feel more in control of the project.
In some projects WBS is created using Post-its. What has been your experience of creating Work Breakdown Structure? Take a minute and share in the Comments below.
With this we’ve completed Scope management knowledge area concepts. Let us now see what is involved in creating and managing project schedule.
[SneakyAffiliate sneakyaffiliateurl=”https%3A//www.pmexamsmartnotes.com/pmprecast-myposts” sneakyaffiliatecookiexpdays=”1″ sneakyaffiliatesplash=”Are%20you%20sure%20you%20want%20to%20leave%20before%20you%20checkout%20special%20PM%20PrepCast%20sale%20by%20Cornelius%3F”] [/SneakyAffiliate]
