The Project Coach

Some people think of those 3 letters and hold up the sign of the cross as if to ward off vampires.  For some reason this seems to be one of those areas of project management work that meets with more resistance than most from beginning practitioners.  I’m often asked “Do we really need to go to all the trouble of creating one of those?” There seems to be confusion about what a WBS is and why anyone would need one, and generally speaking a lot of fear about the effort involved to prepare one. 

Work breakdown structures are simply a way of organizing the work activities necessary to implement the project into a numbered outline form.  One of the best advantages that then comes from that is a way to provide traceability from then on throughout your project between requirements, project plans, test cases, issue logs, etc. This helps ensure nothing is lost in the cracks.  Notice I said traceability between requirements and implementation work in the WBS.  That’s an important distinction to make.  I’m a firm advocate that requirements should also be uniquely identified perhaps in a matrix or outline form, but that’s not the WBS, requirements are, well requirements, or the “what” or needs.  The WBS is an outline of the activities that the project team creates to implement those requirements.  It is the “how” or work tasks to deliver on the needs.

There are not many hard fast rules about how to construct a WBS.  Remember basic outline rules from English class in school, and use common sense and good judgment.  Generally speaking at the highest level, of the WBS outline is the object or product that your project was commissioned to produce. At the next level down could be major subcomponents, or phases of the project.  That’s where the judgment comes in.  Think of what constitutes the major chunks of work.  One of the “rules” is that one of the branches should include all the project management work, and another rule is that each branch should be complete; meaning all the subcomponents on a branch should add up to 100% of the work of the branch.  Makes sense, right?    If there is testing or integration work, that should probably be represented as well. 

So now let’s talk about traceability.  To me, this is the real advantage of using a WBS.  It makes you account for every requirement, and conversely it helps prevent scope creep by proving that every bit of work you are doing was justified by a requirement.  Let me say that again – it helps you prevent scope creep!    First, let’s discuss traceability of requirements to business objectives.  As the project scope is progressively elaborated through project charter or project definition phases through the creation of scope statements or statement of work, high level business needs, project objectives and goals will be documented.  Then, as the high level requirements are identified, it is a good idea to tag them with a unique identifier, and associate them with the project objective that they stem from.  That ensures that requirements are aligned to the objectives and business needs.  Then as the work is defined in the WBS to implement the requirements, each of those WBS elements can be tied to one or more requirement IDs.   A single requirement may be totally or partially implemented by multiple WBS elements, and/or a single WBS element may contribute to the implementation of multiple requirements.  Having a traceability matrix reveals where the connections are, which then directly assists in creating functionality test cases.  It helps ensure that no requirement has been overlooked, and that no work is the result of scope creep if it can be tied back to requirements that are themselves tied to the original business needs that justified the project business case.   Given all this incentive I’ve now hopefully instilled for creating work breakdown structures, let’s see if we can eliminate some of the reservations over difficultly.  Consider this example of a business case for a project to implement a software applicant tracking system.

Business Need:  Fill Open Positions with quality candidates in a timelier manner.

    Objective 1:  Reduce the amount of time recruiters spend reading and filtering resumes.

    Objective 2:  Reduce the amount of time recruiters spend corresponding back and forth with candidates collecting information.

    Objective 3:  Improve our ability to file and locate candidate records.

Based on the above high level need and resulting business objectives, the following high level requirements (not a complete list) may be captured and associated with the objectives.  There is obviously still a great deal of detailed requirement elaboration to be done on each one, but the high level requirements are captured below.

The high level WBS for the implementation work might look like something as follows.  (Normally, you would probably define activities to enough levels below the first level as necessary to be able to plan and manage the work):

Applicant Tracking System Implementation

1.0   Requisition Posting Module

1.1   Setup Requisition Filter options

2.0   Resume Capture

2.1   Configure Resume Storage facility

2.2   Setup Filtering Options

3.0   Build Questionnaire

4.0   Setup employment application

5.0   Testing

5.1   Test requisition

5.2   Test resume Capture

5.3   Test Questionnaire

5.4   Test employment application

6.0   Project Management

Once you have both the requirements table above and the WBS, you can then create a traceability matrix that proves you have addressed all the requirements and that you have not taken on any unnecessary work.  You should make each of the lowest items in each branch of the WBS appear in the matrix as well as each Requirement:

So if you’re one of those who have been avoiding this important and beneficial step in project planning, go ahead and give it a try on your next project.  I bet it won’t be nearly as scary as you think, and it just may keep you from forgetting something important.