Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

DOs and DON'Ts of PRA

5 replies [Last post]
S M
User offline. Last seen 2 years 14 weeks ago. Offline
Joined: 6 Oct 2012
Posts: 12
Groups: None

I  am in a company that is new to using the PRA tool, despite having used P6 for a few years.

My question(s) is, what must we be aware of and to have performed when taking our P6 plan and importing it into PRA?

I understand that some things have to be removed and modelled perhaps as activities, but what must myself and others carrying this is out keep in mind, and also to watch out for when performing this task?

Myself and the others have had the PRA formal training days but we are interested in the more practical application from experienced users.

Thanks,

Scott

Replies

S M
User offline. Last seen 2 years 14 weeks ago. Offline
Joined: 6 Oct 2012
Posts: 12
Groups: None

Thanks guys that's a great start.

 

 Merge Bias -  the Oracle trainer refused to go into this in detail,  and I understand this a large,complex theory. What is your rudimentary understanding of it and it rearing its head in PRA?

 

Thanks everyone.

 

Scott

Rafael Davila
User offline. Last seen 6 hours 55 min ago. Offline
Joined: 1 Mar 2004
Posts: 4829

From http://www.spiderproject.com/images/img/pdf/Project%20Control%20Methodologies.pdf

Photobucket

You cannot mix oil with water.

If you manage your job with PRA then running risk simulation with limited resources with the same software makes sense. If you use other software to manage the Job such as P6 which has different algorithm not only for resource leveling but for other functionalities the results might not be valid, not even within an acceptable margin of error. No matter how good, usually importing/exporting between different software makes the models different.

Dennis Hanks
User offline. Last seen 3 years 34 weeks ago. Offline
Joined: 17 Apr 2007
Posts: 310

SM

Jenn's advice is critical.  If your schedule is 'flawed', your analysis will be next to useless, so clean up the schedule according to Gary's advice.  Recommend Fuse, it makes schedule integrity enforcement a bit easier - the GAO metrics (with some modification) are what I would use.  PRA still does not like SS and FF relationships, but will work with them - suggest eliminating.

My advice on profiles - stick with triangle until you have a sense for the range bias.  If too optimistic use Trigen, if too pessimistic use BetaPERT.  Beyond that you are on your own.

The "merge bias" that Gary alluded to is a significant philosophical hurdle that arises from mutliple near-critical paths.  Nothing can be done except to be aware of what is happening.  It is something that sceptics will grab onto, so be prepared to explain it.

Currently weather modeling and risk factors cannot be run concurrently, this can be a real pain.  I am a fan of weather modeling and try to avoid risk factors, but I am not always successful.  Trying different modeling techniques with the "Weather Allowance" being the easiest, if you are only interested in finish date analysis.

As you get into it a bit more, do not hesitate to use this forum.  It is not 'real-time', but it is free.

PS:

1. Do not use the API connection between P6 and PRA, there are some LOE, milestone, and soft constraints issues. Use the .xer export.

 2. If you use the Weather Module, and I am hoping you will, you have to use "Days" when importing.  Otherwise, use "hours" especially if you use multiple calendars.

3. I have to use a MM DD YYYY format, the key is a 4 character year.  This may be unique to me, but I thought I would mention it.  I  use something like  30 Oct 2012 for my formats and always turn off 'time'.  PRA may use different durations (roundoff), so check your import log if your deteministic date is different from the P6 date.  All of this is within the 'level of accuracy' that we are using, but you should be aware of it.

That should be it for now, if something else occurs to me I will let you know.  Have fun, PRA is a dynamite program, even with all of its 'flaws'.

Gary Whitehead
User offline. Last seen 26 weeks 3 days ago. Offline

Things to watch out for in terms of schedule quality:

-Lags will not be varied in the monte carlo analysis, so minimise the use of them

-Constraints, particuarly hard ones, will play havoc with monte carlo analysis, so minimise / eliminate them.

-Don't have any "dangles" -ie all activities should have at least 1 sucessor and predecessor

-Make sure you understand if your durations estimates are optimistic, pessimistic, or most likely.

-Remove any buffers / TRAs / hidden float before doing the analysis

 

Things to watch out for in terms of assigning risks:

-Try where possible to have your risks detailed enough to relate to a single activity in the schedule. You can assign a risk to more than one activity, but it gets messy (i.e if you have a single risk assigned to 2 activities, are you doubling the likelyhood of it occuring?)

-Never assign schedule risks to summary bars or LOEs or mandy constraints

 

Things to whatch out for when assigning duration uncerntainty:

-There are a number of different prob distribution shapes you can select from. Which one you choose can have a substantial effect on the results of your analysis. No-one has been able to explain to me which ones are most appropriate to use in which circumstances. I suggest you have a play with a few trial projects, and decide for yourself which seems to be giving the most sensible results.

 

Things to watch out for when reporting the results:

-For projects of any kind of complexity, you will almost certainly find your schedule's determinstic completion date will have quite a low % probability (say 10%) unless you habitually use buffer tasks. You need to manage expectations when reporting these figures to management / clients, as the temptation is for them to infer that if you are saying you only have a 10% chance of hitting the deterministic date, that means your schedule is crap.

-The real benefits of PRA analysis in my view arrise from the Tornadoe charts, which help you focus on the most important risks, and the trends of P50 / P80 dates, which should come forward in time, and also get closer to your determinstic date as you succesfully manage your risks. The absolute numbers churned out are less important than the trends in my view, since there is so much guestimation involved in generating them.

 

Cheers,

G

Jenn Weber
User offline. Last seen 6 years 14 weeks ago. Offline
Joined: 20 Jan 2011
Posts: 35
Groups: None

Hi Scott, 

One of the most important factors in a schedule risk analysis is ensuring that you have a well-built plan to begin with.  Issues like missing logic, high float or high durations, lags, redundant logic or artificial constraints in a schedule can affect the risk analysis process and result in a misleading risk model. PRA includes a few checks to help validate the schedule quality prior to risk analysis or you can use a tool like Acumen Fuse to gain further insight into any schedule issues that may affect the analysis.  

Dr. Dan Patterson, one of the founders of Pertmaster (now PRA) has written a white paper explaining the types of things to look for within the schedule and how they can affect the risk analysis.  Use the link below to read this paper. 

Improved Schedule Risk Analysis through Metric Assessment

I hope this helps! 

- Jenn