Project Management. Dr Jae K. Shim

Чтение книги онлайн.

Читать онлайн книгу Project Management - Dr Jae K. Shim страница 10

Project Management - Dr Jae K. Shim

Скачать книгу

a quality manner, on time, and within budget provides a great feeling of satisfaction. For a contractor, it could lead to additional business from the same customer in the future or to business from new customers referred by previously satisfied customers.

       CHAPTER 4Using the Work Breakdown Structure to Plan a Project

      Planning answers the questions “What must be done?,” “How long will it take?,” and “How much will it cost?” Planning the “What” is vital; projects frequently fail because a significant part of the work is forgotten. In addition, once tasks have been identified, the time and resource requirements must be determined. This is called estimating.

      A major problem in project planning is determining how long tasks will take and what it will cost to do them. Inaccurate estimates are a leading cause of project failures, and missed cost targets are a common cause of stress and recrimination in project management.

      The most useful tool for accomplishing all of these tasks is the Work Breakdown Structure (WBS). The idea behind the WBS is simple: you can subdivide a complicated task into smaller tasks, until you reach a level that cannot be further subdivided. Decomposition is used in developing the WBS. A that point, it is usually easier to estimate how long the small task will take and how much it will cost to perform than it would have been to estimate these factors at higher levels.

      Nevertheless, it is still no easy feat to estimate task durations for activities that have never been performed before. Because this is the typical situation in engineering hardware and software development projects, we might expect many of these estimates to be in error, and this seems to be demonstrated by experience. Still, the Work Breakdown Structure makes it easier to estimate knowledge tasks than any other tool we have.

       A Simple Example

      As an example, if I want to clean a room (see Exhibit 7), I might begin by picking up clothes, toys, and other things that have been dropped on the floor. I could use a vacuum cleaner to get dirt out of the carpet. I might wash the windows and wipe down the walls, then dust the furniture. All of these activities are subtasks performed to clean the room.

      As for vacuuming the room, you might have to get the vacuum cleaner out of the closet, connect the hose, plug it in, push the vacuum cleaner around the room, empty the bag, and put the machine back in the closet. These are still smaller tasks to be performed in accomplishing the subtask called vacuuming. The diagram in Exhibit 7 shows how this might be portrayed in WBS format.

image

      Note that we do not worry about the sequence in which work is performed when we do a WBS. That will be worked out when we develop a schedule. However, you will probably find yourself thinking sequentially, as it seems to be human nature to do so. The main idea of doing a WBS is to capture all of the tasks. So if you mind yourself and other members of your team thinking sequentially, don’t be too concerned, but don’t get hung up on trying to diagram the sequence or you will slow down the process of task identification.

      The typical WBS has three to six levels, and these can be labeled as shown in Exhibit 8. It is, of course, possible to have projects that require a lot more levels. Twenty levels is considered to be the upper limit, and that is a huge project. Note that level 1 is called the program level. The difference between a program and a project is just one of degree.

image

      An example of a program is the development of an airplane. For example, the WBS for Boeing’s 787 airplane program might have been drawn as shown in Exhibit 9. Notice that the engine, wing, and avionics are large enough jobs to be called projects in their own right. In fact, the program manager’s job is to make sure that the projects are all properly integrated. The engine mounts on the wing, so, somewhere in the structure to develop the engine, there will be an activity called “Design wing mounts.” And for the wing, there will be an activity called “Design engine mounts.” If these are not coordinated properly, you will wind up with an engine that won’t mount on the wing. The job of coordinating these is called system integration.

image

       Guidelines for Developing the WBS

      One important question in constructing a WBS is “When do you stop breaking down the work?” The general guideline is that you stop when you reach a point where either you can estimate time and cost to the desired degree of accuracy or the work will take an amount of time equal to the smallest units you want to schedule. If, for instance, you want to schedule to the nearest day, you break down the work to the point where tasks take about a day to perform. If you are going to schedule to the nearest hour, then you stop when task durations are in that range.

      Remember the rule that the people who must do the work should participate in planning it? That applies here. Usually a core group identifies top-level parts of the WBS; those parts are further refined by other members of the team and then integrated to obtain the entire WBS.

      One important point: the WBS should be developed before the schedule. In fact, the WBS is the device that ties the entire project together. It allows resources to be assigned and estimates of time and cost to be made and shows the scope of the job in graphic form. Later, as the project is tracked, the work can be identified as falling in a particular box in the WBS.

      There are many software packages that print a WBS after schedule data have been entered. That is a nice feature, since it gives a graphically attractive WBS. It is important that the rough drawing be made prior to input in the scheduling software, though. The reason is quite simple: until everyone has agreed that all tasks have been identified, it is misleading to develop a schedule. You cannot be sure that the critical path identified by a partial schedule will be the same for the full schedule.

      There are a number of approaches to developing the WBS. Ideally, you proceed top-down, following development of a good problem statement and mission statement. As previously mentioned, however, the mind does not always operate in such nice, linear fashion. As you develop the WBS, you may sometimes find that it helps to understand the job better. For that reason, about it is not necessary to be so strict about doing things in a specific order. You do what works best for you.

      The WBS does not have to be symmetrical. That is, all paths need not be broken down to level 6 (or whatever level you stop at). Since the rule is to break work down to a level sufficient to achieve the estimating accuracy you desire, one path may take six levels, while another may need only three.

       Uses of the WBS

      The WBS is a good way to show the scope of a job. If you have ever given someone an estimate for project cost or time and seen the person’s horrified look, you know that they are seeing the project in their mind as much simpler than it is. When you show a project in WBS for, it is

Скачать книгу