Rational Decisions Need a Reversal Test
A software renewal is due on Friday. The current system frustrates the team, a replacement looks promising, and an upgrade appears safer. Someone asks for a rational decision. That request can sound like a demand for the one correct answer, even though nobody knows exactly how any of the three systems will perform next year. The useful question is narrower: given what can be known before Friday, which choice best serves the team’s purpose, and what would make that choice change?
Rational decision making is a disciplined comparison of feasible actions and their likely consequences at the time of choice. It begins by stating the result that matters, then compares options over the same period, separates future differences from money already spent, and tests the assumptions that could reverse the preference. The process can improve a decision without promising a perfect forecast. OpenStax’s discussion of bounded rationality explains why: people face limits in the information they can gather, the time available, and the complexity they can process.
Define the outcome before comparing the offers
The first mistake in a software renewal is to treat the vendor’s offer as the decision itself. A cheaper contract, a familiar interface, and an attractive demonstration answer different questions. Before comparing them, state what the system must do for the people using it. If the real problem is missed appointments, define an acceptable level of missed appointments, the period in which it must be reached, and the money and disruption the organization can bear. Otherwise, a low price may win even though it leaves the original problem untouched.
The UK government’s Green Book frames appraisal around objectives, options, costs, benefits, and risks. It also calls for a description of what is expected if current arrangements continue. That continuing course is the baseline. For an ordinary organizational choice, the same logic is useful: compare each proposed change with a credible account of what happens if you renew the current system. “Do nothing” is rarely costless when a contract, staff time, or service problem continues.
Consider an illustrative scheduling team choosing among renewal, an upgrade, and a move to a different supplier. Assume the team wants fewer than two scheduling errors a month within three months, can spend no more than $55,000 over the next twelve months, and cannot stop taking bookings during implementation. Those figures are invented for this example; they are decision conditions, not claims about a real team or product. They turn a vague wish to “improve scheduling” into a comparison that can exclude an attractive but unsuitable option.
The timing matters as much as the wording. A twelve-month cost comparison should include the same twelve months for every option. An error count should use the same definition across the existing and proposed systems. If one supplier reports errors per booking and another reports errors per month, the apparent difference may come from the denominator. If the team expects its booking volume to change, say so before treating today’s error count as a forecast. The decision can still proceed with imperfect estimates, but the unknowns need to be visible.
Do not force the shortlist to contain only the two offers on the desk. Renewal, an upgrade, and a replacement are sensible candidates here because each is a feasible way to run next year’s bookings. A temporary fix or short pilot may also be feasible if the contract allows it. Adding a real option can change the recommendation; adding an imaginary option that cannot be bought or implemented only makes the comparison look broader than it is. The Green Book’s use of a continuing-course benchmark helps keep the alternatives grounded in an actual choice.
Count costs that the choice can still change
Once the options are clear, compare what follows from each one. OpenStax’s managerial accounting explanation treats a cost as relevant to a choice when it differs between alternatives and can still be affected by the decision. A prior purchase cannot be recovered by renewing the supplier that sold it. A migration fee, an upcoming license payment, or extra staff time may matter because the chosen option changes them.
Suppose the illustrative team estimates that keeping its present system would require a $24,000 renewal and $18,000 of staff time correcting bookings over twelve months. Its future cost is $42,000. An upgrade would require a $38,000 subscription, $5,000 of setup, and $9,000 of correction time: $52,000. A replacement would require a $30,000 subscription, $12,000 of migration, and $6,000 of correction time: $48,000. The arithmetic is illustrative and assumes those categories cover the material costs for this team. In a real choice, the person doing the comparison would have to check what the contracts include and how the staff time was estimated.
This comparison answers a useful question: what does each course cost from today forward? It does not answer whether the additional spend buys enough improvement. If the team paid $20,000 last year to customize the current system, that payment remains gone under all three options. It may explain the reluctance to switch, but it should not be added to the replacement’s future cost or used to justify a new renewal. The distinction is uncomfortable because past spending can feel like a promise that the decision must now honor. The decision can change future returns; it cannot rewrite the earlier payment.
Neither should every item that appears on an accounting statement be treated as a difference. If the same manager’s salary will be paid under all three options, including it in each total makes the figures larger without changing the ranking. If the upgrade needs that manager’s time and delays other work, the displaced work is a genuine consequence even if no new invoice arrives. State that consequence in the comparison, preferably in a unit the team can explain, instead of burying it in a vague allowance for “overhead.”
Costs also need boundaries. Does the upgrade require training during peak booking hours? Does the replacement include data transfer, or will the team pay separately? Is correction time already included in a quoted support package? Asking these questions prevents both omission and double counting. It also stops a low headline subscription from standing in for total cost. The choice remains partly a judgment about what matters, but the calculation should faithfully reflect that judgment.
Set the decision rule, then make the call
The illustrative team’s cost figures put renewal at $42,000, replacement at $48,000, and upgrade at $52,000. Assume its best current estimates are four scheduling errors a month under renewal, two under replacement, and one under upgrade. Assume all three can be operating within three months without stopping bookings. Under the stated requirement of fewer than two errors a month, only the upgrade is expected to qualify. I would choose the upgrade on those assumptions. It costs $10,000 more than renewal and $4,000 more than replacement over the stated year, and that extra spending is the price of meeting the specified service target.
That call depends on the target having a real purpose. If two errors a month are acceptable, the replacement would meet the revised target at an estimated $4,000 less than the upgrade. If four errors are acceptable and the team has no other reason to change, renewal is cheaper still. Conversely, if missed bookings have consequences beyond the correction time already counted, the team should describe those consequences before choosing on price alone. Changing the target after seeing the totals merely to favor a preferred vendor would make the exercise less informative. Changing it because the original target was poorly connected to the actual service problem is a legitimate correction.
A hard requirement and a preference should not be handled in the same way. A system that cannot keep bookings running during installation fails the team’s stated condition even if its subscription is cheap. Among systems that pass, price, ease of use, and expected reliability can be weighed against one another. Treating every consideration as a small point on one scorecard can let a good price compensate for a failure the organization cannot accept. If no feasible option meets all the requirements, the honest response is to revisit the requirements, the budget, or the available options; there is no reason to declare a winner from an unsuitable set.
The cost of a rational choice is sometimes paying more or acting before every uncertainty disappears. The upgrade recommendation spends more now on the expectation of fewer errors. It could disappoint. The relevant question is whether that risk is acceptable given the team’s stated objective, and whether there is a sensible way to learn more before the contract deadline. If a short trial can resolve the key uncertainty at a modest cost without losing the preferred offer, it deserves consideration as its own option. If a trial would miss the deadline and disrupt bookings, its informational value may be outweighed by its consequences.
Find the assumption that could change the answer
The upgrade looks strongest only if it really brings errors below two a month and stays within the $55,000 ceiling. Those are the assumptions to challenge first. A beautiful spreadsheet with a precise total is less useful than a plain statement of where the total could move. The US Government Accountability Office’s cost estimating guide calls for documenting the assumptions behind cost estimates and using sensitivity analysis to see how changes in inputs affect a conclusion. The point is to learn which uncertainty matters, not to decorate the estimate with arbitrary best and worst cases.
In the illustrative case, the upgrade has only $3,000 of room beneath the spending ceiling. If setup costs rise from $5,000 to $9,000, its twelve-month estimate becomes $56,000 and it no longer fits the stated budget. If correction time is $12,000 rather than $9,000, the total reaches exactly $55,000 and still fits a “no more than” ceiling, though with no margin for other omitted costs. Those changes follow directly from the example’s assumptions. They reveal why a firm setup quote and a credible account of expected correction work are more useful than another presentation about features.
The error estimate can reverse the decision as well. If a trial suggests the upgrade will average three errors a month, it misses the target despite fitting the budget. If the replacement consistently produces one error a month and can be implemented without stopping bookings, it would satisfy the target for $4,000 less than the upgrade on the present cost estimates. Before paying for more information, ask what observation would switch the choice. Information that cannot change the choice may still be interesting, but it has less value before a deadline.
These are scenario checks, not probabilities. The article’s invented figures do not tell us how likely an overrun or error rate is. In a real decision, the team could examine contract terms, its booking records, a supplier’s implementation plan, and a limited trial to narrow the important ranges. If those checks still leave the options close, the decision maker should say so. Bounded rationality does not excuse ignoring uncertainty; it means using scarce time to investigate the uncertainties that could alter the recommendation.
Use weighted criteria with care
Some decisions cannot be reduced to one service threshold and a cost total. A choice of location, supplier, or public service design may involve several outcomes that matter for different reasons and cannot all be priced credibly. The UK Government Analysis Function’s guide to multi-criteria decision analysis describes comparing options against declared criteria, assessing performance, and using weights that represent decision makers’ preferences. That can make a difficult trade-off discussable, provided the criteria and their meaning are clear.
For the scheduling choice, a useful comparison might keep service errors, future cost, and implementation interruption distinct. The team would first rule out any option that cannot preserve bookings during installation. It could then discuss how much lower error rates are worth relative to additional spending. A weight is a statement about that trade-off, not a physical property of the software. If people disagree about the weight, show how the preferred option changes when it changes. That disagreement is information about the decision, not a flaw to hide in a final score.
Avoid awarding points for the same benefit twice. If faster booking correction has already lowered the estimated staff cost, a second “efficiency” score for those same saved hours would exaggerate the upgrade’s advantage. Likewise, a vendor’s reputation may be useful only if it changes an outcome the team cares about, such as implementation reliability or support. Give the criterion a concrete meaning and explain how each option performs on it. If a simple comparison of costs and a hard service target resolves the choice, a weighted model adds work without improving the decision.
The guide also warns that simple scoring can conceal weak understanding of what a criterion means. A total of 82 points versus 79 points can look conclusive even when the underlying performance estimates and weights are rough. I would use the scores to expose the reasons for a preference and test whether it survives plausible changes, then state the choice in ordinary language. A number can summarize a judgment; it cannot make the judgment for the people who must live with the result.
Decide at the right level of effort
The person signing the renewal needs a short record of the decision, not a permanent investigation. It should name the objective, the options that were feasible on the decision date, the continuing-course baseline, the future costs and outcomes compared over the same period, the assumptions most likely to reverse the choice, and the reason for the final call. In the illustrative case, that record would say: choose the upgrade if a firm setup cost and a credible service estimate keep it under $55,000 and below two errors a month; otherwise reconsider the replacement or the target. That is a decision someone can act on and revisit.
The effort should match the stakes. A routine purchase with a small, reversible difference may need a brief comparison and a deadline. A costly, difficult-to-reverse commitment warrants better estimates, more attention to alternative options, and a clearer account of uncertainty. The Green Book itself calls for appraisal effort proportionate to a proposal’s scale, cost, complexity, and risk. Rationality does not require spending more on analysis than the decision can reasonably justify.
After implementation, compare what happened with the assumptions that supported the choice. If the upgrade runs over budget or fails to reduce errors, the earlier reasoning should make it clear which expectation failed and what action is now available. That later check cannot prove that the original decision was irrational: a reasonable choice can have a poor outcome when the future is uncertain. It can, however, keep an organization from defending a failing course merely because it chose that course before. The practical standard is a decision whose purpose, trade-offs, and conditions for changing direction are clear when the choice is made.