Schedule risk analysis estimates the probability that a program will meet a milestone or completion date. It applies uncertainty and discrete risks to a logic-driven schedule, runs many simulated outcomes and produces a range of possible finish dates.
A deterministic Integrated Master Schedule (IMS) provides one forecast based on one set of durations. An SRA answers the harder questions: How likely is that date? How much schedule contingency supports an acceptable confidence level? Which activities and risks drive the result?
The analysis does not replace critical path analysis or sound scheduling judgment. Instead, it tests the entire network under uncertainty. Therefore, it can expose vulnerable paths that the deterministic critical path does not reveal.
What Is Schedule Risk Analysis?
A schedule risk analysis, also called a schedule risk assessment or SRA, uses statistical simulation to evaluate how uncertainty may affect scheduled dates. Most quantitative SRAs use Monte Carlo simulation. During each iteration, the model samples activity durations and risk impacts, recalculates the network and records the resulting milestone dates.
After many iterations, the model produces a probability distribution rather than a single finish date. The GAO Schedule Assessment Guide describes SRA as a method for predicting confidence in a completion date, determining the time contingency needed for a selected confidence level and identifying high-priority risks.
The analysis should distinguish two related inputs:
- Duration uncertainty represents normal variation in how long planned work may take. Productivity, staffing, learning curves and estimating accuracy can create this variation.
- Discrete risks are identifiable events or conditions that may occur. Examples include late Government-Furnished Equipment (GFE), test failure, supplier disruption or delayed design approval.
Those inputs can overlap. Therefore, the analyst must avoid counting the same exposure in both an activity range and a discrete risk event.
Why a Deterministic Finish Date Is Not Enough
The critical path method calculates dates from the durations and relationships currently stored in the schedule. However, those durations remain estimates. A 20-day activity may finish in 17 days, 20 days or 31 days depending on the work and its uncertainties.
In addition, several parallel paths may converge on the same review, integration event or delivery. Each path may appear achievable on its own. Still, the milestone cannot occur until every required path finishes. This effect, often called merge bias, can make the combined milestone less achievable than a deterministic schedule suggests.
As a result, an SRA must include more than the current critical path. Near-critical paths can become critical when sampled durations change. Program teams should already monitor these paths through routine near-critical path analysis, but SRA quantifies how often each path may drive a milestone.
What an SRA Should Tell Management
A useful SRA produces management information, not just charts. At a minimum, the results should address:
- The probability of meeting the current forecast or contractual milestone.
- The dates associated with selected confidence levels, such as P50 or P80.
- The schedule contingency required to support a chosen confidence level.
- The activities and paths that most often become critical.
- The uncertainties and discrete risks with the greatest influence on completion.
- The effect of proposed mitigation, recovery or alternative execution strategies.
A P80 date represents the date the simulation finishes on or before in 80 percent of its iterations. It does not guarantee success. Likewise, P50 is not automatically the correct baseline date, and P80 is not a universal government requirement. The appropriate confidence level depends on program policy, risk tolerance, acquisition strategy and any applicable contract direction.
How to Perform a Schedule Risk Analysis
1. Define the decision and milestone
First, identify what management needs to decide. The analysis may focus on contract completion, Critical Design Review, first article delivery, test readiness or another key event.
Also define the schedule version, status date, included scope and data cutoff. Without that information, reviewers cannot reproduce or compare the results.
2. Validate the schedule network
An SRA cannot repair an invalid schedule. Missing logic, excessive constraints, unexplained lags, incorrect calendars and out-of-sequence progress can distort the simulation. In addition, summary schedules may hide the work and merge points that create risk.
Before modeling uncertainty, confirm that the IMS has a valid critical path and credible relationships. The schedule should also include all remaining work needed to reach the analyzed milestone. The DCMA 14-point schedule assessment can support schedule health reviews, although passing those checks alone does not prove that the schedule is suitable for SRA.
Schedulers should also complete a normal critical path analysis. This provides a deterministic reference for comparing the simulation results.
3. Develop uncertainty ranges
Next, assign uncertainty to appropriate remaining activities. A common method uses three-point duration estimates:
- Optimistic: a credible shorter duration if conditions go well.
- Most likely: the duration expected under normal conditions.
- Pessimistic: a credible longer duration if foreseeable difficulties arise.
These values require technical input. Control Account Managers (CAMs), engineers, procurement leads, test personnel and suppliers should explain the assumptions behind each range. Historical performance and comparable work provide stronger support than arbitrary percentages.
For a detailed estimating method, see three-point estimating for schedule durations. The team should document whether the most-likely value matches the current IMS duration and explain any material difference.
4. Model discrete risks and opportunities
Import or map relevant risks from the program risk register. Each modeled risk should have a probability of occurrence, an impact distribution and a clear connection to affected activities or milestones.
For example, a late GFE delivery may delay equipment integration and several dependent test activities. Assigning the risk only to the final delivery milestone would hide its effect on the network. The risk should act where the event would actually disrupt the plan.
Review both threats and credible opportunities. However, do not use unsupported opportunities to offset well-understood threats. Programs that depend on customer-furnished items should also review the planning considerations in Government-Furnished Equipment and schedule risk.
5. Address correlation
Activities rarely vary independently. The same labor shortage, supplier problem or design instability may affect several tasks at once. If the model treats those activities as independent, positive and negative variations may cancel unrealistically.
Analysts can address correlation directly or through risk drivers assigned to multiple activities. The method should fit the available data and tool. More importantly, the SRA report should document the approach because correlation can materially change the completion distribution.
6. Run the simulation and test the model
Run enough iterations for the key outputs to stabilize. Then check whether the results make practical sense. Review unusually early or late outcomes, changing critical paths, calendar behavior and the treatment of completed work.
Do not risk completed activities as if their actual durations remain uncertain. Also remove or correctly handle existing contingency before calculating new contingency. Otherwise, the model may count the same protection twice.
7. Analyze and communicate the results
The cumulative probability curve, commonly called an S-curve, maps completion dates to confidence levels. However, the curve alone does not tell management what to do.
Pair it with driver analysis. Common outputs include:
- Criticality index: the percentage of iterations in which an activity appears on the simulated critical path.
- Duration sensitivity: the statistical relationship between variation in an activity and variation in the finish date.
- Risk sensitivity: the relative influence of discrete risks on the selected milestone.
- Contribution to contingency: the estimated time reduction achieved when a risk or uncertainty is removed from the model.
No single metric provides the full answer. For example, an activity may frequently become critical but have little duration variability. Another activity may become critical less often yet cause severe delay when it does.
Fictional Program Example
Assume the Falcon Ridge communications program has a deterministic qualification-complete date of September 15. The IMS contains parallel paths for flight software, prototype hardware, GFE installation and environmental qualification.
The SRA produces these fictional results:
- Probability of meeting September 15: 28 percent.
- P50 completion date: October 6.
- P80 completion date: November 3.
- Difference between the deterministic date and P80: 49 calendar days.
The deterministic critical path runs through prototype fabrication. However, the simulation shows that flight software integration becomes critical in 61 percent of iterations. A GFE delivery risk and environmental test rework also rank among the top drivers.
The program team should not simply move the date to November 3. Instead, it should evaluate actions against the drivers. For example, the team could add an early software integration build, obtain earlier GFE interface data and conduct test-readiness reviews before entering the chamber.
After modeling those actions, the team reruns the SRA. The revised results then support a risk-informed forecast, contingency decision and mitigation plan.
Schedule Contingency Is Not Total Float
Total float comes from schedule logic, calendars, durations and constraints. It measures how long an activity or path may slip before affecting a calculated milestone or successor date.
Schedule contingency serves a different purpose. It protects a target date against quantified uncertainty and risk. The Department of Energy Performance Baseline Guide discusses using Monte Carlo simulation and duration ranges to quantify schedule contingency.
A common method compares the deterministic finish with a date at the selected confidence level. However, the placement, ownership and use of contingency vary by organization, agency and contract. Do not hide contingency inside inflated activity durations or unexplained logic. Any contingency incorporated into a controlled baseline should follow the program’s approved change-control and baseline-management processes.
Schedule contingency also differs from EVMS management reserve. Management reserve is budget held for management control purposes, not a block of schedule time.
Contractual Requirements Versus Recommended Practice
SRA is a recognized scheduling practice, but it is not automatically a deliverable on every federal or DoD contract. The solicitation, contract data requirements, statement of work, Integrated Master Plan and IMS instructions, and program-specific tailoring determine what the contractor must submit.
The DoD IMP and IMS Preparation and Use Guide discusses narrative, technical and statistical schedule risk analysis. It describes statistical SRA as a Monte Carlo-type analysis that can be performed by the offeror, procuring activity or both. Guidance language should not be treated as a contract clause unless the solicitation or contract makes it binding.
Likewise, FAR 34.202 requires an Integrated Baseline Review when an Earned Value Management System is required and directs the review to assess schedule realism and inherent risk. However, that provision does not itself prescribe a Monte Carlo SRA deliverable.
Therefore, proposal and execution teams should read the actual contract direction. If the customer requires an SRA, confirm the required milestones, data format, confidence levels, frequency, risk methodology and supporting narrative.
Using SRA During Execution and EVMS
SRA should not end after the baseline review. Risks retire, durations change and new execution data becomes available. Therefore, programs should update the analysis at meaningful decision points and after major changes to scope, logic, risk exposure or execution strategy.
Useful triggers include a rebaseline, major supplier disruption, significant test failure, material change to the risk register or a forecast slip to a key contractual milestone. The NASA Schedule Management Handbook also presents schedule assessment and risk analysis as recurring management activities rather than one-time exercises.
Still, an updated SRA does not authorize a baseline change. The program must process any resulting PMB revision through its approved change-control system. For related EVMS considerations, see how schedule changes affect the Performance Measurement Baseline.
Common SRA Failure Modes
- Running SRA on broken logic: The simulation produces precise-looking but unreliable output.
- Risking only the deterministic critical path: This prevents alternate and near-critical paths from emerging.
- Using arbitrary ranges: Standard percentages applied to every activity ignore differences in work type and maturity.
- Double-counting risk: The model includes the same exposure in duration ranges and discrete risk events.
- Ignoring correlation: Related activities vary independently even though a common cause affects them.
- Treating P80 as universally required: The selected confidence level should come from governing direction or an explicit management decision.
- Presenting only an S-curve: Management receives a date distribution without the drivers or mitigation choices.
- Confusing contingency with float: The schedule team treats calculated float as risk protection.
- Failing to preserve assumptions: Reviewers cannot reproduce the analysis or explain changes between runs.
Practical SRA Review Checklist
- Does the IMS contain all remaining scope needed for the analyzed milestone?
- Does the schedule have valid logic, calendars and status?
- Are duration ranges credible and supported by technical owners?
- Are discrete risks mapped to the activities they would affect?
- Has the analyst prevented double-counting between uncertainty and risks?
- Does the model address correlation or common risk drivers?
- Are the deterministic date, current forecast and contractual date clearly distinguished?
- Do the results show confidence dates, criticality and sensitivity?
- Are mitigation actions tied to the leading drivers?
- Can another analyst reproduce the run from the documented assumptions?
Schedule Risk Analysis FAQ
Is SRA the same as critical path analysis?
No. Critical path analysis calculates the driving path from the schedule’s current durations and logic. SRA varies durations and risks across many iterations to identify possible finish dates and paths that may become critical.
Must every activity receive a three-point estimate?
Not necessarily. The modeling approach should cover all material uncertainty without creating unmanageable data collection. However, excluding large portions of remaining work can understate risk. Any summary or filtering method needs a documented rationale.
How often should an SRA be updated?
No universal frequency applies to every program. Update it often enough to support decisions and reflect material changes in status, logic, uncertainty and the risk register. Contractual reporting frequency, when specified, takes precedence.
Can Microsoft Project perform a complete Monte Carlo SRA by itself?
Microsoft Project can provide the underlying logic-driven schedule, but quantitative Monte Carlo analysis commonly requires compatible risk-analysis software or another analytical environment. Regardless of the tool, the scheduler must validate calendars, logic, constraints and status before exporting or analyzing the model.
Final Interpretation
A credible SRA converts an IMS from a single-date forecast into a risk-informed decision model. It shows how likely the current plan is, where the plan may fail and which mitigation actions can improve the outcome.
The value does not come from selecting the most conservative percentile. It comes from using credible schedule logic, defensible uncertainty, mapped risks and transparent assumptions. When those elements are in place, schedule risk analysis gives program managers a practical basis for setting dates, managing contingency and focusing attention on the work most likely to control program success.