Everyone Is Right. They’re Not Talking About the Same Thing.

In a project review meeting, someone asks a simple question:

How many active projects do we have?

Sales says twelve.

Operations says fifteen.

Finance has nine active cost centers.

Legal finds eleven current contracts.

No one is improvising. No one is working from false information. Each answer can be defended from the records available to that function.

The problem begins with the next question:

Which number is correct?

A sold project that has not started yet counts for Sales but not for Operations. Two delivery streams under one contract may be treated as separate projects by the team executing them while remaining one project for Finance. A scope expansion may receive its own budget without generating a new contract. A commercially closed engagement may still remain open because obligations are unresolved.

After twenty minutes, the meeting is no longer debating how many projects exist.

It is discovering that the organization never defined, with enough precision, what it means by a project.

This kind of disagreement is often treated as a data problem.

It is not always one.

An organization can keep producing more information while lacking something more fundamental: a stable answer to what that information is actually about.

A shared word does not guarantee a shared referent

Organizations reuse names because doing so makes coordination easier.

Customer. Project. Order. Case. Incident. Contract. Account. Request.

A common word allows many people to speak quickly about something everyone appears to recognize.

But sharing a word does not mean referring to the same thing.

For Sales, a customer may exist once an opportunity becomes sufficiently real.

For Finance, the relevant object may only exist once there is a billable relationship.

For Legal, what matters may be the contractual counterparty.

For Operations, the relevant entity may be the specific organization for which an outcome must be delivered.

Those views do not need to be identical.

Forcing every function into one representation could remove distinctions that are operationally useful. Different functions observe different aspects of reality because they need to do different things with it.

Legibility does not require everyone to describe the world in the same way.

It requires that, when two parts of the organization claim to be talking about the same thing, the organization can determine whether they actually are.

The representation may vary.

The referent cannot vary silently.

That silence is where a particular kind of confusion begins.

Sometimes the most basic problem underneath a reporting disagreement is simply this:

we do not know what we are counting.

Project Atlas

Suppose a company signs one contract to deliver Project Atlas.

At first, the identity seems obvious. There is one commercial promise, one contract, one budget, and one delivery team. All of it fits comfortably under the same name.

Months later, delivery splits into two independent streams.

One depends on infrastructure. The other on software development. Different people become responsible for each, and the work begins to be planned separately.

Finance still carries one cost center.

Legal still carries the original contract.

The client still calls the whole engagement Atlas.

Then one of the streams changes substantially. Its scope is renegotiated, it receives a dedicated budget and team, and it begins to extend several months beyond the other.

Inside Delivery, people start treating it as a separate project.

Finance still sees Atlas.

Legal still sees one primary obligation amended under the same contract.

What changed?

Not necessarily anything that can be described as an error.

Each representation may still be useful to the function that depends on it.

But the organization now needs to answer a different question:

Do we still have one project with two components, or do we now have two related projects?

The issue is not what phase Atlas is in.

The issue is whether Atlas still names one entity.

“Atlas needs more budget.”

“Atlas is behind.”

“Atlas has been delivered.”

“Atlas still has open obligations.”

The label survived.

What may have changed is the shape of what the label refers to.

The organization kept talking about one thing even after it may no longer have been one.

Identity has boundaries

What makes two activities part of the same project?

What distinguishes two customers from two business units inside the same customer?

When does a new request remain part of the original case, and when does it become another case?

These are not questions about progression.

They are questions about what counts as one thing.

Changing the owner of a project does not necessarily create a new project.

Neither does changing the budget, the deadline, or part of the scope.

But some changes affect more than the attributes of an entity.

At some point, what the organization has continued treating as one thing may no longer be one thing.

A label can survive that split.

The reverse can happen as well: one thing can become scattered across multiple names.

An acquisition may leave the same customer represented twice across different systems. Finance may use the legal entity name, Sales the commercial brand, and Delivery the operating business unit.

Using the same name everywhere would not solve the problem.

Two names can refer to one thing.

One name can conceal several.

What matters is whether the organization can tell which condition it is dealing with.

When a ticket is not an incident

The distinction becomes even clearer in support and technology.

A customer reports that they cannot complete a critical transaction.

A support ticket is opened.

Support investigates.

Engineering identifies a defect.

At the same time, a partial service outage is registered as an incident.

These things may be connected:

the customer’s problem,

the support ticket,

the service incident,

the engineering defect.

But connection does not mean identity.

Closing the ticket may mean that Support has responded to the customer.

Resolving the incident may mean that service availability has been restored.

Fixing the defect may require a later product change.

Fully restoring the outcome the customer needed may require something else again.

If the organization uses the word incident for all of these, it can create an appearance of coherence that does not exist.

One report says the incident is closed.

Another team is still working on the defect.

The customer is still waiting for the original problem to be resolved.

People can argue with complete confidence and all have evidence for what they are saying.

One points to the closed ticket.

Another points to restored service.

Another says the bug remains open.

The disagreement appears to be about the status of “the incident.”

It is not.

They are defending different things.

Sometimes a meeting does not run long because information is missing.

It runs long because language made a shared referent appear to exist when it never did.

A master record does not exhaust the problem

Part of this problem belongs legitimately to data management.

Master Data Management, semantic modeling, canonical identifiers, data governance, and entity-resolution practices can all help connect representations and reduce duplication.

But an organization can maintain technically excellent master records and still use the entities behind those records inconsistently.

One function may treat a commercial relationship as a customer, another as a billable account, and another as a contractual counterparty. Data infrastructure can represent those distinctions.

It cannot, by itself, determine which distinctions the organization needs to preserve in order to operate and when several of them should be treated as one thing.

That question appears in how work is assigned, what gets counted, and what the organization treats as a unit.

It also appears in what people assume remains the same over time.

Resolution, in this sense, is not merely the ability to join two records.

It is the ability to answer a basic organizational question:

when Finance says one thing and Operations says another, are they talking about the same entity?

And if they are not, what is the relationship between the two?

Integrating systems without answering that question can connect representations while leaving the underlying ambiguity intact.

Automation removes a quiet human capability

People are remarkably good at reconstructing ambiguous referents.

They understand that “Atlas” means one thing in a Legal conversation and something slightly different in Delivery.

They know that a closed ticket does not necessarily mean the underlying problem has disappeared.

They remember that two names in two systems refer to the same customer.

They reconstruct incomplete language from history and context.

That ability allows an organization to operate for a long time without making many of these relationships explicit.

Automation reduces that tolerance.

Not because machines are incapable of working with multiple representations.

They can.

The problem is that the organization still needs a way to establish what each representation refers to and how those representations relate.

A system can correctly execute an instruction across every “active project” and still produce the wrong result if Finance and Delivery use project to mean different units.

It can automatically close “resolved incidents” when the resolution criterion actually belongs to the support ticket rather than the service incident.

It can combine customer records and duplicate exposure, obligations, or activity because two representations were interpreted as separate entities.

In each case, the automation may be working exactly as designed.

The failure happened earlier.

The organization never stabilized the referent sufficiently for the system to know what it was expected to act on.

Legibility therefore does not always begin with more data.

Nor does it always begin with a better dashboard.

There is a prior question.

Before knowing something

An organization can know an enormous amount about its projects, tickets, and customers while remaining unable to determine consistently what unit each record represents.

None of this requires every entity to have one universal and immutable definition.

A sufficiently stable referent is not one that never changes.

It is one whose identity does not change without the organization being able to recognize that it changed.

Legibility does not require freezing reality in order to describe it.

It requires enough continuity for people and systems to know when they are still talking about the same thing.

Because before measuring something, you need to know what is being counted.

Before describing it, you need to know what the description refers to.

And before asking what a system knows about something, the organization needs to be able to answer a much simpler question:

What, exactly, is that something?