Your Project Keeps Reopening Decisions That Were Already Signed Off

The decision was made six weeks ago. Everyone was in the room, someone approved the document, and delivery got on with it.

Now it is back. A stakeholder says the agreed approach will not work. Another says they never understood it that way. Two sprints of work sit on top of it.

People are allowed to change their mind when they learn something new. The problem is that nobody can tell which situation this is. Did new information arrive, or was the decision never properly made? If the project cannot answer that, every reversal costs the same.

Sign-off happened. It just did not mean what the team assumed it meant.

Project clinic summary

Symptom:
Decisions and requirements get formally signed off, then reopened or reversed weeks later, after delivery has already built on them.

Likely causes:
Sign-off was collected on a document rather than a specific decision; the approvers were not the real decision owners; the trade-off was never made visible; nothing recorded what was actually agreed and what it assumed.

BA move:
Write the decision before you seek approval: what is being decided, what is being ruled out, who owns it, and what it assumes. Then a reversal becomes diagnosable instead of mysterious.

Why this hurts the project

The reversal itself is rarely the expensive part. What costs money is everything built on top of it.

Reversed during refinement, a decision costs a conversation and an updated story. Reversed after two sprints, it touches implementation, test cases, training material, and the release plan. It also touches the decisions made downstream assuming this one was settled, and nobody has a list of those.

Then there is the slower damage. When agreements stop holding, teams adapt. Developers build optionality nobody asked for. Analysts stop closing topics because closing them stops meaning anything.

The visible cost is the rework. The invisible cost is a delivery team that has quietly stopped treating any decision as final.

Not every reversal is a failure

This is where most projects get the diagnosis wrong, in both directions.

Some reversals are the system working. A vendor withdraws. A regulator publishes something new. A pilot contradicts an assumption everyone was comfortable with. Reopening is correct, and a project that resists it out of process pride will ship the wrong thing on schedule. Others were always coming, because the agreement was never solid enough to hold.

The test is straightforward. Can the project point to what was decided, why, and what it assumed? If yes, and one of those assumptions has changed, the reversal is legitimate. If not, the reversal was structural. Something got approved, but nothing got decided.

Signals of a legitimate reversal	Signals of an avoidable one
A named assumption has demonstrably changed	Nobody can say what the decision assumed
The original decision and its options are on record	The record says “approved” and nothing else
The person reopening it can say what is new	The person reopening it is describing the original problem again
It is a different decision reversing this time	It is the same decision reversing for the third time
The trade-off was visible then and the cost has now landed differently	The trade-off is being discussed for the first time now

The right-hand column is not a list of stakeholder failings. It is a list of things the project did not write down.

Likely causes

Sign-off was collected on a document, not a decision. Someone approved a specification containing four real choices, none named as choices. Approving a document is a low-bar act.

The people who signed could not actually decide. A delegate attended because the owner was travelling. The signature was real, the authority behind it was not, and nobody checked.

The trade-off was never made visible. The stakeholder agreed to what they were getting, not what they were giving up, because the rejected options were never presented. When the cost lands, reopening is rational.

Nothing recorded what was agreed. The ticket says approved, with a name and a timestamp. It does not say approved to do what, instead of what, on whose authority, on what assumption. So the conversation restarts from zero.

The wording was loose enough to sign in good faith and read two ways. If that is the dominant pattern, the deeper issue is how requirements are written, covered in Your IT Project Requirements Are Too Vague.

There was no route for new information. The only move is to raise it informally and hope, so legitimate change arrives looking exactly like someone being unreasonable.

If decisions on your project are not getting made at all, that is a different problem, covered in Decisions Keep Stalling in Your IT Project. This one is about decisions that land and then come apart.

Diagnostic questions

Work these against a specific reversal, not in general.

1. When the decision was reopened, could anyone point to a written record of what was agreed?
2. Did that record say what was ruled out, or only what was chosen?
3. Was the person who signed the person who could genuinely decide?
4. Did the approver see what the decision cost them, or only what it gave them?
5. Was sign-off collected on a specific decision, or on a document containing several?
6. What assumption was the decision resting on, and has that assumption changed?
7. Did new information genuinely arrive, or did old information get understood properly for the first time?
8. Could two people have read the agreed wording and reached different conclusions?
9. Is there any route for handling new information other than reopening the decision informally?
10. Is the same decision reversing repeatedly, or are different decisions reversing once each?
11. How long after sign-off did the reversal arrive, and what happened in between?
12. Have people started hedging because they expect agreements to move?

Question ten does the most work. Different decisions reversing once each means the project is absorbing change. The same decision reversing three times means it was never made.

IT Project Problem Diagnostic Checklist includes a Decision Health section. Use it to check whether key decisions on your project have clear owners and whether reopened decisions are being tracked rather than absorbed.

What the BA can do

You cannot appoint decision owners or overrule a director. You can control how the decision is framed, what gets written down, and what gets made visible before anyone approves anything.

Write the decision before you seek approval, not after.

Confirm the owner beforehand. Ask who can say yes without checking with someone else. If nobody answers cleanly, you have found something more useful than an approval.

Put the rejected option in the room. A stakeholder who sees the trade-off and agrees anyway rarely reverses later, because nothing new has happened to them.

Name the assumptions. These become the legitimate reopening triggers. If one breaks, reopening is correct, and the project can say so out loud.

Give reversals a route. When something comes back, classify it in one line before debating it: new information, or a decision never properly made. A route, not a gate. Five minutes.

Read it back before anyone signs. Corrections are free then and expensive later.

The decision record

Five lines, written before approval is sought.

What is being decided
Find out whether DoR and DoD exist on your project. If they do, read them. Check whether BA sign-off on acceptance criteria appears as an explicit condition in the DoD. If neither exists, that is your starting point.

What is being ruled out
The options not taken, and what each one would have given up.

Who owns it
The person who can say yes without checking. Name the gap if there is one.

What it assumes
The conditions this decision depends on. These are your reopening triggers.

Date and where it lives
Somewhere findable in six weeks by someone who was not there.

The wording that fills it in is ordinary. “Before we close this, let me read back what I think we just agreed.” Then: “We are choosing this, we are not doing that, and this rests on the assumption that volumes stay under X. If that changes, we should reopen this deliberately.”

That last sentence does most of the work. It gives everyone permission to reopen the decision for a stated reason, which is what stops it being reopened for unstated ones.

Common mistakes

Adding more approvers. The reflex when sign-off fails is to require more of it. A vague decision approved by six people is still a vague decision, and it now takes three weeks.

Treating the approval timestamp as the decision record. A name and a date prove somebody clicked something.

Quoting the sign-off back at people. “But you approved this” resolves nothing and blocks the useful question, which is whether anything genuinely changed.

Recording the outcome but not the assumption. Decision logs that name the choice and never its conditions miss the part you need later.

Filing every reversal as scope change. Scope creep is new work absorbed quietly at the boundary, covered in Your IT Project Scope Keeps Expanding. This is an existing agreement coming apart. Treating one as the other hides both.

FAQ

What if the stakeholder genuinely did not understand what they signed?
Then the sign-off was collected on the wrong thing. That is a framing finding, not a stakeholder finding. What was put in front of them did not make the choice visible enough to recognise.

Is a decision log not just more documentation?
It is five lines written during a meeting you were already having. Filled in afterwards and filed where nobody looks, it is documentation. Read back in the room before approval, it is a working tool.

What do I do about a decision that has reversed three times?
Stop trying to approve it again. Something structural is unresolved: no real owner, a conflict between two stakeholders, or a dependency on something not yet known. Name which one. A fourth approval will not survive.

How is this different from a project that just changes direction a lot?
Direction changes when there is no agreed view of success to test decisions against, covered in Your IT Project Has No Clear Vision. Here the direction is agreed and the decisions inside it are not.

What to do next

Take the last decision that reversed on your project and write its decision record retrospectively: what was decided, what was ruled out, who owned it, what it assumed.

You probably cannot fill in all four. Whichever line you cannot complete is the mechanism.

Then write the record properly for the next decision, before approval rather than after.

Before the next decision goes for approval, use the IT Project Problem Diagnostic Checklist to check whether stakeholders actually share the same understanding of goals, priorities, and responsibilities. Agreement that is not shared tends not to hold.