|
|||||
Project
Management MGMT627
VU
LESSON
23
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.
159
Project
Management MGMT627
VU
·
Review
the Contract Work Breakdown Structure
(CWBS) elements to ensure
correlation
with
the following:
The
specification tree
o
Contract
line items
o
End-items
of the contract
o
Data
items required
o
Work
statement tasks
o
Configuration
management requirements
o
·
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.
Figure
23.1: 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
160
Project
Management MGMT627
VU
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):
Table
23.1: 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
161
Project
Management MGMT627
VU
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.
162
Table of Contents:
|
|||||