One of the hardest things to achieve in a project can be a complete list of the project tasks. A Work Breakdown Structure (WBS) is a tool that helps to divide the project into manageable blocks of work, however especially on larger projects this can seem daunting or even pointless at first glance. How can it be possible to foresee all the things that are going to occur in a project that might involve thousands of people over several years? And even if it is possible, there can be a lot of resistance from the project team to plan the project in so much detail, as the effort to produce such a comprehensive document may seem to outweigh the benefits. Maybe the team even prefers to avoid early decisions and wants to leave some flexibility in how some parts of the project are done. On the other hand, how can the project be properly planned, budgeted and correctly tracked if its unclear what exactly needs to be done?
In my personal experience, even if a WBS is accepted as a cornerstone of classical project management, it is missing from many projects and rarely done in sufficient detail.
An Agile Point of View
During my work I have also observed projects that have turned away from even trying to formally create a WBS document at the start of a project and have instead adopted agile methods such as SCRUM and KANBAN as a project management approach. Agile methods appear to do away with most waterfall processes except the most superficial of project plans. Agile practitioners embrace the unpredictability of their projects such that they may not even be really concerned about which topics will be included in the sprint (time box) after the next.
At first glance the agile and classical project management methods seem to follow opposite directions here, but under the surface I think there is a lot in common. Even if an agile method doesn’t provide much long term guidance for a project, it does force short term structure and high detail for the work to be completed. For instance, in order for a project team to use a KANBAN board for task tracking and allocation in their project, they must of course first identify what those task are. In essence using a KANBAN to steer the project forces the creation of kind of small-scale WBS.
Combining Approaches
Considering the resistance to creating a full WBS at the project start, then why not use the a KANBAN board as a secret tool to build the project WBS? Most teams can work easily with a KANBAN board to allocate and track tasks. If the project manager accepts some flexibility in the WBS, and creates it initially only at a top-level, then the KANBAN boards can become a tool to naturally fill out the WBS with detail as the project progresses, iteratively refining the plan as more information becomes available (rolling-wave planning). The result is a flexible WBS that grows in depth with the project, remains ahead of the tasks that are in work but always contains the entire project scope, at least at a high level.
