I talked earlier about a Work Breakdown Structure (WBS), but this is such an important subject it is valuable to revisit.
The WBS should accomplish several things:
It is the mechanism that takes the project's requirements and turns them into manageable project tasks
It is used to communicate project objectives to the project team and other stakeholders
Its output is used to build your first plan and schedule
In David I. Cleland's Book "Project Management: Strategic Design and Implementation. Second Edition" he states that:
In general the development of the WBS provides the means for:
Summarizing all the deliverables , resources, and activities of a project
Relating work elements to each other and to the total project
Building the matrix organization for the project by cross referencing the work elements to the organizational resources responsible for their completion
Addressing all contracted resources required for the project.
Estimating costs, simulating project scenarios, and conducting risk analysis
Providing information to define, budget, schedule, perform, and control work packages
Definition: "Work Package" - A deliverable at the lowest level of the Work Breakdown Structure.
Keep in mind a complex WBS isn't' required for most small and medium sized projects. Many times a simple deliverable-oriented tree of activities that graphically displays the work to be done will suffice. By that I mean a structure similar to an organization chart with the project name on the top row and the second row consisting of some elements of your project methodology.
For example, for an IT project the second row headings might be:
Analysis
Requirements
Design/Procurement
Coding/Installation
Test/Acceptance
Close-out.
The best way to get started with creating a WBS is to gather the team (always done with the team) and write down the project tasks on Post-It Notes. Then, use an available wall to post the tasks in the appropriate places under the headings of your WBS's second row.
