A Single Word Keeps Meaning Two Different Things on Your Project

Two people describe the same requirement. Both sound right. Both are confident. The thing gets built, and it satisfies neither of them.

You trace the argument back and it lands on one word. “Active customer.” One person meant anyone with a login. The other meant anyone who had ordered in the last ninety days. Neither was vague. Neither was careless. Each was precise about a different thing, and nobody noticed until the mismatch was already inside a story, a data field, and a report. The word looked settled. It never was. It just never got tested.

This is not a requirements-are-too-vague problem. Vague means nobody said enough. This is the opposite. Everyone said plenty. They just meant different things by the same term, and the project built on top of the gap.

Project clinic summary

Symptom:
A key project term means different things to different people, or its meaning drifted mid-project, and the mismatch was built into stories, data, and reports before anyone noticed.

Likely causes:
Terms enter requirements without a canonical meaning, no one owns the domain language, definitions are never updated when the domain changes, and nothing surfaces divergent usage before it ships.

BA move:
Find the load-bearing terms, pin the few where the ambiguity actually costs something to one agreed meaning, and keep those definitions current instead of writing a glossary once and forgetting it.

Why this hurts the project

Caught in refinement, a definition gap is a five-minute conversation. Caught later, it has already spread. It is in the eligibility logic, the migration mapping, and two dashboards that now report different numbers for what looks like the same thing. The word did not get more complicated. It got more expensive.

The quiet damage is trust in the numbers. When two reports disagree over a definition, people do not conclude that one metric was scoped differently. They start to doubt all of them. One unshared meaning can put a shadow over a whole reporting suite.

And the argument keeps coming back, because arguing about the requirement never resolves it. The requirement was never the problem. The word underneath it was.

What this usually looks like in practice

Two teams both building correctly, to different meanings of the same term. Everyone does good work. The work does not fit together. A metric means one thing in the warehouse and another on the dashboard. A rule fires on the wrong population, because “eligible” was read one way in the spec and another in the build.

Or a term that was clear at kickoff quietly shifted. Scope changed, or a business rule changed, and the meaning of “region” or “complete” moved with it. Some of the work followed the new meaning. Some did not. Now both live in the same system.

Likely causes

The reasons are mechanical, not personal. Nobody is being sloppy. The project just has no machinery for keeping meaning shared.

Terms enter requirements without a canonical meaning. A word gets used in a workshop, everyone nods, and it goes into a story. No one wrote down which meaning was agreed, because in the room it felt obvious. Obvious to each person, separately, and differently.

No one owns the domain language. When two definitions of a term exist, nothing decides which one wins. With no owner to arbitrate, both survive, and both get built.

Definitions are never updated when the domain changes. A term pinned correctly at the start can still drift when scope or a rule changes. If nothing prompts a review of what depends on the old meaning, the drift stays invisible until something breaks.

Nothing surfaces divergent usage before it ships. No point in the process catches two people using the same word differently. So the mismatch travels downstream, and the first real test of shared meaning happens in a build or a report.

Questions worth asking

When the same disagreements keep tracing back to what a word means, check the pattern:

1. When two people disagree about a requirement, does it keep coming back to what a single word means rather than what should be built?
2. Can you name three terms on this project that carry real weight in logic, data, or reporting?
3. For each of those, is there one agreed meaning written down, or several confident versions in people’s heads?
4. Does any key term mean one thing in one system and something different in another, with no one owning the gap?
5. Has a term’s meaning changed since kickoff because scope or a rule changed, and did all the affected work move with it?
6. When a definition gets agreed, is it recorded anywhere the next person building against it would actually find?
7. Do your reports ever disagree in ways that turn out to be a definition difference, not a data error?
8. Does any definition record what the term excludes, or only what it includes?

If several of these point the same way, the project is not arguing about requirements. It is carrying unshared meaning downstream.

Thee IT Project Problem Diagnostic Checklist includes a Requirements Health section. Use it to check whether the terms your user stories, business rules, and acceptance criteria depend on actually mean the same thing to everyone.

What the BA can do about it

You do not fix this by defining everything. You fix it by finding the few words that carry weight and keeping them shared.

Find the load-bearing terms. Most projects have five to ten words that actually drive logic, data, eligibility, money, or reporting. The rest do not matter enough to manage. The test is cost: if two people read this word differently, does something break or mislead? If yes, it is load-bearing. If no, leave it alone. The output is a short list, not a fifty-row glossary.

Surface divergence before you discuss it. Take one load-bearing term. Ask two or three people to write down, separately, who or what it includes and excludes. Independently, before anyone talks. The silence matters, because it stops the loudest voice in the room from setting the meaning by default. Then compare. The gaps between the written answers are the finding.

Pin each load-bearing term to one agreed meaning, including what it excludes. The exclusions and examples do more work than the definition sentence. A definition card is enough:

Term
Active customer

Agreed meaning
A customer with at least one completed order in the last ninety days.

Explicitly excludes
Active customer

In / out examples
In: ordered 40 days ago. Out: signed up last week, never ordered.

Owner and last changed
Owner: [named role]. Last changed: [date].

Attach the definition where the work happens. A definition parked in a separate document prevents nothing. Restate or link the agreed meaning in the stories, acceptance criteria, and data fields that depend on it. This is where meaning meets the build, and where you can build the agreed meaning into acceptance criteriaso testing checks the right population.

Version the definition when the domain changes. When a pinned term’s meaning moves, write a short dated note and check what already depends on the old meaning. Drift is only dangerous when it is invisible. A change record makes it something you can see and act on.

Add one checkpoint where divergence would surface. For load-bearing terms, put a standing question into refinement or review: does everyone here mean the same thing by this word? One deliberate check catches the mismatch while it is still cheap to fix.

Common mistakes

Writing a giant glossary nobody maintains. A hundred definitions that go stale in a month are worse than ten that stay current. They look like coverage while providing none.

Pinning every term instead of the few that carry weight. If everything is defined, nothing is prioritised, and the maintenance collapses under its own volume.

Treating a definition as permanent. The domain changed and the definition did not. A pinned term is not a solved term. It needs a review when the ground under it moves.

Recording what a term means but not what it excludes. Most real disagreements live at the edges. “Does a refunded order count?” The exclusions are where the money is.

FAQ

Isn’t this just a glossary?
A glossary is a list of words. This is a small set of load-bearing terms with agreed meanings, exclusions, owners, and a change history, attached to the work that depends on them. The list is the easy part. The pinning and the maintenance are the point.

How do I know which terms are load-bearing?
Apply the cost test. If two people reading the word differently would break logic, mislead a report, or send a rule at the wrong population, it is load-bearing. If nothing breaks, it is not worth managing. Usually you land on five to ten.

What if two definitions are both legitimately needed?
Name them as two different terms. “Active customer” and “registered customer” can both exist, precisely, as long as they are distinct words. The failure is one word doing two jobs, not two meanings existing.

Whose job is it to own a definition?
Someone with authority to decide, usually on the business side for domain terms. The BA’s job is to surface the divergence and get it pinned, not to invent the meaning. If a term genuinely has no owner, that is itself a finding worth raising.

What to do next

Take one term that caused a real argument recently. Ask two people who were in it to write down, separately, what that word includes and excludes. Compare the answers before they talk.

If the definitions match, you had a different problem. If they do not, you have found a load-bearing term that was never shared, and you know where to start.

When the same word keeps producing different builds, the project is not unlucky. It has a signal worth acting on. This is not the same problem as requirements that were never specific enough, and it is not quite a requirement that keeps returning in a new form, though it can hide behind both. Sometimes the undefined term is even the word “done” itself.

Before the next term forces a rebuild, use the IT Project Problem Diagnostic Checklist to surface where unshared meaning and weak requirements are already building up across the project.