Brainstorming Dependencies and Activities

In "Identifying the Tasks and Activities" we considered identification of the activities and tasks that might be required in a software development project. Particularly, we saw how the 65 activities from 17 software engineering processes explained in IEEE 1074 could be arranged according to a particular life cycle model to form a usable work breakdown structure. We could use those IEEE 1074 activities because the project we wanted to do fit an existing life cycle model closely enough to reuse most of the activities. But what if there is no precedent for the kind of project you are going to do? What if there is no existing life cycle model already defined?

In this case, you must invent the activities through brainstorming with your project team, group them and arrange them into a WBS, and then find all the dependencies using the information presented earlier in this section. To help with the invention of new activities, use the nominal group technique described in the next section. It is simple to use and extremely valuable for collecting balanced input and ideas from those on the project team. Then you can lead the team in finding dependencies amongst the activities as explained below in the "Process for Identifying New Dependencies" section.

Nominal Group Technique

Andre Delbecq and Andrew Van de Ven, based on research funded by the University of Wisconsin and the U.S. Department of Health, Education, and Welfare (HEW), developed the "nominal group technique" in 1968. The technique is an excellent way to get balanced participation in most data gathering efforts. It is good for:

The reason it works is that it allows for every team member to rank items without being pressured by others. This is especially valuable in teams where a few dominant personalities do all the talking, and the majority just follows along quietly. The process is shown in Box 1.

The object of this exercise is to produce a list of activities that the team believes will satisfy the goals of the project, as stated in the project's charter. This is a substitute for not having a WBS template matched to a life cycle already. It is generally good to write each activity on adhesive notepaper (like 3M's Post-its, which we will generally call "stickies" here), and use a large white board or wall space to capture them where everyone can see them all. Typically, only a few rounds are required to get a list of activities that can be used to populate a WBS. Next, we'll see a process for using the activities on stickies to build the WBS.

Process for Identifying New Dependencies

One problem you will notice with the resulting list of activities on stickies from the nominal group technique session is that many of the activities have different granularity. That is, if durations were estimated for them, some would take only an hour or two to do (like "perform software build") but others would take weeks or months (like "design production system"). The solution to this problem is to group the items in a hierarchical fashion (a la WBS) using affinity diagramming. This just means putting all the stickies with activities that have common elements together on one part of the whiteboard, and separate them from the rest. You may have to try various different ideas for commonality. Sometimes rewriting a few activities can help them fit together better. A general rule of thumb is to have detail one level below the level that day-to-day management will take place.

The next step is to arrange the stickies into a product-oriented work breakdown structure using the guidelines discussed in "Creating the Work Breakdown Structure". Arrange them into logical groupings from highest-level activities to lowest. When you get this settled down into a good representation that the team agrees on, capture it on paper (but leave the stickies up there). You will have a useful WBS from which to derive dependencies.

Next you can find the dependencies between all the activities by carefully considering each activity and rearranging the stickies on the whiteboard using the information supplied in this section. It is best to start with the deliverable in mind, at the end of the project. Ask the question, "What is the last thing that the project does?" Put that on the whiteboard as the final item that closes the project. Then successively work backward from the last item asking the question, "What will have to be done in order to accomplish ...?" This should keep you from adding activities that don't directly relate to producing the deliverable, keeping "gold plating" to a minimum.

Using erasable markers (because you are likely to change them several times), draw lines connecting the stickies according to the dependency types discussed earlier. Work through the whole project like this, establishing dependencies appropriate for the task. Be sure that you don't end up with any "dangles" as illustrated in Figure 1, which would indicate a string of activities that don't produce anything. The resulting dependency map is almost a complete network diagram, as shown in the bottom part of "Scheduling Fundamentals" Figure 5. We'll look more closely at network diagramming in "Scheduling the Work".

To sum up the process, follow the steps below:

1. Brainstorm an activity list - Use the nominal group technique to build a list of possible activities for the project on stickies.2. Find affinity collections - Logically "group" activities by identifying the work that must or will be performed together. The level of detail and number of high-level items will be governed by the nature of the project. Disregard duration and resources at this point.3. Find highest WBS levels - Summarize the groupings by work product output to derive the higher levels of the WBS.4. Capture WBS representation - Copy all the WBS information to paper. It becomes part of the project plan.5. Find dependencies - Working from the end to the beginning, logically arrange stickies on the whiteboard. Using markers, draw the dependency relationships between activities, being careful to look for all interdependencies.

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.