How do I test the work breakdown structure?

From the systems engineering and systems management way of thinking, we can say that each task in the WBS is a process that converts inputs to outputs. In the WBS we have identified the tasks that must be completed in order for us to complete the project. Is this really good enough, or can we do a better job?

The answer is "Yes, we can do a better job". By applying a little systems management methodology, we can vastly improve the level of accuracy of our work breakdown structure. The technique here is to look at the inputs and the outputs of each of the processes or tasks in the WBS. Each input for each task must come from somewhere, and each of the outputs generated as a result of doing each task must be needed by some other part of the project. By ensuring that each input is coming from somewhere in the project and each output is needed by some other part of the project, we can raise the accuracy of the WBS considerably.

Tell me more …

Although the WBS is an excellent way to find all of the work that needs to be done to complete the project, we can improve this ability considerably by looking at each of the already identified tasks as a process that converts inputs into outputs.

In order for a task to be accomplished it must have the necessary inputs. This is the same thing as saying that before we can make an aluminum die casting, we have to have the metal, the mold, the design, and the metallurgical specification. When we have all of that, we can process the inputs into outputs, the finished casting (see Figure 2-11).

Figure 2-11: SYSTEMS APPROACH

The problem is much the same in managing project work breakdown structures. Before we can complete a task in the project, we must have certain inputs from other parts of the project or from somewhere or someone outside of the project. Once we have the necessary inputs, we can process them by doing the work of the task and produce outputs that are the results or products of that task. The outputs of the task must be needed by some other part of the project, or they must contribute to the delivery of a deliverable.

Suppose part of the deliverables of a project is the production of an aluminum die cast heat sink for an electronic assembly (see Figure 2-12). Before we can produce the die casting we will need to have a design for the heat sink, a metallurgical specification and a design for the mold that will produce it. Before we can design the casting we will have to know the size and layout of the components that will be mounted on it. We will also have to know the amount of heat that will be generated by each component, the temperature of the environment, and the maximum allowable temperature that each component will be allowed to reach.

Figure 2-12: SYSTEMS APPROACH: DESIGN A HEAT SINK

When we have completed the design task, certain outputs will be produced. Among them might be the dimensions of the heat sink, cooling requirements, maximum allowable temperature, and the aluminum alloy to use, to name a few.

When we use this approach to creating the WBS and testing it, we end up having at least two people look at the definition of each task. One person on the project team is looking at the inputs that are necessary for them to do their work and determining the outputs that will be the products of their work. At the same time another person is doing the same thing for their task. In this case they are trying to find another task manager who is looking for the inputs that they will be producing as outputs and they are looking for another task manager who will supply them with the inputs that they need. One task's output is another task's input. In this way each input and each output is looked at from the creation and the consuming standpoint.

Every input to a task must come from somewhere and every output from a task must go somewhere. Inputs must come from somewhere within the project or must come from somewhere external to the project. All outputs must be the input to some other task in the project or must contribute to the production of a deliverable.

If a task requires an input and the input cannot be found, it may be necessary to create a new task or at least assign this input as the output of one of the project tasks, or even purchase the input from an outside source.

If the output of a task cannot locate another task that requires it as an input or if it does not contribute to the completion of a deliverable, then the question must be asked, "Is this output necessary?" It might be possible to eliminate this work from the project. So, as an additional benefit we have the opportunity to eliminate from the project unnecessary features or work that someone feels should be done but that is not required by the project.