This discussion is reproduced from a discussion from IT TOOLBOX under project management, which i found interesting and want to share with all of you. Enjoy reading......
PAL
____________________________________________
Hi Frair,
On the subject of Risk assessment, I like to engage my whole team
in identifying and qualifying risks. What is important is to be
consistent across the project life cycle and across resources.
I see by the other postings that other project managers define
their risk level consistently.
I use the classic (Probability times Impact) formula and I enter
project tasks in my MS project schedule to address High Impact,
High probability risks. If you do not have set definitions for
quantifying risks, I suggest starting with James P Lewis's book
"The Project Managers Desk Reference" Page 302 - 306 .
I hold regulary scheduled risk sessions throughout the the
project and update the project schedule accordingly.
Hi Friar:
As has been written before, two kinds of risks are
possible:
Overbudget and Overtime.
First, let us consider that both are independent form
each other.
You can model each individual risk using expert
opinions and modelling those opinions as Beta
distributions of probability, using max, min, mean and
most likely values as parametrs. Joint distributions
can be obtained by Monte Carlo simulation.
At any time, having new evidence about each estimated
probability, you can actualize it by the Bayes rule,
recalculations are made, again, by MC simulation.
The whole task can be done wit @Risk for Project from
Palisade Inc, an Add In for MS Project. Also you can
make the same (for free) with Prof Myerson´s Simtools,
and Add In for Excel.
If risks are interdependent you should estimate
covariances, a more complex approach but feasible
anyway.
@Risk has been selected by PMI as a valuable tool for
Risk Assesment and Modelling
Alfredo Russo
Risk Modeler and Consultant
Official @Risk Instructor for Argentina
------------
Everyone's answers are great explanations of the risk mgmt
theory, and I especially enjoyed reading about the idea of
adding the risk factor information into columns in MS Project.
But let me break down my original question further.
1- How to you identify risks to the project that exist from
within your schedule? perhaps due to the way the schedule is
constructed and/or managed.
When you identify a new risk and enter it into your risk
register, if "schedule" is within the Category domain set for
the risk record, what techniques do you use to analyze the
schedule, allowing you to point at the "data" in your MS Project
plan, and say "Look! Task #345 is injecting risk into our
project plan because...!"? Perhaps the way the task is linked
is preventing an accurate critical path calculation?
2- How do you "quantify" the risks that originate from your
schedule?
Scenario: If WBS section 3.0 of your schedule is Server
Configuration, and there's an identified risk that the server
hardware may ship late from the vendor, you can take the
aggregate cost of section 3.0 and quantify the cost of the
possible delay. But that risk is not originating from the
schedule. It originates at the vendor and is displayed in the
schedule.
According to PMBOK 3rd edition, P*I is not a quantitative
technique (11.4). PMBOK states that the P*I evaluation of an
identified risk is a "qualitative" technique (11.3.2.1-2) "to
prioritize identified risks" (11.3).
In his PM Desk Reference, Lewis states, "Naturally most risks and
threats cannot be quantified in any objective way, but we can
use a subjective method that seems to work fairly well. (p302)"
If the method is subjective, how can it be quantitative? He
goes on to describe a technique of deriving the risk's
likelihood and severity score, which he calls the "Risk
Probability Number". Are subjectively applied severity scores
quantitative, or are they qualitative? Maybe this is why PMBOK
says that P*I is qualitative?
What I'm looking to achieve is to perform a risk assessment of
"project managment", of the PMO itself. I'm turning the weapons
of PMBOK to assess the performance of the Project Manager. I'm
hoping to apply my madness across all areas of project
management, and thought this discussion group would be a good
place to start by creating examples related to scheduling (Time
Management).
--------------
Friar-
The tool that first comes to my mind is the CHI SQUARED table in
classic
PERT Analysis. The PERT diagram drawn by Microsoft Project looks like
the classic PERT Analysis, but lacks a few key factors:
Classic or Statistical PERT Analysis assigns three values to each task:
A = the minimum time it could take to complete
B = the average time required for completion
C = the minimum time it could take to complete
These are combined with the formula (A + 4B + C)/6 for a Statistical
Medium
Then all the Statistical Mediums are combined, as well as all the A's,
B's, and C's for tasks on the CRITICAL PATH.
The results are normalized and compared to a CHI SQUARED probability
table, which shows the probability of completing a project by a
specific
date.
This is a strictly mathematical quantification. One may read from the
CHI SQUARED table that e.g. there is a 10% probability of completing in
50 weeks, a 50% probability of completing in 55 weeks, and a 90%
probability of completing in 60 weeks. This analysis helps me
demonstrate that any time one CRASHES a project to take the minimum
time
for all tasks on the CRITICAL PATH, yes, you complete the project in
the
minimum amount of time, but the probability of success is Zero%. If my
schedule has 50 weeks, it has only a 10% chance of completing ON-TIME
i.e. HIGH RISK. If my schedule has 60 weeks, It has a 90% chance of
completing ON-TIME i.e. LOW RISK. Hey, it works for something complex,
like the Trident Missile.
Mark A. Cascella, PE
Busy Exec Tech LLC
