Decisions Under Pressure
What High-Stakes Project Environments Reveal About Leadership
In the summer of 2003, a small foam strike damaged the leading edge of Space Shuttle Columbia’s left wing during launch. The damage was known. Engineers at NASA raised concerns. They requested satellite imagery to assess the extent of it. Their requests were denied by programme managers who had already decided, on the basis of incomplete analysis, that the damage was not critical.
Sixteen days later, Columbia disintegrated on re-entry. All seven crew members died.
The subsequent investigation by the Columbia Accident Investigation Board did not conclude that NASA had made a technical error. It concluded that NASA had made a decision-making error - specifically, that the organisation’s structure, culture and communication patterns had systematically prevented the people with the most relevant information from influencing the decision that mattered most.
The report’s language was unsparing. It described an organisational culture in which hierarchy suppressed challenge, in which schedule pressure distorted risk assessment, and in which the desire to maintain normalcy led decision-makers to discount information that complicated the picture they had already formed.
This is not a story about space exploration. It is a story about how complex organisations make decisions under pressure - and about the specific, predictable ways in which those decisions go wrong.
The patterns the Columbia investigation identified are not unique to NASA. They appear, with remarkable consistency, in every high-pressure decision-making environment. Including, on a smaller and less catastrophic scale, in the delivery of complex workplace projects.
The Illusion of Rational Decision-Making
The dominant model of decision-making in organisational life is rational.
We gather information. We analyse options. We assess risk. We select the course of action that best serves our objectives. We document our reasoning. We move forward with confidence.
This model is not wrong. It describes, with reasonable accuracy, how we believe we make decisions, and how we present those decisions to others after the fact.
What it does not describe, with any accuracy, is how we actually make decisions - particularly under pressure.
The work of Daniel Kahneman, developed across four decades and distilled most accessibly in his 2011 book Thinking, Fast and Slow, offers a more accurate account. Kahneman describes two systems of thought. System 1 is fast, automatic, intuitive and associative. It operates below the level of conscious awareness, drawing on pattern recognition and prior experience to generate rapid judgements. System 2 is slow, deliberate, analytical and effortful. It is the system we invoke when we believe we are reasoning carefully.
The critical insight is that System 1 does most of the work, even when we believe System 2 is in charge. Our conscious reasoning is frequently a post-hoc rationalisation of conclusions that System 1 has already reached. We feel as though we are analysing options. We are, more often than not, constructing justifications for what we have already decided.
This would be unremarkable if System 1 were reliably accurate. It is not. Kahneman’s research, and the vast body of subsequent work it has inspired, documents a consistent set of cognitive biases - systematic errors in judgement that occur predictably and that are not corrected by intelligence or expertise.
In stable, low-stakes environments, these biases are manageable. In complex, high-pressure environments - where the information is incomplete, the time is short, and the consequences of error are significant - they become the primary determinant of decision quality.
The project environment is precisely such an environment. And the leaders who navigate it most effectively are not those who are free from cognitive bias. They are those who understand it well enough to counteract it.
The Biases That Shape Project Decisions
There are dozens of documented cognitive biases. Four are particularly consequential in the context of complex project delivery.
Optimism bias.
Humans are systematically overoptimistic about the probability of positive outcomes and underestimistic about the probability of negative ones. We consistently underestimate how long tasks will take, how much they will cost, and how many things will go wrong. Research by Oxford professor Bent Flyvbjerg, who has studied the cost and schedule performance of major infrastructure projects across decades and geographies, finds that projects are delivered on time and within budget far less frequently than project plans predict - not because project managers are incompetent, but because project plans are systematically produced by optimistic humans who are subject to exactly the biases that Kahneman describes. The programme you are presenting to your client at the start of a project is, in all likelihood, more optimistic than the reality that awaits. The question is not whether this is true but by how much - and what mechanisms are in place to surface the gap before it becomes a crisis.
The sunk cost fallacy.
Once an investment of time, money or effort has been made, humans find it psychologically difficult to abandon the course of action that produced it - even when the rational case for doing so is overwhelming. We continue to invest in failing projects because we have already invested so much. We persist with approaches that are clearly not working because changing course would require us to acknowledge that the previous investment was wasted. In a project context, the sunk cost fallacy operates at every scale. It appears in the reluctance to revisit a brief that has already consumed months of design development. It appears in the resistance to changing a contractor who is clearly underperforming. It appears in the unwillingness to acknowledge that a project has drifted significantly from its original intent, because acknowledging the drift would require difficult conversations that everyone is hoping to avoid.
Groupthink.
When cohesive groups face pressure to reach consensus, the quality of their decision-making frequently deteriorates. Individual members suppress doubts in order to preserve harmony. Dissenting views are marginalised. The group converges on a position not because it is the best available but because it is the one that everyone can live with. Irving Janis, who coined the term in 1972, identified several conditions that tend to produce it: high group cohesiveness, insulation from outside opinion, strong directive leadership, and high decision stress. All four are regularly present in project decision-making environments. The project that never seems to surface bad news is not a well-run project. It is a project team that has succumbed to groupthink - in which the social cost of raising problems has come to feel higher than the professional cost of ignoring them.
Confirmation bias.
Once we have formed a view, we selectively attend to information that confirms it and discount information that challenges it. We ask questions designed to validate our existing hypothesis. We interpret ambiguous data in ways that support our preferred conclusion. In a project context, confirmation bias operates most destructively in the assessment of risk. A project team that has decided a contractor is performing adequately will interpret ambiguous progress reports as adequate. A project manager who has concluded that a programme is on track will interpret slippage in individual activities as recoverable rather than systemic. The antidote is not more information. It is the deliberate cultivation of disconfirmation - the active search for evidence that challenges the current hypothesis, and the creation of conditions in which that evidence can be raised without social or professional cost.
“The project that never surfaces bad news is not a well-run project. It is a project team in which the social cost of raising problems has come to feel higher than the professional cost of ignoring them.”
What Pressure Does to Decision-Making
Understanding cognitive bias is necessary but insufficient. Bias operates in all conditions. What makes the project environment distinctive is the specific way in which pressure interacts with those biases to compound their effects.
Under pressure, several things happen simultaneously.
Attention narrows. The field of information that decision-makers actively consider shrinks to the most immediately salient inputs - the things that are loudest, most urgent, or most proximate. Information that is important but not urgent is systematically under-attended to. The early warning signals that might avert a crisis are present in the data but are not reaching the people who need to act on them.
Time horizons compress. The pressure to solve today’s problem crowds out thinking about tomorrow’s consequences. Short-term solutions that create long-term problems become attractive. The value engineering exercise that saves cost this month creates operational problems next year. The programme acceleration that hits the handover milestone stores up quality defects that will cost more to resolve in occupation than they would have in construction.
Hierarchy becomes more pronounced. Under pressure, organisations tend to become more hierarchical, not less. The conditions that make challenge feel risky - deference to seniority, fear of the consequences of raising bad news - intensify. The information gradient between the people who know what is happening on the ground and the people who are making decisions about it widens precisely when it should be narrowing.
Social cohesion is prioritised over accuracy. In high-pressure moments, the desire to maintain team cohesion and avoid conflict frequently overrides the commitment to honest assessment. The project manager who knows the programme is slipping but presents a confident update because the client meeting is already tense. The contractor who knows a quality issue is significant but manages it quietly because raising it formally would trigger a difficult conversation. The cost consultant who absorbs a budget overrun into contingency rather than flagging it explicitly because the project director has already committed to the client that costs are under control.
Each of these individual choices is understandable. Collectively, they produce the pattern that the Columbia investigation identified: an environment in which the information that is most needed for good decisions is systematically prevented from reaching the people who need to make them.
The Leader’s Role in Counteracting These Dynamics
The research on decision-making under pressure is not, ultimately, pessimistic. It does not conclude that cognitive bias is insurmountable or that high-pressure environments inevitably produce poor decisions. What it concludes is that good decisions under pressure require deliberate leadership intervention - that the conditions for accurate, timely, high-quality decision-making must be actively created, because they do not arise naturally.
Several interventions are supported by the evidence.
Create explicit permission for challenge.
The single most powerful intervention available to a leader in a project environment is the explicit establishment of challenge as a professional norm rather than a social transgression. This requires active, visible behaviour - not a stated policy but a demonstrated practice. The leader who regularly asks “what are we missing?” rather than “are we agreed?”, who responds to challenge with curiosity rather than defensiveness, who thanks the person who raises the uncomfortable question rather than marginalising them, is creating the conditions in which Kahneman’s System 2 can actually operate. The teams that make the best decisions under pressure are not those with the most talented individuals. They are those in which psychological safety is highest - in which every member feels safe enough to share what they actually know, suspect and fear, rather than what they believe their leader wants to hear.
Introduce structured devil’s advocacy.
One of the most effective countermeasures to groupthink is the formal assignment of a devil’s advocate role - someone whose explicit responsibility is to challenge the emerging consensus, surface the arguments against the preferred course of action, and represent the interests of the information that the group is inclined to discount. Groups that include a formal devil’s advocate consistently make better decisions than groups that do not, even when the devil’s advocate is known to be arguing a position they do not personally hold. A pre-mortem - the technique developed by psychologist Gary Klein, in which a team imagines that the project has already failed and works backwards to identify what caused it - is one of the most powerful and accessible applications of this principle. Conducted at the start of a project or at key decision points, it surfaces the concerns and doubts that individuals hold privately but have not felt safe to raise publicly.
Slow down at the moments that matter most.
Kahneman’s prescription for improving decision quality under pressure is deceptively simple: introduce friction at the moments when fast, automatic thinking is most likely to produce error. Require explicit documentation of the reasoning behind significant decisions. Build in deliberate pause points before major commitments. Ask teams to articulate - in writing, not just verbally - the assumptions on which their recommendations depend and the conditions under which those assumptions would prove wrong. In a project context, this translates to a set of governance disciplines applied at the critical junctures of every programme: before a procurement decision, before a contractor is appointed, before a value engineering exercise is agreed, before a programme is compressed. These are the moments when the pressure is highest and the cognitive biases are most active. They are also the moments when the consequences of poor decision-making are most significant and most durable.
Maintain the information gradient.
The widening gap between the information available at the front line of a project and the information available to decision-makers at the top of the hierarchy is one of the most consistent predictors of project failure. Maintaining a narrow gradient - ensuring that senior decision-makers have access to the actual picture of project performance, not the managed version that has passed through layers of interpretation and political calculation - is one of the most important functions that a well-structured governance framework can serve. Culturally, this requires an environment in which bad news travels upward without penalty. Structurally, it requires reporting frameworks that make it difficult to obscure emerging issues and escalation processes that are fast enough to be useful rather than so formal that they create disincentives to use them.
“The project manager is not simply a coordinator of activity or a tracker of progress. They are the architect of the decision-making environment - and the quality of that environment determines the quality of the project.”
The Project Manager as Decision Architect
The discipline of decision-making under pressure is not, in the end, about individual cognitive excellence. It is about system design.
The insight from Kahneman, Edmondson, Lencioni, Janis and the generations of researchers who have studied how groups and organisations make decisions under pressure is consistent: the quality of decisions in complex, high-pressure environments is determined less by the intelligence of individual decision-makers than by the quality of the environment in which those decisions are made.
This reframes the project manager’s role in a significant way.
The project manager is not simply a coordinator of activity or a tracker of progress. In the most important sense, the project manager is the architect of the decision-making environment. They design the governance structures that determine how information flows. They create the cultural conditions that determine whether challenge is welcomed or suppressed. They establish the rhythms and disciplines - the pre-mortems, the structured reviews, the escalation processes - that determine whether the team’s collective intelligence is available to the decisions that need it.
This is leadership. Not in the heroic, individual sense that the word often implies - not the lone figure who sees what others cannot and acts when others will not. But in the systemic sense that the research supports: the patient, deliberate creation of conditions in which groups of people can consistently make better decisions than any of them could make alone.
The project manager who understands this - who sees their role not as managing a programme but as architecting a decision-making environment - is providing something qualitatively different from sophisticated administration. They are providing the conditions in which a complex project can navigate the inevitable uncertainty and pressure of delivery without the cognitive biases and organisational dynamics that so reliably produce failure.
The Question Worth Asking
The most useful thing a project leader can do, at the outset of any complex programme, is not to finalise the Gantt chart or agree the reporting cadence.
It is to ask, honestly, how this project will make its most important decisions - and whether the environment being created will produce the quality of decision-making that the project deserves.
Not who will be in the room, but what will happen in the room. Not what the process says, but what the culture permits. Not what the governance framework requires, but what the team’s actual dynamics will allow.
These are the questions that determine, more than any other factor, whether a project succeeds or fails.
And they are, almost universally, the questions that are never asked.
goo collective is a senior-led project management and cost consultancy working at the intersection of commercial expertise and human performance. We build decision-making environments as carefully as we build programmes - because in complex projects, the quality of decisions is the quality of the outcome.