WBS

A WBS is a logical breakdown (decomposition) and representation (hierarchical structure) of the “work” required by the project. A WBS can take one of two forms: graphical or outline. The graphical form is best for communicating the top three to five levels of work activity to senior management or customer stakeholders. The outline form is best for capturing the details needed for cost and schedule development.

A WBS shows the work and any interim deliverables that are required to produce the major project deliverables identified in the project definition process. In most cases, the WBS reflects the components that make up the final deliverables and the approach (methodology) used to develop, integrate, and validate them. In short, we can say, the WBS is an organized task list.

By creating a WBS, we employ the primary secret weapon of managing large, complex projects, which is break the work into chunks and manage many smaller components. Many organizations leverage standard WBS templates to ensure any new project includes the recommended work items.

Now a days many industries and organizations routinely use the following terms in an interchangeable fashion: WBS, project plan, project schedule, and work plan. But, these terms do represent different project management elements and should not be used interchangeably. However, as with all “less than-ideal” practices, there are reasons they develop. Understanding the reasons is always helpful, and, in this case, can provide additional insights as to why projects can get into a “troubled” state.

When you think about the process for developing a schedule, determining the work (detail tasks) that is required is the first step. 

After you have identified the work tasks, you can determine what resources are required for each task, how much effort each task will take and what logical dependencies exist between the tasks. At this point, you can begin to construct the first of several iterations of a project schedule. But if you project scheduling software such as Microsoft (MS) Project you might encounter a few problems. Here’s a common scenario:

·        You are told to build a work plan for the project.

·        You go to your desk and open up MS Project and start entering and organizing the tasks that need to be performed.

·        You enter estimated durations and start and end dates for some of the key or most visible tasks.

·        You present results to your supervisor for review.

Now my question is what did you present to your boss? A WBS? It does have work tasks listed. A project schedule? It was created in MS Project. A work plan? That’s what your boss asked for. Well, what you probably have here is a high-level WBS and an initial milestone schedule summary, at best. This example illustrates how an inadequate project planning and schedule development process combined with inadequate training on the project scheduling software can lead to “terminology” confusion.  You might be wondering what are the key differences between the WBS and the project schedule?

The key differences between the WBS and the project schedule include the following:

·        Task dependencies—WBS does not show them; a project schedule does.

·        Scheduled tasks—WBS does not show when tasks occur; a project schedule shows start and end dates for each task.

·        Task assignments—WBS does not show who is assigned to an individual task; a project schedule does.

Another question that comes to our mind is why don’t we directly prepare project schedule and skip WBS creation?

The Project Management Institute (PMI) considers the WBS the most important tool of the project manager. Why?

More than any other project management tool, the WBS provides the foundation for defining and organizing the work needed to fulfil the project objectives. Through the WBS, the work to produce the targeted deliverables is structured, assigned, scheduled, tracked, and reported. Through the WBS, the work of the project is effectively represented and communicated to all stakeholders. A well done WBS accomplishes the following objectives for the project manager:

·        Manage the pieces—It provides a mechanism to manage any project size or complexity. Through decomposition, you can manage the pieces (work packages) rather than the whole project.

·        Better work definition, fewer changes—It enables identification of all necessary work for the project and only the necessary work.

·        Better estimates, better planning—It improves the accuracy of cost, duration, and resource estimates.

·        Better control—It defines a baseline for performance measurement and control.

·        Clear responsibilities—It facilitates clear responsibility assignments at both an individual and organizational level.

·        Stakeholder buy-in on scope work effort—It facilitates understanding and buy-in of the project scope, the project approach, the work effort involved, and alignment between scope and work from each stakeholder.

·        Tighter management integration—It provides a mechanism to relate the work directly to schedule, budget, and resource allocation plans.

·        Better team performance—It enables each team member to easily understand how her work fits into the overall project, how it affects the work of other team members, and to stay focused on deliverables.

·        Risk factors identified early—Through decomposition of the work, a more complete and effective risk analysis can be performed during project planning.

·        Confidence increases—When people see that the work of the project is structured, definable, and doable, their confidence level in the project increases.

Here I am ending this post. In the next post we’ll see how to create a WBS.