Blogs


Welcome to PCI Blogs - selection of thoughts and tips shared by Project Controls community.

test

Brief methodology for undertaking QSRA/QCRA

Lets first understand what is QRA and Monte Carlo?


Quantitative Risk Analysis (QRA) is a forecasting technique used to predict project cost and/or schedule outcomes, and to estimate an appropriate level of contingency. The QRA seeks to develop realistic project schedules and estimates for a genuine prediction on how the project may result. In the past, project contingency has often been set by means of an uplift (E.g. 10% on cost/time). This approach is rudimentary, often provides no justification on why a certain uplift is applied, and may result in an entirely inadequate risk contingency.

There is generally a finite number of occasions on which a project can baseline schedules/budgets; we can maximise our chances of success by utilising Monte Carlo Analysis (MC).

Monte Carlo is a mathematical technique utilising random sampling, within specified distributions to calculate the probability of explicit outcomes. The underlying principal of the method is rooted in the law of averages, and the law of large numbers; creating a mathematical prediction of how the process may eventuate.

MC uses input duration ranges, as opposed to single point estimates for activity durations, to offset the inherent uncertainty in estimating. For a holistic coverage of possible cost/schedule outcomes, Risk Events (with a defined probability of occurrence, as well as an impact duration range) can be assigned to activities within the programme and contribute to the analysis (effectively extending the linked activity by the nominated impact duration value, on any iteration in which it appears). The Risk Analysis model is simulated hundreds, or thousands of times, and on each iteration a value is randomly selected from within the defined duration range for each activity. The most widely used, and easily understandable, range distribution is a triangular distribution (often referred to as a 3-point estimate and provided as a minimum, most likely, and maximum). The MC simulation is entirely random, plotting the outputs of each iteration as it works to create several useful insights. MC analysis undertaken on a project schedule takes cognisance of logic uncertainty and calendars, creating forward and backward pass calculations for each relationship in the plan, ultimately providing confidence intervals based on the range of start/finish dates for each milestone/activity.

Cumulative distribution graphs (S-curves) can be created to inform probability distributions (from which we can extrapolate confidence percentiles e.g. P50/P90.) For example, a P50 project completion date of 1st December 2018 occurs within the 50th percentile of the output dates; this means that in 50% of all iterations the project finish date is on, or before, 1st December 2018.

A relatively risk adverse organisation may prefer QRA models to provide a P90 confidence of meeting the schedule/cost target, where the results of the analysis show that in only 10% of iterations this value is exceeded. Conversely, a more risk tolerant organisation may be willing to accept a confidence percentile south of P50.

A QRA can help to provide a realistic forecast, and illustrate the key driving factors within a plan, in addition to quantifying the schedule benefits of timely interventions. This information is conducive to effective, risk-based decision making.

QSRA

The purpose of a Quantitative Schedule Risk Analysis (QSRA) is to provide assurance that key milestones/objectives within a project schedule will be met.


A QSRA can help to provide a realistic forecast, and illustrate the key driving factors within a plan, in addition to quantifying the schedule benefits of timely interventions. This information is conducive to effective, risk-based decision making.


The following inputs are necessary prior to analysis:


· Reviewed and agreed deterministic plan, considered suitable for analysis. If the existing project plan file is not suitable, a plan of

· Duration ranges for each line in the plan – minimum (optimistic), most likely (deterministic) and maximum (pessimistic). Depending on the Distribution type selected, a 2-point range (Min to Max) may be sufficient.

· Project Risk Register. (Note – there may be a requirement to hold a separate risk review prior to the QSRA process to ensure sufficiently mature Quantitative risk information is held)

Workshop – A workshop may be held with project stakeholders to review the analysis inputs. Several component parts of the analysis can be established at the workshop, such as risk impact mapping and duration uncertainty.

Programme – The programme must be representative of the programme of works, and must follow planning guidelines (attached). The programme should be reviewed in the workshop, to the following end:

- A review of activity durations to assign Duration Uncertainty values to the deterministic programme durations. The project team must ensure that the Duration Uncertainty estimates do not account for the impact of Risk and should account for only the inherent uncertainty in estimating the activity duration. The project team must challenge uncertainties and risks to ensure that optimism bias has been accounted for, and that all values provided are met with sufficient challenge.

- A review of where bespoke risks are to be mapped to the programme – This is to be an appropriate activity (or activities) the risk impact may be assigned.

Risk Register – The project risk register, with associated probability and impact values – including any planned management actions, must be addressed as it is a component part of the analysis. Existing risks should be sense checked by QSRA workshop attendees, and any links/correlation between risks should be identified before being imported into the plan. All risks should have assigned probability of occurrence values (%) as well as a Time impact ranges. The likely impact of a risk may be expressed as a 3 -point estimate (minimum, most likely, maximum) or a 2-point estimate (minimum to maximum).

QCRA

The purpose of a Quantitative Cost Risk Analysis (QCRA) is to estimate an appropriate level of cost contingency to supplement the project estimate and provide confidence that the budgetary allowance will not be surpassed.

A fully quantified risk register is essential to undertake the Cost Risk Analysis. Each applicable cost risk must have assigned probability of occurrence values (%) as well as a Cost impact ranges. The likely impact of a risk may be expressed as a 3 -point estimate (minimum, most likely, maximum) or a 2-point estimate (minimum to maximum).

The Risk Register should contain justification of the impact ranges (a qualifying statement of how costs have been built up, specific to each risk). E.g. ‘Cost impact may be X hours allowance for SME input @ £Xp/h + additional equipment costs = £Xk + Contractor prelims at £X per day ’.

The Risk Register should be cross-referenced with the Cost Model to ensure the impact of specific Risks have not been included for already in the base estimate.

QCRA should be run on Target (post-mitigated) risk assessment. This relies on the stability of the assumption, that identified mitigations are successful and the results are as expected.

A Monte Carlo Analysis can be run on the Risk Register inputs; resulting in the conception of output values specific to the project (as confidence percentiles). Specialist software (E.g @Risk, Primavera Risk Analysis etc. must be used to undertake the anlaysis).

Risks that are >70% of occurrence at Target assessment, should be transferred into the base estimate (or via contractual transfer depending on the project phase) or eliminated by terminating the linked activity/activities.

Cumulative distribution graphs (S-curves) can be created to inform probability distributions (from which we can extrapolate confidence percentiles e.g. P50/P90.)

If you like to know more about Project Risk Analysis or require any support, please contact us at info@Projcon-Advisory.com

Continue reading
15224 Hits
0 comments

Project Controls Trailblazer Apprenticeship – Path forward

In this post, We are attempting to offer an overview on upcoming Project Controls Trailblazer Apprenticeship based on knowledge which comes from our engagement in the development of this standard. 

The Project Controls Technician Apprenticeship (Level 3) that is part of the Government’s Trailblazer programme that aims to establish new standards for apprenticeships and is committed to reaching three million apprenticeship starts in England by 2020. has been developed by an employer-led working group consisting of Project Control leaders from 40 organisations that deliver complex projects across engineering, energy, infrastructure, construction and manufacturing sectors. Professional bodies such as ACostE, APM, IRM and CICES have also contributed to the development together with training providers and academia

The standard and assessment plan are ready to be delivered and used and have been fully approved by the Minister of State for Skills at the Department of Education, giving the green light for the launch of the apprenticeship in Q3 2017. A funding band (core government contribution which is currently capped at £21k per apprentice has been assigned to the standard.

In beginning to promote the apprenticeship, we have found that employers have a positive approach to the Project Controls Technician apprenticeship but are not sure who to engage with to get started, how to achieve a return on investment against the new apprenticeship levy and how best to establish Project Control apprenticeships and use the flexibility in the way the programme can be configured to meet their requirements for a viable programme that at the same time satisfies the mandatory criteria required by government.

Project Controls Institute being an approved training provider (via our parent org) for this Apprenticeship has created a dedicated KB offering options to guide employers in the right direction to provide a sure start for training your Project Controls apprentices. Based on our professional knowledge, we have also devised the unique delivery approach to offer this training to our clients which can be seen on our website.

Finally, we will be offering further insight on this topic at Project Controls Expo in Masterclass, supported by Employer, ECITB and possibly some government representation (SFA/DoE). If you any questions in the meantime, feel free to contact us at info@ProjectControlsInstitute.com

Continue reading
37776 Hits
0 comments

How does "Resource curve" work in P6?

 

How does “Resource curve” work?

 

Let say we have an activity with 100 days duration and 100 labor units. By default it use Linear spread.

It mean, when you reach 5% of duration (5th day in this example) you have 5% of total unit (5 unit in this example). And it spread evenly to that period.

So resource spreadsheet will be like this:

Now if I change to 6 %.

3

It mean, when you reach 5% of duration (5th day in this example) you have 6% of total unit (6 unit in this example). And it spread evenly to that period.

So resource spreadsheet will be like this:

Similarly, when you reach 10% of duration (10th day in this example) you have 5% more of total unit (5 unit in this example). And it spread evenly to that period.

So resource spreadsheet will be like this:

And it follow that regulation until the end of curve.

Now you understand how the resource curve work.

Hopefully it will help you to distribute resource unit as your wish:-)

 

 

 

 

Tags:
Continue reading
49272 Hits
0 comments

How to backup and restore Primavera P6 Oracle Express (XE) database

 

Notes:

  • Be sure to remove any < > used in the above examples
  • Backup command example:  exp system/mypassword@XE full=y file=C:\PrimaveraP6\backups\xedump.dmp log=C:\PrimaveraP6\backups\exp_xedump.log
  • If any of the paths contain spaces they should be enclosed in single quotes. EX: log=’C:\My directory that has a space\exp_xedump.log’

How to restore:

From the command prompt (go to ‘Start’ > ‘Run’ > type ‘cmd’ and click ‘OK’) using the format below

imp userid=system/ @xe file= \xedump.dmp commit=y buffer=8000000 fromuser=(admprm$pm,privprm$pm,pubprm$pm,bgjob$pm) touser=(admprm$pm,privprm$pm,pubprm$pm,bgjob$pm) log= \imp_xedump.log
 

 

Where:

  • is the password you used when you installed P6 Standalone or Oracle XE manually
  • is the complete path to the folder where the existing database backup dmp file is located and where the log file will be created. (For example: file=C:\PrimaveraP6\backups\xedump.dmp log=C:\PrimaveraP6\backups\xedump_import.log)
    • If any of the paths contain spaces they should be enclosed in single quotes. EX: log=’C:\My directory that has a space\imp_xedump.log’

Note:

When importing using the import ‘touser’ option, the database users specified must already exist in the target database into which you’re importing the data.

To check whether these users exist or not:

  1. Open a new command prompt window (go to ‘Start’ > ‘Run’ > type ‘cmd’ and click ‘OK’)
  2. In the command prompt window, type: “sqlplus system/ @xe”
    where is the password you used when you installed P6 Standalone or Oracle XE manually
  3. At the SQL> prompt, type: “select username from dba_users;”
  4. Check for the P6 schema users in the list of current database users

To create these users if the do not already exist, use the following steps:

  1. Download one of the following scripts:
  2. Review the before_import.sql script and make necessary modifications for your environment (such as tablespace locations)
  3. Open a new command prompt window (go to ‘Start’ > ‘Run’ > type ‘cmd’ and click ‘OK’)
  4. In the command prompt window, type: “sqlplus sys/ @xe as sysdba”
    where is the password you used when you installed P6 Standalone or Oracle XE manually
  5. At the SQL> prompt, type: “@ \”
    where is the complete path to the script and is the name of file.  Example, @C:\temp\before_import_8x.sql
Tags:
Continue reading
50305 Hits
0 comments

The Schedule Quality Index™

With the recent launch of the Fuse Schedule Index Calculator, we often get asked, what is the Schedule Quality Index™ and how is it calculated? 

First and foremost the Schedule Quality Index is a means of assessing how well planned a schedule.  It is a single score that is calculated from nine separate schedule check metrics.  The metrics span multiple key attributes, or building blocks of a schedule that together from the underpinnings of a structurally sound schedule. 

The Schedule Quality Index is made up of the following nine checks (metrics):

Missing Logic

In theory, all activities should have at least one predecessor and one successor associated with them. Failure to do so will impact the quality of results derived from a time analysis as well as a risk analysis. This number should not exceed more than 5%.

Logic Density™

This metric calculates the average number of logic links per activity. An average of less than two indicates that there is logic missing within the schedule. An average greater than four indicates overly complex logic, with a high likelihood of redundant links. Therefore, Logic Density™ should be between two and four.

Critical

While a highly critical schedule is not necessarily a sign of poor scheduling, it can indicate a highly risky schedule. Use this metric as a point of reference.

Hard Constraints

Hard, or two-way, constraints such as ‘Must Start On’ or ‘Must Finish On’ should be avoided. Use of such constraints can lead to inaccurate finish dates and a lack of insight into the impact of schedule changes, risk events, and earlier delays.

Negative Float

Negative float is a result of an artificially accelerated or constrained schedule, and is an indication that a schedule is not possible based on the current completion dates.

Insufficient Detail™

Activities with a high duration relative to the life of the project are an indication of poor schedule definition. Detail should be added to the schedule.

Number of Lags

A lag is a duration applied to a logic link often used to represent non-working time between activities such as concrete curing. Lags tend to hide detail within the schedule and cannot be statused like normal activities; therefore, lags should be converted to actual activities with durations.

Number of Leads

A lead, also known as a negative lag, is often used to adjust the successor start or end date relative to the logic link applied. This is a poor practice as it can result in the successor starting before the start of the predecessor.

Merge Hotspot

A merge hotspot is an indication of how complex the start of an activity is. If the number of links is greater than two, there is a high probability that the activity in question will be delayed due to the cumulative effect of all links having to complete on-time in order for the activity to start on time.

Continue reading
36583 Hits
0 comments

Planning & Scheduling rules/principles

·         Project Plans which optimise expenditure of time, recognise cost implications and reflect the contractual obligations for the design, procurement, construction and commissioning of plant facilities.

·         Regular updates of all project activities and their inter relationships.

·         Early indication of deviations from the approved project programme so that action can be taken to minimise their effect.

It is to be noted that key elements of plans are Scope of work and Method of execution including WBS.   

With regards to Scheduling, it is a determination of timing of events in the Project i.e., When tasks will be performed and its a reflection of plan. Here are main features of scheduling :

·         Provides comparison of actual progress against plan

·         Identify deviations from plan (problem areas)

·         Enables early corrective actions and adjustments to plan

In other words, scheduling is the science of using mathematical calculations and logic to predict when and where work is to be carried out in an efficient and time-effective sequence.

Here are some rules to minimise the chances of your plan to get failed and ensure project completes before or on time.

 

Ø   Most importantly, Project Planning & Scheduling must involve decisions concerning :

·         the overall strategy of how the work process is to be broken down for control;

·         how the control is to be managed;

·         what methods are to be used for design, procurement & construction;

·         the strategy for subcontracting and procurement;

·         the interface between the various participants;

·         the zones of operation and their interface;

·         maximising efficiency of the project strategy with respect to cost and time;

·         risk and opportunity management.

Ø   In the process of converting the plan into a schedule  the scheduler should determine:

·         the duration of the activities;

·         the party who will perform the activities;

·         the resources to be applied to the activities; and

·         the method of sequencing of one, or more activities in relation to other activities.

Ø   Depending upon the density of the schedule, the purpose for which it is to be used and the information available, an activity duration must be derived from following only. Any assumptions must be documented in case needs to be validated in future.

·         experience

·         industry standards

·         benchmarking

·         comparison with other projects

·         calculation from resources

·         specification.

Ø   The schedule must illustrate a realistic and practical project plan showing how the project is intended to be, in a form that is sufficiently accurate for its identified density.

Ø   Schedule must be capable of identifying the following:

·         the longest path to completion;

·         the longest path to intermediate key dates, or sectional completion dates;

·         logic and activities, which are critical from those, which are not critical to one, or more completion dates;

·         total float on each path;

·         free float on each activity, on each path;

Ø   The strategy for schedule review must take account of the development of the schedule as better information becomes available and, as the project proceeds, the increasing density of the schedule as it develops from initiation through the work on site to commissioning the completed project.

Ø   When change is imposed, scheduler must be able to identify it contemporaneously, the effect of delaying and disrupting causal events on the planned sequence and to advise team members on the likely effect of possible recovery strategies.

Ø   Risk is inevitable part of any program however if dealt well, can be brought under control. Contingency period to deal with risks should be designed to be identified separately for both the employers and the contractors risks and for those risks which are related to:

·         an activity, or chain of activities

·         a contractor, subcontractor, supplier, or other resource

·         an access, or egress date, or date of possession, or relinquishment of possession

·         the works, any defined section, and any part of the works.

Ø   For Schedule reporting , it is impracticable to use the whole of the schedule at any one time in its detail. For effective reporting it should be summarised to different degrees of summarisation for differing purposes. Most project scheduling software packages facilitate this hierarchical structuring by virtue of a summarisation, or roll-up facility.

Some basic tips:

  • Do not use Mandatory Constrained dates. If a constraint has been used, then “Start on or After” can be opted. Keep use constraints as minimal as possible.
  • Adopt Finish to Start logic as much as possible. Avoid SF links completely.
  • No “Dangles” at all in schedule. LOE tasks could be an exception here.
  • Avoid use of lags, especially long duration lags
  • Keep Level 3 activities to similar levels of detail whenever possible
  • Roll-ups from Level 3 to Level 2 must be “many to one” with no splitting of level 3 activities into individual level 2’s
  • Status activities only after confirming its reliability & source
  • Make your activity ID’s intelligent to identify where it belongs to.
  • WBS development is must before the creation of schedule
  • Avoid changing RD just to keep the activity out of critical path
  • Identify Key Events and Drop Dead Times before developing the plan
  • Schedules needs not to be way too detailed.
  • Be realistic irrespective of pressure from Client, Project Managers and Engineering/Construction leads.
  • Avoid “tweaking” of the logic to “make it fit.”
  • Activities must be linear and sequential (Finish-to-Start), instead of being overlapped, i.e., successor starts before the predecessor – a version of “fast-tracking” at the molecular level.
  • Planning procedure should encompass familiarisation, outline plan, strategic plan and detailed plan along with planning method statement
  • Do not deceive (to mislead by a false appearance or statement). Don’t mislead the schedule by false appearance
  • Get buy-in from the responsible owners of the plan. In absence of this, plan is no more than a worthless piece of paper.
  • Ensure the calendars are set before developing the plan to includes the holidays and working hours restrictions, if any.
  • Activity codes should identify the various attributes of the schedule as fields, the values of which will facilitate organisational changes, and facilitate filtering of important parts of the schedule.
  • Schedule review must check for buildability, content, integrity, constraints, open end tasks, long lags, negative lags, ladders and critical paths to name a few.

Summary:

Don’t twist the plan, contort the plan, reduce the plan, expand the plan, modify the plan, distort the plan, adjust the plan, change the plan.. Instead, follow the plan..

Continue reading
14655 Hits
0 comments

Categories

Search