“My life amounts to no more than one drop in a limitless ocean. Yet what is any ocean, but a multitude of drops?”–Cloud Atlas, by David Mitchell.
The process of decomposition of the scope done in this process is where the seeds of the miraculous “power of we” on a project are sown. What do I mean? A project is a large undertaking that, in some cases, would be impossible for one single, solitary human being to do on their own. From the construction of the pyramids to the landing of a man on the moon, projects have succeeded because they take a huge amount of work–what is called the scope of the project in PMI language–and break it down into manageable parts that individual human beings can perform. The project manager takes the individual human beings and puts them on a team so that they became a team with the “power of we”, that is, the power of doing more than any group of individuals of the same size could do on their own (the power of “I” alone). When you are on a good team, as the poet Rumi once said:
“You are not just the drop in the ocean. You are the mighty ocean in the drop.”
The process of creating the work breakdown structure or WBS is called “decomposition” and it is the main tool and technique used in this process.
5.4.2 Create WBS: Tools and Techniques
5.4.2.1 Expert Judgment
Of course, the people you will turn to in order to create the work breakdown structure are those with expert judgment, particularly those who have worked on similar projects. Remember, a project team member who wants to avoid work may be lazy, but a project team member who wants to avoid unnecessary work that has been done before is smart. The best place to look for your model of a WBS on a project in terms of the structure of the WBS is the procedures and templates for the WBS, one of the organizational process assets that is an input to this process. For the contents of the WBS, the best place to look would be project files and lessons learned from previous projects, again, some of the organizational process assets that are inputs to this process. And the people that created those documents would be great experts to have as consultants for the creation of the WBS on your particular project.
5.4.2.2 Decomposition
There is only one main tool & technique for this process, and that is decomposition, which is the process of dividing the scope of the project from the level of deliverables, which are contained in the project scope statement (the output of the last process 5.3 Define Scope), to smaller, more manageable parts called work packages, which are the lowest level of the WBS for which cost and duration can be reasonably estimated and managed.
How does the process work? For visual examples you may want to refer to while looking at these steps, see pages 158 and 159 of the PMBOK® Guide.
- Look at the Scope Management Plan for guidelines on how your organization does the WBS (the plan should indicate how all of the scope management processses are to be done, not just this one). The Scope Management Plan is an output of process 5.1 Plan Scope Management.
- Look for the templates for the WBS that your organization may use (these are some of the organizational project assets that are an input to this process). You will use these templates to create the WBS based on instructions contained in the Scope Management Plan.
- Look for the deliverables of the project scope in the Project Scope Statement, which is the output of the previous process 5.3 Define Scope. Remember the scope is developed first at
- the level of requirements (high-level requirements are in the Project Charter, more detailed requirements are developed in the Collect Requirements process 5.2 and placed in the Requirements Documentation)
- the level of deliverables (the Define Scope process 5.3 develops the deliverables that will fulfill those requirements), and then finally
- the level of work packages (this process 5.4 Create WBS takes the deliverables and breaks them down into work that a person can reasonably do in a matter of hours).
- Okay, now let’s build the WBS! The top level is the name of the project itself.
- The second level will any phases of the project life cycle if the project is broken up that way (design, creation of prototypes, testing, etc.).
- The product and project deliverables are the next level of decomposition, which can organized by the requirements they relate to. These can be further subdivided into “major deliverables” and “deliverables” based on the complexity of the project.
- The deliverables are further broken down until they reach the lowest level, that of work packages.
- Once the decomposition of the deliverables is verified as appropriate, then you can develop and assign identification codes to the components of the WBS, where the first level has the identification 1.0, the second level has the identification 1.1, 1.2, 1.3, etc., the third level has the identification 1.1.1, 1.1.2, 1.1.3, etc. This identifies the level to look for any particular component and which component is the “parent” of any particular component. The parent is the component which is broken down into subcomponents at a lower level.
- Once the work packages have all been uniquely identified, you can start adding “control accounts” associated with a group of associated work packages. These are used in the monitor and control phase and contain a hierarchical summation of the costs, schedule, and resources used for that group of work packages.
- For those work packages which are not done immediately, or are as yet without detailed estimates of schedule, cost, or resources, you can create “planning packages” which essentially are a way of saying TBD or “TO BE DETERMINED”.
- Additional information on each work package can be compiled into something called the WBS dictionary, which is information created from other processes in other knowledge areas that supports the scope information contained in the WBS.
That is the detailed process of creating the WBS. The outputs of the process are described in the next post.
Filed under: Uncategorized |
Leave a Reply