Work Breakdown Structure (WBS) is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. — PMBOK
According to the Project Management Book of Knowledge (PMBOK), the Project Manager (PM) must create WBS during the Planning Process Group or in the Scope Management Knowledge Area. Therefore, over and above PMBOK’s guidelines, I think WBS is a critical aspect that a Project Management Team (PMT) needs to work on at the early stage of the project.
When I was initially introduced to the concept of WBS, when I was taking my Project Management Certification (PMP), we usually focused on getting it up and tagging it with Time and using it to develop the Gnatt Chart. When creating this using tools such as WBS Schedule Pro, we can include the Task Owner and give it a Cost to sum it up to the Project Budget. However, when I thought through this while conducting the online Project Management Fundamental training, I felt that WBS is beyond these.
How can WBS help us in managing projects? Below are my thoughts.
Scope of Work (SOW)
The requirement to solicit requirements from customers is beyond the discussion of this article. I will assume that either the PM or the Business Analyst has done this. While PMBOK asked us not to do anything less or more beyond the SOW, it’s human nature that we expect more for less.
WBS enable us the clarity to see what the PMT needs to perform to deliver the project per what’s required. If there is anything more than the customer is asking, this helps us to see if we can efficiently work on that without having significant disruptions to the project. I am not advocating for Scope Creep, but we ought to run the project like a human instead of being overly technically correct.
Ownership
Many cannot understand the importance of having someone take ownership of the task. Of course, there is an issue of having ownership without authority, but what’s worst? WBS enables the PMT to identify who is the ONLY person that’s accountable for this particular task. The person accountable may not be the person who’s physically completing the task, but the PM knows who to approach if there is any delay.
WBS also helps to identify which could be dependency tasks that can be managed by an individual instead of having multiple parties, which complicates the communication. Breaking down the project in this manner also helps the PMT to associate a specific task that requires particular expertise and ensure someone suitable is on top of the situation.
Cost & Time
The ability to break down the project into “bits & pieces” enable the PMT to provide a reasonable cost & time estimation for the project. Yes, we are supposed to keep to the time and cost of running the project. However, there are also external circumstances at work that derail what the PMT planned on executing.
The tagging of cost & time in this manner provides the best alternative of having the best estimate that might be closest to the actual cost of running the project. At least, this is what the literature tells you. But, if you think this alone will give you the best estimate, you might be missing the other vital aspects of WBS.
Procurement
Breaking down the project into smaller tasks enables the PMT to know what they need to purchase to produce the project. The pandemic has changed our view on procurement and supply chain disruptions. We realised that we depend heavily on one another and can no longer operate in a silo. Not when everyone is looking at the cheapest and fastest.
This helps to give us the Bill of Material (BOM) and develop a plan to look at possible disruptions to the project in terms of delays and rising costs. For example, suppose you will purchase raw materials from a country that might be in a political situation that could cause a potential delay. In that case, you can start to consider alternative approaches, either getting from another source, getting alternative materials, or purchasing early.
Have you realised that we are navigating in another Knowledge Area, the Procurement Knowledge Area? The exciting realisation is that we are also threading in the Risk Knowledge Area with these considerations.
Risk
The work packages in the WBS enable the PMT to have clarity in consideration of the risk that each work package might inherit. When we see things from a higher level, we might not be aware of the composition of those that operate in the lower level, those details. This blindside could cause an issue to the project if the risk occurred and caught the PMT off-guard.
When handling the risk of a work package, it might create percussion for other work packages. Working on risk at this resolution helps the PMT identify if there could be other considerations before deciding on the risk action.
I feel that risk might not be a focal point for the PMT as this involve a lot of people and take a lot of time. However, risk is an essential aspect of the project and working it right could save the project budget and probably reduce cost, bringing more profitability to the project.
I will write another article on this.
Quality
Quality is another aspect we might not have considered in detail when managing a project unless it’s an explicit clause mentioned in the project requirement.
Does it occur to you that if we managed the project with quality built-in right from the start, we might have avoided some situations that resulted in time, budget, or productivity loss? In addition, the ability to tag quality considerations to the work packages could help the project mitigate problems later. Quality does not necessarily mean quantifying or testing to determine if the outcome means a certain standard. It can simply mean defining a standard process of approaching a work so that everyone in the PMT who deals with a task of similar nature knows what to do.
For example, what’s the difference between all these? “10 10 22”, “10 October 2022”, “October 10 2022”, “10 Oct 22”, etc. You might know that it means the same thing, but taking care of these in the form of data could mean differently. The team might need additional codes to take care of these or spend additional time cleaning the data before it’s meaningful.
Summary
While we might feel that we do not need to break down the project into work packages, working out a WBS has many benefits. Yes, it takes a significant time to work all these out, but it might be worth the effort to save the time and budget of the project you are managing.
Lastly, while the ten knowledge areas are taught in serial, they all work in parallel and affect each other as more details unfold. As a result, it’s nearly impossible to run a project by approaching things as what it’s listed in the text.
תגובות