Schedule management is a cornerstone of good Project Management. How the schedule is developed is just as important as how it is managed. For the past 15+years, I’ve looked and reviewed a number of different schedules: hand-sketched tasks on a piece of paper (yes, one time it was on a napkin) to 30,000+ activities in robust schedule software. Depending on the nature of the project, a hand drawn diagram with a few activities may do the trick. However, more often than none, projects that need scheduling help cannot be achieved via a sketch on a piece of paper. This is where proper schedule develop and management comes in. One of the key differentiators between a good or bad schedule is one that can be used to properly execute a project vs. one that is just a printed for show is how the schedule is developed and structured. The foundation to developing a schedule is the creation of a Work Breakdown Structure (WBS). This is a hierarchical structure that categorizes all the work that need to be completed on the project into the lowest manageable elements. Start with the highest level of work then identify subordinate elements under each level. For a typical project there are 3–5 levels of a WBS. Some may have more. Some organizations may use associate their Level 1 WBS to be the Project Name to distinguish multiple projects from each other (see example below). When the activities are developed, they can then be listed under their respective WBS Code. The difference between an activity and a WBS code is that one is an action vs. a categorization of the work or action. After the hierarchal WBS is defined, a numerical code that is aligned the structure is assigned. For example, all categories in the top level (Level 1) would be given the codes 1.0, 2.0, 3.0, etc. The subordinate level (Level 2) would be 1.1, 1.2 or 2.1, 2.2 or 3.1 etc., similar to an outline structure. Once the WBS is defined, the activities can then be added under the lowest level WBS elements that fits its description. Some of the common mistakes of a WBS are: · WBS is not an organizational structure — work should not be categorized by who reporting structure of who is doing the work. · Not enough granularity — having only one or two levels will not provide enough detail for the work to be broken down; therefore, there may be a risk that activities assigned to the WBS element is not an actual activity but another lower level WBS element. Not enough granularity also makes it hard to track and manage the work and associated activities that need to be done for the project. · Inconsistency between the same WBS level — For example, if WBS 1.0 is Phase 1 and WBS 2.0 is Phase 2, then WBS 3.0 should also be a Phase of a project and nothing else. Inconsistent WBS levels will make for a difficult when analyzing the schedule in the future. · Activities listed as a WBS — All action related items should not be a WBS. They should be a task or activity that is listed under their respective WBS Code. Remember that a well-defined WBS during schedule development will allow for more effective use of the schedule when utilizing to manage various elements of work for the project during execution.
