Decision Making Tool for Project Management: What Plans Miss

I sat through a project review in which the program manager presented a 47-item risk register, a resource-loaded Gantt chart and a RACI matrix covering 12 workstreams. Every decision making tool in the room was current, every traffic light was green. The project was already 14 weeks behind and nobody in the room could explain why.

The reason was not in any of those documents. The entire timeline rested on the assumption that a specialist supplier could deliver a custom component at twice the volume specified in the original agreement, and nobody had asked the supplier whether this was possible.

The risk register listed "supply chain disruption" as a medium risk with three mitigations, but the actual assumption underneath it, the one that mattered, had never been stated, let alone tested.

Project management has no shortage of decision making tools: matrices, registers and governance frameworks. What it does not have is a mechanism to test whether the assumptions inside those tools can bear the weight of the decision.

The industry maintains the apparatus because the apparatus employs people, not because it tests what matters. I built the Walk, a guided version of the Universal Decision-Making Method, to provide that mechanism: five steps that surface, rank and monitor the assumptions a project decision rests on, before the project plan commits resources against them.

A decision making tool for project management is a structured method for testing whether the assumptions inside a project plan can support the commitment that plan requires.

Why project managers' existing tools miss the decision

Denver International Airport opened 16 months late in 1995 after a $560 million overrun on its automated baggage handling system. The system had been designed and tested for a single airline on one concourse. City officials expanded the scope to cover all 20 airlines across three concourses without re-baselining the project assumptions, and the technology had never operated at that scale.

On opening day, bags were shredded, misrouted and lost. After a decade of unreliable operation, the system was decommissioned entirely in 2005.

The project had a risk register and a governance structure approved by the city council. What it did not have was a step that forced anyone in the room to ask a plain question: has this system been tested at the scale we are now committing to? A RACI chart told the team who was responsible for the baggage system. It did not tell them whether the assumption that the system could operate at twenty times its proven capacity had any evidence behind it.

I have seen this pattern in mining and in defence procurement. The tools are different, the governance language is different, but the failure is always the same: the project documentation manages the options on the table without ever questioning what sits underneath them. The Walk forces that separation between the options on the project plan and the assumptions underneath them, because the score on a decision matrix means nothing if the assumption it rests on has never been tested.

Write down the three assumptions your current project plan rests on and ask your team which ones have evidence behind them. Start the Walk →

When project managers need the full method

Not every project decision needs assumption testing. A decision matrix or scoring model handles bounded choices well enough when choosing wrong costs time rather than the organisation's viability: picking between three qualified vendors for a routine procurement, selecting a scheduling tool, or deciding which team handles a work package.

The Walk is for the decisions that can break the project. Material commitments where the assumptions could change during implementation and the outcome cannot be easily reversed: committing to a technology that has not been tested at the planned scale, or approving a budget that depends on an exchange rate holding for three years. Decisions that cross ethical territory fall into the same category, because the people who bear the consequences need to see what was assumed about them.

PMI reports that organisations with effective decision-making see 40% higher project success rates. The other 60% had decision making tools. Those tools did not test the things that actually determined the outcome.

A useful test: if the project sponsor would expect to see a documented record of the decision, its assumptions and the evidence behind them before committing resources, then the decision needs more than a matrix. The five-step method forces the team to name the assumptions and rank the evidence behind each one before they leave the room.

The assumption your project plan never tested

The UK's High Speed 2 rail program was estimated at £30 to £36 billion in 2010. By 2023, costs had risen to between £88 and £103 billion at 2019 prices, and the northern leg had been cancelled entirely. The program had business cases and risk registers, all properly maintained and reported through formal governance channels.

The National Audit Office found that the root cause was what their reports called "hopeful assumptions": costs that had been excluded from the budget at the front end crept back in once the project was committed, and nobody had a mechanism to surface or challenge them. The NAO reviewed 227 government major projects with a combined value of £834 billion and found the same pattern across the portfolio.

Healthcare.gov followed a similar path in 2013. McKinsey delivered a risk report to CMS leadership in March of that year, seven months before launch, identifying major integration risks across the vendor consortium. CMS leadership acknowledged the report and proceeded on the assumption that the vendors would integrate the system successfully, because they had contracts that said so.

The Government Accountability Office found that CMS did not use available oversight tools or contract management capabilities. Six people enrolled on launch day. Emergency remediation cost more than $600 million.

The Walk takes project managers through each assumption and asks a plain question: what is your evidence that this is true? The evidence, not the project plan or the schedule. The assumption that vendors would integrate successfully was the load-bearing element of the entire Healthcare.gov program, and had anyone stated it as an assumption and tested it against the McKinsey evidence, the launch decision would have been different.

What a project management decision tool must actually produce

Most project management decision making tools produce either a ranked list of options or a status report. A decision matrix tells you which vendor scored highest on your weighted criteria. A risk register tells you which risks are rated red this quarter. Neither is a decision record. Neither names the assumptions the decision rests on or assigns responsibility for monitoring those assumptions.

I have watched projects where the team left the room believing they had agreed the same decision, only to discover months into implementation that they had not. A wind-speed study used data from the wrong monitoring station. An instrument drifted out of calibration without triggering a review. A neighbouring construction project changed the water table years after the original design was signed off.

The cause was the same in each case: the decision was never recorded in a way that named its assumptions and made them monitorable.

The Walk produces a Decision Record that names the assumptions a project decision rests on, assigns each one to a named person for monitoring, and specifies the action to take if an assumption changes. That record outlives the project team.

When the board asks two years later why the decision was made and what it assumed, the record answers a question that institutional memory cannot. That is what a decision making tool must actually produce.

---

Grant Purdy is the co-author, with Roger Estall, of Deciding (2020), and the architect of the Universal Decision-Making Method.