Written by Create a work breakdown structure or create WBS. Last process in a planning process group of scope management knowledge area. What is a work breakdown structure? Before we get into detail, we need to understand a work breakdown structure. A lot of the time, you may see it as an organization chart. Yes, this is a hierarchical diagram because most of us only see it as a hierarchical diagram when we see an organization chart. So what breakdown structure is? A hierarchical diagram helps us in decomposing or subdividing the work. So we may have a project work breakdown structure that starts at a project level, and we may subdivide it into deliverables. Now how do we subdivide it? There are various possible approaches if we follow the phased-based path; we say that this is my complete project. Let us take an example of an IT project we created a job site; you will say I will do requirement analysis first and then develop or design and develop. Then you have to do a test etc. These are a Phase-level division of work breakdown structures. Inside the requirement, you will have modules, one module to three modules. So that is how you can create a work breakdown structure. For the same site, you may also create a work breakdown structure that is delivery-oriented. So rather than dividing in a phase, you say that in my project, I have a module called search, I have a model called vacancy management, or I have a module called profile management and inside those modules in a search. You have various types of search like keyword search, location search, salary search. So they are decomposing the complete project scope statement into small manageable components and a hierarchy Queue of decomposition. We are talking about the first level, second level, and third level.
Further decomposition can happen in this. Here we have decomposed it based on features. We may deliver search first; then we provide the latency management, then we may provide the profile creation or vice versa. Now how do we create it? Before we understand how we make it, we need to know what we need to start? We need to know what is work, then only we can break the work. We can get the work from the project scope statement, an output of “define scope,” and we also have requirement documentation which we have received from the collect requirement. So these two provide us what the work is. So we have a project scope statement as an input. We have required documentation, and information tells us what the work is. But as a project manager, you also need to know how to convert this work into a work breakdown structure.
At what level of details we are going to go. Are you going to follow the phased approach? Are we going to follow a deliverable path? So we need to know the how part of scope management. How much time will you think about why I need to make a plan and then do it. If I know I am a project manager and only have to create a work breakdown structure, why write it first. If you are thinking of a small project, I understand this is obvious to come to your mind but think about a big project where you are creating this, and somebody else is working on it. So for you to control the quality of his work structure, this is the only option. So here you will tell, and you need to follow this approach. It would help if you went at his level. Then, in a complete project, whoever is making this work breakdown structure in their respective war rooms, follows the scope management plan in the respective geography. You follow enterprise environmental factors and ordination processes in general. They always help us in finding out how to create this particular work breakdown structure.
When we talk about tools and techniques, a problem needs to be divided, subdivided, or decomposed. So the first tool and technique that comes into the picture is decomposition, which means dividing the work into small manageable components. That’s it! How do you do it? It would help if you thought about it; no ready-made solution says this requirement decomposes it that way. You need to understand the condition. It would be best if you saw your scope management plan. It would be best if you saw your environmental factors. You need to take help from your organization’s process aside and put your mind in it, which is why we need expert judgment, an expert who understands the technique of decomposition, who understands the scope of work. We know how and what the scope management plan is talking about? Look at these two things and create a work breakdown structure. It is good to have a deliverable-oriented work breakdown structure. Because by completing some components whatever I do, even if in a phase-wise thing that the phase level deliverable should come here and this deliverable should be mentioned in your project scope statement. So you know that this particular deliverable has these many sub-components. Once I have done with these sub-components, I can go for verification, acceptance of that specific deliverable. Now, how many levels should we have in our breakdown structure? Should a leaf node end at a time base work? Should it end at a 10-month work? How do I decide? You decide to look at a scope management plan. How do we mention the factors behind it, the project’s complexity, and the type of control you need in your project’s scope management plan. If your project needs too much power, as a project manager, you want to know the status of all the work packages as frequently; you may decide to divide a work breakdown structure. If you need high-level control, you may not go to those fine-grained levels.
There may be their way of further dividing it into their respective teams, but here we may limit somewhere at the top. But whenever you specify the leaf node of a work breakdown structure is called a work package, and then we will do a time management knowledge area. We will divide this work package, or it will identify activities for executing this work package. So in a work breakdown structure, we are not talking about actions. We are not talking about the sequence; no, we’ll talk about the work package, a deliverable component that works as one unit, and defined activities to get that package under time management or defined activity process. That is a separate process that is not a part of creating a work breakdown structure. So the leaf node of the work breakdown structure is one package. Creating a work breakdown structure is the last process, “last planning group process,” of a project scope management. So it gives us a scope baseline, we get scope, critical baseline. Now, what is your baseline? It’s an approved version of the scoop statement also; we have a scope statement inside it, we have a work breakdown structure inside it, and we have a work breakdown dictionary. These are the three components that form the scope baseline, and from a combination of these, it should be obvious there’s a baseline. It is not just the scope statement but also a work breakdown structure and WBS dictionary.
What is the WBS dictionary? WBS dictionary details these packages or WBS components, so every WBS component may be detailed in a WBS dictionary by a day off. It may have an identifier with a description of this work package, but all will go inside it. We may also have a control account attached to it now.
A control account is a new term which we are using. It’s an accounting code that will help us control expenses under the work breakdown structure for our package. So we may be spending money on various activities. These activities combine, and we can analyze that against travel, how much money we are paying or against a given work package, how much money we have spent? So we may have a control account in our structure. We may have various other fields like we can have an assumption related to that work package. We can have acceptance criteria attached to that work package.
In some cases, a WBS structure may have introduced a quality requirement. Some may have a quality requirement mentioned as a form of an inner work WBS dictionary. We may also have a budget allocated at the WBS level. We may have responsibilities assigned to who is responsible for executing this package. So if you have a distributed environment, you may have our packages distributed across geography, so you should know who is accountable for finishing this particular work package. So, such details that help you identify and explain a work WBS element can be included in the work breakdown structure dictionary. The second output coming from creating WBS is simple to update project documents. So that you may edit various project documents not limited to requirement-related records, but need related documents like requirement traceability matrix and requirement documentation may frequently get updated based on this work breakdown structure. Because in the requirements traceability matrix, you would like to mention which WBS elements are taking care of requirement implementation of this particular requirement. So, in summary, a process that creates WBS gives us a scope baseline. It provides us with a work breakdown structure and a work breakdown dictionary.