In project management, cost and schedule are often estimated, tracked, and analyzed separately, treated as two different reporting requirements. But real projects don’t behave that way — cost and schedule are correlated, since delays drive costs and cost pressures can compress schedules. The old cliché “time is money” is a truism.

This is why Joint Confidence Level (JCL) analysis has become such an important tool in modern project governance. It provides a unified view of cost and schedule risk, and it connects directly to the organization’s risk appetite and risk tolerance.

What JCL Really Measures

A JCL is the probability that a project will meet both its cost and schedule targets simultaneously. Instead of asking:

• “What’s the chance we finish on time?”
• “What’s the chance we stay within budget?”

JCL asks the more realistic question:

“What’s the chance we achieve both?”

This matters because cost and schedule risks are rarely independent. A risk event that delays a critical path activity often increases labor, overhead, or escalation costs. JCL captures these interactions in a way that single-dimension analysis cannot.

Why JCL Matters for Governance

Organizations with mature risk practices use JCL as a decision gate. NASA, for example, has long required major programs to meet a minimum JCL threshold (often around 70%) before proceeding through key milestones.

The logic is simple:

A low JCL indicates that cost and schedule risks are interacting in ways that threaten project success.

A high JCL indicates that the project has sufficient contingency and a realistic plan.

JCL becomes a health indicator — a single metric that reflects the combined effect of uncertainty across the entire project.

Using JCL to Set Risk-Adjusted Contingencies

JCL provides a natural way to convert Monte Carlo results into actionable contingency levels:

1. Run a joint cost-schedule Monte Carlo simulation.
2. Identify the cost and schedule values at the target JCL (e.g., JCL70).
3. Set contingency as the difference between the baseline and the JCL values.
4. Validate against tolerance to ensure the result is within acceptable limits.

This creates a transparent, defensible method for establishing reserves — one that reflects both the organization’s risk posture and the project’s actual uncertainty.

JCL as a Core Capability in RiskyProject

In many organizations, JCL is treated as a special, occasional exercise: a summary model is built, a separate Monte Carlo tool is run, and the results are reconciled back into the project’s real cost and schedule data by hand. That extra step is where confidence in the result — and often the result itself — tends to get lost.

RiskyProject takes a different approach. Joint cost-and-schedule risk analysis is built into the platform’s risk engine rather than layered on top of it, so JCL is available as a standard part of the same environment where the schedule and cost model already live — not a separate workflow analysts have to maintain. Risk-adjusted contingencies, JCL curves, and tolerance checks are generated from the same integrated simulation, which keeps the cost and schedule story consistent and makes JCL practical to run regularly rather than as an occasional, resource-intensive exercise.

The Value: A More Realistic View of Project Risk

JCL doesn’t replace traditional cost or schedule analysis — it integrates them. It provides a more realistic picture of how risks propagate through a project and how cost and schedule interact under uncertainty.

When combined with clearly defined risk appetite and tolerance, JCL becomes a powerful governance tool that:

• Improves predictability
• Supports consistent decision-making
• Reduces optimism bias
• Aligns project teams and executives around a shared understanding of risk

In short, JCL helps organizations make better decisions — not because it eliminates uncertainty, but because it makes uncertainty visible, measurable, and manageable. And when JCL is built into the tools teams already use to manage cost and schedule, that visibility is available every time it’s needed, not just when there’s time to build a special model for it.