Project planning and Scheduling
 The course project planning and scheduling is




intended to introduce students with:
basic concept and processes of project planning,
tools and techniques of project planning
basic concept and processes of scheduling
tools and techniques of project scheduling
Outline in brief
 part 1: Introduction
 What is project: Meaning, attributes, and parameters
 Project vs. operations
 Project management processes
 Part 2: project planning
 Project planning processes
 Project scope planning
 Project scope definition










Project scope verification
Project scope change control
Part 3: project scheduling
Defining scheduling
Process of project scheduling
Activity definition
Activity sequencing
Activity duration estimating
Schedule development
Schedule control
Chapter one: Introduction
 1. What is project?
What is project cont’d?
 Project is a temporary endeavor undertaken to create
a unique product or service.
 Temporary means that every project has a definite
end.
 Unique means that the product or service is different
in some distinguishing way from all similar products or
services.
 A project has a unique purpose.
 Every project should have a well-defined objective.
What is project cont’d
 project is an endeavor
in which human, (or
machine),material and financial resources are
organized in a novel way, to undertake a unique scope
of work, of given specification, within constraints of
cost and time, so as to deliver beneficial change defined
by quantitative and qualitative objectives.
What is project cont’d
 A project is a plan or proposal consisting of a
sequence of unique, complex, and connected
activities having one goal or purpose and that must be
completed by a specific time, within budget, and
according to specification.
 Sequence of activities: A project comprises a number
of activities that must be completed in some specified
order, or sequence.
What is project cont’d
 Unique activities: The activities in a project must be
unique. A project has never happened before, and it
will never happen again under the same conditions.
 Complex activities: The activities that make up the
project are not simple, repetitive acts
 Connected Activities: Connectedness implies that
there is a logical or technical relationship between
pairs of activities.
 One goal: Projects must have a single goal.
What is project cont’d
 Specified Time: Projects have a specified completion
date. This date can be self-imposed by management or
externally specified by a customer or government h
agency.
 Within Budget: Projects also have resource limits,
such as a limited amount of people, money, or
machines that are dedicated to the project.
 According to Specification: The customer, or the
recipient of the project's deliverables, expects a certain
level of functionality and quality from the project
What is project cont’d
 Some attributes:
 A project requires resources.
 Resources include people, hardware, software, or other
assets.
 A project should have a primary sponsor or customer.
 A project involves uncertainty
 It is an answer to a business opportunity or problem
 It goes through distinct stages
-It has a beginning, a middle and an end…
What is project cont’d
 It must be approved to proceed
-It consumes resources...
 It is confined by definable boundaries
-It has defined scope, budget, schedule, quality...
 Scope: What is and is not included as part of the
project

Budget : How much can be expended for direct and
indirect costs

Schedule : Start and end dates for each deliverable

Quality : Qualitative terms, conditions and
expectations expressing each stakeholders’ interests
What is project cont’d
 Every project is constrained in different ways by its scope,
time goals, and cost goals.
 Scope: What is the project trying to accomplish?
 Time:
How long should it take to complete the project?
 Cost:
What should it cost to complete the project?
 These limitations are referred to us the Triple Constraint of
project management. Managing the triple constraint means
making trade-offs between project scope, time and cost goals
for a project.
2. Operations and Projects
 Is project the same with operations?
PROJECTS vs. OPERATIONS
 Projects differ from ongoing operations in the following
ways:
 projects start and end
 projects are focused on one objective
 projects have short term strategies
 projects end!!
 ongoing operations are focused on continuing support of an
organization
 ongoing operations have long term strategies
 ongoing operations focus on multiple objectives
 ongoing operations don’t (normally) end!!
PROJECTS vs. OPERATIONS
 Operations are existing systems and functions whereas
Projects are one-time multi-disciplinary resource
configuration.
 Operations focus on “Maintaining”, whereas Projects
focus on “Change”.
3. Project management defined
 Project Management is the application of
knowledge, skills, tools and techniques to
project activities in order to meet or exceed
project requirements(stakeholder needs and
expectations from a project).
 It deals with tools, people, and systems.
Project management cont’d
 The tools are work breakdown structures, PERT
scheduling, earned value analysis, risk analysis, and
scheduling software (to name a few).
 tools are the primary focus of most organizations
that want to implement project management
 However, tools are a necessary but not a sufficient
condition for success in managing projects
Project management cont’d
 The processes are far more important, because if you
do not employ the correct processes for managing, the
tools will only help you document your failures with
great precision.
 It is the people who run the processes. Organizations
are people and people engage in processes to get the
results
 Hence, project management calls for not only
understanding techniques or operations of tools
but understanding people management
Project management cont’d
 Requirements are constraints on every project, no





matter how large or how small
They are defined by the PCTS targets
P = performance requirements, technical (features of
deliverable) and functional (what the deliverable is
supposed to do)
C = Cost to do the job
T = time required for the project
S = scope or magnitude of the work
Project management cont’d
 The relationship between them may be given by the
following expression:
 C = f(P, T, S)
 However, we are always estimating the values of these
variables, so their exact relationship is never
known.
 Literatures represent the relationship that exists
between the PCTS constraints using a triangle where
P, C, and T representing the lengths of the sides,
while S representing the area.
Project management cont’d
 What is important about this illustration is that one
cannot arbitrarily assign values to all three sides
and the area.
 If three are specified, the fourth can be determined,
but if you try to assign values to all four, they will
“fit” only by accident.
 It is common for the project sponsor or some other
manager to want to dictate values for all four.
 This is, in fact, a common cause of project failures.
Project management cont’d
 It is a project manager’s job to tell the sponsor what he
or she needs if he/she to do a project.
 In this regard, the values for P, T, and S may be given
by sponsor and the project manager may tell the
sponsor the cost to achieve those targets.
Project management cont’d (defn.2)
 Project management is accomplished through the
application and integration of the project
management processes of initiating, planning,
executing, monitoring and controlling, and closing”
 From a project management perspective there are five
main stages:



Initiation
Planning
Execution
Controlling and
Wrap-up (close-out)
Project management cont’d
 Initiation Phase:
 The need for a project is identified.
 An appropriate response to the need is determined
and described. (This is actually where the project
begins.)
 Issues of feasibility (can we do the project?) and
justification (should we do the project?) are
addressed.
Project management cont’d
 The Planning Phase involves
 Defining the scope of the project
 Identifying intermediate work products (interim
deliverables) along with the strategy for producing
them.
 Definition of the required elements of work (tasks)
and the optimum sequence for executing them (the
schedule).
 Estimates are made regarding the amount of time
and money needed to perform the work and when
the work is to be done.
Project management cont’d
 During the third phase, the Execution Phase,
 the prescribed work is performed under the watchful
eye of the project manager.
 Progress
is
continuously
monitored
and
appropriate adjustments are made and recorded as
variances from the original plan.
 Throughout this phase, the project team remains
focused on meeting the objectives developed and
agreed upon at the outset of the project.
 Controlling: the act of comparing where you are to
where you are supposed to be, so that corrective action
can be taken when there is a deviation from the target.
Project management cont’d
 During the final phase, or the Close-Out Phase,
 the emphasis is on verifying that the project has
satisfied or will satisfy the original need.
 Ideally, the project culminates with a smooth
transition from deliverable creation (the project) to
deliverable utilization (the post-project life cycle).
 The project customer accepts and uses the
deliverables.
 Throughout this phase, project resources (the
members of the project team) are gradually redeployed and the project finally shuts down.
Project management cont’d (defn.3)
 Project management is facilitation of the planning ,
scheduling, and controlling of all activities that
must be done to meet project objectives
Part II
Project planning
What planning is about?
 Planning – is the dynamic process of making decisions





today about future actions;
What missions or objectives be achieved,
What actions should be taken,
How the end can be achieved,
When to achieve it, Who is to do it, Where to do it.
It bridges the gap between where we are now and where we
want to be.
 It gives bases for monitoring and evaluation of activities.
Logical process (steps) in planning
What is project planning?
 Project planning may be described as establishing a




predetermined course of action within a forecasted
environment.
It involves:
Identifying the tasks necessary to achieve a project goal,
Estimating of required resources to accomplish the tasks,
and
Scheduling of people and tasks to meet the deadline.
 It expresses the objectives & requirements of the project in
terms of project scope, project schedule, and resource
requirement, project cost estimation, project quality,
and project risk management.
What is project planning cont’d?
 It’s often been said that project management really
consists of two major phases—doing the right
project and doing the project right.
 Ensuring that your project is based upon a true need
and that it’s justified from a business standpoint
are two important aspects of doing the right project.
 Project planning, on the other hand, is all about doing
the project right.
 In essence, the project plan is a kind of map that you
can use to guide you and your team from beginning to
end.
What is project planning cont’d?
 project planning is also an enormous subject mainly
composed of strategic and tactical components(strategic vs. implementation planning)
 The strategic component consists of understanding
some of the principles and philosophies of
planning.
 The second component of project planning is tactical
-almost mechanical
 It consists of the step-by-step process of creating a
detailed project plan, using estimates as raw material.
Project Planning as continuous Process
 project plans tend to emerge gradually.
 They are continuously modified and refined in




terms of content, structure, and level of detail.
As the project definition becomes more refined:
work is broken down into ever-increasing levels of
detail,
assumptions are verified or refuted, and
actual results are achieved, the project plan must keep
pace _ continuous re-planning.
Project Planning as continuous Process
 Planning Is Not a One-Time Event!
 As conditions change, your original plan must be
modified to reflect those changes.
 The project plan is a living document and you should
expect to be planning throughout the life of your
project.
Why project planning?
 To eliminate or reduce uncertainty
 To improve efficiency of the operation
 To obtain a better understanding of the objectives
 To provide a basis for monitoring and controlling work
Beware! Common Planning Failures
 Failure to Plan- project managers feel (or are





pressured into feeling) that planning is not worth
doing at all.
Failure to Plan in Sufficient Detail
Failure to Know When to Stop Planning
Failure to Involve Task Performers in Planning
Failure to Reflect Risk and Uncertainty in Plans
Failure to Keep the Plan Current.
How Much Planning Is Enough?
 The answer to this question is … it depends:
 Organizational Expectations.
 Project Importance.
 Project Complexity.
 Project Size.
 Amount of Uncertainty.
Planning and estimation
 Estimating is a big part and subset of project





planning.
To prepare reasonably accurate, thorough project plan,
you’ll need to estimate many things:
how long it will take to do the work,
how much the work will cost,
how much money the project will save or make,
the magnitude of the risk and uncertainty involved,
and other aspects of the project.
Planning and estimation cont’d
 Estimation
may be defined as “determining
approximately the size, extent, value, cost, or nature
of something.”
 The nature of project work is such that—even with
significant prior experience—the uncertainty
inherent in projects simply does not allow for
absolute precision in estimates.
Planning and estimation cont’d
 Some tips to make better estimation:
 Ask the person responsible for doing the work to prepare




the estimate.
Ask a subject matter expert—a person with knowledge or
experience in that area.
Use historical data and make appropriate adjustments.
Use mockups, trial runs, tests, field studies, or other
simulated experiences as a guide.
Remember: estimates should reflect what you believe to be
the most likely outcome.
Planning and estimation cont’d
 Estimating Pitfalls
 Estimating is difficult. There are many things that can
undermine the accuracy or validity of your estimates.
 Among the most common pitfalls are the following:
 Poorly defined scope of work. This can occur when
the work is not broken down far enough or individual
elements of work are misinterpreted.
 • Omissions. Simply put, you forget something.
Planning and estimation: pitfalls cont’d
 Rampant optimism. This is the rose-colored
glasses syndrome, when the all-success scenario is
used as the basis for the estimate.
 Failure to assess risk and uncertainty- neglecting
or ignoring risk and uncertainty can result in estimates
that are unrealistic.
 • Time pressure. If someone comes up to you and
says, “Give me a ballpark figure by the end of the day”
and “Don’t worry, I won’t hold you to it,” look out! This
almost always spells trouble.
 Failure to involve task performers.
Preparing a Detailed Project Plan: Step
by Step
 Preparing detail project plan involves various steps and
can be grouped into:
 Project scope management (Identifying what
needs to be done )
 Project schedule development (part III)
Project scope management
 what is scope and scope management in project
context?
What is scope?
 In the project context, the term scope may refer to:
 Product scope- the futures and functions that are to
be included in a product or service
 Describes the product to be delivered –”what does
the customer wants you to produce with the
project?”
 The deliverables are products such as a new system, a
new building, a new process, etc.
 Completion of the product is measured against
product requirements that define the features or
functions of the products.
What is scope?
 Project scope- describes the work that must be done
in order to deliver a product with the specified
features and functions
 The first step in the planning process consists of
identifying exactly what you’re going to do, the scope
of work.
 In this stage, you identify major elements of work and
then break them down systematically into smaller and
smaller pieces, until each piece becomes a comfortable
size to estimate, execute, and monitor.
What is scope?
 The work representing project scope may comprise of
various deliverables
 The deliverables can be meetings, reports, analysis,
design documents, phases of project, etc.
 Completion of works under project scope is measured
against the project scope management plan that is a
subsidiary to the project management plan.
What is scope?
 Project scope is a statement that defines the







boundaries of the project
Known with different names in different discipline:
Functional specification- in information system
Statement of work
Document of understanding,
Scoping statement,
Project initiation document,
Project request form.
What is project scope management?
 Project scope management includes the process
required to ensure that the project includes all the
work required and only work required to complete
the project successfully
 Primarily concerned with defining and controlling
what is and is not included in the project
 This document is the foundation for all project work
to follow.
 It is critical that scope be correct. Why?
Project scope management processes
 Initiation –committing the organization to begin the
next phase of the project
 Scope planning- developing a written scope
statement as the basis for future project decisions
 Scope definition- subdividing the major project
deliverables into smaller, and
components
more manageable
Project scope management processes
 scope verification- formalizing acceptance of the
project scope
 Scope change control- controlling change to project
scope
 Note: though the project scope management
processes appear here as a discrete elements with
well defined interfaces, in practice they may
overlap and interact
1. Initiation
 Project scope management requires consulting and
understanding project initiation or authorization
documents if any
 Initiation is the process of formally recognizing
that a new project exists or that an existing project
should continue into its next phase
 Formal initiation links the project to the ongoing work
of the performing organization
 Feasibility study, preliminary plan or some other
equivalent form of analysis proceeds formal initiation
of the project in some organizations
Initiation cont’d
 The initiation could be informal in other cases such
as internal service projects and operational efficiency
improvement project (eg, training project- EEPCO,
ETC as a case in point)
Inputs and outputs
.
Inputs:
-product
descriptions
-project selection
criteria
-Strategic plan
-Historical
information
Out puts
-Project charter
-Constraints
-Assumptions
-assignment of
project manager
Inputs to initiation
 Product
descriptionthis
documents
the
characteristics of a product or service that the project
was undertaken to create
 The product description will generally have less detail
in early phases and more detail in later ones as the
product characteristics are progressively elaborated
Inputs to initiation
 The product description should also document the
relationship between the product being created and
the business need or other stimuli that gave rise to the
project
 While the form and substance of the product
description will vary, it should always be detailed
enough to support later project planning
Inputs to initiation
 Strategic plan- all projects be supportive of the
performing organization’s strategic goals – the
strategic plan of the performing organization should
be considered as a factor in project selection decision
 Project selection criteria- are typically defined in
terms of the product of the project and can cover the
full range of possible management concerns (financial
return, market share, public perception, etc.)
Inputs to initiation
 Historical information- information about both the
results of previous project selection decisions and
previous project performance should be considered to
the extent it is available
 When initiation involves approval for the next
phase of a project, information about the results
of previous phases is often critical
Outputs from initiation
 After considering these and other relevant inputs, a project
may be formally authorized. This may be formalized
through:
 Project charter- a document that formally recognizes the
existence of a project
 It provides the project manager with the authority to
apply organizational resources to project activities
 When a project is performed under contract, the signed
contract will generally serve as the project charter for the
seller
Outputs from initiation cont’d
 Project manager identified/assigned: need to be
done as early in the project as is feasible
 Constraints:
are factors limiting the project
management team’s options
 E.g., A pre-defined budget is a constraint that is highly
likely to limit the team’s options regarding scope,
staffing, and schedule
 When a project is performed under contract,
contractual provisions will generally be constraints
Outputs from initiation cont’d
 Assumptions: are factors that, for planning, purposes,
will be considered to be true, real, or certain.
 E.g. If the date that a key person will become available
is uncertain, the team may assume a specific start date
 Generally involve a degree of risk
 Note: events like producing project charter and
assigning project manager marks formal recognition
of a new project initiation or authorization.
2. Scope planning
 Scope planning is the process of developing a
written scope statement
 Scope statement serves as the basis for future project
decisions including, in particular, the criteria used to
determine if the project or phase has been completed
successfully
 A written scope statement is necessary for both
projects and sub-projects
 It defines the boundaries of work
Scope planning cont’d
 The scope statement forms the basis for an
agreement between the project team and the
project customer by identifying both the project
objectives and the major product deliverables
 If all the elements of scope statement are already
available (e.g., a request for proposal may identify the
major deliverables, the project charter may define the
project objectives) , this process may involve little
more than physically creating the written
document
 Accordingly, previous information or documents like
product descriptions, project charter (contract),
constraints (like project budget) and assumptions
serve as inputs to project scope planning
Outputs from scope planning
 The two main outputs of scope planning are:
 scope statement and
 scope management plan
1. Output: Scope statement
 Scope statement- provides a documented basis for
making future project decisions and for confirming or
developing common understanding of project scope
among stakeholders
 May need to be revised or refined as project
progresses to reflect changes to the scope of the
project
Contents of Scope statement
 The scope statement is supposed to include either
directly or by reference to other documents:
 Project justification-the business need that the
project was undertaken to address
 Project product- a brief summary of product
description
Contents of Scope statement cont’d
 Project deliverables- a list of the summary level sub-
products whose full and satisfactory delivery marks
completion of the project
 E.g. deliverables for a software development project
might include: the working computer code, a user
manual, and an interactive tutorial
 For organizational structure development project:
alternative organizational structure, job description
and specification document, HR policy manual, --
Contents of Scope statement cont’d
 When known, exclusions should be identified but
anything not explicitly included is implicitly excluded
 Project objectives: the quantifiable criteria that must
be met for the project to be successful
 Project objectives may include cost, schedule, and
quality measures at minimum
Contents of Scope statement cont’d
 Project objectives should have:
 an attribute- e.g., cost
 A yardstick – e.g., Birr and,
 An absolute or relative value – e.g., less than 2,000,000
Birr
 Note- in some areas, project deliverables are called
project objectives while project objectives are called
critical success factors
Output: scope management plan
 Scope management plan: this document describes
how project scope will be managed and how scope
changes will be integrated into the project
 It should also include an assessment of the expected
stability of the project scope- i.e., how likely it to
change, how frequently, and by how much
scope management plan cont’d
 The scope management plan should also include a
clear description of how scope changes will be
identified and classified
 Scope management plan may be formal or informal,
highly detailed or broadly framed based on the needs
of the project
3. Scope definition
 Involves subdividing the major project deliverables ( as
identified in the scope statement) into smaller, more
manageable components in order to:
 1. improve the accuracy of cost, time, and resource
estimates
 2. define a baseline for performance measurement and
control
 3. Facilitate clear responsibility assignment
Scope definition cont’d
 Proper scope definition is critical to project success
 When there is poor scope definition, final project cost
is expected to be higher because of the inevitable
changes which disrupt project rhythm , cause rework,
increase project time, and lower the productivity and
morale of the worker
Input/output
Inputs to scope definition
 Scope statement
 Constraints
 Assumptions
 Other planning outputs- the outputs of the processes
in other knowledge areas should be reviewed for
possible impact on project scope definition
 Historical information about previous projects should
be considered – information about errors and
omissions on previous projects is specially useful
Tools and techniques for scope
definition
 Work breakdown structure (WBS) templates A WBS from a previous project can often be used as a
template for a new project
 Although project is unique, WBS can often be reused
since most projects will resemble another project to
some extent
 Decomposition- involves subdividing the major




project deliverables into smaller, more manageable
components until the deliverables are defined in
sufficient detail to support future project activities:
planning
Executing,
controlling, and
closing
 Decomposition involves the following major steps:
1. identify the major elements of the project: In general,
the major elements will be the project deliverables
2. Decide if adequate cost and duration estimates can be
developed at this level of detail for each element
 The meaning of adequate may change over the course
of the project- decomposition of a deliverable that will
be produced far in the future may not be possible
 For each element, proceed to step 4 if there is
adequate detail and to step 3 if there is not- this means
that different elements may have deferring levels of
decomposition
3. identify constituent elements of the deliverable
 Constituent elements should be described in terms of
tangible, verifiable results in order to facilitate
performance measurement
 Should be defined in terms of how the work of the
project will actually be accomplished
 Tangible, verifiable results can include services as well
as products ( e.g., status reporting could be described
as a weekly status reports; for manufactured item,
constituent elements might include several individual
components plus final assembly
 Repeat step 2 on each constituent element
4. verify the correctness of the decomposition:
 Are the lower-level items both necessary and sufficient
for completion of the item decomposed?
 If not, the constituent elements must be modified
(added to or deleted from or redefined)
 Is each item clearly and completely defined? If not the
descriptions must be revised or expanded
 Can each item be appropriately scheduled? Budgeted?
Assigned to specific organizational unit such as
department, team, or person- who will accept
responsibility for satisfactory completion of the item?
 If not, revisions are needed to provide adequate
management control
Outputs from scope definition
 Scope definition results in Work Breakdown
Structure (WBS)
 What is WBS?
WBS cont’d
 WBS
is a deliverable-oriented grouping of project
elements that organizes and defines the total scope of the
project
 WBS
is
a
deliverable-oriented
hierarchical
decomposition of the work to be executed by the project
team to accomplish the project objectives and create the
required deliverables.
 Work not in the WBS is outside the scope of the project
 As with the scope statement, the WBS is often used to
develop or confirm a common understanding of project
scope
WBS cont’d
 The items at the lowest level of WBS are often referred
to us work packages
 It is the point at which the cost and schedule can be
reliably estimated.
 The level of detail for Work Packages will vary with
the size and complexity of the project.
WBS cont’d
 It represents an explicit description of the project‘s
scope, deliverables and outcomes—the “what‘‘ of the
project.
 However, the WBS is not a description of the processes
followed to perform the project . . .
 nor does it address the schedule that defines how or
when the deliverables will be produced.
 Rather, the WBS is specifically limited to describing
and detailing the project‘s outcomes or scope.
WBS cont’d
 It is a foundational project management component,





and as such is a critical input to other project
management processes and deliverables such as:
activity definitions,
project network diagrams,
project and program schedules,
performance reports,
risk analysis and response, control tools or project
organization.
WBS cont’d
 WBS is normally presented in chart form
 Each item in the WBS is generally assigned a unique
identifier: these identifiers are often known collectively as
code accounts
 Work element descriptions are often collected in a WBS
dictionary
 WBS Dictionary will typically include work package
descriptions as well as other planning information such as
schedule dates, cost budgets, and staff assignments
WBS cont’d
 Note: WBS should not be confused with other kinds of
“breakdown” structures used to present project
information- such as:
 Contractual WBS (CWBS)- which is used to define
the level of reporting that the seller will provide the
buyer
 Organizational breakdown structure (OBS), which
is used to show which work elements have been
assigned to which organizational units
WBS cont’d
 Resource breakdown structure (RBS), which is a
variation of the OBS and is typically used when work
elements are assigned to individuals
 Bill of materials (BOM), which presents a
hierarchical view of the physical assembles,
subassemblies, and components needed to fabricated
a manufactured product
 Project breakdown structure (PBS), which
fundamentally the same as a properly done WBS.
 The term PBS is widely used in application areas where
the term WBS is incorrectly used to refer to a BOM
WBS cont’d: Creating WBS:
 There is no ―right‖ way to construct a WBS.
 The full scope of work for the project is placed at the top of




the diagram,
and then sub-divided smaller elements of work at each
lower level of the breakdown.
Each descending level represents an increasingly detailed
description of the project elements
At the lowest level of the WBS the elements of work is
called a work package.
A list of project‘s activities is developed from the work
packages.
key characteristics of high-quality
WBS
 1. WBS is that it is “deliverable oriented‘‘.
 Here a deliverable is defined as any unique and
verifiable product, result, or capability to perform a
service that must be produced to complete a process,
phase or project.
 In this context, oriented means aligned or positioned
with respect to deliverables (i.e., focused on
deliverables).
Deliverable oriented WBS
 2. An additional key attribute of the WBS is that it is a
hierarchical decomposition of the work.
 Is hierarchical and constructed in such a manner that
 (a) each level of decomposition includes 100% of the
work of its parent element, and
 (b) each parent element has at least two child
elements
 Hence decomposition process need to confirm to the 100%
Rule
 100% rule states that the WBS includes 100% of the work
defined by the project scope and, by doing so, captures all
deliverables in terms of work to be completed
 The rule applies at all levels within the hierarchy; the sum of
the work at the “child‘‘ level must equal 100% of the work
represented by the “parent‘‘.
 The WBS should not include any work that falls outside the
actual scope of the project; that is, it cannot include more
than 100% of the work.
 3. Includes only those elements to be delivered by the
project (and nothing that is considered out of scope)
4. Uses noun and adjective to describe the deliverables,
not verb-objective format
5. Employs a coding scheme that clearly depicts the
hierarchical nature of the project
6. Includes a WBS Dictionary that describes and
defines the boundaries of the WBS elements
7. Contains work packages that clearly support the
identification of the tasks, activities and milestones
that must be performed in order to deliver the work
package
8.
Is updated in accordance with project change
management procedures
Task oriented WBS
 Why in terms of deliverables?
 With task-oriented Work Breakdown Structures, the
focus will be on process or action
 This implies that the true end-product of the WBS
element is a refined process rather than the actual
deliverables of the process.
 The performance of the process, rather than outputs,
becomes the focus of the work,
 and as such it is possible to perform the process
flawlessly without ever producing specific deliverables
 Hence, it is advisable to state WBS in terms of noun
and adjective rather than in terms of verb-objective
Coding WBS
 Coding scheme is a critical element to quality Work
Breakdown Structures
 It should clearly show the parent-child relationship or
the level on the chart
 previous WBS:
 The top of the chart reflects the project level and is
coded with a 1. The next level of decomposition, level
2, is broken down into 1.1, 1.2, 1.3 and 1.4.
Coding WBS
 Coding scheme is a critical element to quality Work
Breakdown Structures
 It should clearly show the parent-child relationship
or the level on the chart
 previous WBS:
 The top of the chart reflects the project level and is
coded with a 1. The next level of decomposition, level
2, is broken down into 1.1, 1.2, 1.3 and 1.4.
4. Scope verification
 Is the process of formalizing acceptance of the project
scope by the stakeholders (sponsor, client, customer,
etc.)
 Requires reviewing work products and results to
ensure that all were completed correctly and
satisfactorily
 If the project is terminated early, the scope verification
process should establish and document the level and
extent of completion
 Scope verification differs from quality control in that it
is primarily concerned with acceptance of the work
results while quality control is primarily concerned
with the correctness of the work results
Inputs to scope verification
 1. Work results:
 work results- which deliverables have been fully or
partially completed, what costs have been incurred or
committed, etc. are an output of project plan execution
 2. product documentation.
 Documents produced to describe the project’s
products must be available for review
 The terms used to this documentation (plans,
specifications, technical documentation, drawings,
etc.) vary by application area
Tools and techniques for scope
verification
 Inspection
 It includes activities such as measuring, examining,
and testing undertaken to determine whether results
confirm to requirements
 Known with names such as reviews, product reviews,
audits, walk- through
Outputs from scope verification
 Formal acceptance
 Documentation that the client or sponsor has accepted
the product of the project or phase must be prepared
and distributed
 Such acceptance may be conditional, specially at the
end of a phase
5. Scope change control
 Scope change control is concerned with
 1. influencing the factors which create scope changes
to ensure that changes are beneficial
 2. determining that a scope change has occurred , and
 3. managing the actual changes when and if they occur
 Scope change control must be thoroughly integrated
with other control processes such as
 Time control
 Cost control
 Quality control
Inputs to scope change control
 A. WBS
 B. Performance reports-
 provides information on scope performance such as
which interim products have been completed and
which have not
 Performance reports may also alert the project team to
issues which may cause problems in the future
 C. Change requests
 Changes may require expanding the scope or may





allow shrinking it
Change requests may occur in many forms such as:
Oral or written
Direct or indirect
Externally or internally initiated
Legally mandated or optional
 Most change requests are the result of:
 An external event – e.g., a change in a government
regulation
 An error or omission in defining the scope of the
product- e.g., failure to include a required future in the
design
 A value-adding change (taking cost reduction
advantage brought by new technology which was not
at the time when the scope was originally defined)
 D. The scope management plan in general can be
an input to scope change control
 Tools and techniques for scope change control
 Scope change control system- defines the
procedures by which the scope may be changed- may
include paper work, tracking systems, approval levels
needed for authorization
 Additional planning
Outputs from scope change control
 Scope change – is any modification to the agreed-upon
project scope as defined by the approved WBS
 Often requires adjustments to cost, time, quality, and
related project objectives
 Corrective action- anything done to bring expected future
project performance into line with the project plan
 Lessons learned- the cause of variance, the reasoning
behind the corrective action chosen, and other types of
lessons learned from scope change control should be
documented so that this information becomes part of the
historical database for both the project and other projects
of the performing organization