PM-Foundations – Organizing Your WBS

Creating a well-organized Work Breakdown Structure (WBS) is always on my list of “critical few” project management best practice areas. The WBS is utilized to effectively define the scope of the project, decomposing the work down into components that can be estimated, scheduled, and tracked/controlled throughout the project life cycle. The WBS makes the scope of the project actionable in the form of a deliverable oriented and hierarchical view of the work. The WBS defines the scope of the project down to the lowest level deliverables called work packages.

One of the most common questions I get when discussing the WBS with project teams is, “What is the best way to organize the project deliverables?” A lot of people think the answer must be obvious, because it does not seem to get discussed much by the team when the WBS takes its initial shape / form. It is not at all a stupid question. There are two very different ways that team members think about the project. One way of thinking about the project is focused on the product that is being created, and the other perspective is based upon how the project work will be completed. Selecting one school of thought over the other will drive a totally different end result in terms of the organization of the WBS. As the project manager, you have to live with the organization of your WBS throughout the project life cycle (it drives the organization of the project schedule, as well as the monitoring / controlling processes), therefore you want to be sure you have purposefully selected an organization approach that works for the project team.

Product Based WBS Organization

For those of us with experience in a manufacturing environment, you are familiar with the concept of the bill of material. The bill of material describes how to build a product from the end product down to the lowest level parts or components. The bill of material is utilized to manage building products in a repeatable, efficient, and cost effective manner (automated utilizing an ERP system). When designing or developing a new product, the bill of material is a logical manner to organize the work that needs to be completed. For product development type projects, organizing the WBS in this manner helps the team think about and visualize whether or not they have effectively accounted for and planned all aspects of the product. This approach also provides an understanding of how different aspects of the product are coming together as the product development effort progresses.

Benefits

Downside

  • Provides the ability to trace the components of the product down to the lowest level sub-components
  • Improves the visibility of the current status of product components (particularly important when working with suppliers)
  • Engineers relate well to the WBS organization structure
  • The WBS is not organized from “beginning to end” of the project life cycle
  • Top levels of the WBS remain open until the end of the project
  • Non-product related deliverables do not fit well in the WBS (unless they are define as part of product’s the bill of material structure)

Project Based WBS Organization

As a project manager, I generally think about the project effort in terms of how the work is going to be completed (based upon the timing and dependencies associated with deliverables). With this approach the work is grouped into work streams (sub-projects), and project phases (defined with major milestones). As you get into lower levels of the WBS the organization of deliverables is based upon the different components of the project or product. This approach allows the project manager to update the project “from top to bottom” as the project progresses (assuming the project progresses in pretty much the same manner as it was planned).

Benefits

Downside

  • The “flow” of the WBS relates closely to the way project work will be completed
  • As work is completed, components of the WBS can be “closed”
  • Generally, easier for project managers to update progress
  • Difficult to utilize the WBS to obtain/communicate the “bill of materials” relating to the product
  • Difficult to highlight the status of specific product components
  • Engineers may struggle with understanding the schedule (and often complain about it)

 

What is the Best Fit for My Project?

There are good reasons to organize your WBS from both the product and project perspective. Below are several factors to take into consideration when you are working with your team to determine the best approach for organizing your WBS.

  • Standalone vs. Dependent Work Efforts – Where are the majority of the dependencies and interrelationships within the separate work efforts? Are the dependencies more focused on the product components or the phases of the project? Are the project milestones tied to the product components or gates in the project life cycle? It is much easier to manage dependencies in a vertical manner within a single work stream, rather than in a horizontal manner across multiple work streams.
  • Wide vs. Deep – Based upon my experience, it is much easier to manage a project that has a WBS that is deeper (vertical) than it is wide (horizontal). Part of this preference goes back to the fact that it is easier to manage dependencies within a single work stream (vs. across work streams). However, I also find that it is easier to manage and measure progress of the overall project (solution) if there are fewer separate work streams that link directly to the highest level of the WBS (the over solution / project summary). For example, if there are 15 major product components associated with your project, with significant dependencies across the components, you should have a good case for organizing the WBS around the project life cycle.
  • Who Cares? – Who are going to be the major consumers of the information maintained within the WBS and the project schedule? Is the effort more product or project focused? If it is a very product focused effort, largely comprised of a team of engineers, you may be fighting an uphill battle to suggest that the WBS should be organized based upon the project phases.
  • What Does Progress Look Like? – How will you be receiving updates on project progress? Will progress updates be organized around separate product related work efforts, or based upon the project phases and upcoming project milestones? Again, the answer to these questions will be largely dependent upon the composition and focus of your project team.
  • Iterative Implications – When the team makes the decision to deliver the project in an iterative manner, they are making the decision that the WBS needs to be organized around the iterations. Iterations are time based, and therefore the WBS takes on a project based organization structure (with the project phases being the individual iterations and milestones for deployments).
  • Either approach will work – As you can tell from my analysis above, I am a project manager and obviously favor one approach over the other. The bottom line is, either approach can work for you and the project team. I can honestly say that some of my most successful project were managed with a product based WBS. In some cases additional steps are required in the WBS definition, and schedule set-up to provide views of the schedule / status from both a product and project perspective. This can be accomplished in MS Project by creating custom fields and special views (using sort and filter functions with the custom fields).
Advertisements

Using MS Project to Set-up your Project for Success

Project managers that are not as familiar with using tools like MS Project to create a project schedule often “dive in head first” creating their project schedule. These project managers open a new file, start furiously loading project tasks, and the project schedule evolves as project planning progresses. After the project schedule baseline is established, and project execution begins, these project managers begin the weekly battle to maintain the project schedule in a manner that keeps it close to reflecting reality. Some of the telltale signs that your schedule is difficult to maintain include:

  • You change the dependency on a task and the dates do not change
  • You extend the duration and the work hours do not change
  • You add a new resource and the dates change unexpectedly
  • Your schedule shows people working on Thanksgiving and Christmas
  • Durations are displayed in hours, and work is displayed in minutes

I was working with a project manager whose schedule had become so difficult to maintain that he declared that his “tool had become compromised”. This created much frustration for the project manager, but the even worse result was that he was not sure that the milestone commitments established in the schedule were correct or achievable (and he did not know how to fix it).

Obviously, how well the WBS is organized has a significant impact on the ability to effectively and efficiently maintain the schedule throughout the project life cycle. In addition, there are several set-up activities within MS Project that allow the project manager to tailor the project schedule to meet their needs. Paying attention to these set-up activities when the project is first created allows you to better understand and control the behaviors within the schedule as you update the project schedule to reflect progress. The set-up tips described below include defining the project start date and project calendar, establishing default schedule options, and entering your project resources.

Defining Project Information

The first MS Project set-up feature I look at is Project Information. This feature establishes the start date for the project. This feature is also utilized to link the default project calendar to the project. If you are using MS Project Server, the project office has most likely established predefined project calendars. When using MS Project 2010, I generally start with the standard project calendar (see below for setting up the project calendar).

Setting up the Project Calendar

One of the most embarrassing things during a schedule review is when someone points out that you have scheduled resources to work on a holiday. That is why it is a best practice to early on tailor the calendar to accurately reflect your project environment. The project calendar is accessed from the function “Change Working Time”. This function provides the ability define non-working days (e.g., holidays). Again, if you are using MS Project Server, the non-working days are likely predefined on the project calendar you selected from the server configuration.

Setting up Schedule Defaults

One of the most important MS Project set-up functions (and also one of the most commonly overlooked) is Project Options. The Project Options lets you tailor many features based upon your personal preference, but the Schedule Options contains settings that will impact the day-to-day behavior within your project schedule. There are two primary components of the Schedule Options:

  • Calendar Options: These setting are used to define the work week (start and end of the week, hours / day, hours / week, and start and end of the work day). The calendar options may also be configured for specific project calendars.
  • Scheduling Default Settings: These options are utilized to define default settings associated with new tasks. I always recommend that durations are set-up as “days”, and work is set-up as “hours”. Unless there are special circumstances associated with your schedule, these are the most logic units of measure for managing the timeline and work effort. If you are creating a resource loaded project schedule, you should set up new tasks as effort driven. The option that seems to be confusing to project managers is the “task type”. The “task type” is utilized to define which task elements are updated when another element is updated (duration, hours, and resource unit allocations). The table below helps illustrate the update behavior associated with the different “task type” options. My personal preference is “fixed duration”. This option allows you to effectively control / manage the timeline (duration) when making updates to the schedule.

Note: Units refers to the % that a resource is allocated to the task. Fixed duration locks in the timeline and recalculates either units or work.

Defining Resources

Before getting too far into creating the schedule, it is important to define your resource pool in an organized manner. The following are the key elements associated with the resource pool:

  • Name – Use the standard naming convention for loading names in the schedule. It is important to be consistent.
  • Initials – Allows you to abbreviate the resource names for viewing in the schedule (takes up less space on specific views)
  • Group – Allows you to group the resources in a logical manner, either by organization or resource grouping. I generally use this field to define the different type of resources assigned to the project (e.g., project manager, business analyst, developer, QA).
  • Std. Rate – Defines the cost / hour for the resource. This is a key element for project budgeting purposes.
  • Max Units – Defines to what level the resource is working on the project. This is a key element used for resource leveling purposes.
  • Base Calendar – Establishes the working calendar that is used for this resource (may have specific resources with different work times).

If you are using MS Project Server to load projects into your project schedule, you select project resources associated with your project from the Global Resource Pool (vs. entering resources to create the project resource pool).

Note: This is a bit of a milestone on my blog – my 50th post. Hope you enjoy the content as much as I do creating it.