The scope statement is a very important tool and, to some extent, we can say it is a contract between the project manager and the customer. However, Scope statement, does not help us to define the project in terms of activities, timing and people involved. In order to reach that level of detail, we need to clearly define the activities necessary to reach the scope. To do this, we can use a specific technical tool, the WBS: the work breakdown structure. The WBS is the hierarchical list of all the activities necessary to reach the project scope. Normally it is shaped as an upside down tree: at the top we have the project and at the bottom we have each single activity that needs to be performed in order to reach the final output. Each element of the WBS is normally called WBE (work breakdown element) The first one represents the whole project, then it is iteratively broken down into smaller work packages till the reach, theoretically, of the smallest WBE which represents a single activity. Still, in big projects this may mean to have hundreds or even thousands of work packages, therefore we need to have a clear and structured way to be sure that the breaking down process works properly. What is the right way to build a WBS? The human brain normally works in this way: when I think about the activities I need to perform, in order to get to a result, my brain starts to put them in a logical order. First I do the engineering, then I do the procurement, then I do the construction and so on. This kind of approach is good, but not necessarily the best one. The risk to actually forget some activities is pretty high even in small projects. The difficulties are related to the fact that phases may often overlap, or I may see with different aggregation levels different parts of the project. We need to move from our usual approach and embrace a more structured and reliable method. Each WBE is identified by disassembling the previous one into smaller and sufficiently independent problems. In doing so we need to consider two main rules. The first one is that the disassembling of each WBE must be done with a single logic. There may be different logics to divide a WBE in smaller packages, they may be phases, physical parts in the case of products, functions in the case of software or services, and others, depending on the field of the project. The second rule is that all the levels of the WBS must be a comprehensive view of the project, in other terms summing all the WBE at a given hierarchical level we have all the elements that constitute the project. Furthermore, when dividing a WBE, we need to be sure that all the descendent elements represent completely the node we are disassembling. In the product world, the best way to create a WBS is to base it on a product breakdown structure. The idea is: I can see the project as a whole and I divide it into systems, and then systems into single components. Once I get to the level of a single component, I will start asking myself what are the activities needed to have those components: the engineering activities, the procurement activities, the construction activities and so on. So, in this way, it is gonna be a lot easier to control the project because we'll just put a person in charge of each component who's responsible for all different activities that we need to perform in order to have the component. At a certain point we should ask ourselves how much should we go on? Is the WBS detailed enough to be considered complete? If the answer is yes, then the WBS is created, otherwise probably we need to revise and improve the WBS starting the process from scratch again. Usually, after 5-6 levels it is very difficult to be precise. The WBS is a great tool to anticipate opportunities and constraints, since it forces the project manager to identify all the activities at the very beginning. Moreover, its systematic approach helps identifying the eliminatory activities while facilitating the whole vision. Among the other strengths of this tool, it is a great way to learn from previous projects or to bring the experience into the next ones. It means that for similar projects we may start from a standard WBS, benefiting from the experience done in the past. Finally, it enables the delegation of tasks to other people. In this perspective, one final comment: when we have a complex and big project, it is usually a problem to have full control of all the packages at the managerial level. I might have hundreds of thousands of different work packages in a project. And I can have dozens of thousands of them open at a certain point. So if I look at a project in that moment, I might find that this work package is ahead of schedule, the other one is behind schedule, this is over budget while another is under budget and so on. It's very difficult to obtain a general view of a project in this way; so when it goes to complex industrial projects, normally we also consider another level that is known as the control account. The control account is like a sub-part of the project with the control account manager as the person in charge, who's like a mini project manager responsible just for that part of a project. That part will be then split into different work packages, controlled and so on, but at this level, I can really, fully understand how the project is going. Normally in big projects, I might have a number of control accounts.
