Book review – Secrets to mastering the WBS in real world projects

Secrets to mastering the WBS in real world projects is by Liliana Buchtik PMP and was published by the Project Management Institute (PMI) in 2010. Liliana Buchtik is president of Buchtik Global, a consulting and training firm specialising in project management.
The book is written in a simple question and answer format and each chapter heading is phrased as a question. There are 12 chapters covering all aspects of the construction and use of the Work Breakdown Structure (WBS) in this 202 page paperback book.

Chapter 1 sets the scene by providing a definition of the WBS as “a structure used to breakdown or divide the project work” to show what the project has to deliver to achieve the desired outcome.

Chapter 2 advances 20 potential benefits that can be obtained by implementing a WBS. These range from understanding the work through to inspiring confidence and gaining credibility.

Chapter 3 explains 4 areas of confusion about the WBS. These being confusing the WBS with a sequence of work, confusing the WBS with a schedule, confusing the WBS with the organisational breakdown structure (OBS) and not using the modern working definition of the WBS. The author takes time on the final point to explain the difference between a task and deliverable based structure.

Chapter 4 asks what questions need to be asked to understand the capability of a well structured WBS. The chapter asks the what, when, why, who and how questions that relate to the creation of the WBS.

Chapter 5 covers the theoretical requirements of creating a WBS. This includes how many levels the WBS should go to and identification and numbering of the individual elements. One of the key aspects of this chapter is answering the question of how many levels are needed in the WBS. The author suggests that you should “decompose the WBS to the level where you are able to manage the work and able to assign and estimate resources, costs and time”.

Chapter 6 covers the practical steps needed to create a WBS that aids project delivery. The author walks the reader through a 20 step model to create the WBS. This begins with understanding the required inputs and closes with baselining the identified project scope.

Chapter 7 discusses software tools that can be utilised to visually represent the WBS. Visual WBS’s are considered as either being a tree structure , text based outline or a spreadsheet based tabular format. Software such as Microsoft Word, Excel and Visio are covered as is MindManager and others.

Chapter 8 explains how the WBS can be integrated with the management of scope. The author argues that “it’s almost all about scope and how to better manage it. The scope is the basis for planning.” The chapter advances the sensible concept that we must, as project managers, understand the scope of the project and that the WBS is a key pillar in this strategy.

Chapter 9 shows how the WBS can be used to derive resource and cost schedules including why this should be done and offering practical advice on how to do it.

Chapter 10 demonstrates how the project manager can integrate the WBS with stakeholder and risk management. The central thesis of the chapter being that the WBS can be exploited for uses beyond pure scope management.

Chapter 11 and 12 close the book by exploring its use in virtual, multicultural and agile environments.
The book closes with a conclusion and 2 appendices encompassing 2 generic WBS templates.

The book provides an interesting view on the WBS. The author conveys an obvious passion for the subject which draws the reader in. The practical advice is relevant and every project manager should be able to take something from this book and apply it to their project management practice. I recommend this book to any project manager looking to broaden their understanding of this powerful project management process.

Agile Project Management

Agile project management is almost a misnomer, in Scrum there is no such role as the project manager. However as project managers we may be asked manage agile projects.

Scrum consists of three roles namely product owner, ScrumMaster and the wider team. The product owner is responsible for ensuring the right product is being built. This is a challenging role and the product manager has to juggle a range of priorities. He should be available to the team and be able to make decisions about the product. If the product manager cannot make decisions then this can have a significant impact on an agile project. We do not what to deal with decision making as exceptional events, the information should be quickly presented and the team empowered to make decisions.

The scrum master works to manage the progress of the team. He should remove any hurdles to progress, facilitate workshops and meetings and monitor progress. The scrum master is the closest role to that of the traditional project manager. However, if you are a scrum master be careful not to be a project manager. By that I mean we should not be shackled by classic project management processes. I talked about lean methods yesterday and those principles should be present in the scrum master role. It’s about doing the right things rather than doing things right.

The team are the intellectual power in the agile process. They provide the intellectual capital to build the products identified by the product manager. They are the engine that delivers the results usually through an agreed iterative process with the product manager. Various approaches can be taken to managing the process of product creation, we can timebox or set requirement limits and so on. The aim being that we quickly identify what we need to do, prioritise and agree what we work on; and rely on the scrum master to create the environment that can deliver success.

This is a step change for some project managers who suddenly find themselves in an agile environment. It is an environment where responsibility is devolved down to the team. The team can set workloads and control scope whilst the product manager is empowered to make scope/time/cost tradeoffs . For a project manager moving into Agile teams this can be a liberating process and, given the right project, can demonstrate how powerful a process agile can be. Working in agile environments presents a significant personal development opportunity for a project manager. It shows how there is no one size fits all approach to project management, rather that we have a series of tools at our disposal that we utilise on a situation by situation basis.