Project Management

Apply work breakdown structure techniques to organize a program


Most of have you have used a work breakdown structure (WBS) to break large units of work into the smaller activities. These smaller activities end up being used as the basis for your project schedule. This technique is also called "decomposition" - that is, breaking down larger entities into more and more granular components or "breaking big rocks into small rocks."

You can apply this same logic when structuring very large projects. If you have work that's too large to manage as one unique project, you can break the work up into a set of smaller projects. You can then establish a program to coordinate the individual projects so that all of the business objectives and business value is achieved.

You can use this simple model to define the underlying projects within the program.

1. Define the overall scope of the program. This is the first step. You can't define the underlying projects unless you understand the total amount of work required. The program scope defines the totality of work. Anything not in the program scope would not be considered as a part of the program. 2. Break the overall scope into the underlying deliverables. This is where the work breakdown structure technique comes in. In this case we are actually creating a model called the Program Work Breakdown Structure (PWBS). 3. Break down large deliverables into smaller work products. Some deliverables may still be too large to create in one unique project. In this case, you'll need to break the large deliverable into smaller work products. These can also be called sub-deliverables. For instance, a large IT system could be further broken down into databases, web, batch processes and core application logic. 4. Define each deliverable/work product to be a project. At this point you have broken a large piece of work down into a more manageable group of deliverables and work components. The trick now is to define individual projects to create each major deliverable and each work component. 5. Estimate the work required for each project. You should be able to determine, at a high level, the work required to complete each project. This may not be instantly obvious and might require some upfront analysis and research. However, you must have some idea as to the estimated effort, cost, and duration of each project before you can proceed to the next step. This will not be extremely accurate, but hopefully you can get these estimates of effort and cost to around plus or minus 35%-50%. 6. Put the projects in sequence. Now that you have the projects identified and estimated, you can create a high-level project Gantt chart. You can determine which projects need to be executed sequentially and which ones can be executed in parallel. You can also estimate the overall duration of the program by laying out the sequence of the underlying projects. Likewise you can create an overall project budget by adding up the estimated costs for all of the projects.

The days of the mega-project are over. It's better to break down huge initiatives into a group of smaller projects, and then coordinate and manage the multitude of smaller projects under an overall program. The technique above gives you guidance on how to define what these smaller projects look like.

4 comments
wspuck
wspuck

Lots of wisdom in a small space here. The comments add significant insights, too. Thanks. What struck me as implicit in the article and the comments was the interplay between the product (the system to be developed) and the project. Both are systems, and all systems are hierarchical. That's why they can be modeled as tree structures, such as a WBS. A good WBS is product oriented. It should derive from the hierarchical model of the product, which is usually called a Product Breakdown Structure (PBS). The work to develop each PBS element is the core of the WBS. Too often WBSs look like either the organization chart of the team that is to develop the system or the customer's or developer's cost accounting structure. There needs to be a mapping of the WBS to both of these, but not as a means for designing the project. Finally, as both the article and the comments imply, to the PBS core of the WBS there needs to be added the work needed to create the process-oriented deliverables of a project, such as documents, quality processes, testing, and the work to create the PBS (system engineering) and to progressively integrate the pieces as they are deweloped.

cook.sandy
cook.sandy

The one element missing in hour excellent brief is the need for interface control among the sub projects and the work elements in the decomposed project's WBS. It may be old-fashioned - it goes back decades - but the Interface Control Document holds the work to a mutually understood requirement while giving freedom within the subproject and work packages. It should be one fo the first tasks and should be developed when the WBS is developed. Interface control can take the form of an annotated interface diagram, a process description, an IO or HIPO description, or whatever suits the type of project. The factors can be data, interface protocols, processes, etc.; whatever fits. If a basic ICD is not developed at the time of establishing the WBS, and if it is not maintained just as rigorously as the CM docs, error creeps in, and the level of error - the angle of deviation - is not always predictable.

jbjohnson
jbjohnson

I've found that structured analysis (data flow diagramming) can be a powerful technique for creating work breakdown structures. Simply treat the project as a one time process, with inputs and outputs, sources and destinations, etc. Start with the "single bubble" for the entire project, and include all the "sources" (user needs, existing components, etc.) and "destinations" (system operating environments, trainers, etc.) As you perform the process decomposition, a WBS falls out as a sub-process outline, with deliverables (outputs) associated with each sub-process (= project activities and tasks.) One benefit of this approach is that it's very thorough...if you track the flows properly, everything gets accounted for. You in fact have a detailed description of exactly what needs to happen to create the deliverables. Another benefit of this approach is that the cross sub-process flows tell you where the dependencies are, so you can easily sort out parallel and sequential processes. It may appear that this is "the long way around" to get to a WBS and that it would be more straightforward to use a more "experience" and template based outlining approach to the WBS, working directly in the final project-oriented formats. What I've found is that after you learn to use structured analysis diagramming for WBS, it's much more reliable, much faster, and produces a higher quality end product. Structured analysis diagramming can be performed very quickly and agressively, with a lot of confidence, due to its built in consistency checks. It doesn't make assumptions and it doesn't leave anything to chance. Translating the results back to standard project formats is small change compared to the overall work of analysis and design in constructing the raw WBS. Jim Johnson http://www.actionmap.com

jbakaev
jbakaev

like this simple and precise approach, and I would like to add few essential things to be remembered: In step 2 Break the overall scope into the underlying deliverables: apply the 100% rule; the WBS should contain all the work packages needed to execute the project, if it is not in the WBS it is not in the project In step 5 Estimate the work required for each project: add some management reserve to your estimation to cover the risks of unknown unknowns In step 6 Put the projects in sequence: look for hidden dependencies that may jeopardize your planning if they stay undiscovered