Most, if not all, successful projects are dependent on good project scope management. Project scope management is made up of several processes that dictate what’s included in the project. One of the most crucial processes and often most difficult is creating a work breakdown structure or “WBS”. What makes a WBS so crucial and difficult is that it breaks down and groups all of the work necessary for the entire scope of the project. All of the schedules, costs, resources, and changes are founded under the WBS. Since one the primary purposes to a WBS is to group work together, people will often start with either a tree/branch structure or a chart in tabular or list form. These structures can help provide a visual of what work falls into its corresponding group. Below are some examples of WBS’s broken down into groups and deliverable levels; the first in tree/branch form and the second in tabular form.
There are several popular approaches to developing a functioning WBS.
· Using guidelines
· The analogy approach
· The top-down approach
· The bottom-up approach
· The mind-mapping approach
Today we will be focusing on the top-down and bottom-up approaches. Even in our daily lives, using a top-down approach is common in breaking down all kinds of problems that are too big to tackle all at once. It’s usually logical to breakdown sections into smaller more focused steps when needed. The same is true with higher level, company-wide projects, which makes this a common approach when creating a WBS. With a top-down approach project items are broken down into smaller and smaller package levels until all resources are assigned to their proper respective groups. While this is a popular approach, there are some inherent problems. The top-down approach relies heavily on higher-level management preparation and planning, typically by those who will be furthest from the work. The problem with this is that it also requires this higher-level management to be familiar with the technology and any possible problems that would be faced by the lower-level employees implementing the project. Upon immediate evaluation it would seem that this would be a fairly uncommon choice among organizations, but in fact it’s just the opposite. Many large organizations still tend to follow this top-down approach and it tends to work. The top-down approach for large projects requires so much preparation that once this plan is in place, barring any potential problems, there is a relatively short deployment time for the project. This means that worker momentum usually remains high for the entire life of the project and there is less time for any possible project diverging.
Generally, higher-level management knows the most about where they want the project to go and what the outcome should be. They’re the ones usually responsible for any financial resources lost due to bad planning so the top-down approach makes sense. On the other hand, wouldn’t it be better if certain decisions were made by those with the most experience on the matter? This is where the bottom-up approach shines. Instead of relying on lengthy planning by upper-level management, team members are responsible for identifying any tasks that the project might require and then organize those tasks themselves. Starting with the lowest level tasks, the then group those tasks into more general higher-level groups. This can sometimes be more time consuming than the top-down approach, but it is better at avoiding the problems that occur when upper-level management doesn’t fully understand how to implement the project, such as in the top-down approach. One of the risks involved with the top-down approach is that because team members are not necessarily close to the project, if any unforeseen problems start to bring down momentum, the project can start to see even more problems from teams losing interest. The bottom-up approach helps counter that by the teams effectively planning out the project themselves. This can give team members more of a connection to the project and help keep motivation higher than just following marching orders for a project given to them by management. This approach is prone to change and adaptation as the project goes on and thus tends to avoid the upfront financial dedication involved in a top-down approach, but also takes on the risk of being more costly without a clear path laid out from the beginning.
Both approaches have their pros and cons and there really isn’t a right choice when creating a WBS. They both have their inherent risks, just on both ends of the life of the project. The top-down requires more of an upfront planning and dedication to the project while a bottom-up approach requires it less upfront and more throughout the life of the project. Larger companies tend to follow a top-down approach while smaller companies can tend to follow a bottom-up approach. One thing that’s critical to project scope management is to actually develop a WBS in the first place whether it is either of the above approaches or any of the other several.
Bibliography
Schwalbe, Kathy. InformatIon technology Project ManageMent. 9th ed., Professor Emeritus, Augsburg College, 2018.
Agile Transformation: Top-down vs Bottom-up. (n.d.). Retrieved from ADAPTOVATE: https://www.adaptovate.com/agile-transformation-top-down-vs-bottom-up/