Project Risk Tolerance — Setting the Threshold for Go/No-Go Decisions
Before any analysis can produce a meaningful recommendation, your organization needs to answer one foundational question: what minimum probability of success are you willing to accept? Defining your risk tolerance threshold is what turns a probability number into a decision.
What Is Project Risk Tolerance?
Project risk tolerance is the minimum probability of success your organization is willing to accept before committing resources to a project. It is not a measure of how risky a project is — it is a statement of how much risk your organization is prepared to carry in pursuit of the upside.
The concept is straightforward in practice. If you require a 70% probability of on-time, on-budget delivery, that is your threshold. Any project that does not meet it gets a No-Go. A project that exceeds it gets a Go. A project that is close might get a Conditional — proceed, but address the specific risks bringing the number down first.
Without a defined threshold, probability numbers are meaningless for governance purposes. “There is a 62% chance this project succeeds” invites debate. With a threshold of 70%, that number is an unambiguous signal. With a threshold of 55%, the same number is a clear green light. The threshold is what converts analysis into a recommendation.
Incertive uses Monte Carlo simulation to produce a probability of success for every project plan you analyze. You define your threshold, the simulation runs, and the platform compares the two — delivering a Go, No-Go, or Conditional verdict with the full probability distribution behind it.
Why Defining It Matters
Removes Subjectivity
Without a defined threshold, approval decisions depend on whoever argues most persuasively in the room. A pre-committed threshold moves the conversation from “I feel good about this” to “the data meets or does not meet our stated standard.” This reduces the influence of optimism bias, seniority, and political pressure on decisions that should be driven by evidence.
Creates Organizational Consistency
When every project is evaluated against the same standard, your portfolio of approved projects reflects a coherent risk profile rather than a random collection of whoever made the strongest case. Program managers can compare projects across the portfolio on equal footing. Executives can see immediately which projects are operating near the threshold and which have comfortable margins.
Makes the Recommendation Defensible
When a project is approved or rejected, stakeholders inevitably ask why. A documented threshold and a probability-backed verdict give you a clear, auditable answer: the project met our standard, or it did not. This is especially important for governance, audit, and post-mortem reviews where the reasoning behind decisions needs to withstand scrutiny months or years after the fact.
How Different Organizations Set Thresholds
Risk tolerance varies significantly by organizational culture, industry, and project type. Here is how threshold ranges typically map to organizational posture:
How Incertive Uses Your Threshold
You Define Your Threshold
When you set up a project analysis in Incertive, you specify the minimum probability of success your organization requires for this type of project. You can use a portfolio-wide standard, a project-category standard, or a threshold specific to this decision. Incertive stores this alongside the project description so the full decision context is preserved.
The Simulation Runs
Incertive analyzes your project plan, identifies the uncertain variables, and runs a Monte Carlo simulation across thousands of scenarios. Each scenario samples from the plausible range of every uncertain input and calculates whether the project achieves its stated objectives. The result is a full probability distribution showing how often the project succeeds across the simulated range of futures.
Result Compared to Threshold — Go/No-Go Verdict Delivered
The simulation's success probability is compared directly to your threshold. If the probability clears the threshold, Incertive delivers a Go verdict. If it falls below, the verdict is No-Go. If the probability is close to the threshold — within a range where targeted risk reduction could shift the outcome — the verdict is Conditional, with specific recommendations for which risk factors to address. Every verdict includes the full probability distribution, the key drivers, and the reasoning behind the recommendation.
Frequently Asked Questions
What is a good risk tolerance threshold for most projects?
For most organizations, a threshold in the 65–75% range is a reasonable starting point for standard internal projects. That means you are requiring at least a 65–75% probability of achieving your core objectives before committing full resources. However, there is no universally correct number. A regulatory compliance project with severe penalties for failure may warrant an 85% threshold, while an exploratory innovation initiative might proceed at 55% because the upside justifies the higher uncertainty. The right threshold is the one that reflects the actual consequences your organization faces if the project fails — financially, reputationally, and operationally.
Should different types of projects have different thresholds?
Yes, and most mature project governance frameworks treat threshold-setting as project-specific rather than organization-wide. A few dimensions that typically drive threshold differences: the reversibility of the commitment (a phased pilot is more forgiving than a full deployment), the financial exposure relative to reserves, the strategic importance of the outcome, and the existence of fallback options. Many organizations define threshold tiers by project category — for example, infrastructure replacements at 80%, new product launches at 65%, and experimental pilots at 50%. The key is to define these tiers explicitly rather than letting every project manager negotiate their own threshold at approval time.
Who in the organization should set the risk tolerance?
Risk tolerance is ultimately a governance decision, which means it should be set or ratified at the level that controls the resources being committed. For project-level decisions, that is typically the project sponsor or steering committee. For portfolio-level decisions, it is often the executive team or a dedicated investment committee. Program managers and project managers should inform the threshold discussion by surfacing what the data actually shows — the probability distribution, the key drivers, and the range of outcomes — but they should not set the threshold unilaterally. Organizations that allow teams to self-select their own thresholds tend to see threshold inflation over time: teams lower the bar to get the approval they want rather than the approval the project deserves.
How does risk tolerance connect to go/no-go decisions?
Risk tolerance is the mechanism that converts a probability into a recommendation. Without a defined threshold, a 62% success probability is just a number — it does not tell you whether to proceed. With a threshold of 70%, that same number is an unambiguous No-Go. With a threshold of 55%, it is a clear Go. The threshold transforms probabilistic output into a binary decision, which is exactly what project governance requires. Incertive embeds this logic directly into its go/no-go verdict: you define your threshold, the simulation produces a success probability, and the platform compares the two to deliver a Go, No-Go, or Conditional recommendation with a clear rationale. This removes the ambiguity that causes approval meetings to drag on without resolution.
Can Incertive model different risk tolerance scenarios?
Yes. Incertive lets you run the same project analysis against multiple threshold settings so you can see how the recommendation changes as you adjust your tolerance. This is particularly useful in two situations. First, when the executive team has not yet agreed on a threshold and wants to understand what different standards would imply for a specific project. Second, when a project is borderline — close to the threshold — and you want to understand whether targeted risk reduction could tip it into Go territory. By modeling the sensitivity of the verdict to both the threshold and the underlying risk factors simultaneously, Incertive gives decision-makers a much richer picture than a static probability number alone.
Explore More
Set Your Threshold. Get a Defensible Answer.
Describe your project, define your risk tolerance, and Incertive runs the simulation — delivering a probability-backed go/no-go verdict you can stand behind.
Start Free Trial