# Schedule and Cost Risk Analysis: [Project name]

> Schedule and cost risk analysis: a quantitative analysis that runs a
> Monte Carlo simulation on the project's critical path schedule, with
> uncertainty ranges on durations and costs and with discrete risk
> events as drivers, to find how likely the project is to meet its
> dates and budget. It reports the finish date and cost at chosen
> confidence levels (P50, P80), the probability of meeting the target,
> criticality and sensitivity of activities and risks, and the schedule
> and cost contingency needed. The approach follows the concept of
> integrated cost and schedule risk analysis described in AACE
> International Recommended Practice 57R-09 and best practice 8 of the
> public GAO Schedule Assessment Guide (GAO-16-89G). Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Run the analysis on a schedule that is already sound: complete logic,
  few constraints, a valid critical path. A Monte Carlo run on a broken
  network produces precise-looking nonsense. Section 3 is the gate.
- Model the risks as drivers (discrete events with a probability and an
  impact on named activities) on top of plain duration uncertainty. The
  drivers explain why the dates move, which is what decision makers need.
- Report results as a range with confidence levels, never as one date.
  State the number of iterations, the random seed and the tool, so the
  run can be reproduced.
- Repeat the analysis at each major decision point and after big
  changes. Compare runs to show whether risk is falling.
- The worked example uses a fictional port operator, Halvane Ports, and
  a terminal gate automation project with six activities, two risk
  drivers and 10,000 iterations (seed 2026). All results in sections 7
  to 10 come from that one run.
-->

## Document control

<!-- Guidance: Identify the analysis, the schedule and estimate versions it used, and its status. An analysis is only valid for the baseline and data date it was run on. -->

| Field | Value |
|---|---|
| Document ID | [SRA-PROJECT-001] |
| Project name and code | [Project name], [PRJ-NNNN] |
| Version | [1.0] |
| Status | [Draft / In review / Issued / Superseded] |
| Analyst | [Name, role] |
| Owner | [Project manager] |
| Reviewers | [Planner, cost estimator, risk manager, independent reviewer] |
| Schedule analysed | [File name, version, data date YYYY-MM-DD] |
| Cost estimate analysed | [Estimate ID, version, base date] |
| Risk register version | [ID, version, date] |
| Simulation tool and settings | [Tool, version, iterations, seed, sampling method] |
| Decision supported | [Funding approval / Baseline / Gate review / Contract bid] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Project manager | [Name] | [Accepted] | YYYY-MM-DD |
| Independent reviewer | [Name] | [Review findings closed] | YYYY-MM-DD |
| Sponsor | [Name] | [Contingency approved at P80 / other level] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 *(Example)* | YYYY-MM-DD | [Analyst] | First run on baseline schedule v2.0 |
| 1.0 *(Example)* | YYYY-MM-DD | [Analyst] | Ranges revised after risk workshop, issued for funding decision |
| 1.1 *(Example)* | YYYY-MM-DD | [Analyst] | Re-run after R1 mitigation agreed |

## Contents

1. [Purpose and decision](#1-purpose-and-decision)
2. [Scope and inputs](#2-scope-and-inputs)
3. [Schedule health check](#3-schedule-health-check)
4. [Risk drivers](#4-risk-drivers)
5. [Duration and cost uncertainty](#5-duration-and-cost-uncertainty)
6. [Model and simulation settings](#6-model-and-simulation-settings)
7. [Schedule results](#7-schedule-results)
8. [Cost results](#8-cost-results)
9. [Criticality and sensitivity](#9-criticality-and-sensitivity)
10. [Risk prioritisation and what-if runs](#10-risk-prioritisation-and-what-if-runs)
11. [Contingency and recommendations](#11-contingency-and-recommendations)
12. [Assumptions, limitations and quality checks](#12-assumptions-limitations-and-quality-checks)
13. [Glossary and references](#13-glossary-and-references)

## 1. Purpose and decision

<!-- Guidance: Say which decision the analysis informs and at what confidence level the organisation sets dates and budgets. If there is no policy, propose one and get it agreed before showing results, so the choice is not made to fit the answer. Pitfall: starting the analysis with no decision in view. -->

| Item | Value *(Example)* |
|---|---|
| Decision | Approve the project budget and the go-live date to be announced to shipping lines |
| Target date | Go-live at working day 175 from the data date (contract milestone with the port authority) |
| Target budget | EUR 1,450 thousand (deterministic estimate) |
| Confidence policy | Budget and announced dates set at P80; internal targets at P50 |
| Questions to answer | How likely is day 175? What contingency gives 80% confidence? Which risks matter most? |

## 2. Scope and inputs

<!-- Guidance: List every input with its version and owner. The scope of the model must match the scope of the decision: if the budget includes commissioning, the model must include commissioning. -->

| Input | Version and source *(Example)* | Owner |
|---|---|---|
| Schedule | Summary network of 6 activities derived from the integrated schedule v2.0 (412 activities), data date YYYY-MM-DD | Planner |
| Cost estimate | Base estimate v1.3: time-dependent costs EUR 6 thousand per working day, fixed costs EUR 550 thousand | Cost estimator |
| Risk register | RAID log v14, 23 open risks, 2 retained as drivers after screening | Risk manager |
| Range data | Risk workshop on YYYY-MM-DD with 9 participants, plus history from two earlier gate projects | Analyst |
| Calendar | 5-day working week, [holiday list] | Planner |

The example uses a summary network to keep the template readable. In
practice, run the analysis on the full integrated schedule or on a
summary network that keeps all the logic that drives the finish date,
and say which you used.

## 3. Schedule health check

<!-- Guidance: Check the schedule against recognised good practice before modelling. The GAO Schedule Assessment Guide lists ten best practices; the analysis relies most on complete logic, a valid critical path, realistic float and durations. Record failures and how they were fixed. Pitfall: hard date constraints left in the network, which stop risk from moving the dates downstream. -->

| GAO best practice | Check | Result *(Example)* |
|---|---|---|
| 1 Capturing all activities | All scope in the WBS appears in the schedule | Pass |
| 2 Sequencing all activities | No open ends except start and finish; few lags and leads | Pass after 4 open ends fixed |
| 3 Assigning resources | Key resources loaded on critical activities | Pass |
| 4 Establishing durations | Durations based on estimates, not targets | Pass |
| 5 Horizontal and vertical traceability | Delays flow through logic to the finish | Pass after 2 hard constraints removed |
| 6 Valid critical path | Continuous path from data date to finish | Pass |
| 7 Reasonable total float | No unexplained float above [44] working days | Pass |
| 8 Schedule risk analysis | This document | n/a |
| 9 Updated with actual progress | Data date status complete | Pass |
| 10 Baseline maintained | Baseline v2.0 saved | Pass |

Use `project/project-schedule` for the schedule itself and
`project/work-breakdown-structure` for the scope check.

## 4. Risk drivers

<!-- Guidance: Take risks from the register and model the ones that could move the finish date or cost materially. Each driver has a probability of occurring and an impact range on named activities. Keep threats and opportunities. Pitfall: double counting, where the same uncertainty is put into both the duration range and a risk driver. -->

| ID | Risk driver | Probability | Impact if it occurs | Activities affected | Register ref |
|---|---|---|---|---|---|
| R1 *(Example)* | Customs hold on imported barrier and camera hardware | 30% | Adds 10, 15, 25 working days (min, most likely, max) and EUR 40 thousand of storage and expediting | B Hardware procurement | RSK-007 |
| R2 *(Example)* | Integration defects between the gate system and the terminal operating system | 40% | Adds 5, 10, 20 working days | E Integration testing | RSK-012 |
| [Rn] | [Driver] | [%] | [Range] | [Activities] | [Ref] |

Screened out *(Example)*: 21 risks with expected schedule impact below
2 working days or already covered by the duration ranges in section 5.
Record each screened-out risk and the reason in the register.

## 5. Duration and cost uncertainty

<!-- Guidance: Give each activity a range that reflects estimating uncertainty only (not the discrete risks in section 4). Use three-point estimates from people who know the work, challenge narrow ranges, and record the distribution shape. Pitfall: ranges of plus or minus 10% everywhere, which is a sign nobody thought about each activity. -->

| ID | Activity | Predecessors | Min | Most likely | Max | Distribution |
|---|---|---|---|---|---|---|
| A *(Example)* | Detailed design | none | 30 | 35 | 45 | Triangular |
| B *(Example)* | Hardware procurement | A | 40 | 50 | 70 | Triangular |
| C *(Example)* | Gate software build | A | 50 | 60 | 80 | Triangular |
| D *(Example)* | Lane installation | B | 20 | 25 | 35 | Triangular |
| E *(Example)* | Integration testing | C, D | 25 | 30 | 45 | Triangular |
| F *(Example)* | Go-live and handover | E | 8 | 10 | 15 | Triangular |

Durations are in working days. The deterministic plan uses the most
likely values: A (35), then the longer of B plus D (75) and C (60), then
E (30) and F (10), giving 150 working days. The B and D path is critical;
the C path has 15 days of float.

| Cost element | Basis | Min | Most likely | Max | Distribution |
|---|---|---|---|---|---|
| Time-dependent team and site costs *(Example)* | EUR 6 thousand per working day of project duration | Follows simulated duration | | | Derived |
| Gate hardware *(Example)* | Supplier quotes | 380 | 400 | 460 | Triangular |
| Software licences *(Example)* | Fixed price contract | 150 | 150 | 150 | Fixed |
| R1 storage and expediting *(Example)* | Only when R1 occurs | 40 | 40 | 40 | Fixed, conditional |

Base estimate *(Example)*: 150 days times 6 plus 400 plus 150 equals
EUR 1,450 thousand. Linking cost to duration is what makes the analysis
integrated: a late project costs more because time-dependent costs keep
running.

## 6. Model and simulation settings

<!-- Guidance: Describe the model so another analyst can rebuild it. Include correlation: activities that share a cause (same supplier, same estimator) tend to overrun together, and leaving correlation out narrows the result. Pitfall: thousands of iterations on an untested model; check the model with a few manual runs first. -->

```mermaid
flowchart LR
  A["A Detailed design"] --> B["B Hardware procurement"]
  A --> C["C Gate software build"]
  B --> D["D Lane installation"]
  D --> E["E Integration testing"]
  C --> E
  E --> F["F Go-live and handover"]
  R1(["R1 Customs hold"]) -.-> B
  R2(["R2 Integration defects"]) -.-> E
```

| Setting | Value *(Example)* |
|---|---|
| Iterations | 10,000 |
| Random seed | 2026 |
| Sampling | Simple random sampling |
| Risk driver occurrence | Independent draws per iteration |
| Correlation between activity ranges | None modelled in the example (see section 12) |
| Merge point | E starts after the later of D and C |
| Outputs recorded | Finish date, total cost, critical path per iteration, input samples |
| Tool | [Tool name and version, or script reference] |

The merge at activity E matters: when two paths join, the start of the
next activity is set by whichever path is later in that iteration, so
the expected start is later than either path's own most likely date.
This merge bias is one reason why deterministic dates are rarely met.

## 7. Schedule results

<!-- Guidance: Show the distribution of the finish date, the confidence levels and the probability of the target. Put the deterministic date on the same chart so readers see how optimistic it is. Pitfall: reporting only the mean. -->

| Result | Working days from data date *(Example)* |
|---|---|
| Deterministic finish | 150 |
| Probability of finishing by day 150 | 4.2% |
| P10 | 154 |
| P50 | 170 |
| Mean | 171 |
| P80 | 182 |
| P90 | 189 |
| Probability of meeting the target (day 175) | 64.6% |

```mermaid
xychart-beta
  title "Cumulative probability of finish, working days (Example)"
  x-axis ["140", "145", "150", "155", "160", "165", "170", "175", "180", "185", "190", "195", "200", "205", "210"]
  y-axis "Probability of finishing by day (%)" 0 --> 100
  line [0.2, 1.1, 4.2, 11.2, 22.2, 36.1, 51.0, 64.6, 76.2, 85.1, 91.3, 95.7, 97.9, 99.3, 99.8]
```

*Example reading:* the plan of 150 days has about a 4% chance of being
met. The contract milestone at day 175 has about a 65% chance. To reach
80% confidence the team needs 182 working days, 32 more than the
deterministic plan and 7 more than the contract milestone allows.

## 8. Cost results

<!-- Guidance: Report cost at the same confidence levels as the schedule and show how much of the spread comes from schedule delay through time-dependent costs. State whether results include escalation and currency effects. -->

| Result | EUR thousands *(Example)* |
|---|---|
| Base estimate (deterministic) | 1,450 |
| Probability of finishing within the base estimate | 2.8% |
| P10 | 1,487 |
| P50 | 1,589 |
| Mean | 1,599 |
| P80 | 1,680 |
| P90 | 1,730 |
| Contingency to reach P80 | 1,680 - 1,450 = 230 |

*Example reading:* most of the cost spread comes from duration, because
every working day of delay adds EUR 6 thousand. The 32 days of schedule
growth to P80 alone explain about 192 of the 230 contingency, although
P80 cost and P80 duration do not come from the same iterations and do not
add exactly. Escalation and currency effects are excluded and are
covered in the estimate (`project/solution-estimate`).

## 9. Criticality and sensitivity

<!-- Guidance: Criticality index: share of iterations in which an activity was on the critical path. Sensitivity: how strongly each input moves the finish date across the iterations (correlation of input sample with result). Use both: an activity can be always critical but have a narrow range, so it does not drive uncertainty. -->

| Activity or driver | Criticality index *(Example)* | Correlation with finish *(Example)* |
|---|---|---|
| R1 Customs hold | n/a | 0.59 |
| B Hardware procurement | 97.4% | 0.47 |
| R2 Integration defects | n/a | 0.46 |
| E Integration testing | 100% | 0.32 |
| A Detailed design | 100% | 0.23 |
| D Lane installation | 97.4% | 0.23 |
| F Go-live and handover | 100% | 0.10 |
| C Gate software build | 2.6% | 0.01 |

*Example reading:* the two risk drivers rank first and third. The
software build (C) is almost never critical: its 15 days of float absorb
its range, so effort to speed it up would not move the finish date. The
hardware path (B then D) is critical in 97.4% of iterations.

## 10. Risk prioritisation and what-if runs

<!-- Guidance: Rank risks by how much the P80 date and cost fall when each risk is removed from the model, one at a time, with the same seed. This gives each mitigation a value in days and money that can be compared with its cost. Pitfall: ranking by probability times impact from the register, which ignores float and path logic. -->

| Run *(Example, same seed)* | P50 days | P80 days | P80 gain | P80 cost | P80 cost gain |
|---|---|---|---|---|---|
| All risks | 170 | 182 | | 1,680 | |
| R1 removed | 165 | 175 | 7 days | 1,614 | 66 |
| R2 removed | 165 | 176 | 6 days | 1,649 | 31 |
| R1 and R2 removed (uncertainty only) | 161 | 169 | 13 days | 1,577 | 103 |

| Mitigation *(Example)* | Risk | Cost | Expected effect | Decision |
|---|---|---|---|---|
| Pre-clearance with customs broker and bonded storage booking | R1 | 15 | Probability from 30% to about 10% | Recommend: costs 15, worth up to 66 at P80 if R1 is removed |
| Early interface test harness from the terminal operating system vendor | R2 | 25 | Impact range halved | Recommend if vendor confirms delivery by day 40 |
| [Mitigation] | [Risk] | [Cost] | [Effect] | [Decision] |

Re-run the model with each agreed mitigation to show the residual
position before the contingency decision in section 11.

## 11. Contingency and recommendations

<!-- Guidance: Turn the results into decisions: what date to commit, what contingency to hold, who holds it and when it can be released. Keep schedule and cost contingency explicit and separate from management reserve. -->

| Recommendation *(Example)* | Basis |
|---|---|
| Commit externally to day 182 (P80), not day 175 | 64.6% chance of day 175 is below the P80 policy |
| Or keep day 175 and fund both mitigations in section 10 | Removing R1 alone gives P80 of 175 |
| Hold schedule contingency of 32 working days as a visible buffer before go-live, owned by the project manager | P80 minus deterministic finish |
| Hold cost contingency of EUR 230 thousand (P80 minus base), released as risks retire | Section 8 |
| Re-run the analysis at hardware delivery and before integration testing | Largest drivers retire at those points |

Feed the approved contingency into the project management plan
(`project/project-management-plan`), the business case
(`business/business-case`) and the baseline. Track contingency use
through `project/earned-value-report` and `project/change-control`.

## 12. Assumptions, limitations and quality checks

<!-- Guidance: Be open about what the model leaves out. Readers trust an analysis more when its limits are stated. Have an independent reviewer check the model and the inputs. -->

| Item | Statement *(Example)* |
|---|---|
| Summary network | Six activities stand in for 412; the critical logic was preserved and tested against the full schedule |
| No correlation | Activity ranges sampled independently; real ranges that share causes would widen the result, so P80 may be optimistic |
| Triangular ranges | Chosen for transparency; tails beyond the stated maximum are not modelled |
| Risk drivers independent | R1 and R2 have no common cause |
| Excluded | Scope change, force majeure, escalation and currency |
| Expert bias | Ranges came from a facilitated workshop with prompts against anchoring on the plan |

| Quality check | Result *(Example)* |
|---|---|
| Deterministic run of the model equals the schedule's finish (150) | Pass |
| Results stable when the seed changes (P80 within 1 day) | [Pass / Fail] |
| Every driver traceable to a risk register entry | Pass |
| No duplicated uncertainty between ranges and drivers | Pass after workshop review |
| Independent reviewer has rebuilt one result | [Pass] |

Risk management principles and process: ISO 31000:2018. Register and
method templates: `compliance/risk-register`,
`compliance/risk-methodology`, `project/raid-log`. For simulation
methods in a business analytics context, see
`mba/mba-decision-analytics-guide`.

## 13. Glossary and references

<!-- Guidance: Define the probabilistic terms consistently and list every document the analysis relies on. -->

| Term | Meaning |
|---|---|
| Monte Carlo simulation | Repeated calculation of the schedule and cost with inputs drawn at random from their ranges |
| Iteration | One calculation of the model with one set of sampled inputs |
| P50, P80 | Value not exceeded in 50% or 80% of iterations |
| Risk driver | Discrete uncertain event with a probability and an impact range on named activities |
| Criticality index | Share of iterations in which an activity was on the critical path |
| Merge bias | Delay added when parallel paths join, because the later path sets the start of the next activity |
| Contingency | Time or money held for identified risks, sized from the analysis |
| Management reserve | Money held outside the project baseline for unidentified risks |

| Reference | Title | Use |
|---|---|---|
| AACE RP 57R-09 | Integrated Cost and Schedule Risk Analysis Using Risk Drivers and Monte Carlo Simulation of a CPM Model (AACE International) | Method concept (cited only) |
| AACE RP 41R-08 | Understanding Estimate Ranging | Background on ranges (cited only) |
| AACE RP 40R-08 | Contingency Estimating, General Principles | Contingency concept (cited only) |
| GAO-16-89G | GAO Schedule Assessment Guide: Best Practices for Project Schedules, December 2015 | Health check and best practice 8 (US government publication) |
| GAO-20-195G | GAO Cost Estimating and Assessment Guide, March 2020 | Cost risk and uncertainty background |
| ISO 31000:2018 | Risk management, guidelines | Risk principles (cited only) |
| [Doc ID] | Integrated schedule (`project/project-schedule`) | Model input |

## Standard and licence note

Structure aligned with the concept of AACE International Recommended
Practice 57R-09, *Integrated Cost and Schedule Risk Analysis Using Risk
Drivers and Monte Carlo Simulation of a CPM Model* (current listing:
July 2019 revision, editorial revision October 2022), with AACE RP
41R-08 and 40R-08 named for background. AACE Recommended Practices are
licensed publications: this template cites their names and numbers only,
is original text written for this collection, and reproduces no text,
tables, figures or worked examples from them. The health check and
merge bias description are based on the public US Government
Accountability Office *Schedule Assessment Guide* (GAO-16-89G, December
2015), best practices 1 to 10, and the *Cost Estimating and Assessment
Guide* (GAO-20-195G, March 2020). ISO 31000:2018 is cited by name only.
The worked example was computed for this template with a reproducible
simulation (10,000 iterations, seed 2026). Check the current editions
before relying on them.

Official text: AACE International, purchase or member access:
https://web.aacei.org/resources/publications/recommended-practices.
ISO, purchase or licensed access: https://www.iso.org/standard/65694.html.
GAO guides (free): https://www.gao.gov/products/gao-16-89g and
https://www.gao.gov/products/gao-20-195g.

Template licence: MIT.