CATEGORII DOCUMENTE |
Bulgara | Ceha slovaca | Croata | Engleza | Estona | Finlandeza | Franceza |
Germana | Italiana | Letona | Lituaniana | Maghiara | Olandeza | Poloneza |
Sarba | Slovena | Spaniola | Suedeza | Turca | Ucraineana |
The Work Breakdown Structure
Perry now has the visibility he needs and the details for building the project. Now he will use the SOW to develop a work breakdown structure, or WBS. The WBS is a detailed listing of the deliverables and tasks for building the product or delivering the service. It is a top-down, broad-to-specific hierarchical outcome of the work to perform.
There are several benefits to developing a WBS.
The WBS forces the project manager, team members, and customers to delineate the steps required to build and deliver the product or service. The exercise alone encourages a dialogue that will help clarify ambiguities, bring out assumptions, narrow the scope of the project, and raise critical issues early on.
It lays the groundwork for developing an effective schedule and good budget plans. A well-defined WBS enables resources to be allocated to specific tasks, helps in generating a meaningful schedule, and makes calculating a reliable budget easier.
The level of detail in a WBS makes it easier to hold people accountable for completing their tasks. With a defined WBS, people cannot hide under the cover of broadness. A well-defined task can be assigned to a specific individual, who is then responsible for its completion.
The process of developing and completing a WBS breeds excitement and commitment. Although Perry will develop the high-level WBS, he will seek the participation of his core team to flesh out the WBS. This participation will spark involvement in the project.
Of course, developing a WBS is not easy. For one, it takes timeand plenty of it. A large WBS (one that identifies several thousand activities) can take several weeks to develop. For another, it requires effort. There is a knowledge transfer and exercise of brain power. The larger the scope of the project, the larger the WBS will be. More people must provide input and then approve the portion they are responsible to perform. Finally, the WBS requires continual refinement. The first iteration is rarely right and as the project changes, so does the WBS. Still, the advantages outweigh the challenges. A good WBS makes planning and executing a project easier.
Where WBSs Go Wrong More often than not, a simple WBS can improve the overall performance of a project. Sometimes, however, a WBS can do more harm than good. The reasons some WBSs fail are as follows: The WBS does not have sufficient detail. If it is kept to too high a level, estimating, and tracking the schedule and cost performance become guesstimation. Composite or roll-up views lack meaning because the lower-level content is missing or too general to be reliable. The WBS is the result of one individual and does not include those who will work on the tasks. When the WBS is published, few team members have a sense of ownership or commitment to the contents. The WBS does not cover the whole project. It contains only the activities needed to build the project. It might omit other important activities, such as project administration and training. The result is that subsequent delivery of the product or service is unsatisfactory. The entire WBS is not used in subsequent planning. The project manager takes an eclectic view of the WBS, using only selected portions. The result is incomplete planning, lacking a comprehensive view of the work to be done. There is a failure to put the WBS under configuration management. Once everyone agrees on its contents, the WBS should not become frozen or baselined, with all future changes not identified or evaluated for their impact on the project. Failure to manage changes to the WBS can result in unanticipated impacts on the scope, schedule, or cost. |
As Perry progresses down each leg of the WBS, he gets to a level of detail that provides the ability to track and monitor progress, make assignments that build accountability, and reliably estimate the hours to perform tasks. How detailed the WBS gets depends on the level of control the project manager wants. Generally, the more specific the WBS, the more accurate the planning and the greater the ability to monitor progress. A common heuristic Perry uses is the 80-hour rule: each of the lowest-level items in the WBS should not exceed 80 hours effort. If the job requires more, then he breaks down the task into smaller tasks. Perry recognizes that he will have to continually refine the WBS as he estimates the time to complete tasks.
To begin developing a WBS, Perry identifies all the requirements for the wedding. First he reviews the SOW, which provides a guideline since it is representative of a high level and contains all the necessary information. Other sources of information for building the WBS are documentation, including the WBS, of related projects; interview notes; legal documentation; and memorandums.
With this information, Perry decides on how to approach the WBS. There are many ways to draw up a WBSfor example, by responsibility (see Exhibit 6-1); by phase; or by deliverables. He decides on deliverables for this WBS since that worked best for him in the past. It is also easier to determine progress at a higher level when reporting to senior management or the customer.
Exhibit
6-1. Work breakdown structure based on responsibility.
The WBS generally consists of two components. The first component is the product breakdown structure (PBS), which delineates the segments that constitute the final product or service. It may also contain items deemed important (e.g., training). Each item in the PBS is described with a noun and a unique number.
The other component is the task breakdown structure (TBS), which contains the tasks to build or deliver something (see Exhibit 6-2). It may also list tasks deemed important to the project. Each task in the TBS is described with an action verb, a noun, and a unique number.
The lowest level in the WBS is the work package level. These are the tasks or subtasks he will use to assign responsibilities, construct schedules, and track progress. Consider the WBS as a giant topical outline. Each level lower is a breakdown of a higher level. The items in the lower level constitute the one in the next higher level. Sometimes the higher levels of a WBS are managerial levels; the details are rolled up to the managerial level for reporting purposes. Lower levels are called technical levels.
Exhibit
6-2. Task breakdown structure (TBS).
On very large projects, each task in the work package has an accompanying description, contained in a WBS dictionary. Each entry in the dictionary describes the expected output of the task. Thus, a WBS dictionary can help the project manager determine whether a task has been completed.
Perrys WBS for the Smythe wedding is shown in the Appendix. He used a word processing program to produce it. But he can also display the WBS graphically, as a tree diagram, by using graphics software. Another way is to post sticky notes on a wall to display the hierarchical relationship. Either way, the display will look like Exhibit 6-3.
With his draft of the WBS ready, Perry is now able to solicit input from the key players. He presents it to the steering committee and obtains their acceptance. Next, he identifies the key skills needed to perform the tasks and obtains additional input from team members. The PBS gives him an idea of the following needed expertise:
Attendants
Cosmetologist
Drivers
Florist
Hair stylist
Exhibit
6-3. Graphic display of task breakdown
structure.
Jewelers
Lawyer
Musicians
Photographer
Planners
Public relations expert
Receptionists
Tailor
Travel agents
Ushers
Valet
Videographer
Waiters
Wedding consultants
At the moment, Perry has no idea how many people with the requisite expertise are necessary. But he will require at least one of each on the core team (the key participants).
To acquire core team members, Perry needs once again to present his case to the steering committee, and upon receiving its approval, to contact the relevant functional organizations. Perry now has his core team, as shown in Exhibit 6-4. Perry then solicits input from these core team members regarding the WBS and gets ready to take on the next step in planning: estimating the time to complete each task.
The work breakdown structure, although time-consuming to prepare, is an excellent foundation for the remaining project planning functions. Next we consider the work-time estimates; which aid in the preparation of schedules and costs.
Questions for Getting Started
What are the deliverables for your project? Did you display them in the product breakdown structure (PBS) of the WBS?
Exhibit 6-4. Core team members.
Attendant, Pat Jones |
Public relations expert, Eva Brewster |
Cosmetologist, Cynthia Fralusinski |
Receptionist, Wonda Wrangell |
Driver, Terry Karla |
Tailor, Frank Galucci |
Florist, David Rockford |
Travel agent, Larry Eisenberg |
Jeweler, Henry Winkless |
Usher, Michael Cramer |
Lawyer, Robin Schister |
Valet, Danny Smith |
Musician, Vy Toon |
Videographer, Raymond Leazowitz |
Photographer, Gina |
Davies Waiter, Ted Rogers |
Planner, Hank Wilson |
Wedding consultant, Mary Ewing |
What are the tasks for your project? Did you display them in the task breakdown structure (TBS) of the WBS?
Did you receive input from all relevant parties when building the WBS?
Did you perform the following when building the WBS:
Explode each leg down to the lowest level of detail (e.g., using the 80-hour rule)?
Give each item a unique number?
Give each item in the PBS a name consisting of an adjective and a noun?
Give each item in the TBS a name consisting of an action verb and an object?
Did you put the WBS under configuration control in the event that an item is added, removed, or modified?
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 3218
Importanta:
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved