Chapter Four_ Students

Esra Aleisa
The work of the project can be successively
subdivided into smaller and smaller work
elements.
The outcome of this hierarchical process is
called the work breakdown structure
(WBS).
 The five generic steps described herein provide a
structured approach for collecting the project
information necessary for developing a work breakdown
structure.

1. Defining the project Scope

2. Establishing Project Priorities
3. Creating the Work Breakdown
4. Integrating the WBS with the Organization
5. Coding the WBS for the Information System
Defining the project scope sets the stage for developing a
project plan.
Project scope is a definition of the end result or mission of
your project—a product or service for your client/customer.
The primary purpose is to define as clearly as possible the
deliverable(s) for the end user and to focus project plans.
As fundamental and essential as scope definition appears, it is
frequently overlooked by project leaders of well-managed,
large corporations.
project participants.
Research clearly shows that a poorly defined scope or mission is the
most frequently mentioned barrier to project success.

In a study involving more than 1,400 project managers in the United

States and Canada, Gobeli and Larson found that approximately 50%
of the planning problems relate to unclear definition of scope and
goals.
This and other studies suggest a strong correlation between project
success and clear scope definition.
The scope document directs focus on the project purpose throughout
the life of the project for the customer and project participants.
The scope should be developed under the direction of
the project manager and customer.

Your project scope definition is a document that will be

published and used by the project owner and project
participants for planning and measuring project success.

Scope describes what you expect to deliver to your

customer when the project is complete.

Your project scope should define the results to be

achieved in specific, tangible, and measurable terms.
1. Project objective
2. Deliverables
3. Milestones
4. Technical requirements
5. Limits and exclusions
6. Reviews with customer
 The first step of project scope definition is to define the overall
objective to meet your customer's needs.

For example, as a result of extensive market research a computer

software company decides to develop a program that automatically
translates verbal sentences in English to Russian.
The project should be completed within three years at a cost not to
exceed $1.5 million.

Another example is to design and produce a completely portable,

hazardous waste, thermal treatment system in 13 months at a cost
not to exceed $13 million.

The project objective answers the

questions of what, when, and how
much.

Scope > Scope Check list > Objectives

 The next step is to define major deliverables—the expected
outputs over the life of the project.

For example, deliverables in the early design phase of a

project might be a list of specifications.

In the second phase deliverables could be software coding

and a technical manual.

The next phase could be to test prototypes.

The final phase could be final tests and approved software.

The output

Scope > Scope Check list > Deliverables

A milestone is a :: in a
project that occurs at a point in time.
The milestone schedule shows only major segments of work; it repre-
sents first, rough-cut estimates of time, cost, and resources for the
project.

The milestone schedule is built using the deliverables as a platform to

identify major segments of work and an end date

for example, testing complete and finished by July 1 of the same year
• Milestones should be natural, important control points in the
project.
• Milestones should be easy for all project participants to
recognize.

Scope > Scope Check list > Milestones

 More frequently than not, a product or service will have technical
requirements to ensure proper performance.

For example, a technical requirement for a personal computer might

be the ability to accept 120-volt alternating current or 240-volt direct
current without any adapters or user switches.

Another well-known example is the ability of 911 emergency systems

to identify the caller's phone number and location of the phone.

Examples from information systems projects include speed and

capacity of database systems and connectivity with alternative
systems.

Technical Specifications

Scope > Scope Check list > Technical requirements

 Failure to define the limits of the scope leads to false expectations and
to expending resources and time on the wrong problem.

Examples of limits are:

local air transportation to and from base camps will be outsourced;
system maintenance and repair will be done only up to one month after
final inspection;
client will be billed for additional training beyond that prescribed in the
contract.
Exclusions further define the boundary of the project by stating what
is not included.
Examples include: data will be collected by the client, not the
contractor; a house will be built, but no landscaping or security
devices added; software will be installed, but no training given.

Expectations and Exclusions define

::
Scope > Scope Check list > Limits and exclusions
 Completion of the scope checklist ends with a review with
your customer—internal or external.

The main concern here is the understanding and agreement

of expectations.

Is the customer getting what he or she desires in deliverables?

Does the project definition identify key accomplishments,
budgets, timing, and performance requirements?
Are questions of limits and exclusions covered?

Clear communication in all these issues is imperative to avoid

claims or misunderstanding.

Survey

Scope > Scope Check list > Reviews with Customer

Many companies engaged in contracted work refer to
scope statements as ::
Other organizations use the term :: .
However, the term project charter has emerged to have
a special meaning in the world of project management.
 A project charter refers to a document that authorizes
the project manager to initiate and lead the project.

This document is issued by upper management and

provides the project manager with written authority to
use organizational resources for project activities.

Often the charter will include a brief scope description as

well as such items as risk limits, customer needs, spend-
ing limits, and even team composition.

A project is ready to go

Scope Statement vs. Project Charter

Many projects suffer from scope creep, which is the tendency for the project
scope to expand over time--usually by changing requirements, specifications,
and priorities.

Scope creep can be reduced by carefully writing your scope statement.

A scope statement that is too broad is an invitation for scope creep.

Scope creep can have a positive or negative effect on the project, but in most
cases scope creep means added costs and possible project delays.

Changes in requirements, specifications, and priorities frequently result in

cost overruns and delays.
Example: On software development projects, scope creep is manifested in
bloated products in which added functionality undermines ease of use.
 If the project scope needs to change,
it is critical to have a sound ::

in place that records the change

and keeps a :: of all project changes.

The log identifies the change,

impact, and those responsible for
accepting or rejecting a proposed
change.

Project managers in the field

constantly suggest that dealing with
changing requirements is one of their
most perplexing problems.
 The five generic steps described herein provide a
structured approach for collecting the project
information necessary for developing a work breakdown
structure.

1. Defining the project Scope

2. Establishing Project Priorities
3. Creating the Work Breakdown
4. Integrating the WBS with the Organization
5. Coding the WBS for the Information System
 Quality and the ultimate success of a project are traditionally
defined as meeting and/or exceeding the expectations of the
customer and/or upper management in terms of cost (budget).
time (schedule), and performance (scope) of the project.

The interrelationship among these criteria varies. For example,

sometimes it is necessary to compromise the performance and
scope of the project to get the project done quickly or less
expensively.

Often the longer a project takes, the more expensive it

becomes. However, a positive correlation between cost and
schedule may not always be true.

Other times project costs can be reduced by using cheaper. less

efficient labor or equipment that extends the duration of the
project.

Likewise project managers are often forced to expedite or

"crash" certain key activities by adding additional labor,
thereby raising the original cost of the project.

Priorities
 One technique found in practice that is useful for this purpose is completing
a priority matrix for the project to identify which criterion is constrained,
which should be enhanced, and which can be accepted:

Constrain. The original parameter is fixed.

The project must meet the completion date, specifications and scope of the
project, or budget.

Enhance. Given the scope of the project, which criterion should

be optimized?
In the case of time and cost, this usually means taking advantage of
opportunities to either reduce costs or shorten the schedule. Conversely, with
regard to performance, enhancing means adding value to the project.

Accept. For which criterion is it tolerable not to meet the original

parameters? When trade-offs have to be made, is it permissible for the
schedule to slip, to reduce the scope and performance of the project, or to
go over budget?

Priorities > The priority matrix

The priority matrix here is for the development of a new
wireless modem.
Because time to market is important to sales, the project
manager is instructed to take advantage of every opportunity to
reduce completion time.
In doing so, going over budget is acceptable though not
desirable. At the same time, the original performance
specifications for the modem as well as reliability standards
cannot be compromised.
 The five generic steps described herein provide a
structured approach for collecting the project
information necessary for developing a work breakdown
structure.

1. Defining the project Scope

2. Establishing Project Priorities
3. Creating the Work Breakdown
4. Integrating the WBS with the Organization
5. Coding the WBS for the Information System
Once the scope and deliverables have been identified, the work of the
project can be successively subdivided into smaller and smaller work
elements.

The outcome of this hierarchical process is called the work

breakdown structure (WBS).
Use of WBS helps to assure project managers that all products and work
elements are identified, to integrate the project with the current
organization, and to establish a basis for control.

Basically, the WBS is an outline of the project with different levels of detail.

The WBS begins with the project as the final deliverable.

The figure shows the
major groupings
commonly used in the
field to develop a
hierarchical WBS.

The WBS begins with the

project as the final
deliverable.

This breakdown groups

work packages by type of
work within a deliverables
and allows assignment of
responsibility to an
organizational unit.
 Each item in the WBS needs a time and cost estimate.

With this information it is possible to plan.

As the WBS is developed, organizational units and individuals are assigned

responsibility for executing work packages, This integrates the work and the
organization.

Use of the WBS provides the opportunity to "roll up" (sum) the budget and
actual costs of the smaller work packages into larger work elements so
that performance can be measured by organizational units and work
accomplishment.

The WBS can also be used to define communication channels and assist in
understanding and coordinating many parts of the project. The structure
shows the work and organizational units responsible and suggests where
written communication should be directed. Problems can be quickly
addressed and coordinated because the structure integrates work and
responsibility.

Creating the Work Breakdown Structure > why?

 The lowest level of the WBS is called a work package.

Each subdeliverable requires work packages that will be completed by an

assigned organizational unit.

It is not necessary to divide all elements of the WBS to the same level.
Each work package of the WBS should be as independent of other packages
of the project as possible.

No work package is described in more than one subdeliverable of the WBS.

Work packages are short duration tasks that have a

definite start and stop point, consume resources,
and represent cost.

Creating the Work Breakdown Structure > work packages

 Each work package is a control point.

A work package manager is responsible for seeing that the package is completed on time,
within budget, and according to technical specifications.

Practice suggests a work package should not exceed 10 workdays or one reporting period.

If a work package has a duration exceeding 10 days, check or monitoring points should be
established within the duration, say, every three to five days, so progress and problems
can be identified before too much time has passed.

Creating the Work Breakdown Structure > work packages

 To review, each work package in the WBS:
1. Defines work (what).
2. Identifies time to complete a work package (how
long).
3. Identifies a time-phased budget to complete a work
package (cost).
4. Identifies resources needed to complete a work
package (how much).
5. Identifies a single person responsible for units of
work (who).
6. Identifies monitoring points for measuring progress
(how well).

Creating the Work Breakdown Structure > work packages review

 Because the lowest subdeliverable usually includes several
work packages, the work packages are grouped by type of
work—for example, hardware, programming, testing.

These groupings within a subdeliverable are called cost ac-

counts.

This grouping facilitates a system for :: project

progress by :: .

Cost accounts are::

Creating the Work Breakdown Structure > Cost accounts

 Creating a WBS from scratch can be a
daunting task.
Project managers should take
advantage of relevant examples from
previous projects to begin the process.
WBS are products of group efforts.
If the project is small, the entire
project team may be involved breaking
down the project into its components.

For large, complex projects, the people responsible for the major
deliverables are likely to meet to establish the first two levels of
deliverables. further detail would be delegated to the people
responsible for the specific work. Collectively this information
would be gathered and integrated into a formal WBS by a project
CresautiipnpgotrhtepWWersoorkn.Breakdown Structure > work packages
review
 The five generic steps described herein provide a
structured approach for collecting the project
information necessary for developing a work breakdown
structure.

1. Defining the project Scope

2. Establishing Project Priorities
3. Creating the Work Breakdown
4. Integrating the WBS with the Organization
5. Coding the WBS for the Information System
 The WBS is used to link the organizational units responsible for
performing the work. In practice, the outcome of this process is
the :: breakdown structure (:: ).

The purposes of the OBS is to identify organization units

responsible for work packages, and tie the organizational unit
to cost control accounts.

Integrating the WBS with the Organization

 As in the WBS, the OBS assigns the lowest
organizational unit the responsibility for
work packages within a cost account.

Herein lies one major strength of using

WBS and OBS; they can be integrated.

The intersection of work packages and the

organizational unit creates a project
control point (:: ) that
integrates work and responsibility.
Integrating the WBS with the Organization
 The five generic steps described herein provide a
structured approach for collecting the project
information necessary for developing a work breakdown
structure.

1. Defining the project Scope

2. Establishing Project Priorities
3. Creating the Work Breakdown
4. Integrating the WBS with the Organization
5. Coding the WBS for the Information System
 The codes are used to
define levels and
elements in the WBS,
organization elements,
work packages, and
budget and cost
information.

The codes allow reports

to be consolidated at any
level in the structure.

Coding the WBS for the Information System

 An example
for the new
computer
project and
the "Disk
storage
units" is
shown here.

Coding the WBS for the Information System

The coding system can be extended to cover large projects.

Additional schemes can be added for special reports. For

example, adding a "-3" after the code could indicate a site
location, an elevation, or a special account such as labor.

Some letters can be used as special identifiers such as "M"

for materials or "E" for engineers You are not limited to
only 10 subdivisions (0-9); you can extend each subdivision
to large numbers—for example, .1-.99 or .1- .9999.
The following example is from a large, complex project:
3R -237A --- P2-33.6
where 3R identifies the facility, 237A represents elevation
and the area, P2 represents pipe two inches wide, and 33.6
represents the work package number.
 In many cases, the size and scope of the project do not warrant
an elaborate WBS or OBS.
One tool that is widely used by project managers and task force
leaders of small projects is the :: .

When projects are not that big

Research shows that over 80% of interpersonal problems are
due to miscommunication
What information needs to be collected and when?
Who will receive the information?
What methods will be used to gather and store
information?
What are the limits, if any, on who has access to
certain kinds of information?
When will the information be communicated?
How will it be communicated?
1. :: . Identify the target groups. Typical groups
could be the customer, sponsor, project team,
project office, or anyone who needs project
information to make decisions and/or contribute
to project progress.
2. :: . What information is pertinent to stakeholders who
contribute to the project's progress?
Project status reports Deliverable issues
Changes in scope Team status meetings
Gating decisions Accepted request changes
Action items Milestone reports

Top management needs to know the information required to

make strategic decisions and manage the portfolio of projects.
3. :: of information. When the information needs are
identified, the next step is to determine the sources
of information.
where does the information reside?
How will it be collected? For example, information relating to
the milestone report, team meetings, and project status
meetings would be found in the minutes and reports of
various groups.
4. :: modes. In today's world, traditional
status report meetings are being supplemented by:
e-mail, teleconferencing, Lotus Notes, SharePoint, and a
variety of database sharing programs to circulate
information.
In particular, many companies are using the Web to
create a virtual project office" to store project
information.
Project management software feeds information directly
to the Web site so that different people have immediate
access to relevant project information.
In some cases, appropriate information is routed
automatically to key stakeholders. Backup paper
hardcopy to specific stakeholders is still critical for many
project changes and action items.
5. :: . Determine who will send out the information.

For example, a common practice

is to have secretaries of meetings
forward the minutes or specific
information to the appropriate
stakeholders.
In some cases the responsibility
lies with the project manager
or project office.

Timing and frequency of distribution appropriate to the

information need to be established.