A project rarely fails because nobody made a decision. More often, it fails because people made decisions too late, on weak information, or without being clear about who owned the consequences. Knowing how to improve project decisions is therefore less about finding a clever framework and more about building the conditions for sound judgement when pressure rises.
This matters in protective security, resilience and operational change. A delayed decision on access control, contractor competence, system integration or response arrangements can create risk that is expensive to unwind later. The same is true in any project with a fixed opening date, multiple suppliers or an exposed public-facing environment. Good governance does not protect a project if the people within it cannot recognise an issue, assess it and act.
Start with the decision, not the meeting
Many project teams spend too much time discussing status and too little time defining the decision that is actually required. A weekly meeting becomes a place where risks are read aloud, updates are given and actions are carried forward. Everyone leaves busy, but the point of uncertainty remains.
Before a decision meeting, state the decision in one sentence. For example: should the project accept a temporary technical workaround, delay deployment, or change the operating model? That framing forces the team to distinguish between a problem to investigate and a choice that needs an owner.
It also prevents a common failure: treating agreement as a decision. A room can agree that an issue is serious while nobody agrees to fund, approve or implement a response. The project then drifts behind polite language such as “under review” or “being considered”.
A useful test is simple. At the end of the discussion, can someone state what has been decided, who owns the next step, what assumptions apply and when the decision will be reviewed? If not, the meeting has produced conversation rather than control.
Separate facts, assumptions and preferences
Projects are full of statements that sound factual but are not. “The supplier will resolve it.” “Operations will manage.” “The deadline cannot move.” Sometimes these are true. Often they are assumptions that have gained authority through repetition.
Decision quality improves when teams separate three things: what is known, what is assumed and what people prefer. These categories should not be merged in a slide deck or buried in a risk register. They need to be challenged openly.
Consider a venue preparing a new security arrangement before a major event. The project team may know that a physical system will be installed by a given date. It may assume that staff will be trained and competent before handover. It may prefer not to alter visitor flows because this would affect the commercial plan. Those are very different propositions. If the training assumption fails, the technical installation alone does not provide capability.
This is where experienced project leadership earns its value. It asks what evidence supports the claim, what would make it untrue and what the operational consequence would be. That is not pessimism. It is the discipline that stops a plan being mistaken for reality.
Improve project decisions by setting decision rights early
Unclear authority creates delay, workarounds and resentment. A project manager may be accountable for delivery but unable to approve a design change. A security lead may identify an unacceptable risk but lack a defined route to escalation. Operations may inherit the finished system without having had enough influence over whether it can actually be used.
These gaps are usually visible early, yet teams often avoid resolving them because senior stakeholders do not want to limit their options. The result is predictable. Routine choices become escalations, urgent choices are made informally, and significant decisions are revisited when a more senior person takes interest.
Set decision rights at the beginning and revisit them when the project changes shape. This does not require a large governance document. It requires clarity on who recommends, who decides, who must be consulted and who must be told. The important point is that the authority matches the consequence. Someone cannot be held responsible for delivery if they have no influence over the decisions that determine it.
For higher-risk work, record the escalation threshold. Define which risks can be accepted within the project team and which require senior approval. A known, documented risk may still be acceptable. An unowned risk is not.
Use time properly, especially when urgency is genuine
Pressure can sharpen judgement, but false urgency degrades it. Teams often treat every issue as immediate because the project is already under strain. That encourages rushed approvals and suppresses challenge. It also means genuinely urgent issues receive no more attention than routine ones.
A better approach is to identify the decision horizon. What must be decided now because delay closes an option? What needs more evidence within 48 hours? What can wait until the next formal review without increasing exposure? These are not administrative distinctions. They determine whether the team has enough time to think.
When a decision cannot wait, reduce the question rather than pretending certainty exists. Decide the minimum safe action, establish who will monitor the outcome and set a specific point for reassessment. In a live operational environment, a reversible decision with close oversight is often better than waiting for perfect information. But reversibility must be real. Some decisions, such as accepting a weak handover or commissioning an arrangement that staff do not understand, create consequences that are difficult to retrieve.
Bring operational reality into the room
Projects commonly make decisions on behalf of the people who will use, maintain or respond through the finished arrangement. That is a weakness, particularly in security and resilience work. A technically compliant design can still fail if it adds unmanageable workload, creates unclear responsibilities or assumes behaviours that will not hold under pressure.
Operational colleagues should not be consulted only at the end, when the cost of changing course is highest. Their input is most valuable when choices are still open. Ask them how the arrangement will work at a busy time, during staff shortages, when communications are poor or when a supervisor has to make a rapid judgement.
This does not mean every operational preference should determine the project. Users can resist necessary change, and familiarity is not the same as effectiveness. It does mean that a project must test its assumptions against the conditions in which the system, process or plan will actually operate.
A useful challenge is to ask: who has to make this work at 02:00 on a difficult day? If the answer is absent from the decision, the team may be designing for an ideal environment that does not exist.
Create a decision record people will use
A decision log is often treated as project administration. Used properly, it is a learning tool and a control measure. It should be short enough to maintain and useful enough to revisit.
For each material decision, capture the issue, options considered, evidence available, decision owner, chosen action, assumptions and review date. Add the expected outcome. Without this, teams cannot tell whether a decision was sound but produced an unexpected result, or whether the original judgement was weak.
The record also protects against institutional amnesia. Staff change, suppliers rotate and months pass between design and handover. Later, people may challenge a decision without understanding the constraints that existed at the time. A clear record does not make the original choice beyond criticism, but it makes review honest.
Avoid using the log to defend every decision. Its purpose is not to prove that the project was right. Its purpose is to expose whether assumptions remain valid and whether action is producing the intended effect.
Make challenge part of the process
The best project teams do not rely on confidence alone. They create room for informed dissent before a decision becomes difficult to reverse. This is especially important when seniority, commercial pressure or a fixed deadline makes agreement feel inevitable.
Assign someone to test the preferred option. Their role is not to be obstructive. It is to identify failure points, missing evidence and unintended consequences. The question is not “why will this fail?” but “what would have to be true for this to work, and have we checked it?”
A short pre-mortem can be effective. Ask the team to imagine that the project has gone wrong six months after delivery. What decisions contributed? What warning signs were missed? What was accepted because nobody wanted to be the person who delayed progress? The answers often reveal issues that a standard risk review has normalised.
Build capability, not dependency
A project cannot make better decisions if every judgement waits for one experienced individual. That person becomes a bottleneck, and the organisation remains exposed when they are unavailable. Capability means people at the right level understand the risk, know their decision boundaries and can explain their reasoning.
This requires more than a policy briefing or a completed course. Teams need realistic practice, feedback and opportunities to examine the consequences of their choices. Capability assessments can help identify where confidence is unsupported, where knowledge is thin and where decision-making habits need attention. Mildot Group’s approach is founded on that practical distinction: evidence of learning is not the same as evidence of readiness.
The aim is not to remove judgement from projects with templates and escalation routes. It is to make judgement more visible, better informed and easier to improve. The next decision that matters will not arrive in the format of a training exercise. It will arrive with incomplete information, competing priorities and people looking for a clear answer. Build a project team that can give one.
