Criticality Index

The criticality index is a probabilistic measure of how often an activity sits on the critical path across the iterations of a Monte Carlo schedule simulation. If 10,000 QSRA iterations are run and a specific activity lies on the critical path in 7,500 of them, its criticality index is 75%. The measure exists because the deterministic critical path — calculated once on a single set of point estimates — is only one of many possible critical paths the project could actually take, and the dominant one in deterministic terms is not always the one most likely to drive completion in reality.

The interpretation that matters in practice: an activity with high criticality index is one the project team should be watching even if its deterministic total float looks comfortable. A path with 5 days of float on the deterministic plan can become critical the moment any of its activities slip past that float — and on a programme with material duration uncertainty, those slips happen often. The criticality index quantifies how often. An activity with 80% criticality index is on the critical path in 80% of plausible futures; whether it sits on the deterministic critical path today is almost irrelevant.

Criticality index is most useful as a mitigation-prioritisation tool. The conventional approach of focusing only on activities with zero or near-zero total float (the deterministic critical and near-critical paths) misses risk-driving activities that live on what looks like a comfortable secondary path until a discrete risk event triggers them onto the critical chain. A risk-loaded schedule that ranks activities by criticality index pulls those into view — and Acumen Risk's variance analysis output, Safran Risk's sensitivity reports and Primavera Risk Analysis (Pertmaster) all expose the index by default. AACE Recommended Practice 64R-11 (Risk Analysis and Contingency Determination Using Expected Value) treats criticality index as a standard output of integrated cost-schedule QRA work.

Common interpretation errors: First, criticality index is not the same as activity sensitivity. Sensitivity measures the statistical correlation between an activity's duration and the project end date; criticality measures the proportion of iterations in which the activity is on the critical path. These are related but distinct — an activity can be highly sensitive without ever lying on the critical path if its duration affects total cost rather than schedule. Second, criticality index doesn't tell you the magnitude of any delay; it tells you the frequency of the activity being on the critical path. A high criticality index combined with a low sensitivity score might mean the activity is on the critical path often but never drives meaningful delay; a low criticality index combined with high sensitivity might mean the activity rarely drives completion but when it does the impact is large. Both measures should be read together. Third, criticality is a function of the input distributions and risk register — change the three-point estimates or the discrete risks and the index changes. It is not a property of the schedule; it is a property of the simulation. Re-run the QSRA after any material baseline change and the criticality rankings should be re-checked.

On UK programmes the most useful application of the criticality index is at the gateway review. A QSRA report that ranks the top 10 activities by criticality index, paired with the discrete risks driving each one, gives the gateway reviewer a defensible answer to the question 'what should the project team be watching?' — and avoids the trap of mitigation effort flowing only to whatever happens to be on the deterministic critical path the day the workshop ran.