MGMT 8009M Week 5 Decision Reconstruction Example

Shipped on a Thursday Under Rules Followed as Written: A Decision Reconstruction of a Software Release With a Known Payment Defect, Built From Forty-One Dated Entries With the Outcome Set Aside

Student Name

Walden University

MGMT 8009M: Organizational Decision Making and Judgment

Instructor Name

Month Day, Year

Shipped on a Thursday Under Rules Followed as Written: A Decision Reconstruction of a Software Release With a Known Payment Defect, Built From Forty-One Dated Entries With the Outcome Set Aside

The Decision and Its Outcome, Then Set Aside

On Thursday, April 10, 2025, the release board at Brockway Software, a composite maker of point-of-sale systems for independent restaurants, approved version 8.4 for general release. A defect in the payment module was known at the time. Over the following eleven days, a share of card transactions at about 300 client restaurants failed to settle, and Brockway issued credits and refunds worth about $410,000. That is the outcome. The rest of this paper sets it aside.

The reason for doing so is empirical. Fischhoff (1975) found that people who learned an outcome rated it as more foreseeable than people kept unaware of it, and they were largely unaware that the knowledge had changed their judgment. Baron and Hershey (1988) showed a related effect: people rate the quality of a decision higher when its outcome was good, even when the decision itself was identical. A reconstruction that reads the release board's meeting through the customer losses will see a warning that was obvious. The question is what the board could see on April 10.

The Timeline

[after]

Each entry in the full appendix carries its date, document type and the roles who could open it. Nothing is paraphrased where the original wording survives.

Table 1

Selected Entries From the Release 8.4 Record (41 Entries in Full Appendix)

Who Could See What

The defect's full description, including the words "may drop transactions," lived in the engineering tracker. The release board's members did not use that tracker. What reached them, on April 2, was a readiness summary with a single line: three open severity-3 defects, none blocking. The summary was produced by a script that counts defects by severity; it does not carry their descriptions. The April 8 customer success note mentioned "occasional tip issues" at two pilot sites, but it went to customer success and product managers, not to the board, and its wording did not connect to PAY-2291.

On April 10, therefore, the board held a count and a severity label. Under the release policy, severity-3 defects do not block a release. The board followed the policy as written.

Three Harmless Precedents

Why was PAY-2291 rated severity 3? The triage record shows that releases 8.1, 8.2 and 8.3 each shipped with a payment-module defect involving post-authorization adjustments, each rated severity 3, and none produced a reported settlement failure. The engineer who rated PAY-2291 cited those precedents in the triage comment: "same class as 2104 and 2187, shipped clean."

Vaughan (1996) described how, before the Challenger launch, engineers and managers came to accept anomalies in the shuttle's joint seals because each earlier flight with an anomaly had returned safely. Each acceptance became the baseline for the next, a process she called the normalization of deviance. The same pattern appears in the Brockway triage history. A class of warning that had appeared three times without harm came to be read as routine, and the rating rule, which weighed past impact heavily, encoded that reading. The fourth instance looked like the first three.

The Step Where It Could Have Turned

The reconstruction locates one point where different information would plausibly have produced a different release: the triage rating on March 6. Had the rating been severity 2, the release policy would have required either a fix or a written exception signed by the head of engineering, and the defect's description would have reached the board. What the rating rule lacked was a factor for consequence if the defect occurred, independent of whether similar defects had occurred before. A payment defect that drops transactions has a high consequence even if past instances were harmless.

The reconstruction does not claim that the authors of the rating rule should have foreseen this case. The rule had worked through dozens of releases. Its weakness became visible only when a defect with a familiar pattern and a different consequence arrived.

A Second Possible Turning Point

The April 8 customer success note might also have changed the outcome, had it been routed to the release board and linked to the defect. The reconstruction treats this as weaker than the triage step: the note was vague, came two days before the meeting and described symptoms that pilot sites had reported for unrelated reasons before. It is listed in the appendix as a possible signal, not as a missed one.

What Would Change

Two changes follow from the record. The triage rule should rate payment and settlement defects on consequence first, regardless of precedent. The readiness summary should carry the one-line description of every open defect in the payment module, not only a count. Neither change depends on anyone being more careful.

Limits

Brockway is a composite case, and the appendix is a constructed record. A real reconstruction would also interview participants, with attention to how their memories had been shaped by the outcome.

References

Baron, J., & Hershey, J. C. (1988). Outcome bias in decision evaluation. Journal of Personality and Social Psychology, 54(4), 569-579. https://doi.org/10.1037/0022-3514.54.4.569

Fischhoff, B. (1975). Hindsight is not equal to foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance, 1(3), 288-299. https://doi.org/10.1037/0096-1523.1.3.288

Vaughan, D. (1996). The Challenger launch decision: Risky technology, culture, and deviance at NASA. University of Chicago Press.