Your Project Has a Vision Document Nobody Believes In

There is a vision document. It was written, circulated, and approved. You can find it in the wiki in about thirty seconds.

Then a real trade-off lands. Cut the feature or slip the date. Serve finance well or operations well, because you cannot do both by Friday. And nobody opens the vision. Nobody quotes it. The decision gets made on other grounds while the document meant to guide exactly this choice sits untouched a few clicks away.

That is the symptom. Not a missing vision. A vision that exists and decides nothing. The box looks ticked: there was a workshop, there was sign-off, the status report is green. But watch the project choose between two things it wants, and the vision is not in the room. It gets quoted at kickoff and never again.

Project clinic summary

Symptom:
A signed-off vision document exists, but nobody reaches for it when a real trade-off has to be made.

Likely causes:
The vision was produced to clear a gate rather than to drive decisions; it was smoothed into wording too bland to settle any real choice; nothing in delivery references it; no one owns it after sign-off.

BA move:
Reconnect the vision to live decisions. Pressure-test it against one real trade-off, translate it into decision criteria, and put it where choices actually get made.

Why this hurts the project

A vision earns its keep when the project has to choose between two good options. Take that away and decisions still get made, just on worse grounds: whoever is loudest, whatever deadline is nearest, or plain habit. None of those is a shared goal.

Scope drifts for the same reason: if nothing settles what matters most, every request looks about as valid as the next, and the boundary quietly moves. Worse, the signed-off vision suggests alignment already exists, so nobody looks for the gap. The document did not fail because it was missing. It failed because it was never doing any work.

What this usually looks like in practice

You do not diagnose this from the document. You diagnose it from behaviour, and a few signs show up together. Ask three people what the project is for and you get three different answers, despite a vision everyone signed. Decisions get justified by “we need to ship” rather than by the outcome the project is meant to deliver. The vision reads well enough to be pasted into any project in the company. And when you ask someone to name a single decision the vision changed, there is a pause, then a change of subject.

That last one is the tell. If nobody can point to a choice the vision settled, it is not guiding the project. It is describing it, generously, after the fact.

This is a different problem from having no vision at all rather than a disbelieved one. There the document is missing; here it exists, it was approved, and it is inert. The two need different fixes.

Likely causes

None of this is about people not caring. It is about how the document was built and what it connects to.

It was produced as a gate deliverable. Something needed a vision to pass a stage, so one got written. It cleared the gate, and it was never designed to be picked up again.

It was smoothed into wording that excludes nothing. After enough reviews to win everyone’s sign-off, a vision often reads like “deliver a modern, user-friendly platform that adds value for customers.” Nobody objected because there is nothing to object to. A vision that rules nothing out cannot settle a choice between two things.

It was never translated into anything usable. A vision statement is not decision criteria. If nobody turned it into “when we choose, we favour this over that,” there is nothing operational to reach for at a real trade-off.

Nothing in delivery references it. Not backlog refinement, not prioritisation, not scope calls. If the vision has no place in any ritual where decisions get made, it will never be in the room when one is.

No one owns it after sign-off. Approval is not ownership. Once the signatures are in, the vision often has no defender, no one whose job it is to ask whether a trade-off matches what the project agreed it was for.

Diagnostic questions

Trace it through the project’s actual decisions.

1. When did the vision last change a decision here? Can anyone name that decision?
2. If you asked three people what the project is for, would you get the same answer?
3. When a trade-off comes up, does anyone open the vision, or does it run on deadline and volume?
4. Is the vision specific enough to rule anything out, or agreeable enough to fit any project?
5. Has it been translated into criteria a team could use to choose between two options?
6. Does any delivery ritual reference the vision at all?
7. Who owns the vision now that it is signed off? Is that a real answer or a name on a page?
8. When the vision and the deadline disagree, which one wins in practice?

If most of these come back weak, the vision was never wired into how the project decides.

The IT Project Problem Diagnostic Checklist includes a Decision Health section. Use it to check whether your project’s key trade-offs have shared criteria, or whether they are being settled by deadline and volume instead.

What the BA can do

You are often the one who notices the vision has gone quiet, because you sit close to the decisions. You do not need to rewrite it. You need to make it do work again.

Pressure-test the vision against one real trade-off. Take a live decision and resolve it using only the vision; if it falls silent, that silence is the finding.

Translate the vision into decision criteria: three or four statements of the form “when we must choose, we favour X over Y.” That page can settle things the vision itself cannot.

Put the vision where decisions happen. Move it from the wiki into the prioritisation and scope templates, so it is consulted at the point of choice, not at kickoff.

Make its absence visible. When a call runs purely on deadline or volume, note it in the decision log without blame, along with the risk that creates. One concrete example beats endless reminders that the vision exists.

Assign live ownership. Name who defends the vision when trade-offs appear, usually the sponsor or product owner, and have them consult it on scope and priority calls.

Sharpen the vision so it excludes something. Add the missing edge: what the project is deliberately not optimising for. A vision that can justify saying no to a tempting request can finally decide things.

A worked example

A project’s vision promises “a modern, user-friendly platform.” Two weeks from release, a trade-off appears: polish the workflow for finance or for operations, with time for only one. Someone tries to settle it with the vision, but both options are modern and both are user-friendly, so it has nothing to say. The call goes to whoever pushed hardest, and the other group quietly logs that the platform is not really for them.

Now run it with a sharper vision: the platform exists first to give operations one reliable place to work, because that is where the current process breaks. Same trade-off, and it decides itself. Operations gets the polish, finance waits, and the choice matches what the project said it was for. That is the difference between a vision that describes and one that decides. The second can disappoint people on purpose, which is exactly why it works.

Common mistakes

Rewriting the vision into nicer prose. A more elegant statement that still excludes nothing is still inert. Ask whether it can now settle a trade-off it could not before.

Adding more sign-off. Re-approving the vision by more senior people does not give it authority. It was already signed. Authority comes from being used in decisions, not from more signatures.

Treating it as a motivation problem. Sending it round again and asking people to keep it front of mind rarely helps. The vision is not ignored because people are careless, but because it was never connected to the moments where it would matter.

FAQ

Isn’t a signed-off vision enough?
No. Sign-off proves people did not object to the wording. It does not prove the vision guides decisions, and only the second test matters day to day.

Whose job is the vision, really?
Ownership sits with the sponsor or product owner, but the BA is usually the one who notices it has gone inert and reconnects it.

What if leadership will not engage with it?
Make the cost of the disconnect visible on a real decision. A concrete trade-off going wrong pulls engagement that an abstract document never will.

Where to go next

If the inert vision is also leaving decisions stuck, the two problems reinforce each other. When you are ready to rebuild the vision so it can guide the work again, the practical guide walks through the steps.

What to do next

Take one real trade-off your project faces right now and try to resolve it using only the vision. If you can, it is doing its job. If you cannot, you have found the gap. Close it with the smallest possible move: one line that lets the vision settle that choice, and one place to put it where the next decision will see it.

Before your next big trade-off, run the IT Project Problem Diagnostic Checklist to see whether the vision, decisions, and stakeholder expectations are actually pointing the same way.