Project Organization and

Scheduling
Project Elements: Functions,
Activities and Tasks
Project Elements
 Functions

 Activity or set of activities that span the entire

duration of the project
 Examples:
• Project management
• Configuration Management
• Documentation
• Quality Control (Verification and
validation)
• Training
 Activities

 Major unit of work with precise dates

 Consist of smaller activities or tasks
 Culminate in project milestone.
• Internal checkpoint should not be
externally visible
• Scheduled event used to measure
progress
 Milestone often produces baseline
 Activities may be grouped into larger activities
 Example of Activities

 Major Activities:
• Planning
• Requirements Analysis
• System Design
• Object Design
• Implementation
• System Testing
• Delivery
 Activities during requirements analysis:
• Refine scenarios
• Define Use Case model
• Define object model
• Define dynamic model
• Design User Interface
 Tasks

 Smallest unit of management accountability

• Atomic unit of planning and tracking
• Finite duration, need resources, produce
tangible result (documents, code)
 Small enough for adequate planning and
tracking
 Examples of Tasks

 Unit test class “Foo”

 Test subsystem “Bla”
 Write user manual
 Write meeting minutes and post them
 Write a memo on NT vs Unix
 Schedule the code review
 Develop the project plan
 Related tasks are grouped into hierarchical
sets of functions and activities.
 Action item (A task assigned to a person that
has to be done within a week or less)
 Work Packages
 Generic term for discrete tasks with definable
end results
 Typically the “leaves” on the tree
 The “one-to-two” rule
• Often at: 1 or 2 persons for 1 or 2 weeks
 Basis for monitoring and reporting progress
 Ideally shorter rather than longer
 Work Breakdown Structure: WBS

 Hierarchical list of project’s work activities

 Represented in two formats
• Outline Format
• Graphical Tree (Organizational Chart) format
 Outline format uses a decimal numbering system
• Ex: 3.1.5
• 0 is typically the top level
• Includes Development, Mgmt., and project support
tasks
• Shows “is contained in” relationships
• Does not show dependencies or durations
 WBS

 Contract WBS (CWBS)

• First 2 or 3 levels
• High-level tracking
 Project WBS (PWBS)
• Defined by PM and team members
• Tasks tied to deliverables
• Lowest level tracking
 A Full WBS Structure
 Up to six levels (3-6 usually) such as

 Upper 3 can be used by customer for

reporting
 Different level can be applied to different uses
• Ex: Level 1: authorizations; 2: budgets; 3:
schedules
WBS Chart Example
 WBS Outline Example
0.0 Retail Web Site
1.0 Project Management
2.0 Requirements Gathering
3.0 Analysis & Design
4.0 Site Software Development
4.1 HTML Design and Creation
4.2 Backend Software
4.2.1 Database Implementation
4.2.2 Middleware Development
4.2.3 Security Subsystems
4.2.4 Catalog Engine
4.2.5 Transaction Processing
4.3 Graphics and Interface
4.4 Content Creation
5.0 Testing and Production
 WBS Types
 Process WBS
• Activity-oriented
• Ex: Requirements, Analysis, Design, Testing
• Typically used by PM

 Product WBS
• Entity-oriented
• Ex: Financial engine, Interface system, DB
• Typically used by engineering manager

 Hybrid WBS: both above

• This is not unusual
• Ex: Lifecycle phases at high level with component or
feature-specifics within phases
• Rationale: processes produce products
Product WBS
Process WBS
Less frequently used WBS Types
• Organizational WBS
• Research, Product Design, Engineering,
Operations
• Can be useful for highly cross-functional
projects
• Geographical WBS
• Can be useful with distributed teams
• NYC team, San Jose team, Off-shore
team
 WBS Techniques
 Top-Down
 Bottom-Up
 Analogy
 Rolling Wave
• 1st pass: go 1-3 levels deep
• Gather more requirements or data
• Add more details later
 WBS Techniques
 Top-down
• Start at highest level
• Systematically develop increasing level of
details
• Best if
• The problem is well understood
• Technology and methodology are not new
• This is similar to an earlier project or
problem
• But is also applied in majority of situations
 WBS Techniques
 Bottom-up
• Start at lowest level tasks
• Aggregate into summaries and higher
levels
• Cons
• Time consuming
• Needs more requirements complete
• Pros
• Detailed
 WBS Techniques

 Analogy
• Base WBS upon that of a “similar” project
• Use a template
• Analogy also can be estimation basis
• Pros
• Based on past actual experience
• Cons
• Needs comparable project
 WBS – Basis of Many Things

 Network scheduling
 Costing
 Risk analysis
 Organizational structure
 Control
 Measurement
 Project Life Cycle
 Projects are usually organized in phases
 Typically, organizations define (or adopt) their
own life cycles, namely
• The technical work to be done in each
phase
• The deliverables to be produced by each
phase.
• Who is involved
• The rules of transition from one phase to
the next
 Project Life Cycle

Idea
Inputs PM Team

Phases Initial Intermediate Final

Charter Plan Progress

Acceptance Handover
Outputs Scope
Statement
Baseline Approval

Product
 Project Life Cycle
Initial Phase Intermediate Phase Closing Phase

Cost and Staff

Influence of stakeholder
Cost of change
Project and Product Life Cycle

Upgrade

Business Plan Operations Divestment

Idea

Product

Phases Initial Intermedi Final

ate
 Process Groups

 If we take a slightly different point of view,

we can start organizing the activities
necessary to carry out a project in process
groups
 The organization is a variation of the plan-
do-act cycle
 Process Groups

Monitoring &
Controlling

Planning

Initiating Closing

Executing
 Process Groups
 Initiating: defines and authorizes the project
 Planning: defines and refines the project
objectives and plans the course of actions
 Executing: integrates people and resources
to carry out the project management plan
 Monitoring and controlling: measures and
monitors progress to identify variances
 Closing: formalizes acceptance of the
product, service, or results and brings the
project to an orderly end.
 Levels of Activity

Execute

Plan

Closing
Initiate
 Process Groups and Project
Boundaries

Monitoring & Deliverables End User

Controlling

Planning

Project Project
Initiator/Sponsor Inputs Initiating Closing

Project
Executing Process
Records Assets
 Ways to Organize Personnel

• Organizational Strategies
– Hierarchical Tree
– Informal Team
– Chief Programmer Teams
– Matrix Organization
– SWAT Team
• Issues
– As project size increases, more structuring is needed.
– Informal teams cope with high uncertainty better.
– Efficient communication is a key issue
– Software structure often mirrors organization structure.
 Hierarchical Organization

 A tree-like management structure with the real work being done at

the leaves (developers). Interior nodes are various levels of
management.
 The lowest level of managers control the work of one team.
Higher level managers coordinate the work of several teams.
 Different management styles used in different parts of the
hierarchy.
• Disadvantages
• Communication follows the tree structure unless specific
steps are taken to facilitate the communication.
• Specific knowledge tends to dissipate as it moves up the
tree.
• Decisions propagate downward in the tree, may be distorted
before they reach the leaves.
Functional/Hierarchical
 Hierarchical Structure (Remarks)

 Projects with high degree of certainty, stability,

uniformity and repetition.
• Requires little communication
• Role definitions are clear
 When?
• The more people on the project, the more
need for a formal structure
• Customer might insist that the test team be
independent from the design team
• Project manager insists on a previously
successful structure
 Remarks Contd…

 Operational decisions originate at the top of

the hierarchy and propagate downwards in
the tree.
 Sharp distinction of functions and rigid
structure
 Good for small firms, geographically
concentrated, with a small set of standard
products, mainly focused in operational work
 Organization of work in projects is clumsy
 Matrix Organization

 Identify people with particular skill sets. Assign people

to projects needing those particular skills.
 An individual may be simultaneously involved in
several projects reporting to different managers.
 Could also do this with small teams instead of
individuals.
 Manager is responsible for coordination and overall
direction.
 Works well if the sharing of people works well and
managers cooperate.
 Makes effective use of skilled personnel/teams.
 Disadvantages: working for multiple bosses is never
easy.
 Matrix Organization
QuickTime™ and a
None decompressor
are needed to see this picture.

General
Direction

Administration
Marketing Production Sales Personnel
and Finance

Project A

Project B

Project C

Project D
 Matrix Organization
General
Direction

PMO Marketing Production Administration Sales Personnel

and Finance

Project A

Project B

QuickTime™ and a
None decompressor
Project C are needed to see this picture.

Project D
 Matrix Organization (Remarks)
 Structural “accommodation” of projects
 May or may not contain a PMO (Project
Management Office) for sharing resources,
monitoring and control
 Multi bosses “syndrome”
 The point is where the decisions are taken:
• Weak matrix
• Balanced matrix
• Strong matrix
 Weak Matrix

 Responsibility mainly located in the

functional areas
 PM acts more as a facilitator (helps keeping
focus, monitor and control) and negotiator
 Useful in structures where products are
standardized but production is complex
 Facilitates an orientation of the organization
towards a project management culture
 Strong Matrix
 PM is responsible of:
• Planning operational activities (it “tells” functional areas
what has to be done.
• Coordinating people
• Monitoring and Controlling progress.
 Friction between PM and Functional Areas:
• PM focused on short term goals
• Functional area responsible inclined to think of the
lending personnel as a “favor”.
• Necessity of mediating requests of different projects
and project managers for the Functional Areas
 Good for complex products with standard production
cycles
 Balanced Matrix

 Something between Strong and Weak

 Need for a PM
 PM hasn’t got all the authority of a Strong
Matrix (usually embedded in a functional unit -
it may report to the person responsible of an
area)
 Chief Programmer Teams
 Clever organization of a programming team modeled
on a hospital surgical team.
 Goals: increase productivity of programmers and
quality of software
 The key ideas are
• Let each person concentrate on doing those tasks
that they can do best
• Librarian does all clerical tasks: program editing,
compilations, maintaining archives, running
canned tests, etc.
• Chief Programmer concentrates on technical
issues and not on the management
• Simplifies communication and reporting structure.
Chief Programmer Team Example
Egoless Programming Team
(Weinberg)
 Ego-less Programming

 Weinberg’s work has a major impact on the way

programmers are managed
 Programmers should be encouraged to suppress
their own interests (ego) for the good of the team
and the project
 All team members should feel equally responsible
for the success of the project
 Readers and writer - an early form of peer review
to encourage cooperation among team members
 Emphasis is on importance of setting correct
goals for the team
 Project-Based
General
Direction

Administration
and Finance Project 1 Project 2 Project 3

QuickTime™ and a
None decompressor
are needed to see this picture.
Project Based Project Organization
 Project-Based (Remarks)

 Project is central
 Disadvantages:
• Lack of specialization
• Continuity of work and reallocation of
people after the project ends
Divisional
 Remarks
 Strategy located in the Direction
 Responsibility and operational decisions are
taken by the Division
 Allows for specialization to specific
markets/sectors
 Profits and losses are shared
 Competition among divisions
 Divisions tend to operate on smaller term goals
 Duplication of functions may increase costs
 Projects within Division are relatively simple.
 Interdivisional projects more complex.
 Observations on Management
Structures
 Egoless structures don't work well
"Ownership" is important
 Hierarchical information flow does not work well with
iterative and incremental software development
process
Manager is not necessarily always right
 Project-based structures
• Cut down on bureaucracy reduces development
time
• Decisions are expected to be made at each level
• Hard to manage
 How to Organize a Team

 Use fewer better people.

 Try to fit the tasks to the capabilities and
motivations of the people available.
 Help people get the most out of themselves.
Encourage education, professional
development and advancement.
 Select people who work well together for the
same team. Well balanced and harmonious.
 Pro-actively deal with disruptive, dysfunctional
team members.
Factors Affecting Team Organization

 Difficulty of the problem to be solved

 Size of resulting program
 Team lifetime
 Degree to which problem can be
modularized
 Required quality and reliability of the system
to be built
 Rigidity of the delivery date
 Degree of communication required for the
project
 Summing up…
Functional Weak Matrix Balanced Matrix Strong Matrix Projectized

PM Authority Little or none Limited Low to Moderate Moderate to High High to almost Total

Resource Little or none Limited Low to Moderate Moderated to High High to almost total
Availability

Who controls the Functional Manager Functional Manager Mixed Project Manager Project Manager
project budget

Project Manager Part-time Part-time Full-times Full-time Full-time

Role

Project Part-time Part-time Part-time Full-time Full-time

Management
Administrative Staff
 What is a Project Schedule?

 The project schedule is a calendar that links

the tasks to be done with the resources that
are required to do them.
• Before a project schedule can be created,
the project manager must have a WBS and
estimates.
• The schedule is part of the project plan.
 Scheduling Objectives

 Primary objectives
• Best time
• Least cost
• Least risk
 Secondary objectives
• Evaluation of schedule alternatives
• Effective use of resources
• Communications
 Project Scheduling
 Split project into tasks (create a WBS)
 Estimate time and resources required to complete
each task.
 Organize tasks concurrently to make optimal
use of workforce.
 Minimize task dependencies to avoid delays
caused by one task waiting for another to
complete.
 Dependent on project manager’s intuition and
experience.
 Project Scheduling (II)
… according to Sommerville:
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to schedule
Wait ( for a while )
Review project progress
Revise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop
 Scheduling Principles - 1
 Compartmentalization
• the product and process must be
decomposed into a manageable number of
activities and tasks
 Interdependency
• tasks that can be completed in parallel must
be separated from those that must be
completed serially
 Time allocation
• every task has start and completion dates that
take the task interdependencies into account
 Scheduling Principles - 2

 Effort validation
• project manager must ensure that on any
given day there are enough staff
members assigned to complete the tasks
within the time estimated in the project
plan
 Defined Responsibilities
• every scheduled task needs to be
assigned to a specific team member
 Scheduling Principles - 3

 Defined outcomes
• every task in the schedule needs to have
a defined outcome (usually a work
product or deliverable)
 Defined milestones
• a milestone is accomplished when one or
more work products from an engineering
task have passed quality review
 Building the project schedule

 Allocate resources
• Once tasks (from the WBS) and
size/effort (from estimation) are known
• For each task in the WBS, one or more
resources must be assigned
• Choose person or people for each task
based on qualifications, familiarity and
availability
• Take overhead into account when
calculating the duration of each task
 Building the project schedule

 Identify dependencies
• A task has a dependency if it involves an
activity, resource or work product which
is subsequently required by another task
• Tasks may have dependencies because
they may require the same resource
 Building the project schedule
 Identify dependencies (continued)
• Every dependency has a predecessor, or a task that
must be begun, in progress, or completed, for
another task to begin
• Identify the type of predecessor for each
dependency
 Building the project schedule

 Create the schedule

• Most project
schedules are
represented using
a Gantt chart
• The Gantt chart
shows tasks,
dependencies and
milestones using
different shapes
 Building the project schedule
 Reconcile the schedule with the organization’s needs
• Once resources are allocated to each task, a final
date can be calculated
• If this date is unacceptable, the project plan must
change
• Either additional resources must be allocated to
the project or the scope must be cut down
• Brooks’ Law: “Nine women cannot have a baby in
one month.”
• In other words, some tasks can only be done by
one person, no matter how critical they are.
 Building the project schedule
 Add review meetings to the schedule
• Progress reviews meetings are held regularly to
check the progress of a project versus it's
scheduled progress.
• Milestone reviews are meetings which the project
manager schedules in advance to coincide with
project events.
• The most common way for project managers to
handle milestone reviews is to schedule them
to occur after the last task in a project phase
(such as the end of design or programming).
 Building the project schedule
 Optimize the schedule
• Critical path is the sequence of tasks
that represent the minimum time
required to complete the project.
• If a task is on the critical path then
delaying that task will delay the
project.
• Allocating resources to tasks on the
critical path will reduce the project
schedule; allocating them to other
tasks will have less effect.
 Terminology
 Precedence
• A task that must occur before another
is said to have precedence to the other
 Concurrence
• Concurrent tasks are those that can
occur at the same time (in parallel)
 Leads & Lag Time
• Delays between activities
• Time required before or after a given
task
 Terminology
 Milestones
• Significant events on a project with duration
of zero
• Identify critical points in your schedule
• Shown as inverted triangle or a diamond
• Often used at “review” or “delivery” times
• Or at end or beginning of phases
• Ex: Software Requirements Review
(SRR)
• Can be tied to contract terms
 Terminology

Example
Milestones
 Terminology

 Deliverable:
• a deliverable is a measurable and
verifiable work products

… in current practice sometimes milestone and

deliverable are used interchangeably (both
used to identify products - milestones may
represent key-products)
 Terminology
 Overhead is any effort that does not go to the
core activities of the task but is still required in
order for the people to perform it—a sort of
“real world” cost of actually doing the work.
• Two people performing a task will require
more effort than one person doing the same
task
• Assigning two people to the task requires
more effort, but the task generally has a
shorter duration
 Terminology
 Slack/Float is the amount of time which any of the tasks
can be delayed without causing the due date of the final
task in the sequence to be delayed as well.
• A tight schedule has very little slack; a delay in any
task will cause a delay in the due date
• Free Slack
 Slack that an activity has before it delays next task
• Total Slack
 Slack an activity has before delaying whole project
• Slack Time TS = TL – TE
• TE = earliest time an event can take place
• TL = latest date it can occur w/o extending project’s
completion date
 Scheduling Techniques

• Mathematical Analysis
• Network Diagrams
 PERT

 CPM

• Bar Charts
• Milestone Chart
• Gantt Chart
 Network Diagrams

 Developed in the 1950’s

 A graphical representation of the tasks
necessary to complete a project
 Visualizes the flow of tasks & relationships
 Network Diagrams
(Dependencies and Schedule)
 An important temporal relation “must be preceded by”
 Dependency graphs show dependencies of the tasks
(hierarchical and temporal)
• Activity Graph:
• Nodes of the graph are the project milestones
• Lines linking the nodes represent the tasks
involved
• Schedule Chart (MS-Project):
• Nodes are tasks and milestones
• Lines represent temporal dependencies
 Label dependency graph with the estimates
 4 Task Dependency Types
 Mandatory Dependencies
• “Hard logic” dependencies
• Nature of the work dictates an ordering
• Ex: Coding has to precede testing
• Ex: UI design precedes UI implementation
 Discretionary Dependencies
• “Soft logic” dependencies
• Determined by the project management
team
• Process-driven
• Ex: Discretionary order of creating certain
modules
 4 Task Dependency Types

 External Dependencies
• Outside of the project itself
• Ex: Release of 3rd party product;
contract signoff
• Ex: stakeholders, suppliers, Y2K, year
end
 Resource Dependencies
• Two task rely on the same resource
• Ex: You have only one DBA but
multiple DB tasks
 Task Dependency Relationships
 Finish-to-Start (FS)
• B cannot start till A finishes
• A: Construct fence; B: Paint Fence
 Start-to-Start (SS)
• B cannot start till A starts
• A: Pour foundation; B: Level concrete
 Finish-to-Finish (FF)
• B cannot finish till A finishes
• A: Add wiring; B: Inspect electrical
 Start-to-Finish (SF)
• B cannot finish till A starts (rare)
 Network Diagrams

 Two classic formats

• AOA: Activity on Arrow
• AON: Activity on Node
 Each task labeled with
• Duration (in standard unit like days)
• Identifier (usually a letter/code)
 There are other variations of labeling
 There is 1 start & 1 end event
 Time goes from left to right
Node Formats
 Network Diagrams
 AOA consists of
• Circles representing Events such as ‘start’ or
‘end’ of a given task
• Lines representing Tasks i.e. Thing being done
‘Build UI’
• Much like a Arrow Diagramming Method (ADM)
 AON
• Tasks on Nodes: Nodes can be circles or
rectangles (usually latter) - Task information
written on node
• Arrows are dependencies between tasks
• Much like Precedence Diagramming Method
(PDM)
MS-Project Example
 Critical Path

 “The specific set of sequential tasks upon

which the project completion date depends”
 All projects have a Critical Path which is the
shortest path in the network
 Accelerating non-critical tasks do not directly
shorten the schedule
 Critical Path Method is the process for
determining and optimizing the critical path
 Non-CP tasks can start earlier or later
without affecting the completion date
Critical Path Example
Critical Path Example (AON Format)
 Example
Activity Precursor Duration EST EFT LST LFT Slack

Start - 0 0 0 0 0 0

A Start 2 0 2 0 2 0

B Start 3 0 3 4 7 4

C A 5 2 7 2 7 0

D A,B 4 3 7 7 11 4

E D 2 7 9 11 13 4

F B,C 6 7 13 7 13 0

FINISH E,F 0 13 13 13 13 0

EST = earliest start time, EFT = earliest finish time.

LST = latest start time, LFT = latest finish time Slack = (LST - EST) or (LFT – EFT)
 CPM Equations
EST(START) always = 0, EFT(START) always = 0.
LST(START) always = 0, LFT(START) always = 0.
EFT(I) = EST(I) + DUR(I).
EST(I) = max(EFT of all its predecessors).
LST(I) = LFT(I) - DUR(I).
LFT(I) = min(LST of all successors).
LFT(FINISH) = LST(FINISH) = EST(FINISH) =
EFT(FINISH).

Critical path is sequence of all nodes with Slack = 0.

Example Step 1
 Forward Pass

 To determine early start (EST) and early

finish (EFT) times for each task
 Work from left to right
 Adding times in each path
 Rule: when several tasks converge, the
EST for the next task is the largest of
preceding EFT times
Example Step 2
 Backward Pass

 To determine the latest finish (LFT) and

latest start (LST) times
 Start at the end node
 Compute the bottom pair of numbers
 Subtract duration from connecting node’s
earliest start time
Example Step 3
Example Step 4
 Program Evaluation and Review Technique
PERT
 A network analysis technique used to estimate
project duration when there is a high degree of
uncertainty in the individual activity durations.
 Due to uncertainty, uses duration ranges and the
probability of falling to a given range.
 Uses an “expected value” (or weighted average) to
determine durations.
 Uses a prescribed method to calculate the
expected durations and then uses them as input to
network diagram.
 PERT provides a method for estimating the
probability of meeting or missing target dates.
 PERT Estimates

 Start with 3 estimates

• Optimistic (a): The shortest time in which we
would expect to complete the event, barring
outright miracles.
• Most likely (m): The time we would expect
the task to take under normal
circumstances.
• Pessimistic (b): The worst possible time
allowing all reasonable eventualities.
 PERT Formula

 Combined to estimate a task duration

 Using Expected Durations
 The expected durations are used to carry out a forward
pass of network using the technique as used in CPM.
 The calculated event dates are not the earliest
possible dates, but are the dates by which we expect
to achieve those event.
 For the example discussed, the expected project
duration is 13.5 weeks.
 Unlike the CPM, the PERT method does not indicate
the earliest date by which we could complete the
project but the expected date.
 Advantage is that it places an emphasis on the
uncertainty of the real world.
 PERT Formula
 Confidence Interval can be determined based on
a standard deviation of the expected time using a
bell curve (normal distribution)

For the whole critical path use

• In case of multiple paths to an event node, its standard

deviation will be the maximum of the standard
deviations of all the paths.
 PERT Example

Description Planner 1 Planner 2

m 10d 10d

a 9d 9d

b 12d 20d

PERT time 10.2d 11.5d

Std. Dev. 0.5d 1.8d

 PERT Fundamentals
 PERT is a method for estimating the probability
of meeting or missing target dates.
 There might be only a single target date-the
project completion or we might wish to set
some additional intermediate targets.
 Suppose that we must complete the project
within 15 weeks but we expect it will take 13.5
weeks (it could be more or perhaps less).
 Suppose the activity C in the next example
must be completed by 10 weeks
 Event 5 also has a target date of 10 weeks
 PERT Network with time estimates
Activity duration (Weeks)
Activity Optimistic Most likely Pessimistic Expected Standard
(a) (m) (b) (te) deviation (s)
A 5 6 8 6.17 0.50

B 3 4 5 4.00 0.33

C (A) 2 3 3 2.83 0.17

D (B) 3.5 4 5 4.08 0.25

E (B) 1 3 4 2.83 0.50

F 8 10 15 10.50 1.17

G (E,F) 2 3 4 3.00 0.33

H (D,C) 2 2 2.5 2.08 0.08

 Target dates

• Project Completion 15 weeks

• Activity C 10 weeks
• Delivery of intermediate product to the
customer (Event 5, after E and F) 10
weeks
 Forward Pass
Activity EST EFT
Start 0 0
A 0 6.17
B 0 4.00
C 6.17 9.00
D 4.00 8.08
E 4.00 6.83
F 0 10.5
G 10.50 13.50
H 9.00 11.08
Finish 13.50 13.50
 Event Format

Event Number Target Date

Expected Date Std. Deviation

 `

2
A 6.17 0.50 C
t=6.17 t=2.83
s=0.50 s=0.17

B D H
1 t=4.00 3 t=4.08 4 10 t=2.08 6 15
0 0 4 0.33 9 0.53 13.5 1.22
s=0.33 s=0.25 s=0.08

F E C
t=10.05 t=2.83 t=3.00
s=1.17 s=0.50 s=0.33
5 10
10.5 1.17
 PERT Steps

 For calculating the probability of meeting or

missing a target date following 3 steps are
taken
• Calculate the standard deviation for each project
event.
• Calculate the z value for each event that has a
target date.
• Z = (T-te)/s where T is the target date, te the
expected date and s the standard deviation
• Convert z values to probabilities: Curves are
available to give these values
 Probability Calculation

 Standard Deviation of the

Path (s) = SQRT(1.17^2 + 0.33^2) = 1.22
 Z value = (15 – 13.5)/1.22 = 1.23
 Finding Probability with the curve = 11%
 There is an 11% risk of not meeting the target
date of the end of week 15.
 PERT

 Advantages
• Accounts for uncertainty
 Disadvantages
• Time and labor intensive
• Assumption of unlimited resources is big
issue
• Lack of functional ownership of estimates
• Mostly only used on large, complex project
 Get PERT software to calculate it for you
 CPM vs. PERT

 Both use Network Diagrams

 CPM: deterministic
 PERT: probabilistic
 CPM: one estimate, PERT, three estimates
 PERT is infrequently used
 Network Diagrams
 Advantages
• Show precedence well
• Reveal interdependencies not shown in
other techniques
• Ability to calculate critical path
 Disadvantages
• Default model assumes resources are
unlimited
• You need to incorporate this yourself
(Resource Dependencies) when
determining the “real” Critical Path
• Difficult to follow on large projects
 Bar charts and activity networks
 Graphical notations used to illustrate the project
schedule.
 Show project breakdown into tasks.
 Activity charts show task dependencies and the
critical path.
 Bar charts show schedule against calendar time.
 Milestone Chart

 Sometimes called as “bar charts”

 Simple Gantt chart
• Either showing just highest summary
bars
• Or milestones only
Bar Chart
 Gantt Chart
 Provide a standard format for displaying project
schedule information
 Lists project activities and their corresponding
start and finish dates in calendar format
 It contains
• milestones (black diamond symbol),
• summary tasks (thick black bars with arrows at the
start and end),
• individual task durations (horizontal bar)
• and arrows showing task dependencies (rarely).
Gantt Chart
 Gantt Chart
 Disadvantages
• Does not show interdependencies well
• Does not show uncertainty of a given
activity (as does PERT)
 Advantages
• Easily understood
• Easily created and maintained
 Reducing Project Duration

 How can you shorten the schedule?

 Via
• Reducing scope (or quality)
• Adding resources
• Concurrency (perform tasks in parallel)
• Substitution of activities
 Compression Techniques
 Shorten the overall duration of the project
 Crashing
• Looks at cost and schedule tradeoffs
• Gain greatest compression with least cost
• Add resources to critical path tasks
• Changing the sequence of tasks
 Fast Tracking
• Overlapping of phases, activities or tasks that
would otherwise be sequential
• Involves some risk
• May cause rework