Learning Outcomes

Project management process

Project background information
Project charter
 Learning Outcomes(Contd.)
Internalstakeholders
External stakeholders
Scope statement
Constraints
Assumptions
WBS
Network diagram
 Learning Outcomes(Contd.)
Time & cost estimates
Human Resource Plan
Communication Management Plan
Procurement Management Plan
 Learning Outcomes (Contd.)
Risk management system
Historical records
Lessons learnt
Risk tolerance
Risk thresholds
 Planning for
Risk Management
Main Reasons of Project Failure
because they actually are impossible
possibledeliverable, but the rest of the
objective is unrealistic
Deliverable and the rest of the objective
is possible but too little thought is put
into the work
Risk and project planning helps
distinguish and deal with all three
of these situations.
 Appropriate Project Selection

Number of projects can be minimized

Project
priorities can be aligned with
business and technical strategies
Overestimation of resources and resource
capabilities can be avoided
Risk tolerance should be kept in mind
 Outcomes of
Effective Project Selection Process
the project is authorized, OR
the
project may require changes to scope,
schedule, or resources, OR
Theproject is postponed for later
reconsideration, OR
The project ideas are turned down
 Assignment
Working in a group of 3 to 4, do the following:
Identify and introduce of an innovative project idea
Prepare a list of risks involved in acceptance of
the idea
Brief plan to minimize idea acceptance risks
(30 min preparation + 5 min presentation)
Overall Project Planning Processes
May be considered as unnecessary
overhead and luxury
Is project routine or high-tech
History of success & failure
 Results of Appropriate Planning
Better communication
Less rework
Lowered costs, reduced time
Earlier
identification of gaps and
inadequate specifications
Fewer surprises
Less chaos and fire-fighting
 Known and Unknown Risks
known risks occur frequently enough
to be analyzed in advance.
unknown risks result from the
uniqueness of the work and are difficult
or impossible to anticipate.
Overcoming Project Risk: Lessons from the
PERIL Database

Tom Kendrick

Program Manager, Hewlett-Packard

Company
 The PERIL Database
Project Experience Risk Information
Library
Input
from a large number of projects
and project managers
Contains samples
 The PERIL Database (Contd.)
Project Experience Risk Information
Library
Input
from a large number of projects
and project managers
May shift unknown to known
 The PERIL Database (Contd.)
PERIL is not comprehensive
PERIL is not unbiased. It is random and
self-reported.
PERIL represents only significant risks.
IT Projects PERIL Database
Chapter 3 (Tom Kendrick)
 IDENTIFYING
PROJECT SCOPE RISK
Well begun is half done.
(ARISTOTLE)
Unclear scope almost always have
a negative cost and schedule
impact (Rita)
Why Requirements may be Unclear
Changing environments
Difference in language or culture
Determination time is not enough
Inexperienced project manager
Tendency to avoid arguments
Poor realization of concequences
To keep options open etc.
 Scope Risk Ideas
I. Sources of scope risk
II. Defining deliverables
III. High-level risk assessment
IV. Setting limits
V. Work breakdown structure
VI. Market and confidentiality risk
 I. Sources of Scope Risk
Change Risks
Defect Risks
 Change Risks
Scopecreep: requirements that evolve
and mutate as a project runs
Gaps: specifications or activities added to
the project late
Scope dependencies: inputs or other
needs of the project not anticipated at the
start of a project
 Defect Risks
Relate to non conformity to specification
Generally visible
More in innovative and technological
projects
 II. Defining Deliverables

Start by identifying the people who

should participate
 Scope Risk Management
Techniques
Documented definition process
Straw-man definition document
Rigorous evolutionary methodology
 Deliverable Definition Process
1.Alignment with business strategy (How does this
project contribute to stated high-level business
objectives?)
2.User and customer needs (Has the project team
captured the ultimate end user requirements that
must be met by the deliverable?)
3. Compliance (Has the team identified all relevant
regulatory, environmental, and manufacturing
requirements, as well as any relevant industry
standards?)
 Deliverable Definition Process
4.Competition (Has the team identified both
current and projected alternatives to the proposed
deliverable, including not undertaking the project?)
5.Positioning (Is there a clear and compelling
benefit-oriented project objective that supports the
business case for the project?)
6.Decision criteria (Does this project team have an
agreed upon hierarchy of measurable priorities for
cost, time, and scope?)
 Deliverable Definition Process
7. Delivery (Are logistical requirements understood
and manageable? These include, but are not
limited to, sales, distribution, installation, sign-off,
and support.)
8. Sponsorship (Does the management hierarchy
collectively support the project, and will it provide
timely decisions and ongoing resources?)
 Deliverable Definition Process

9. Resources (Does the project have, and will it

continue to have, the staffing and funding needed
to meet the project goals within the allotted time?)
10.Technical risk (Has the team assessed the
overall level of risk it is taking? Are technical and
other exposures well documented?)
 STRAW- MAN DEFINITION
DOCUMENT
Used when there is a lack of data/info
Projectteam defines specific requirements
based on earlier projects, assumptions,
guesses and their understanding of the
problem etc.
Definitionconstructed this way is certain to
be inaccurate and incomplete
 STRAW- MAN DEFINITION
DOCUMENT (contd)
Firstpossibility: invented requirements will
be accepted and approved giving a solid
basis for planning. (may be misused)
Second possibility: outcome is a flood of
criticism, corrections, edits, and
improvements. (everyone seems to enjoy
being a critic.)
 Evolutionary Methodologies
Rather than defining a system as a whole,
set out a more general objective and then
cyclically describe incremental stages, each
producing a functional deliverable.
The algorithm is called genetic because it
mimics evolution, randomly mutating the
design in small increments and accepting
those mutations that improve the design.
 Evolutionary Methodologies
(contd)

It starts the project with no certain end

slower and more expensive
Minimize scope risk but increase schedule and
resource risk
More common in high end IT projects
 Scope Documentation
Project description
Project Justification
Completion criteria
Customer(s) and/or users
What the project will and will not include
Internal and external dependencies
 Scope Documentation (contd)
HR requirements (in terms of skills and experience)
High-level risks
Cost (rough order-of-magnitude, at least)

Technology required
Infrastructure required
Other significant data and issues
III. High- Level Risk Assessment Tools

Risk framework
Risk complexity index
Risk assessment grid
 Risk Framework
Consider the following project factors & their
sub factors
Technology (the work)

Marketing (the user)

Manufacturing (the production and delivery)

Foreach of these factors, assess the

amount of change required (insignificant or
significant only)

Correlate changes with risk

 Risk Complexity Index
Looks more deeply at the technology being
employed
Separates it into three parts and assigns index (0
to 5 each)
also looks at another source of project risk: the
scale.
Index = (Technology+Architecture+System) x Scale

(Uniqueness, Infrastructure & Resources, System) x scale

 Part Index Estimation
0Only existing technology required
1Minor extensions to existing technology needed
in a few areas
2Significant extensions to existing technology
needed in a few areas
3Almost certainly possible, but innovation needed
in some areas
4Probably feasible, but innovation required in
many Areas
5Completely new, technological feasibility in doubt
 Scale Values

up to twelve people 0.8

thirteen to forty people 2.4
forty-one to one hundred people 4.3
more than one hundred people 6.6
 Project Risk Assessment
Index below 20 are generally low-risk
projects with durations of well under a year
Projects assessed between 20 and 40 are
medium risk. These projects are more likely
to get into trouble and often take a year or
longer.
Most projects with an index above 40 are
high risk, finish long past their stated
deadline, if they complete at all.
Risk Assessment Grid
 Setting Limits
Decisions to continue or to quit in
situations that involve spending more
time, more money, or both.
 Holdor hang up in a telephone queue for
help desks?
Continue to wait for a bus or get a taxi?
Repair an old car or invest in a new one?
Hold or sell a falling stock investment?
 Why Set Limits
Defining project scope with sufficient
detail and limits is an essential foundation
for risk management and project
planning.
Detectingproject overrun early enough to
abort or modify impossible or unjustified
projects will minimize the risk of
unproductive investments.
Work Breakdown Structure (WBS)

A deliverable oriented grouping of project

elements that organizes and defines the total
scope of the project. Each descending level
represents an increasingly detailed definition of
the project work (Project Management
Institute)
 WBS Decomposition Approaches
By
organizational function (marketing, R&D,
manufacturing)
Byproduct physical decomposition (engine,
wings, tail)
By product functional decomposition (fuel
system, atmosphere control system, flight
control system)
 By discipline (hardware, software, quality,
support)
By skill set (programming, accounting,
assembly)
By geography (Karachi, Birmingham,
Johannesburg)
By life-cycle phase (investigation, design,
development, test)
 WBS Completion Test
Status/completion are measurable
Clearly defined start/end events
Activity has a deliverable
Time/cost easily estimated
Duration within acceptable limits
Work assignments are independent
 Risk Identification in WBS

If any part of the project resists work

breakdown using common decomposition
approaches or/and completion tests, that
portion of the project is not well understood,
and it is inherently risky.
 Key Ideas to Identify Scope Risks
Clearly define all project deliverables, and note
challenges.
Set limits on the project based on the value of
the deliverables.
Decompose all project work into small pieces,
and identify work not well understood.
Assign ownership for all project work and probe
for reasons behind any reluctance.
Note risk arising from expected project duration
or complexity.
Chapter 4 (Tom Kendrick)
IDENTIFYING PROJECT
SCHEDULE RISK
 Parkinsons Law

Work expands so as to fill the

time available for its completion.
(C. NORTHCOTE PARKINSON)
 Schedule Risk Ideas

1. Sources of Schedule Risk

2. Activity Definition

3. Estimating Activity Duration

4. Activity Sequencing
 1-Sources of Schedule Risk
Delay risks
Dependency risks
Estimating risks
 Delay Risks
Late delivery
Slow documentation
Defective supply
Slow decisions
Poor access
Lack of interest
Extended debates
 Delay Risks (contd.)

Lack of information
Geographic time lag
Miscommunication

Rework etc.
 Dependancy Risks

Dependency on other projects

Delay

Non-conformity

Interfacing
 Dependancy Risks (contd.)

Dependency on support
Delay

Non-conformity

Documentation
 Estimation Risks
Misleading historical data
Difference in approach

Level of skill

Improportional scale

Judgment error
Over-optimism

Quick planning

Learning curve issues

 2-Activity Definition
Insufficient decomposition
Confusing terminology
 3-Estimating Activity Duration

Estimation Pitfalls
Avoidance

Optimism

Lack of information
Granularity
Overall Estimation Process
 Project-specific Factors
Clarity of the project specifications
Likelihood of significant specification change
New resource requirements
Longer expected project duration
New required technology
Unusual technical complexity
 Project-specific Factors (Contd.)
Extreme requirements for reliability
Geographic separation and cultural diversity
on the project team
Infrastructure and environment differences
Training requirements
 Resource Factors
The
amount of time each day each team
member has for project work
The number of people contributing to each
activity
Theskills, experience, and productivity of
each team member
Training and mentoring requirements
Non-project responsibilities for each person
 Resource Factors (Contd)
Issues of distributed teams
Expected turnover during the project
The number and duration for meetings
Theamount of project communication and
reporting
Travel requirements
Thenumber of required people not yet
assigned
 Nonproject Factors
Holidays
Weekends
Vacations and other paid time off
Other projects
Lengthy non-project meetings
Equipment downtime
Interruptions and shut-downs
Medical leave
 Methods for Estimating
Activity Durations
Similarity to Other Activities
Historical Data
Rules and Formulas
Expert Advice
Delphi Technique
Three Point Technique
Wide-band Delphi Technique
 Project- level Estimates
Thinkingall the initial work on a project,
such as planning, analysis, investigation, initial
design, proposal generation, specification, and
preparation for the business decision to
commit to the project.
 Doingthe work that generally defines the
project. This is where the team rolls up their
sleeves and digs into the creation of the
project deliverable.
 Checkingtesting the results created by the
project, searching for defects in the
deliverable(s), correcting problems and
omissions, and achieving project closure.
Applying Estimating Techniques
Estimates Adjusted for Uncertainty

O+4M+P
=E
6

O Optimistic time
P Pessimistic time
M Most likely time
Beta Distribution
Sources of Sequencing Risks

Three point technique

Finish-to-Start relationship
Open links
Critical path
Multiple critical paths
Interfaces
 Key Ideas for Identifying
Schedule Risks
Determine the root causes of all uncertain
estimates.
Identify all estimates not based on historical data.
Note dependencies that pose delay risks,
including all interfaces.
Find any differences between project effort
requirements and life-cycle norms.
 Key Ideas for Identifying
Schedule Risks (Contd.)
Identify risky activities and schedule them
early in the project.
Ascertain risks associated with multiple critical
(or near-critical) paths.
Note risks associated with lengthy projects.