Project Management

Project as a system

Subsystem and elements: Any system can be broken down into

smaller parts. The smallest part of a system is an element. A
system can also be broken down into parts that are themselves
systems, called subsystems. A subsystem is a system that
functions as a component of a larger system.
Attributes: Systems, subsystems, and elements all have
distinguishing characteristics called attributes; these describe the
condition of systems, subsystems, and elements in qualitative or
quantitative terms.
Environment: The term environment refers to anything outside
the system that influences the behavior or outcome of the system.
 Defining the Project
Step 1: Defining the Project Scope
Step 2: Establishing Project Priorities
Step 3: Creating the Work Breakdown Structure
Step 4: Integrating the WBS with the
Organization
Step 5: Coding the WBS for the Information
System

4–3
 Step 1: Defining the Project Scope
• Project Scope
– A definition of the end result or mission of the project—a product or
service for the client/customer—in specific, tangible, and measurable
terms.
– Project scope verification have different input such as project scope
management, Project scope management plan, WBS dictionary and
Deliverable which help the project manager to take decision.
• Purpose of the Scope Statement
– To clearly define the deliverable(s) for the end user.
– To focus the project on successful completion
of its goals.
– To be used by the project owner and participants
as a planning tool and for measuring project success.

4–4
 Project Scope: Terms and Definitions
• Scope Statements
– Also called statements of work (SOW)
• Project Charter
– Can contain an expanded version of scope statement
– A document authorizing the project manager to initiate
and lead the project.
• Scope Creep
– The tendency for the project scope to expand over time
due to changing requirements, specifications, and
priorities.
4–5
 Step 2: Establishing Project Priorities
• Causes of Project Trade-offs
– Shifts in the relative importance of criterions related
to cost, time, and performance parameters
• Budget–Cost
• Schedule–Time
• Performance–Scope
• Managing the Priorities of Project Trade-offs
– Constrain: a parameter is a fixed requirement.
– Enhance: optimizing a criterion over others.
– Accept: reducing (or not meeting) a criterion requirement.

4–6
 Step 3: Creating the Work
Breakdown Structure
• Work Breakdown Structure (WBS)
– An hierarchical outline (map) that identifies the
products and work elements involved in a project.
– Defines the relationship of the final deliverable
(the project) to its subdeliverables, and in turn,
their relationships to work packages.
– Best suited for design and build projects that have
tangible outcomes rather than process-oriented
projects.
4–7
 Step 3: Creating the Work
Breakdown Structure
• Work Breakdown Structure (WBS) activities
– List of all the Activity
– Scheduling
– Budgeting
– Staffing
– Precedence diagram for the project
– Risk Management
– Estimation of cost
– Project control

4–8
How WBS Helps the Project Manager
• WBS
– Facilitates evaluation of cost, time, and technical
performance of the organization on a project.
– Provides management with information appropriate
to each organizational level.
– Helps in the development of the organization breakdown
structure (OBS). which assigns project responsibilities to
organizational units and individuals
– Helps manage plan, schedule, and budget.
– Defines communication channels and assists
in coordinating the various project elements.

4–9
 Types of WBS Charts
• Once you’ve chosen a deliverable-based or phase-based WBS, you can
also choose between different types of WBS diagrams. Let’s take a
look at the main types of work breakdown structure charts.
• Work Breakdown Structure List: Also known as an outline view, this is
a list of work packages, tasks and deliverables. It’s probably the
simplest method to make a WBS, which is sometimes all you need.
• Work Breakdown Structure Tree Diagram: The most commonly seen
version, the tree structure depiction of a WBS is an organizational
chart that has all the same WBS elements of the list (phases,
deliverables, tasks and work packages) but represents the workflow or
progress as defined by a diagrammatic representation.
• Work Breakdown Structure Gantt Chart: A Gantt chart  is both a
spreadsheet and a timeline. The Gantt chart is a WBS that can do
more than a static task list or tree diagram. With a dynamic Gantt
chart, you can link dependencies, set milestones, even set a baseline.
This is the most common version in project management software.
Example of WBS chart
 Chart
• Bar chart: it is a pictorial chart. A bar diagram is
commonly used to display a work plan, track the progress,
and monitor task implementation.
• The length of bar shows the time required for completion.
• Linked Bar Chart: It is an important our original bar chart
or mile stone chart
• In linked bar chart, activity are linked with arrows and
liners, indicating require and order of activities.
• For example, a project manager may use a bar chart to
show the progression of each project activity. The bars
represent the project activities and the vertical axes
represent the percentage of completion. The project team
can easily identify which activity requires more attention
by reviewing the bar chart.
 Gantt charts
• Gantt charts can be used in managing projects of all sizes and types.
These may include building infrastructures like dams, bridges, and
highways. They may also include software development and other
technologies. Project management tools, such as Microsoft Visio,
Project, SharePoint, and Excel , or specialized software, such as
Gantto or Matchware, can help in designing Gantt charts.
 Core elements of Gantt chart
• A timeline – the backbone of the chart. It is more than a
regular timeline where you can see how your project activities
are progressing. A Gantt diagram allows users to zoom in and
out of their timelines and add more valuable elements.
• A bar – a visual representation of a project or a task. It
demonstrates the length of time and allows seeing who is
engaged in that task.
• Resources – what makes your projects tick (people,
equipment, and machines that bring projects to fruition). 
• Dependencies – showcase how your tasks are linked together. 
• Milestones – measure the project progress and show how it
approaches the goals that have been set.
 Resource Histogram

• In project management, resources are the people, tools and materials necessary to
get the project done.
• A resource histogram is a statistical tool used to manage resources. It’s a
historical bar chart diagram that defines a resource allocation schedule. Resource
histograms help project managers with resource planning and quality
management.
• Resource histograms are often used with Gantt charts. This helps project
managers better understand the project scope and how and when to use their
resources.
• A resource histogram is a stacked bar chart that is used for resource allocation in
project management. It’s basically a resource planning graph that displays the
amount of time a resource is scheduled to work over a period of time. It can also
be used to determine resource availability.
• Resource histograms are made up of:
• A title: which is a brief description of what data is being depicted
• The horizontal axis: which shows the time period
• The vertical axis: which represents the resources
Example of Resource Histogram
 Project management plan
A project management plan is a collection of baselines and
subsidiary plans that include:
• Scope
• Time
• Cost
• Quality
• Communication
• Risk
• HR
• Knowledge management
• integration
 Work Packages
• A work package is the lowest level of the WBS.
– It is output-oriented in that it:
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 person responsible for units of work (who).
6. Identifies monitoring points (milestones)
for measuring success.

4–18
 Step 4: Integrating the WBS
with the Organization
• Organizational Breakdown Structure
(OBS)
– Depicts how the firm is organized to discharge
its work responsibility for a project.
• Provides a framework to summarize
organization work unit performance.
• Identifies organization units responsible
for work packages.
• Ties organizational units to cost control accounts.

4–19
 Step 5: Coding the WBS for
the Information System
• WBS Coding System
– Defines:
• Levels and elements of the WBS
• Organization elements
• Work packages
• Budget and cost information
– Allows reports to be consolidated
at any level in the organization
structure
4–20
 Responsibility Matrices
• Responsibility Matrix (RM)
– Also called a linear responsibility chart.
– Summarizes the tasks to be accomplished and
who is responsible for what on the project.
• Lists project activities and participants.
• Clarifies critical interfaces between units
and individuals that need coordination.
• Provide an means for all participants to view their
responsibilities and agree on their assignments.
• Clarifies the extent or type of authority that
can be exercised by each participant.

4–21
Example
 Project Communication Plan
• 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?
4–24
 Information Needs
• Project status reports
• Deliverable issues
• Changes in scope
• Team status meetings
• Gating decisions
• Accepted request changes
• Action items
• Milestone reports
4–25
 Difference between PM and GM
• Meaning
• Nature
• Process
• Tasks
• Success
• Work location
 Project Outputs
• Accepted deliverables.
• Customer satisfaction.
• Requested changes.
• Recommended corrective actions
CPM and PERT
 Developing the Project Plan
• The Project Network
– A flow chart that graphically depicts the sequence,
interdependencies, and start and finish times of the
project job plan of activities that is the critical path
through the network.
• Provides the basis for scheduling labor and equipment.
• Enhances communication among project participants.
• Provides an estimate of the project’s duration.
• Provides a basis for budgeting cash flow.
• Identifies activities that are critical.
• Highlights activities that are “critical” and can not be delayed.
• Help managers get and stay on plan.

6–29
 Constructing a Project Network
• Terminology
– Activity: an element of the A
project that requires time.
– Merge Activity: an activity that
B D
has two or more preceding
activities on which it depends.
– Parallel (Concurrent) Activities:
C
Activities that can occur
independently and, if desired,
not at the same time.

6–30
Constructing a Project Network (cont’d)
• Terminology
– Path: a sequence of connected, dependent
activities.
– Critical path: the longest path through the
activity network that allows for the completion of
all project-related activities; the shortest
expected time in which the entire project can be
C
completed. Delays on the critical path will delay
completion of the entire project.
A B D

(Assumes that minimum of A + B > minimum of C in 6–31

length of times to complete activities.)
Constructing a Project Network (cont’d)
• Terminology
– Event: a point in time when an activity is started
or completed. It does not consume time.
– Burst Activity: an activity that has more than one
activity immediately following it (more than one
dependency arrow flowing from it). B
• Two Approaches
– Activity-on-Node (AON)
A C
• Uses a node to depict an activity.
– Activity-on-Arrow (AOA)
• Uses an arrow to depict an activity. D

6–32
 Basic Rules to Follow in Developing
Project Networks
1. Networks typically flow from left to right.
2. An activity cannot begin until all preceding connected
activities are complete.
3. Arrows indicate precedence and flow
and can cross over each other.
4. Each activity must have a unique identify number that is
greater than any of its predecessor activities.
5. Looping is not allowed.
6. Conditional statements are not allowed.
7. Use common start and stop nodes.

6–33
 Network Computation Process
• Forward Pass—Earliest Times
– How soon can the activity start? (early start—ES)
– How soon can the activity finish? (early finish—EF)
– How soon can the project finish? (expected time—ET)
• Backward Pass—Latest Times
– How late can the activity start? (late start—LS)
– How late can the activity finish? (late finish—LF)
– Which activities represent the critical path?
– How long can activity be delayed? (slack or float—SL)

6–34
 Forward Pass Computation
• Add activity times along each path in the
network (ES + Duration = EF).
• Carry the early finish (EF) to the next activity
where it becomes its early start (ES) unless…
• The next succeeding activity is a merge
activity, in which case the largest EF of all
preceding activities is selected.

6–35
 Backward Pass Computation
• Subtract activity times along each path in the
network (LF - Duration = LS).
• Carry the late start (LS) to the next activity
where it becomes its late finish (LF) unless
• The next succeeding activity is a burst
activity, in which case the smallest LF of all
preceding activities is selected.

6–36
 Determining Free Slack (or Float)
• Free Slack (or Float)
– Is the amount of time an activity can be delayed after the start
of a longer parallel activity or activities.
– Is how long an activity can exceed its early finish date without
affecting early start dates of any successor(s).
– Allows flexibility in scheduling scarce resources.
• Sensitivity
– The likelihood the original critical path(s) will change once the
project is initiated.
– The critical path is the network path(s) that has (have) the least
slack in common.

6–37
 Practical Considerations
• Network Logic Errors
• Activity Numbering
• Use of Computers to
Develop Networks
• Calendar Dates
• Multiple Starts and
Multiple Projects

6–38
 Extended Network Techniques
to Come Close to Reality
• Laddering
– Activities are broken into segments so the following
activity can begin sooner and not delay the work.
• Lags
– The minimum amount of time a dependent activity
must be delayed to begin or end.
• Lengthy activities are broken down to reduce the delay
in the start of successor activities.
• Lags can be used to constrain finish-to-start, start-to-start,
finish-to-finish, start-to-finish, or combination relationships.

6–39
 PERT
1. Optimistic time: The length of the time required under
optimum conditions; represented by (to)
2. Pessimistic time: The length of the time required under
worst conditions; represented by (tp)
3. Most likely time: The most probable amount of time
required; represented by (tm)
 Formula
• Expected Time (ET) = to+4 tm + tp /6
• Variance of the activity times = (tp -to/6)^2
• Z transformation formula
D - TE
Z =
 cp
 2
 Example 2. CPM with Three Activity Time Estimates

Immediate
Task Predecesors Optimistic Most Likely Pessimistic
A None 3 6 15
B None 2 4 14
C A 6 12 30
D A 2 5 8
E C 5 11 17
F D 3 6 15
G B 3 9 27
H E,F 1 4 7
I G,H 4 19 28
 Expected Time Calculations

ET(A)= 3+4(6)+15
Immediate Expected 6
Task Predecesors Time
A None 7 ET(A)=42/6=7
B None 5.333
C A 14 Immediate
Task Predecesors Optimistic Most Likely Pessimistic
D A 5 A None 3 6 15
E C 11 B None 2 4 14
C A 6 12 30
F D 7 D A 2 5 8
E C 5 11 17
G B 11 F D 3 6 15
H E,F 4 G B 3 9 27
H E,F 1 4 7
I G,H 18 I G,H 4 19 28

Opt. Time + 4(Most Likely Time) + Pess. Time

Expected Time =
6
 Network

Duration = 54 Days
C(14) E(11)

A(7) H(4)
D(5) F(7)

I(18)

B G(11)
(5.333)
Probability Exercise

What is the probability of finishing this project in

less than 53 days?

p(t < D)

D=53
t
TE = 54

D - TE
Z =
 cp
 2
 2 Pessim . - Optim . 2
A ctivity variance,  = ( )
6

Task Optimistic Most Likely Pessimistic Variance

A 3 6 15 4
B 2 4 14
C 6 12 30 16
D 2 5 8
E 5 11 17 4
F 3 6 15
G 3 9 27
H 1 4 7 1
I 4 19 28 16

(Sum the variance along the critical path.)

 = 41
 2
 p(t < D)

t
D=53 TE = 54

D - TE 53 - 54
Z = = = -.156
 cp
2 41

p(Z < -.156) = .438, or 43.8 % (NORMSDIST(-.156)

There is a 43.8% probability that this project will be completed in less than 53 weeks.
 Additional Probability Exercise

What is the probability that the project

duration will exceed 56 weeks?
 Additional Exercise Solution

p(t < D)

t
TE = 54
D=56

D - TE 56 - 54
Z = = = .312
 cp
 2 41

p(Z > .312) = .378, or 37.8 % (1-NORMSDIST(.312))

Adopte
d from
Larson,
Gray
and
Joshi
(2022)8
e
 Topics
• Budgeting
• Estimating project budgets
• Types of budgets
• Work element costing
• Learning curves
• Risk estimation
• Simulation Analysis

1-57
 Budgeting
• A plan for the costs of project resources
• A budget implies constraints
• Thus, it implies that managers will not get
everything they want or need

7-58
 Budgeting Continued
• The budget for an activity also implies
management support for that activity
• Higher the budget, relative to cost, higher the
managerial support
• The budget is also a control mechanism
– Many organizations have controls in place that
prohibit exceeding the budget
– Comparisons are against the budget

7-59
 Estimating Projects
• Estimating
– The process of forecasting or approximating the
time and cost of completing project deliverables.
– The task of balancing expectations of stakeholders
and need for control while the project is
implemented.

5–60
 Estimating Project Budgets
• On most projects
– Material + Labor + Equipment + Capital +
Overhead + Profits = Bid
• In other words
– Resources + Profits = Bid
• So we are left with the task of forecasting
resources

7-61
 Estimating Project Budgets Continued
• Like any forecast, this includes some
uncertainty
• There is uncertainty regarding usage and price
– Especially true for material and labor
• The more standardized the project and
components, the lower the uncertainty
• The more experienced the cost estimator, the
lower the uncertainty

7-62
 Rules of Thumb
• Some estimates are prepared by rules of
thumb
– Construction cost by square feet
– Printing cost by number of pages
– Lawn care cost by square feet of lawn
• These rules of thumb may be adjusted for
special conditions
• However, this is still easier than starting the
estimate from scratch

7-63
 Estimating Budgets is Difficult
• There may not be as much historical data or
none at all
• Even with similar projects, there may be
significant differences
• Many people have input to the budget

7-64
Estimating Budgets is Difficult Continued
• Multiple people have some control over the
budget
• There is more “flexibility” regarding the
estimates of inputs (material and labor)
• The accounting system may not be set up to
track project data
• Usage of labor and material is very lumpy
over time

7-65
Factors Influencing the Quality of Estimates

Planning Horizon

Other (Nonproject) Project

Factors Duration

Quality of
Organization Estimates People
Culture

Padding Project Structure

Estimates and Organization

5–66
Developing Work Package Estimates
Use people familiar
with
the tasks
Include a risk Use several people
assessment to make estimates

Preparing
Initial
Make no allowance Assume normal
for contingencies Estimates conditions

Assume tasks are Use consistent time

independent units

5–67
 Types of Budgeting
• Top-down (macro) estimates: analogy,
group consensus, or mathematical
relationships
• Bottom-up (micro) estimates: estimates of
elements
of the work breakdown structure
• Negotiated

7-68
 Top-Down Budgeting
• Top managers estimate/decide on the overall
budget for the project
• These trickle down through the organization
where the estimates are broken down into
greater detail at each lower level
• The process continues to the bottom level

7-69
 Advantages
• Overall project budgets can be set/controlled
very accurately
– A few elements may have significant error
• Management has more control over budgets
• Small tasks need not be identified individually

7-70
 Disadvantages
• More difficult to get buy in
• Leads to low level competition for larger
shares of budget

7-71
 Bottom-Up Budgeting
• Project is broken down into work packages
• Low level managers price out each work
package
• Overhead and profits are added to develop
the budget

7-72
 Advantages
• Greater buy in by low level managers
• More likely to catch unusual expenses

7-73
 Disadvantages
• People tend to overstate their budget
requirements
• Management tends to cut the budget

7-74
 Work Element Costing
• Labor rates include overhead and personal
time
• Direct costs usually do not include overhead
• General and administrative (G&A) charge

7-75
An Iterative Budgeting Process–Negotiation-in-
Action
• Most projects use some combination of top-
down and bottom-up budgeting
• Both are prepared and compared
• Any differences are negotiated

7-76
Category Budgeting Versus Program/Activity
Budgeting
• Organizations are used to budgeting (and
collecting data) by activity
• These activities correspond to “line items” in
the budget
– Examples include phone, utilities, direct labor,…
• Projects need to accumulate data and control
expenses differently
• This resulted in program budgeting

7-77
 Typical Monthly Budget

7-78
Table 7-1
 Project Budget by Task & Month

7-79
Table 7-2
 Improving The Process of Cost Estimation

• Inputs from a lot of areas are required to

estimate a project
• May have a professional cost estimator to do
the job
• Project manager will work closely with cost
estimator when planning a project
• We are primarily interested in estimating
direct costs
• Indirect costs are not a major concern

7-80
 Problems
• Even with careful planning, estimates are
wrong
• Most firms add 5-10 percent for contingencies

7-81
 Learning Curves
• Human performance usually improves when a
task is repeated
• This happens by a fixed percent each time the
production doubles
• Percentage is called the learning rate

7-82
 Learning Curve Calculations
r Tn = Time for nth unit
Tn  T1n
log rate  T1 = Time for first unit
r n = Number of units
log 2
r = log decimal
N
rate/log 2
Total time  T1  n r

n 1

7-83
 Learning Curve Theory and Numerical
• Learning is the process by which an individual acquires skill, knowledge and ability. When
a new product or process is started, the performance of the worker is not at its best. as
the experience is gained, the performance of the worker improves. the time taken per
unit reduces and thus his productivity goes up. This improvement in productivity of
workers is due to the learning effect. 
• Studies have shown that the number of labor hours required to produce the fourth plane
was about  80 percent of the amount of time spent on the second ; the eight planes took
only 80 percent of the 4th and 16th plane, 80 percent of the 8th and so on.
• If production doubles, the time per unit is 80 percent of the previous units. This is called
an 80 percent learning curve.
• Definition- "Learning curve is a mathematical relationship between the production time
per unit and the number of units produced"
Approaches to Learning Curve Problems
• 1. Arithmetic Analysis: IT is the simplest approach because it is based on the
fundamental concept that if the production of units is doubled, the labour hours per unit
decline by a constant factor.
 Learning Curve Numerical

• eg. if the learning rate is 80% for a particular operation and the first unit took 100 labour hours, the
required labour hours for 2nd, 4th, 8th units etc. will be 
• nth unit produced                                            1              2                                                      4                             
                  8 
• Labour hours for the nth unit                          100       80% of the 100=80 Labour hours   80% of the 80=
64 Labour hour  80% of the 64= 51.2
• Limitation: IT can be used for only a doubled number of units.
• Eg. 2 If you are making the first unit and taking 60 hours and learning curve ratio is 90% then 
•   2nd unit time is .............................
•   4th unit time is .............................
•   8th unit time is .............................
  16th unit time is .............................
 Learning Curve Numerical

• 2. Logarithmic analysis: We can compute the labour hours required for nth unit by formula
• Log y = Log k + S * Log n  Where S = [Log of Learning curve ratio/Log 2]

• y = time required to produce nth unit

• k = time required to produce 1st unit
• n = nth unit for which the time is to calculate
• Example: 
Suppose the time required to produce the 1st unit is 100 hours and the learning curve ratio is 80%. If
we want to calculate the time required for the 5th unit then Log y = Log k + S * Log n
• Log  y = Log 100 + (Log 0.80/ log 2) * Log 5
• Log  y = 2.000 + (1 bar.9031/0.3010) * 0.6990 [From log table)
1 bar.9031 = -1+0.9031 = -0.0969
1 bar .03091 = -1 + 0.3091= 
• Log  y = 2.000 + (-0.0969/0.3010) * 0.6990 
Log  y = 2.000 - 0.2250
Log  y =1.775
Y = A. L. 1.775  = 59.57 
 Learning Curve Numerical
• 3. Learning curve table: This provides us coefficients to calculate not only the labour hours for nth
unit but also the total labour hours for the total number of units.
Example: Suppose the learning curve ratio is 80% and we want to calculate time required for 5th
unit, then we refer to the table and find that at 80% for 5th unit, the coefficient is 0.596. If time
required for 1st unit is 100 hours then the time for 5th unit will be:
• Example: A capable worker took 50 minutes to do the job the first time and 45 minutes the second
time. estimate the learning percentage
• Example:
A manufacturer has committed to supply 10 units of a particular product. The first unit took 100
hours to produce. The manufacturer wants to know 
(a) Time to make the 10th unit  
• (b) Time to make all the 10 units
• (c) Total labour cost if the total labour rate is Rs. 10/hour
• (d) profit earned if the total material cost is Rs. 4000 and the total overhead is Rs. 700. The price per
unit is Rs. 1500.
• Sales cost = 10*1500 = 15000
• Material cost = (4000)
• overhead cost = (700)
• Labour cost = (6317)
• 15000-11017  = 3983
• P = TR - TC
• Use an 80% learning curve to answer each of the questions. (unit values of learning curve for unit = 1
to 10 is 1.00, 0.80, 0.702, 0.64, 0.596, 0.562, 0.535, 0.512, 0.493, 0.477 respectively)
 Learning Curve Numerical

• Another way to calculate Tn value

• Tn=T1nb

• where, n = the unit number (1 for the first unit, 2 for the second unit, etc.)
• T1 = the amount of time to produce the first unit
• Tn = the amount of time to produce unit n
• b = the learning curve factor, calculated as In (p)/ln(2), where ln(x) is the natural
logarithm of x
• p = the learning percentage
• The learning percentage p is interpreted as follows:
• Every time the cumulative production quantity doubles, the unit production rate
will decrease by the percentage p.
 Learning Curve Numerical
• Example: 
• Imagine that we have T1 = 10 hours and p = 90% = 0.90. We can calculate the
production time for the first 10 units as
 Other Factors
• Escalation
• Waste
• Bad Luck

7-90
 Making Better Estimates
• Projects are known for being over budget
– It is unlikely that this is due to deliberate
underestimating
• There are two types of errors
– Random
– Bias
• There is nothing we can do about random
errors
– Tend to cancel each other
• Eliminate systematic errors

7-91
 Risk Estimation
• Duration of project activities varies
• Amounts of various resources needed varies
• Value of accomplishing a project varies
• Can reduce but not eliminate ambiguity
• Want to describe uncertainties in a way that
provides useful insight to their nature

7-92
 Applying Risk Analysis
• Must make assumptions about probability
distributions
– Key parameters
– Variables
• Estimate the risk profiles of the outcomes of
the decision
– Also know as probability distributions
• Simulation is often used

7-93
Project Time-Cost Relationships/ Project
Crashing
9–95
Crashing Numerical

9–96
 Fast Tracking
• Fast tracking applied mostly to construction company but
technique can be used in many other type of project.
• It refers to overlapping the design and build phases of a project.
• Design is usually completed before construction starts,
overlapping the two activities will results in the shortening the
project duration.
• Beginning to build before design is completed might also,
however, result in an increased number of change order,
subsequent loss of productivity, increased cost and loss of time.
• Studies of construction projects revealed that there were more
design changes in fast-tracked projects, the total number of
project change orders was not significantly different than in
similar projects that were not fast-tracked
Example
 Rationale for Reducing Project Duration
• Time Is Money: Cost-Time Tradeoffs
– Reducing the time of a critical activity usually incurs
additional direct costs.
• Cost-time solutions focus on reducing (crashing) activities on
the critical path to shorten overall duration of the project.
– Reasons for imposed project duration dates:
• Time-to-market pressures
• Unforeseen delays
• Incentive contracts (bonuses for early completion)
• Imposed deadlines and contract commitments
• Overhead and public goodwill costs
• Pressure to move resources to other projects

9–100
Options for Accelerating Project Completion
• Resources Not • Resources
Constrained Constrained
– Adding resources – Fast-tracking
– Outsourcing project – Critical-chain
work – Reducing project
– Scheduling overtime scope
– Establishing a core – Compromise quality
project team
– Do it twice—fast and
then correctly
9–101
 Explanation of Project Costs
• Project Indirect Costs
– Costs that cannot be associated with any particular
work package or project activity.
• Supervision, administration, consultants, and interest
– Costs that vary (increase) with time.
• Reducing project time directly reduces indirect costs.
• Project Direct Costs
– Normal costs that can be assigned directly to
a specific work package or project activity.
• Labor, materials, equipment, and subcontractors
– Crashing activities increases direct costs.
9–102
 Reducing Project Duration
to Reduce Project Cost
Identifying direct costs to reduce project time

Gather information about direct and indirect

costs of specific project durations.

Search critical activities for lowest direct-cost

activities to shorten project duration.

Compute total costs for specific durations and

compare to benefits of reducing project time.

9–103
Constructing a Project Cost–Duration Graph
• Find total direct costs for
selected project durations.
• Find total indirect costs for
selected project durations.
• Sum direct and indirect costs for
these selected project durations.
• Compare additional cost
alternatives for benefits.
9–104
 Constructing a Project Cost–Duration Graph
• Determining Activities to Shorten
– Shorten the activities with the smallest
increase in cost per unit of time.
– Assumptions:
• The cost relationship is linear.
• Normal time assumes low-cost, efficient
methods to complete the activity.
• Crash time represents a limit—the greatest time
reduction possible under realistic conditions.
• Slope represents a constant cost per unit of time.
• All accelerations must occur within the normal
and crash times.
9–105
 Practical Considerations
• Using the Project Cost–Duration Graph
• Crash Times
• Linearity Assumption
• Choice of Activities to Crash Revisited
• Time Reduction Decisions and Sensitivity

9–106
 What if Cost, Not Time Is the Issue?

• Commonly Used Options for Cutting Costs

– Reducing project scope
– Having owner take on more responsibility
– Outsourcing project activities or even the entire
project
– Brainstorming cost savings options

9–107
 Using the Resource Schedule to Develop
a Project Cost Baseline
• Why a Time-Phased Budget Baseline Is Needed
– To determine if the project is on, ahead, or behind schedule
and over or under its budgeted costs?
– To know how much work has been accomplished for the
allocated money spent—the project cost baseline (planned
value, PV)
• Creating a Time-Phased Budget
– Assign each work package to one responsible person or
department and deliverable.
– Compare planned schedule and costs using an integrative
system called earned value.
Priority Rules for Sequencing Activities/Tasks
 Topics
• Project scheduling
• Resource allocation
• Workload
• Resource loading
• Resource levelling

1-110
 Types of Project Constraints
• Technical or Logic Constraints
– Constraints related to the networked sequence
in which project activities must occur.
• Physical Constraints
– Activities that cannot occur in parallel or are affected by contractual
or environmental conditions.
• Resource Constraints
– The absence, shortage, or unique interrelationship and interaction
characteristics of resources that require a particular sequencing of
project activities
– Types of Resource Constraints
• People,
• materials,
• equipment

8–111
Constraint Examples

FIGURE 8.1
A Third Constraint: Physical
Types of Resource Constraints
• People
• Materials
• Equipment
• Working Capital
 The Resource Allocation Problem
• CPM/PERT ignore resource utilization and
availability
• With external resources, this may not be a
problem
• It is, however, a concern with internal
resources
• Schedules need to be evaluated in terms of
both time and resources

8-115
 Time Use and Resource Use
• Time limited: A project must be finished by a
certain time
• Resource limited: A project must be finished
without exceeding some specific level of
resource usage
• System-constrained: A project has fixed
amount of time and resources

8-116
 Resource Loading
• Resource loading describes the amount of
resources an existing schedule requires
• Gives an understanding of the demands a
project will make of a firm’s resources

8-117
 Resource A

8-118
Figure 9-6a
 Resource B

8-119
Figure 9-6b
 Resource Leveling
• Less hands-on management is required
• May be able to use just-in-time inventory
• Improves morale
• Fewer personnel problems
• When an activity has slack, we can move that
activity to shift its resource usage

8-120
 Resource Leveling Continued
• May also be possible to alter the sequence of
activities to levelize resources
• Small projects can be levelized by hand
• Software can levelize resources for larger
projects
• Large projects with multiple resources are
complex to levelize

8-121
Constrained Resource Scheduling

Heuristic An approach, such as a

Approach rule of thumb, that yields
a good solution that may
or may not be optimal

Optimization An approach, such as

Approach linear programming, that
yields the one best
solution.
8-122
 Heuristic Methods
• They are the only feasible methods used to
attack large projects
• While not optimal, the schedules are very
good
• Take the CPM/PERT schedule as a baseline

8-123
 Heuristic Methods Continued
• They sequentially step through the schedule
trying to move resource requirements around
to levelize them
• Resources are moved around based on one or
more priority rules

8-124
 Common Priority Rules
• As soon as possible
• As late as possible
• Shortest task first
• Most resources first
• Minimum slack first
• Most critical followers
• Most successors
• Arbitrary

8-125
 Heuristic Methods Continued
• These are just the common ones
• There are many more
• The heuristic can either start at the beginning
and work forwards
• Or it can start at the end and work backwards

8-126
 Optimization Methods
• Finds the one best solution
• Uses either linear programming or
enumeration
• Not all projects can be optimized

8-127
 The Resource Problem
• Resources and Priorities
– Project network times are a schedule
until resources have been assigned.
• The implicit assumption is that resources will be
available in the required amounts when needed.
• Adding new projects requires making realistic
judgments of resource availability and project
durations.
– Cost estimates are not a budget
until they have been time-phased.

8–128
 The Resource Problem (cont’d)
• Resource Smoothing (or Leveling)
– Involves attempting to even out varying demands
on resources by using slack (delaying noncritical
activities) to manage resource utilization when
resources are adequate over the life of the project.
• Resource-Constrained Scheduling
– The duration of a project may be increased by
delaying the late start of some of its activities if
resources are not adequate to meet peak demands.

8–129
 Classification of the Scheduling Problem
• Time-Constrained Project
– Must be completed by an imposed date.
• Time is fixed, resources are flexible: additional
resources are required to ensure project meets
schedule.
• Resource-Constrained Project
– Is one in which the level of resources available
cannot be exceeded.
• Resources are fixed, time is flexible: inadequate
resources
will delay the project.

8–130
 Resource Allocation Assumptions
• Limiting Assumptions
– Splitting activities is not allowed
• once an activity is start, it is carried to completion.
– Level of resources used for an activity cannot be
changed.
• Risk Assumptions
– Activities with the most slack pose the least risk.
– Reduction of flexibility does not increase risk.
– The nature of an activity (easy, complex) doesn’t
increase risk.

8–131
 Resource Allocation Methods (cont’d)
• Time-Constrained Projects
– Must be completed by an imposed date.
– Require use of leveling techniques that focus
on balancing or smoothing resource demands.
– Use positive slack (delaying noncritical activities)
to manage resource utilization over the duration
of the project.
• Peak resource demands are reduced.
• Resources over the life of the project are reduced.
• Fluctuation in resource demand is minimized.

8–132
Botanical Garden

FIGURE 8.2
Botanical Garden (cont’d)

FIGURE 8.2 (cont’d)

 Resource Allocation Methods (cont’d)
• Resource Demand Leveling Techniques
for Time-Constrained Projects
– Advantages
• Peak resource demands are reduced.
• Resources over the life of the project are reduced.
• Fluctuation in resource demand is minimized.
– Disadvantages
• Loss of flexibility that occurs from reducing slack.
• Increases in the criticality of all activities.

8–135
 Resource Allocation Methods (cont’d)
• Resource-Constrained Projects
– Resources are limited in quantity or availability.
– Activities are scheduled using heuristics
(rules-of-thumb) that focus on:
1. Minimum slack
2. Smallest (least) duration
3. Lowest activity identification number
– The parallel method is used to apply heuristics
• An iterative process starting at the first time period
of the project and scheduling period-by-period the start
of any activities using the three priority rules.

8–136
Resource-Constrained Schedule through
Period 2–3

FIGURE 8.3
Resource-Constrained Schedule through
Period 2–3
ES resource load chart

FIGURE 8.3 (cont’d)

Resource-Constrained Schedule through
Period 2–3
Resource-constrained schedule through period 2–3

FIGURE 8.3 (cont’d)

Resource-Constrained Schedule through
Period 5–6
Resource-constrained schedule through period 5–6

FIGURE 8.4
Resource-Constrained Schedule through
Period 5–6
Final resource-constrained schedule

FIGURE 8.4 (cont’d)

Resource-Constrained Schedule through
Period 5–6

FIGURE 8.4 (cont’d)

New, resource-constrained network
Resource Loading and Levelling Numerical
• There are 21 engineer in a group for a large company nominally scheduled
to work 40 hours a week for 34 weeks from February to September. There
is 3 national holiday [Memorial day, the fourth of July and Labor day] in
the 34 week period, 15 engineers will take a two week scheduled vacation
in this period. If the total labour hours for the company project is 28,282.
• Calculate the per week capacity or per week labor hours
• Is the capacity of the workforce (Engineers) less than or greater than the
scheduled
• demand?
• We expect there to be “unexpected” delays for multiple reasons, hence
the admonition to never schedule a resource for more than 80-90 percent
of its capacity. In reality, Engineer often work 50 to 60 hours per week for
extended periods, and if a prolonged period of insufficient work is
available at the company, management layoff some engineers. So what
will be the workweek.
 The Impacts of Resource-Constrained
Scheduling
• Reduces delay but reduces flexibility
• Increases sensitivity of the network
• Increases scheduling complexity
• May make traditional critical path no longer
meaningful
• Can break sequence of events
• May cause parallel activities to become sequential
and critical activities with slack to become noncritical
 Splitting/Multitasking
• Splitting/Multitasking
– A scheduling technique use to get a better project
schedule and/or increase resource utilization
• Involves interrupting work on an activity to employ the
resource on another activity, then returning the resource
to finish the interrupted work
• Is feasible when startup and shutdown costs are low
• Is considered the major reason why projects fail to meet
schedule
Splitting/Multitasking

FIGURE 8.10
 Assigning Project Work
• Factors to Consider in Assigning Work:
– Don’t always pick the same people for the toughest
assignments.
– Choose people with an eye to fostering their
development through participation on the project.
– Pick people with compatible work habits and
personalities but who complement each other.
– Team-up veterans with new hires to share experience
and socialize newcomers into the organization.
– Select people who may need to learn work together on
later stages of the project or other projects.
 Multiproject Resource Schedules
• Multiproject Scheduling Problems
– Overall project slippage
• Delay on one project creates delays for other projects.
– Inefficient resource application
• The peaks and valleys of resource demands create
scheduling problems and delays for projects.
– Resource bottlenecks
• Shortages of critical resources required for multiple projects
cause delays and schedule extensions.
 Multiproject Resource Schedules
• Managing Multiproject Scheduling
– Create project offices or departments to oversee the
scheduling of resources across projects.
– Use a project priority queuing system: first come, first
served for resources.
– Centralize project management: treat all projects as a
part of a “megaproject.”
– Outsource projects to reduce the number of projects
handled internally.
Creating a Time-Phased Budget
Creating a Time-Phased Budget (cont’d)
Creating a Time-Phased Budget (cont’d)
Creating a Time-Phased Budget (cont’d)
Creating a Time-Phased Budget (cont’d)
Monthly Cash Flow Statement
Resource Usage Table
 Risk Management Process
• Risk
– Uncertain or chance events that planning can not overcome or
control.
• Risk Management
– A proactive attempt to recognize and manage internal events
and external threats that affect the likelihood of a project’s
success.
• What can go wrong (risk event).
• How to minimize the risk event’s impact (consequences).
• What can be done before an event occurs (anticipation).
• What to do when an event occurs (contingency plans).

7–157
 Project Risk Management

• What is risk?
Risk: An uncertain event or condition that, if it occurs, has a positive
or negative effect on a project’s objectives

VENTURE OUTCOME
(Project) (Products)

FAVORABLE
UNKNOWNS (Opportunity)
(Uncertainty)
UNFAVORABLE
(Risks)

158
 Risk Management’s Benefits
• A proactive rather than reactive approach.
• Reduces surprises and negative consequences.
• Prepares the project manager to take advantage
of appropriate risks.
• Provides better control over the future.
• Improves chances of reaching project performance
objectives within budget and on time.

7–159
 Managing Risk
• Step 1: Risk Identification
– Generate a list of possible risks through
brainstorming, problem identification and risk
profiling.
• Macro risks first, then specific events

7–160
 Project Risk Management
Risk Identification

• Risk identification is performed throughout the life of the

project

• The process for identifying risk

– Understand the project

– Identify the risk event

– Document the results and take appropriate actions

161
 Project Risk Management
Risk Identification

• Types of risk
– Technical
– External
– Organizational
– Project Management
Note: These are example types of risk and this list can be modified to
meet the needs of your project

• Developing a project RBS (Risk Breakdown Structure) is an

excellent tool to help identify risks
162
 Project Risk Management
Risk Identification

PROJECT
RBS

PROJECT
TECHNICAL EXTERNAL ORGANIZATIONAL
MANAGEMENT

SUBCONTRACTORS PROJECT
REQUIREMENTS ESTIMATING
& SUPPLIERS DEPENDENCIES

TECHNOLOGY REGULATORY RESOURCES PLANNING

COMPLEXITY &
MARKET FUNDING CONTROLLING
INTERFACES

PERFORMANCES
& RELIABILITY CUSTOMER PRIORITIZATION COMMUNICATIONS

The Risk Breakdown Structure (RBS) lists

QUALITY WEATHER categories and sub-categories for project risk. The

163
actual categories will vary across different types of
projects.
 Project Risk Management
Risk Identification

• In your risk identification meeting

– Validate RBS with core team

– Identify risks by source (RBS)

– Identify risks by level of uncertainty:

Known Known / Unknown Unknown / Unknown

Situation with no Situation with an Situation whose
uncertainty identifiable uncertainty existence we cannot
imagine

164
• Step 2: Risk Assessment
– Scenario analysis for event probability and impact
– Risk assessment matrix
– Failure Mode and Effects Analysis (FMEA)
– Probability analysis
• Decision trees, NPV, and PERT
– Semiquantitative scenario analysis
 Managing Risk (cont’d)
• Step 3: Risk Response Development
– Mitigating Risk
• Reducing the likelihood an adverse event will occur.
• Reducing impact of adverse event.
– Avoiding Risk
• Changing the project plan to eliminate the risk or condition.
– Transferring Risk
• Paying a premium to pass the risk to another party.
• Requiring Build-Own-Operate-Transfer (BOOT) provisions.
– Retaining Risk
• Making a conscious decision to accept the risk.

7–166
 Contingency Planning
• Contingency Plan
– An alternative plan that will be used if a possible
foreseen risk event actually occurs.
– A plan of actions that will reduce or mitigate the
negative impact (consequences) of a risk event.
• Risks of Not Having a Contingency Plan
– Having no plan may slow managerial response.
– Decisions made under pressure can be potentially
dangerous and costly.
7–167
 Risk and Contingency Planning
• Technical Risks
– Backup strategies if chosen technology fails.
– Assessing whether technical uncertainties
can be resolved.
• Schedule Risks
– Use of slack increases the risk of a late project finish.
– Imposed duration dates (absolute project finish date)
– Compression of project schedules due to a shortened
project duration date.

7–168
Risk and Contingency Planning (cont’d)
• Costs Risks
– Time/cost dependency links: costs increase when
problems take longer to solve than expected.
– Price protection risks (a rise in input costs) increase
if the duration of a project is increased.
• Funding Risks
– Changes in the supply of funds for the project can
dramatically affect the likelihood of implementation
or successful completion of a project.

7–169
 Opportunity Management Tactics
• Exploit
– Seeking to eliminate the uncertainty associated with an opportunity to
ensure that it definitely happens.
• Share
– Allocating some or all of the ownership of an opportunity to another
party who is best able to capture the opportunity for the benefit of the
project.
• Enhance
– Taking action to increase the probability and/or the positive impact of an
opportunity.
• Accept
– Being willing to take advantage of an opportunity if it occurs, but not
taking action to pursue it.

7–170
 Contingency Funding and Time Buffers
• Contingency Funds
– Funds to cover project risks—identified and unknown.
• Size of funds reflects overall risk of a project
– Budget reserves
• Are linked to the identified risks of specific work packages.
– Management reserves
• Are large funds to be used to cover major unforeseen risks (e.g., change
in project scope) of the total project.
• Time Buffers
– Amounts of time used to compensate for unplanned delays in
the project schedule.
• Severe risk, merge, noncritical, and scarce resource activities

7–171
 Managing Risk (cont’d)
• Step 4: Risk Response Control
– Risk control
• Execution of the risk response strategy
• Monitoring of triggering events
• Initiating contingency plans
• Watching for new risks
– Establishing a Change Management System
• Monitoring, tracking, and reporting risk
• Fostering an open organization environment
• Repeating risk identification/assessment exercises
• Assigning and documenting responsibility for managing risk

7–172
 Topics
• FMEA – Risk priority number
• Decision Tree Analysis for risk management
• Monitoring and control

1-173
 Project Risk Management

FMEA (Failure Mode Effect Analysis)

174
 FMEA
• To understand the use of Failure Modes Effect
Analysis (FMEA)
• To learn the steps to developing FMEAs
• To summarize the different types of FMEAs
• To learn how to link the FMEA to other Process tools

175
 Benefits
• Allows us to identify areas of our process that
most impact our customers
• Helps us identify how our process is most
likely to fail
• Points to process failures that are most
difficult to detect

176
 Application Examples
• Manufacturing: A manager is responsible for moving a
manufacturing operation to a new facility. He/she wants to be
sure the move goes as smoothly as possible and that there
are no surprises.
• Design: A design engineer wants to think of all the possible
ways a product being designed could fail so that robustness
can be built into the product.
• Software: A software engineer wants to think of possible
problems a software product could fail when scaled up to
large databases. This is a core issue for the Internet.

177
 What Can Go
Wrong?

What Is A Failure Mode?

• A Failure Mode is:
– The way in which the component, subassembly,
product, input, or process could fail to perform its
intended function
• Failure modes may be the result of upstream
operations or may cause downstream operations to fail
– Things that could go wrong

178
 FMEA
• Why
– Methodology that facilitates process improvement
– Identifies and eliminates concerns early in the
development of a process or design
– Improve internal and external customer satisfaction
– Focuses on prevention
– FMEA may be a customer requirement (likely
contractual)
– FMEA may be required by an applicable
Quality Management System Standard (possibly ISO)
179
 FMEA
• A structured approach to:
– Identifying the ways in which a product or process
can fail
– Estimating risk associated with specific causes
– Prioritizing the actions that should be taken to
reduce risk
– Evaluating design validation plan (design FMEA) or
current control plan (process FMEA)

180
 When to Conduct an FMEA
• Early in the process improvement investigation
• When new systems, products, and processes are
being designed
• When existing designs or processes are being
changed
• When carry-over designs are used in new applications
• After system, product, or process functions are
defined, but before specific hardware is selected or
released to manufacturing

181
 Specialized
Uses

Types of FMEAs
• Design
– Analyzes product design before release to
production, with a focus on product function
– Analyzes systems and subsystems in early
concept and design stages
• Process
– Used to analyze manufacturing and assembly
processes after they are implemented

182
 Team Input
Required

FMEA: A Team Tool

• A team approach is necessary.
• Team should be led by the Process Owner who is the
responsible manufacturing engineer or technical person,
or other similar individual familiar with FMEA.
• The following should be considered for team members:
– Design Engineers – Operators
– Process Engineers – Reliability
– Materials Suppliers – Suppliers
– Customers

183
 Process Steps

FMEA Procedure
1. For each process input (start with high value inputs),
determine the ways in which the input can go wrong (failure
mode)
2. For each failure mode, determine effects
– Select a severity level for each effect

3. Identify potential causes of each failure mode

– Select an occurrence level for each cause

4. List current controls for each cause

– Select a detection level for each cause

184
 Process Steps

FMEA Procedure (Cont.)

5. Calculate the Risk Priority Number (RPN)
6. Develop recommended actions, assign responsible persons,
and take actions
– Give priority to high RPNs
– MUST look at severities rated a 10

7. Assign the predicted severity, occurrence, and detection levels

and compare RPNs

185
 Information
Flow

FMEA Inputs and Outputs

Inputs Outputs

C&E Matrix List of

Process actions to
FMEA
Map prevent
Process causes or
History detect
186 Procedure failure
 Analyzing

Severity, Occurrence,
Failure &
Effects

and Detection
• Severity
– Importance of the effect on customer requirements
• Occurrence
– Frequency with which a given cause occurs and
creates failure modes (obtain from past data if possible)
• Detection
– The ability of the current control scheme to detect
(then prevent) a given cause (may be difficult to
estimate early in process operations).

187
 Assigning
Rating

Rating Scales
Weights

• There are a wide variety of scoring “anchors”, both

quantitative or qualitative
• Two types of scales are 1-5 or 1-10
• The 1-5 scale makes it easier for the teams to decide
on scores
• The 1-10 scale may allow for better precision in
estimates and a wide variation in scores (most
common)

188
 Assigning
Rating

Rating Scales
Weights

• Severity
– 1 = Not Severe, 10 = Very Severe
• Occurrence
– 1 = Not Likely, 10 = Very Likely
• Detection
– 1 = Easy to Detect, 10 = Not easy to Detect

189
 Calculating a
Composite

Risk Priority Number (RPN)

Score

RPN is the product of the severity, occurrence, and detection

scores.

SeverityX Occurrence
X Detection
= RPN

190
Decision tree analysis in project management

Steps
To use Decision Tree Analysis in Project Risk Management, you
need to:
• Document a decision in a decision tree.
• Assign a probability of occurrence for the risk pertaining to
that decision.
• Assign monetary value of the impact of the risk when it
occurs.
• Compute the Expected Monetary Value for each decision
path.

1-191
 Terms
• Monitoring - Collecting, recording, and
reporting information concerning any and all
aspects of project performance
• Controlling - Uses the data supplied by
monitoring to bring actual performance into
compliance with the plan
• Evaluation - Judgments regarding the quality
and effectiveness of project performance

10-192
 The Planning–Monitoring–Controlling Cycle

• We mainly want to monitor:

– Time (schedule)
– Cost (budget)
– Scope (project performance)
• Closed-loop system
– Revised plans and schedules following corrective
actions

10-193
 Project Authorization and Expenditure Control
System Information Flow

10-194
Figure 10-1
 Designing the Monitoring System
• Identify key factors to be controlled
– Scope
– Cost
– Time
• Information to be collected must be
identified

10-195
 Designing the Monitoring System
Continued

• Do not want to avoid collecting necessary data

because it is hard to get
• Do not want to collect too much data
• The next step is to design a reporting system
that gets the data to the proper people in a
timely and understandable manner

10-196
 Data Collection
• Once we know the data we want, we need to
decide how to collect it
• Should the data be collected after some
event?
• Should it be collected on a regular basis?
• Are there any special forms needed for data
collection?

10-197
 Much Data Involves
• Frequency counts
• Raw numbers
• Subjective numeric ratings
• Indicators
• Verbal measures

10-198
 Information Needs and Reporting
• Everyone should be tied into the reporting
system
• Reports should address each level
• Not at same depth and frequency for every
level
– Lower-level needs detailed information
– Senior management levels need overview reports
• Report frequency is typically high at low levels
and less frequent at higher levels

10-199
 The Reporting Process
• Reports must contain relevant data
• Must be issued frequently
• Should be available in time for control
• Distribution of project reports depends on
interest
– For senior management, may be few milestones
– For project manager, there may be many critical
points

10-200
 Benefits of Detailed and Timely Reports

• Mutual understanding of the goals

• Awareness of the progress of parallel activities
• Understanding the relationship of tasks
• Early warning signals of problems
• Minimizing the confusion
• Higher visibility to top management
• Keeping client up to date

10-201
 Change Control System Process
1. Identify proposed changes.
2. List expected effects of proposed changes
on schedule and budget.
3. Review, evaluate, and approve or disapprove
of changes formally.
4. Negotiate and resolve conflicts of change, condition,
and cost.
5. Communicate changes to parties affected.
6. Assign responsibility for implementing change.
7. Adjust master schedule and budget.
8. Track all changes that are to be implemented

7–202
 Benefits of a Change Control System
1. Inconsequential changes are discouraged
by the formal process.
2. Costs of changes are maintained in a log.
3. Integrity of the WBS and performance measures
is maintained.
4. Allocation and use of budget and management reserve
funds are tracked.
5. Responsibility for implementation is clarified.
6. Effect of changes is visible to all parties involved.
7. Implementation of change is monitored.
8. Scope changes will be quickly reflected in baseline and
performance measures.
7–203
Earned Value Analysis
 Practical

Question:1- 
Assume that operations on a work package were expected to cost $1500 to complete
the package. They were originally scheduled to have been finished today. At this point,
however, we have actually expended $1350, and we estimate that we have completed
two-thirds of the work. What are the cost, schedule variances, cost performance index,
and schedule performance index? Also, calculate Cost-Schedule Index.
Question 2- One can continue the analysis to forecast the future of this work unit
under the condition when no measures are taken to correct matters. The cost to
complete the work unit can be estimated as the budget cost of the entire unit, less the
EV date, adjusted by the CPI to reflect the actual level of performance. 
BAC [Budget at Completion] is given $1500.
• The Earned Value to date (EV) = 1500*2/3 = $1000
• The Estimated cost to complete (ETC), assuming the same cost efficiency level, can be
projected as
• ETC = (BAC - EV)/CPI
• ETC = (1500 - 1000)/0.74 = $676
• EAC = ETC + AC
• EAC = $676+1350  = $2026
 Structure of a Project Monitoring
Information System
• Creating a project monitoring system
involves determining:
– What data to collect
– How, when, and who will collect the data
– How to analyze the data
– How to report current progress to
management

13–208
Project Monitoring Information System
• Information System Structure
– What data are collected?
• Current status of project (schedule and cost)
• Remaining cost to compete project
• Date that project will be complete
• Potential problems to be addressed now
• Out-of-control activities requiring intervention
• Cost and/or schedule overruns and the reasons for them
• Forecast of overruns at time of project completion

13–209
 Project Monitoring System… (cont’d)
• Information System Structure (cont’d)
– Collecting data and analysis
• Who will collect project data?
• How will data be collected?
• When will the data be collected?
• Who will compile and analyze the data?
– Reports and reporting
• Who will receive the reports?
• How will the reports be transmitted?
• When will the reports be distributed?

13–210
 The Project Control Process
• Control
– The process of comparing actual performance against plan to identify
deviations, evaluate courses of action, and take appropriate corrective
action.
• Project Control Steps
1. Setting a baseline plan.
2. Measuring progress and performance.
3. Comparing plan against actual.
4. Taking action.
• Tools
– Tracking and baseline Gantt charts
– Control charts

13–211
 Development of an Earned Value
Cost/Schedule System
• Time-Phase Baseline Plan
– Corrects the failure of most monitoring systems to connect a
project’s actual performance to its schedule and forecast
budget.
• Systems that measure only cost variances do not identify resource
and project cost problems associated with falling behind or
progressing ahead of schedule.
• Earned Value Cost/Schedule System
– An integrated project management system based on the
earned value concept that uses a time-phased budget
baseline to compare actual and planned schedule and costs.

13–212
 Earned Value Analysis

• Have covered monitoring parts

– Timing and coordination between individual tasks
is important
• Must also monitor performance of entire
project
– Crux of matter should not be overlooked
• One way is by using an aggregate performance
measure called earned value

10-214
 The Earned Value Chart and Calculations

• Actual against baseline ignores the amount of

work accomplished
• Earned value incorporates work accomplished
• Multiply the estimated percent work complete
for each task by the planned cost
• Only need percent complete estimate for tasks
currently in progress

10-215
 Rules to Aid in Estimating Percent Completion

• 50-50 rule
• 0-100 percent rule
• Critical input use rule
• Proportionality rule

10-216
 The Earned Value Chart

10-217
Figure 10-6
 Variances
• Variances can help analyze a project
1. A negative variance is bad
2. Cost and schedule variances are calculated as
the earned value minus some other measure
• Will look at some of the more common ones

10-218
 Cost Variance (CV)
• CV = EV – AC

• Negative variance indicates a cost overrun

• Magnitude depends on the costs

10-219
 Schedule Variance (SV)
• SV = EV – PV

• Negative variance indicates you are behind

schedule

• Measured using costs

10-220
 Time Variance (TV)
• TV = ST – AT

• Negative variance indicates you are behind

schedule

10-221
 Indices
• Cost Performance Index
CPI = EV/AC
• Schedule Performance Index
SPI = EV/PV
• Time Performance Index
TPI = ST/AT
• Cost Schedule Index
CSI = EV2/(AC)(PV)

10-222
“To complete” and “At Completion”
• Project manager reviewing what is complete
and what remains
• Final cost and final completion date are
moving targets
• The project manager compiles these into a to
complete forecast
• Actual + forecast = final date and cost at
completion

10-223
 ETC and EAC

ETC = (BAC + EV)/CPI

EAC = ETC + AC
where,
ETC = Estimated cost to complete
BAC = Budget at completion
EV = Earned value
CPI = Cost performance index
EAC = Estimated cost at completion
AC = Amount expended to date (actual cost)

10-224
 Milestone Reporting
• Reports that are created when a project
reaches a major milestone
• They are designed to keep everyone up-to-
date on project status
• For executives and clients, these may be the
only reports they receive

10-225
 Computerized PMIS (Project Management
Information Systems)
• Real projects are often large
– Hundreds of tasks
– Thousands of work units
• Reporting is clearly a job for the computer
• Project management information systems were
one of the earlier applications
• Initially focus was on scheduling
• Now it includes, earned values, variances, and
more
10-226
 PMIS Errors
• Managing the PMIS
• Computer paralysis
• PMIS verification
• Information overload
• Project isolation
• Computer dependence
• PMIS misdirection

10-227
 PMIS Desirable Attributes
• Graphics
Friendliness
• Schedules
Charts
• Calendars
Migration
• Budgets
Consolidation
• Reports
Access

10-228
Development of Project Baselines
• Purposes of a Baseline (PV)
– An anchor point for measuring performance
• A planned cost and expected schedule against
which actual cost and schedule are measured.
• A basis for cash flows and awarding progress payments.
• A summation of time-phased budgets (cost accounts as
summed work packages) along a project timeline.
• What Costs Are Included in Baselines?
– Labor, equipment, materials, project direct
overhead costs (DOC)

13–229
 Methods of Variance Analysis
• Comparing Earned Value
– With the expected schedule value.
– With the actual costs.
• Assessing Status of a Project
– Required data elements
• Data Budgeted cost of the work scheduled (PV)
• Budgeted cost of the work completed (EV)
• Actual cost of the work completed (AC)
– Calculate schedule and cost variances
• A positive variance indicates a desirable condition,
while a negative variance suggests problems or
changes that have taken place.

13–230
 Methods of Variance Analysis
• Cost Variance (CV)
– Indicates if the work accomplished using labor
and materials costs more or less than was
planned at any point in the project.
• Schedule Variance (SV)
– Presents an overall assessment in dollar terms
of the progress of all work packages in the
project scheduled to date.

13–231
 Indexes to Monitor Progress
• Performance Indexes
– Cost Performance Index (CPI)
• Measures the cost efficiency of work accomplished to date.
• CPI = EV/AC
– Scheduling Performance Index (SPI)
• Measures scheduling efficiency
• SPI = EV/PV
– Percent Complete Indexes
• Indicate how much of the work accomplished represents of the total
budgeted (BAC) and actual (AC) dollars to date.
• PCIB = EV/BAC
• PCIC = AC/EAC

13–232
 Forecasting Final Project Cost
• Methods used to revise estimates of future
project costs:
– EACre
• Allows experts in the field to change original baseline
durations and costs because new information tells them
the original estimates are not accurate.
– EACf
• Uses actual costs-to-date plus an efficiency index to
project final costs in large projects where the original
budget is unreliable.

13–233
 Forecasting Model: EACf
The equation for this forecasting model:

13–234
 Formula
• ETC = BAC/CPI - AC
• EAC = AC + BAC - EV
 Other Control Issues

Issues In Maintaining Control Of Projects

Scope Creep

Baseline Changes

Data Acquisition
Costs and Problems

13–236
 Topics
• Project reporting
• Project Evaluation
• Project termination

1-237
 Project Audit
• A formal review of any aspect of a project
• Audits focus on whatever matters senior
management desires
– Another type of audit is an ethics audit
• Evaluate means to set the value of or appraise
• Project evaluation appraises progress and
performance against standard

12-238
 Purpose of Evaluation—Goals of the System

• Efficiency in meeting both the budget and

the schedule
• Customer impact/satisfaction
• Business/direct success
• Future potential

12-239
 The Project Audit
• The main purpose of an audit is to help
achieve the goals of the project
• All facets of the project are studied
• A project audit is equivalent to the application
of TQM to project management

12-240
 Approach to Project Audit
• All facets of the project are studied
• The strengths and weaknesses are identified
• Recommendations are prepared to help
current and future projects

12-241
 Project Audit Recommendations
• Identify problems earlier
• Clarify scope, cost, and time relationships
• Improve performance
• Locate technological advances
• Evaluate quality
• Reduce costs
• Improve risk identification
• Many more…

12-242
 Direct and Ancillary Project Objectives

• Direct goals are stated project objectives

– Including customer satisfaction
• Direct goals ignore many costs and benefits to:
– The project
– Its team members
– The parent organization
• Unstated objectives are called ancillary goals

12-243
 Examples of Recommendations Concerning
Ancillary Goals
• Improve understanding the value of the
project
• Improve process for organizing and managing
projects
• Provide information for entering new markets
• Provide a congenial environment
• Identify organizational strengths and
weaknesses

12-244
 Examples of Recommendations Concerning
Ancillary Goals Continued
• Improve response to risk factors
• Allow access to policy decisions by external
stakeholders
• Improve the way projects contribute to the
professional growth
• Identify high potential personnel

12-245
 Ancillary Goals
• Identification of ancillary goals is difficult
• Finding them requires deductive reasoning
• Ancillary goals affect decisions made on
projects
• Ancillary goals add several additional
dimensions to project evaluation

12-246
 Problems With Indirect Goals
• Difficult to hold people accountable for
unstated goals
• Difficult to separate indirect goals from
personal goals
• Lack of trust
• Different ideas about the indirect goals

12-247
 The Project Audit
• Current status of the project
• Expected status of the project
• Status of critical tasks
• An assessment of potential risks
• What lessons can be applied to other
projects?
• What are the limitations of the audit?

12-248
 Depth of the Audit
• Time and money limit the depth of an audit
• Audits are distracting to those working on the
project
• A poor audit result will lower morale on the
project

12-249
 Types of Audits
• General Audit
• Detailed Audit
• Technical Audit

12-250
 Timing of the Audit
• All significant projects should be audited
• Larger projects may be audited several times
• An audit may also be conducted after the
project is over (post-project audits)

12-251
 Format and Use of the Audit Report

1. It should facilitate the comparison of actual

versus predicted results
2. Significant deviations should be highlighted
3. Reasons for significant deviations should be
given
4. Plans for resolving negative deviations
should be discussed

12-252
 Audit Information
1. Introduction
2. Current status
3. Future project status
4. Critical management issues
5. Risk management
6. Caveats, limitations, and assumptions

12-253
 Responsibilities of the Project Auditor

• Be honest and ethical

• Be independent
• Tell the whole truth
• Seek help for technical issues

12-254
 The Project Audit Life Cycle
• Project audit initiation
• Project baseline definition
• Establishing an audit database
• Preliminary analysis of the project
• Audit report preparation
• Project audit termination

12-255
 Some Essentials of an Audit/Evaluation

• Need to select an audit team with experience

and expertise
• Auditors need access to top management
• Auditors need access to project personnel and
others
• Auditors need access to all records

12-256
 Measurement
• Many aspects are easy to measure
• Performance against budget and schedule are
usually straightforward
• Measurement on projects that include a profit
component is more difficult

12-257
 Project Termination
• All projects end
– The objectives have been completed
– It no longer makes sense to finish
• Some teams move on to other projects
• Other times, members go their own way
• The client may be happy, mad, or anywhere in
between

13-258
 The Varieties of Project Termination

• Termination by extinction
• Termination by addition
• Termination by integration
• Termination by starvation

13-259
 Termination by Extinction
• Extinction occurs in any scenario where the
project goes away
– Successful
– Unsuccessful
– Changes in environment
– Take too long
– Murder
• When work on a project stops, some
organizational work continues

13-260
 Termination by Addition
• Applies to an in-house project
• When the project is successful, it is
institutionalized
• While the project goes away, project
personnel and assets are transferred to the
new business

13-261
 Termination by Integration
• The most common way to terminate a project
• The project comes into the business
– It is absorbed into the existing structure
• That structure absorbs the assets of the
project

13-262
 Aspects of the Transition from Project to
Integrated Operation
• Personnel
• Information systems
• Manufacturing
• Marketing
• Accounting/finance
• Purchasing
• Engineering
• Risk management

13-263
 Termination by Starvation
• Termination by starvation involves greatly
reducing the budget of a project
• Used when it is politically dangerous to cancel
a project
• Bad manners to enquire the status of the
project

13-264
 When to Terminate a Project
• Projects take on a life of their own
• It may be easy to terminate a project that is
finished
• But it can be very difficult to terminate a
project prior to its completion

13-265
 Critical Success Factors
• Technical
Project mission
tasks
• Top-management
Client acceptance support
• Project schedule/plan
Monitoring and feedback
• Client consolation
Communication
• Personnel
Trouble-shooting

13-266
 Fundamental Reasons Why Some Projects Fail

• A project organization is not required

• Insufficient support from senior
management
• Naming the wrong person as project
manager
• Poor planning

13-267
 Non-Technical Reasons for Termination

• Political
• Cross-cultural
• Senescence

13-268
 The Termination Process
1. Must first decide to terminate
2. If the decision is to terminate the project,
the decision must be carried out

13-269
 The Decision Process
• Sunk costs are not relevant to the decision
about terminating a project
• Primary concern for project continuance or
termination is whether or not the organization
is willing to invest the estimated time and cost
required to complete the project

13-270
 The Implementation Process
• Termination can be orderly or a “hatchet job”
• Planning for implementing an orderly shut
down yields better results
• Who leads the shut down project?
• A special termination manager may be used

13-271
 Things to Do
• Ensure tasks are completed
• Notify the client
• Finish the paperwork
• Send out final invoices to the client
• Redistribute resources
• Clear with legal counsel
• Determine what records to keep
• Assign support
• Close the project books

13-272
The Final Report—A Project History
• Project performance
• Administrative performance
• Organizational structure
• Project and administrative teams
• Techniques of project management

13-273
 Project Closure
• Close-out Plan:
• Types of Project Closure Questions to be Asked
– Normal – What tasks are required
– Premature to close the project?
– Perpetual – Who will be responsible
for these tasks?
– Failed Project
– When will closure begin
– Changed Priority and end?
– How will the project be
delivered?

14–274
Implementing Project Closedown
1. Getting delivery acceptance from the customer.
2. Shutting down resources and releasing them to
new uses.
3. Evaluating the team, team members and the
project manager; and reassigning project team
members.
4. Closing accounts and paying all bills.
5. Delivering the project to the customer.
6. Creating a final report.

14–275
 Creating the Final Report
• Executive Summary • Recommendations
– Project goals met/unmet – Technical improvements
– Stakeholder satisfaction – Corrective actions
with project • Lessons Learned
– User reactions to quality – Reminders
of deliverables
– Retrospectives
• Review and Analysis
• Appendix
– Project mission and objective
– Backup data
– Procedures and
– Critical information
systems used
– Organization resources
used

14–276
 Pre-Implementation Conditions: Team
1. Are standards and goals for measuring performance clear, challenging,
and attainable? Lead to positive consequences?
2. Are responsibilities and performance standards known
by all team members?
3. Are team rewards adequate? Management believes teams are important?
4. Is there a career path for successful project managers
5. Does the team have discretionary authority to manage
short-term difficulties?
6. Is there a high level of trust within the organization culture?
7. Are there criteria beyond time, cost, and specifications?

14–277
Project Performance Evaluation: Individual

• Performance Assessment Responsibilities:

– Functional organization or functional matrix: the
individual’s area manager.
• The area manager may solicit the project manager’s opinion
of the individual’s performance on a specific project.
– Balanced matrix: the project manager and the area
manager jointly evaluate an individual’s performance.
– Project matrix and project organizations: the project
manager is responsible for appraising individual
performance.

14–278
 Conducting Performance Reviews
• Begin by asking the individual to evaluate his or her own
performance.
• Avoid drawing comparisons with other team members; rather,
assess the individual in terms of established standards and
expectations.
• Focus criticism on specific behaviors rather than on the
individual personally.
• Be consistent and fair in treatment of all team members.
• Treat the review as one point in an ongoing process.

14–279
 Individual Performance Assessment
• Multiple rater appraisal (“360-degree
feedback)
– Involves soliciting feedback concerning team
members’ performance from all of the people
that their work affects.
• Project managers, area managers, peers,
subordinates, and customers.

14–280
 Retrospectives
• Lessons Learned
– An analysis carried out during and shortly after the
project life cycle to capture positive and negative
project learning—“what worked and what didn’t?”
• Goals of Retrospectives
– To reuse learned solutions
– To stop repetitive mistakes

14–281
 The Value of Retrospective Analyses
• Making Retrospectives Effective:
– Use an independent facilitator to guide the project team
through the analysis project activities.
– Include a minimum of three in-process learning gates during
the life project cycle.
– Designate a team member as owner for each point in the
retrospective.
– Develop an easy-to-use learning repository to ensure future
utilization of retrospective lessons.
– Mandate use of retrospectives as part of the normal process
for all projects.
14–282
 Characteristics of a Closure Facilitator
1. No direct involvement or direct interest in the project.
2. Perceived as impartial and fair
3. Respect of senior management and other project
stakeholders.
4. Willingness to listen.
5. Independence and authority to report audit results without
fear of recriminations from special interests.
6. Perceived as having the best interests of the organization in
making decisions.
7. Broad-based experience in the organization or industry.

14–283
Initiating the Retrospective Review
• Have automatic times or points when audits will
take place. Avoid surprises.
• Conduct audits carefully and with sensitivity.
• Audit staff must independent from the project.
• Audit reports need to be used and accessible.
• Audits support organizational culture.
• Project closures should be planned and orderly.
• Certain “core conditions” must be in place to support team
and individual evaluation.
• Conduct individual and team evaluations separate from
pay or merit reviews.

14–284
 Archiving Retrospectives
• Classifying of Projects:
– Project type
– Size
– Staffing
– Technology level
– Strategic or support
– Issues and problems
– Project mission and objectives
– Procedures and systems used
– Organization resources used
14–285