Using “Work Breakdown Structure (WBS)” for Effective Project Estimation

Thinking about projects and project execution, the competition in this world has become so huge and intense that organizations hardly want to take any risks that might place their projects within the zone of penalty and negative implications during any phase of the project/program. Having said that, because of the accumulative bunch of free project tools and process knowledge available out there today, organizations also take the necessary corrective actions upfront to ensure that all of their programs/projects are fully compliant from a process, quality cost, time, scope and schedule perspective that are much compulsory to meet the delivery demands of the Client/Customer in this progressively challenging project galaxy across the globe. Of the factors mentioned above, let’s take “Scope”. Scope is the core need for all projects – this is the real thing that needs to be understood and implemented for the project. As we all know very well, there are several circumstances across the orb wherein projects have failed or have went into losses for the simple reason of the scope either not being correctly understood or not being correctly implemented on both. “Scope” is the connecting factor for the rest of the project parameters of cost, time, resources, etc. and hence getting to understand scope, breaking it into smaller pieces, creating simpler scope tasks, and confirming the associated project deliverables is the key for any project. This article describes one of the most important tools – the WBS (Work Breakdown Structure) for understanding and decomposing project scope and also the various advantages/successes that a project team could derive if a WBS is well-prepared and used through the duration of the project.

What is a work breakdown structure?

Simply put, a work breakdown structure is a hierarchical decomposition of the scope/work that needs to be estimated and executed during the course of the project in order to accomplish the project objectives and deliverables.

Though it sounds so simple, a WBS has enormous strength and influence to convert complex requirements/scope into small and easier pieces for project estimation, planning and execution. A WBS: 

Related Article: Project Risk Management in 12 Questions

• Gives Clarity on the project needs in terms of deliverables and success criteria – it highlights the “what” of the project
• Organizes the project scope, puts a defined decomposing structure around it
• Gives more simplicity and break-up of the activity to be performed using its each hierarchical decomposed level
• Successively subdivides the scope into manageable components in terms of size, duration, and responsibility
• Is a structured diagram portraying the hierarchical listing of overall project requirements into increasing levels of detail
• Aids in assigning responsibilities, resource allocation, and monitoring and controlling the project
• Is an important instrument for reviewing the decomposed scope (with defined deliverables) with the project stakeholders. It also gives a meaningful pictorial view of the scope and deliverables of the project.

How to Create a WBS and what’s its importance?

Step1: List out the Highest Level requirements / Scope Deliverables

It’s one of the most common practices that the first scope statement or the scope of work that a project team receives might contain information in a mix-up format and hence it cannot be taken as-is and used for project estimation and implementation. The project team needs to discuss the scope with the Customer/ Customer analysts/system users to understand the need of the scope mentioned and also the main objectives/requirements/deliverables that are expected out of the project. It’s implicit that these requirement clarifications and discussions with the Customer teams are required throughout the course of the project as and when required from an estimating perspective. Place these objectives/requirements/deliverables at the first level of hierarchy in the WBS diagram (See Figure 1). This step gives a defined starting point to the project estimation process by converting a scope document into a first set of high level requirements. One of the points to keep in mind is that developing a hierarchical diagram is only for ease of understanding and quicker understanding of the scope decomposition. The broken-up components can be listed and numbered in any format and in any tool (Word, Excel, MPP, etc…) and can be tracked in various ways. It is not the format that matters but the connection and linkage between the parent and the child scope items that make the WBS structure one of the most prominent and useful tools for the process of project estimation.

Figure 1: High Level Requirements

Step2: Break-up each high level requirement into major deliverable categories

Once the high level requirements are available as defined in Step 1 above, for each of the high level requirements, teams should then take-up each of them one by one and start digging into the next level summaries of what’s the product or what are the products that need to be created/changed/implemented for meeting the requirement. It will quite be possible that for a given high level requirements changes might need to be made to four different systems/components each of which could be implemented independently. As part of this step, team should keep asking itself – “what needs to be done” to achieve this requirement? One needs to be sure that the next level break-up being created should relate to products/activities that need to be defined further (See Figure 2).

Figure 2: High Level Requirements Broken-up into Sub-Categories

Step3: Break-up each major deliverable into single or multiple measurable activities

The next step is to take each deliverable/system change identified in Step2 and create defined activities or work-product(s) for each of them with the information related to the associated effort required for each of the activities together the level of risk and complexity for each of them. One thing that needs to be remembered is that as we go down the WBS structure, the activities should get refined till they reach a reasonable and measurable activity. Now the question is “what’s the rule for a measurable activity?”. I would say there is no such confirmed rule and it would mostly depend on the type, size and complexity of the project, organization process and also the level of break-up that the WBS is being built with. Normally, an activity with duration of 40 hours or up to the max of 80 hours is considered as a measurable activity as these durations are reasonable enough for a project lead or a project manager to monitor. The measurable activities thus created are sometimes termed as work packages and one of the principles of a WBS is that the requirements need to be continuously decomposed till we arrive at a final list of work packages that could be monitored. It is very well possible that each major deliverable that we started off in this step might have more work packages and in some cases, it might be needed to decompose the current deliverable into more sub-levels until a defined work package is arrived at. In that case, the WBS structure will go into deeper sub-levels which is ok since the goal of carrying out the WBS exercise is to ensure that each requirement is successfully drilled down to its respective final deliverable/work package (See Figure 3).

Figure 3: Major Deliverables broken down into measureable activities/work-packages

Step4: Review Work Packages for completeness of Scope Coverage

The final step in this process is to ensure that the correct numbering is applied to each of the levels and that each requirement is efficiently drilled down to is respective deliverable mapping all the intermediate WBS components. Each component within each level of a WBS is numbered as and when it’s created. In this step, the WBS components are reviewed from top to bottom to ensure that the top level requirement has its hierarchical deliverable numbers for each of the levels clearly listed and also ensure that none of the high level requirements or the intermediate deliverable is missed in the process. This step also ensures that the implementation of listed components or completion of listed actions will indeed lead to the anticipated results. This final listing of WBS numbering also gives a good idea for the project managers when they are creating the project schedule as the WBS gives detailed information on the predecessor and the successor activities of the each component.

Is WBS required for every Project?

I would say “yes” – But not necessarily as a mandatory requirement. It merely depends on the project needs, the organization process and the type, size and complexity of the project. Having said that, even if we use the WBS process as a standard procedure within the project or not, it is imperative that the principles of WBS are always used by anybody estimating for an important project. Otherwise, how would they arrive at the estimates? If it’s by mere trial and error, the, chances of project failure are extremely high. In other cases, it’s just that the standard process is not explicitly followed, but the implementation team would definitely have arrived at an estimate by implicitly making certain decisions based on the goals of the project that need to be achieved, project risks, expertise, past experience, the organization’s process compliance and the project constraints. As mentioned before, WBS is just an instrument or a tool to decompose a large or a hypothetical scope into a set of definable, structured and measurable activities or tasks that are associated to the respective project deliverables. To add, since a WBS gives an idea of the effort required for each of the work packages together with the associated risk and complexity information, it could also be used as an apparatus to prioritize requirements or deliverables based on the effort required, risk associated, number of unknowns and complexity involved. Hence, a WBS is sometimes used as a connecting point between the Sales/Marketing and implementation teams as it aids them in making scope decisions quickly and with more precision thereby reducing the risk of losing some functionality in the system/product that would otherwise have been more beneficial to the system/product/organization.

Dos and Don’ts

Team Building Activity: The process of creating a WBS should be considered as a team building activity. For projects of normal size, a WBS cannot be created by one team member. It needs various team members to take-up each high level requirement within the given scope, discuss about it with others in the team and then each lead team members need to come-up with the activity/work-package break-up details related to that specific requirement. Likewise, the activity details are arrived at the other lead team members and the project team consolidates all the deliverables information received and collates back to a fully blown WBS which can then further be sued for the next steps of project planning and scheduling.

Not a Project Schedule: A WBS is not a project plan or a project schedule. It only provides detailed information on the given initial scope and on the final deliverables that need to be implemented to achieve the project goals and objectives. It should be understood that WBS helps in giving an accurate input for creating a project schedule by way of the activity/work package information.

Don’t go into too much Detail: Project teams typically assume that as part of a WBS creation, they need to go into details of the high-level requirement – which is correct. But one needs to understand that this drilling down of the high-level requirement should not be taken down to the lowest level of the detail which makes it cumbersome for the project team members itself to monitor and it also leads to micro-management from a project managers perspective which is not healthy for any project. Project teams should start thinking of WBS as an instrument which can be twisted to suit the specific project scope needs. There is no hard and fast rule that one needs to break-up a requirement into three levels or four levels. It is up to the project teams and the project manager to decide on the degree to which a particular requirement/scope needs to be broken-down to in order to make it meaningful and reasonable for successful implementation, monitoring and delivery. There might be some requirements that are straightforward and which would not take a couple of weeks to implement- then in that case the requirement itself can be assumed as a work package spanning across two weeks duration and the output of the final deliverable also is clearly understood since the original requirement defines it with precision.

Customer/Stakeholder Communication: One other vital aspect that projects teams need to bear in mind is to ensure that they always keep an open communication channel with the Customer/Client and the various stakeholders of the project throughout the process of WBS creation. One should not assume that since the team is breaking-up scope into smaller elements and creating a WBS, discussion with the stakeholders is not necessary – that would be one of the biggest blunders. Bottom line is that how can one break-up a larger scope into required smaller elements unless they are clear on the final product change or the functionality that is expected from the project. Breaking-up scope into smaller activities is not going to help unless one is clear on the actual output desired from the given requirements.

To Conclude, if a structured WBS process or procedure is followed, the chances of a successful project estimation, planning and implementation are much higher which would help the global project teams to minimize project risks and also benefit them from getting entangled into a unnecessary change control/scope-creep/project-delay discussions which are the some of the most common avoidable issues persisting in the project management space today.

Thanks for Reading!

Don’t forget to leave your comments below.