CVEN9702 Chap.7 PNET and Monte Carlo Simulation
PNET and Monte Carlo Simulation
PNET and Monte Carlo simulation model uncertain project networks by repeating the schedule with sampled activity durations. Every run recalculates path lengths, project finish and critical-path identity. The resulting observations support completion probabilities, percentiles and criticality indices. A simulation is only as credible as its duration distributions, dependency assumptions and preserved run table.
What this chapter covers
- 01
Assign an appropriate duration distribution to each activity
- 02
Sample activity durations once per simulation run
- 03
Recalculate every path and project finish inside each run
- 04
Count deadline events with an explicit inequality
- 05
Estimate activity and path criticality frequencies
- 06
Validate inputs, dependence and output stability
Worked example · free
Count criticality and deadline exceedance
- +1Project durations are the larger totals: 8, 9, 10, 11 and 9 days.
- +1Path A controls runs two, four and five, giving criticality 3/5 or 60%.
- +1Path B controls runs one and three, giving criticality 2/5 or 40%.
- +1Only durations 10 and 11 exceed nine, so exceedance is 2/5 or 40%.
Key terms
- Simulation run
- One sampled realisation of all activity durations followed by a complete network calculation.
- Deadline exceedance
- The event that simulated project completion is strictly later than a stated target.
- Criticality index
- The proportion of runs in which an activity or path is critical.
- Input distribution
- The probability model used to generate plausible values for an uncertain activity duration.
- Correlation
- Dependence between uncertain activities that makes their sampled outcomes move together rather than independently.
PNET and Monte Carlo Simulation FAQ
Why must the critical path be recalculated in every run?
Sampled durations can change which path is longest. Keeping the deterministic critical path fixed misses path switching and understates uncertainty. Each run must therefore calculate all path totals and store the realised controlling path.
How many simulation runs are enough?
A small hand exercise demonstrates the method but gives coarse probabilities. Software studies use many more runs and check that percentiles and criticality results stabilise. More runs improve sampling precision but cannot correct weak distributions or logic.
What is the difference between beyond and at least?
Beyond a target excludes results equal to the target, while at least includes them. Write the inequality before counting. In a small simulation, including one boundary result can change the percentage materially.
How should tied critical paths be counted?
Choose and disclose a consistent rule, such as crediting every tied path or dividing credit. Preserve tied outcomes so another analyst can reproduce the indices.
Exam move
Start with a two-path network and create a table with one column for each sampled activity, each path total, project duration and critical-path identity. Complete every row before calculating percentages. Add an indicator for a deadline event and sum it to obtain the numerator. Repeat with wording that changes from greater than to greater than or equal so the boundary distinction becomes automatic.
Next calculate activity criticality by counting the runs in which it lies on a controlling path, with a stated treatment of tied paths. Review distribution choice and correlation as separate modelling decisions. Ask whether two activities share weather, access or productivity drivers before sampling them independently.
When using software, examine convergence and input sensitivity rather than reporting excessive decimal precision. A good final answer states the estimate, the sample size and the assumption most likely to affect it. Preserve a transparent run table before relying on software summaries. For each iteration, record sampled durations, every path total, the maximum finish, the controlling path and deadline indicators.
Recalculate one row by hand to confirm that network logic, calendars and boundary tests are implemented correctly. Define ties before counting criticality: either credit every tied path or use a documented fractional convention, but never switch silently. Sort project finishes to estimate percentiles and distinguish the chance of finishing by a date from the date associated with a target confidence.
Increase the run count in stages and plot whether the mean, percentile and key criticality indices stabilise. A result that moves materially with another batch has not converged enough for the claimed precision. Perform sensitivity tests on distribution range, skew and correlations. Shared weather, approval or productivity drivers can make independent sampling understate tail risk.
Compare a deterministic critical path with simulation criticality to identify activities that are rarely controlling in the baseline yet often control under uncertainty. Translate those findings into action: improve data, protect a shared driver, add contingency or monitor a switching path.
Report sample size, random assumptions and material exclusions alongside the headline probability so the estimate remains auditable rather than appearing certain.
