|
WORK BREAKDOWN STRUCTURE
BROAD CONTENTS
Preparation Guides for Work Breakdown Structure (WBS)
Checklists for Preparing Work Breakdown Structure (WBS)
Methods for Structuring Work Breakdown Structure (WBS)
Why Do Plans Fail?
23.1 Preparation Guides for Work Breakdown Structure (WBS):
We have already discussed the preparation guides for the
Statement of Work (SOW). Similarly
there are several preparation guides for the Work Breakdown
Structure (WBS). These are as
follows:
• Firstly,
develop the Work Breakdown Structure (WBS) structure by subdividing the total
effort into discrete and logical sub elements. Usually a program
subdivides into projects,
major systems, major subsystems, and various lower levels until
a manageable -size
element level is reached. Wide variations may occur, depending
upon the type of effort
(e.g., major systems development, support services, etc.).
Include more than one cost center
and more than one contractor if this reflects the actual
situation.
• It is important
to check the proposed Work Breakdown Structure (WBS) and the
contemplated efforts for completeness, compatibility, and
continuity.
• Determine that
the Work Breakdown Structure (WBS) satisfies both functional
(engineering/ manufacturing/ test) and program/project
(hardware, services, etc.)
requirements, including recurring and nonrecurring costs.
• Remember to
check to determine if the Work Breakdown Structure (WBS) provides for
logical subdivision of all project work.
• Establish
assignment of responsibilities for all identified effort to specific
organizations.
• Finally, check
the proposed Work Breakdown Structure (WBS) against the reporting
requirements of the organizations involved.
23.2 Checklists for Preparing Work Breakdown Structure (WBS):
In addition to the preparation guides, there are also checklists
that can be used in the preparation
of the Work Breakdown Structure (WBS):
• Focus to
develop a preliminary Work Breakdown Structure (WBS) to not lower than the top
three levels for solicitation purposes (or lower if deemed
necessary for some special
reason).
• Remember to
assure that the contractor is required to extend the preliminary Work
Breakdown Structure (WBS) in response to the solicitation, to
identify and structure all
contractor work to be compatible with his organization and
management system.
• Following
negotiations, the Contract Work Breakdown Structure (CWBS) included in the
contract should not normally extend lower than the third level.
• It is essential
to assure that the negotiated Contract Work Breakdown Structure (CWBS)
structure is compatible with reporting requirements.
• Assure that the
negotiated Contract Work Breakdown Structure (CWBS) is compatible with
the contractor's organization and management system.
160
• Review the
Contract Work Breakdown Structure (CWBS) elements to ensure correlation
with the following:
- The
specification tree
- Contract line
items
- End-items of
the contract
- Data items
required
- Work statement
tasks
- Configuration
management requirements
• Also, define
Contract Work Breakdown Structure (CWBS) elements down to the level
where such definitions are meaningful and necessary for
management purposes (WBS
dictionary).
• Clearly specify
reporting requirements for selected Contract Work Breakdown Structure
(CWBS) elements if variations from standard reporting
requirements are desired.
• Always assure
that the Contract Work Breakdown Structure (CWBS) covers measurable
effort, level of effort, apportioned effort, and subcontracts,
if applicable.
• Lastly, Assure
that the total costs at a particular level will equal the sum of the costs of
the
constituent elements at the next lower level.
In case of simple projects, the Work Breakdown Structure (WBS)
can be constructed as a "tree
diagram" or according to the logic flow. The tree diagram can
follow the work or even the
organizational structure of the company (i.e., division,
department, section, unit). The second
method is to create a logic flow and cluster certain elements to
represent tasks and projects. In
the tree method, lower-level functional units may be assigned to
one, and only one.
Work Breakdown Structure (WBS) Elements
23.3 Methods for Structuring Work Breakdown Structure (WBS):
It is seen that a tendency exists today to develop guidelines,
policies, and procedures for project
management, but not for the development of the Work Breakdown
Structure (WBS). Since it
must have flexibility built into it, the tendency is to avoid
limiting the way the Work
Breakdown Structure (WBS) must be developed. Some companies have
been marginally
successful in developing a "generic" methodology for levels 1,
2, and 3 of the Work Breakdown
Structure (WBS). In other words, the top three levels of the
Work Breakdown Structure (WBS)
are the same for all projects. The differences appear in levels
4, 5, and 6.
The following table 23.1 shows the three most common methods for
structuring the Work
Breakdown Structure (WBS):
Three Common Methods for Structuring the WBS
As the table shows, the flow method breaks the work down into
systems and major subsystems.
This method is well suited for projects less than two years in
length. For longer-duration
projects, we use the life-cycle method, which is similar to the
flow method. The organization
method is used for projects that may be repetitive or require
very little integration between
functional units.
23.4 Why Do Plans Fail?
Planning is not perfect, no matter how hard we try, and
sometimes plans fail. Typical reasons
why plans fail include:
- Corporate goals
are not understood at the lower organizational levels.
- Plans encompass
too much in too little time.
- Financial
estimates are poor.
- Plans are based
on insufficient data.
- No attempt is
made to systematize the planning process.
- Planning is
performed by a planning group.
- No one knows
the ultimate objective.
- No one knows
the staffing requirements.
- No one knows
the major milestone dates, including written reports.
- Project
estimates are best guesses, and are not based on standards or history.
- Not enough time
is given for proper estimating.
- No one bothers
to see if there would be personnel available with the necessary skills.
- People are not
working toward the same specifications.
- People are
consistently shuffled in and out of the project with little regard for schedule.
Now the question arises, why do these situations occur, and who
should be blamed? If corporate
goals are not understood, it is because corporate executives are
negligent in providing the
necessary strategic information and feedback. If a plan fails
because of extreme optimism, then
the responsibility lies with both the project and line managers
for not assessing risk. Project
managers should ask the line managers if the estimates are
optimistic or pessimistic, and expect
an honest answer. Erroneous financial estimates are the
responsibility of the line manager. If the
project fails because of a poor definition of the requirements,
then the project manager is totally
at fault.
It is important that the project managers must be willing to
accept failure. Sometimes, a
situation occurs that can lead to failure, and the problem rests
with either upper-level
management or some other group. As an example, consider the
major utility company with a
planning group that prepares budgets (with the help of
functional groups) and selects projects to
be completed within a given time period. A project manager on
one such project discovered that
the project should have started ''last month" in order to meet
the completion date. In cases like
this, project managers will not become dedicated to the projects
unless they are active members
during the planning and know what assumptions and constraints
were considered in
development of the plan.
In some cases, sometimes, the project manager is part of the
planning group and as part of
feasibility study is asked to prepare, with the assistance of
functional managers, a schedule and
cost summary for a project that will occur three years
downstream, if it is approved at all.
Suppose that three years downstream the project is approved. How
does the project manager get
functional managers to accept the schedule and cost summary that
they themselves prepared
three years before? It cannot be done, because technology may
have changed, people may be
working higher or lower on the learning curve, and salary and
raw material escalation factors
are inaccurate.
Small mistake accumulate to cause big damage. Sometimes project
plans fail because simple
details are forgotten or overlooked. Examples of this might be:
• Neglecting to
tell a line manager early enough that the prototype is not ready and that
rescheduling is necessary.
• Neglecting to
see if the line manager can still provide additional employees for the next two
weeks because it was possible to do so six months ago.
In addition to this, sometimes plans fail because the project
manager "bites off more than he can
chew," and then something happens, such as his becoming ill.
Even if the project manager is
effective at doing a lot of the work, overburdening is
unnecessary. Many projects have failed
because the project manager was the only one who knew what was
going on and then got sick. |