Website Upgrade Incoming - we're working on a new look (and speed!) standby while we deliver the project

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.

QSRA - how often would be the best?

8 replies [Last post]
Matthew Leung
User offline. Last seen 20 weeks 2 days ago. Offline
Joined: 27 Mar 2017
Posts: 9
Groups: None

Hi everyone,

just wonder how often should QSRA be carried out? Are there any guideline/ reference book saying like 6 months cycle would be more appropriate? 

Thanks a lot. 

Replies

Alex Lyaschenko
User offline. Last seen 10 weeks 22 hours ago. Offline
Joined: 15 Aug 2011
Posts: 59
Groups: None

Matthew,

> Thanks for your advice. But would the risk profile change so much within a week? 

A recent example:

A large construction project in Sydney was delayed due to a union strike (7 days). When I looked at historical data, I found that the project path with delayed activities had sufficient total float (20 days!!!).

The probably associated union risk was not in the list of analysed risks as it has 'low probability and low impact'.

Then SLOWLY, two things were changing every week:

1. The contingency on that path was spent (probably due to uncertainties on the predecessor activities?). Nothing major.

2. Probability of Risk starts slowly growing. 

When it became clear that the probability of that Risk was very high, the total float on that path was three days only. It was too late to react.

If this project had weekly QSRA, the TREND of meeting the committed date would start changing quite noticeable; even the Risk and schedule are not changed dramatically. The Risk analyst by analysing what is causing the change identifies that this schedule path has a severe treat and advise to apply corrective actions ealier. 

However, with QSRA performed every six months, the project missed the opportunity to avoid the delay. 3 months also can't help. 

 

Alex Lyaschenko
User offline. Last seen 10 weeks 22 hours ago. Offline
Joined: 15 Aug 2011
Posts: 59
Groups: None

In Australia, most of the Construction companies who run QSRA do it every 3 or 6 months. I believe the absolute majority are doing it only because:

a) it stated in the contract or;

b) as 'evidence' to justify the desired decision. Mostly to secure extra funds or push comitted deadlines. It is easy achievable just by changing some settings in a risk management tool. 

TfNSW demands that QSRA be performed every three months. Based on my experience, none of $100M+ transport projects in NSW has more-less reliable QSRA.

Sometimes it perfomed every 12 months. QSRA based on P6/MSP schedule and external risk tool is so time-consuming that companies are trying to avoid doing it, if it is only possible. And is it good as QSRA performed based on a determenistic schedule, and external risk register (and subjective data) in an external risk management tool is so inaccurate that it only could be done to "tick the box". It should not drive any business decisions.

I think the only way to use the QSRA results is to run the analysis as often as it is only possible to get a TREND. Absolute numbers are useless, but the trend still could be useful. So, it has to be:

a)     performed at least monthly;

b)     based on very good quality schedule;

c)     with documented consistent settings (Primavera, Risk data, Risk tool);

d)     as complementary data to other project reports.

If a company is serious about the results of QSRA they have to:

* Learns about all Monte Carlo Simulation Pitfalls. There are many of them. 

*  Invest in a probabilistic scheduling tool (with “conditional branches” feature, and good resource levelling algorithms and build-in risk analysis features)

Santosh Bhat
User offline. Last seen 31 weeks 2 days ago. Offline
Joined: 15 Apr 2005
Posts: 381

Matthew, the correct answer is either

  • as required, or
  • Any significant change in the scope or risk profile, that requires changes to cost and schedule estimates.

In practice, QSRA's are likely done on a semi-regular basis, perhaps every 6 or three months. Given that most projects have a reporting cycle of monthly, there is no reason why the QSRA can't be run at a minimum of monthly also, and perhaps only a major review of the risk inputs to occur every three months.

Ultimately, it boils down to the organisation or management's approach ranging from proactively wanting to understand the impact of risks regularly, to just ticking a requirements box..

Does it mean that for six months you do not identify what happens with project risks, do not estimate what happens with your contingency reserves and probabilities to meet project targets?

Jerome Odeh
User offline. Last seen 4 weeks 10 hours ago. Offline
Joined: 19 Jan 2004
Posts: 105

Hi Matthew,

Every 6 months is a common frequency and it looks like a good time interval to assess cumulative schedule changes. 

Most organisaitons have defined time intervals for QSRA and they are usually aligned to budget estimate review and/or when determinstic completion date is no longer realistic.

 

=Jerome

We look what happens with the probabilities to meet project targets, what happens with our contingency reserves.

Risk profile can be the same but some activities can be delayed, resource availability can change and we estimate if correction actions are required.

Besides, risk identification is ongoing, new risks can be discovered and probabilities of old risks can change.

Based on success probability trends we estimate and analyze project performance.

Matthew Leung
User offline. Last seen 20 weeks 2 days ago. Offline
Joined: 27 Mar 2017
Posts: 9
Groups: None

Thanks for your advice. But would the risk profile change so much within a week? 

We do it weekly and analyze trends.