A source of truth is a management decision, not a software feature.

Most businesses I work with have a data sprawl problem by the time they call me. Five tools. Three spreadsheets. Two people who are "the source of truth" for the same number. A CRM that the sales team trusts and the operations team does not.

The proposed solution is almost always a new tool, a better integration, or a migration to a single platform that will "consolidate everything."

Sometimes this is right. More often, it is addressing the symptom while leaving the cause intact.

The cause is not the software. It is the absence of a decision about who owns the data and what happens when it conflicts.

Why data sprawls

Data does not sprawl because people choose chaos. It sprawls because the business adds tools as it grows, and each tool becomes the source of truth for whoever uses it most.

The CRM is the source of truth for pipeline—for sales. The project management tool is the source of truth for delivery—for operations. The spreadsheet is the source of truth for revenue—for finance. The tool the founder prefers is the source of truth for strategic context—for everyone when the other sources are wrong.

Each team is right in their own frame. The problem is that these frames do not agree, and there is no governing decision about which one wins when they conflict.

The question that reveals the problem

The question I find most useful early in an engagement is this: "If the number in the CRM and the number in the spreadsheet disagree, which one is right?"

Most teams cannot answer this cleanly. They say: "it depends," or "the CRM in theory but the spreadsheet in practice," or "you'd have to ask [person's name]." This last answer is the most revealing. It means the source of truth is a person, not a system—and when that person is absent, no one knows what to trust.

A source of truth exists when:

• There is one authoritative record for a given category of data.
• Everyone who uses that data knows which system is authoritative.
• When data in other systems conflicts, the process for resolving it routes to the authoritative record.
• Someone owns the authoritative record and is responsible for its quality.

This is a set of decisions, not a software feature. The software can make the decisions easier to enforce. But the software cannot make the decisions.

The integration trap

A common instinct is to solve data sprawl with integrations: sync the CRM to the project tool, connect both to the reporting dashboard, build a pipeline that keeps everything in agreement.

Integrations can be part of the answer. They are a bad place to start.

An integration between two conflicting sources of truth creates a conflict-resolution problem. When the CRM says the project is in "scoping" and the project tool says it is in "delivery," what does the pipeline do? Usually: it picks one, applies a rule, and produces a number that neither team trusts.

Before you integrate, decide which system is authoritative for which category of data. Then build integrations that read from the authoritative source, not ones that try to merge conflicting inputs.

The ownership principle

Every category of data needs an owner. Not a tool admin—a person who is responsible for the quality and currency of the data in that category.

Ownership means:

• The owner is the person who knows whether the data can be trusted.
• When data is wrong, the owner is responsible for fixing it.
• When data conflicts, the owner is the person whose answer is final.
• The owner has the authority to set standards and require the team to meet them.

Without an owner, data quality degrades slowly and continuously. Everyone has a reason the data in their section is unreliable. Nobody has the authority to insist on better.

Apply this

If your business has a data sprawl problem:

• List the data categories that create confusion or conflict: pipeline, revenue, delivery status, client health, staff capacity—whatever applies to your business.
• For each category, identify the current de facto sources: which systems hold this data, and which do people actually trust?
• Decide which system is authoritative for each category. Write it down. Make it visible to everyone who uses the data.
• Name an owner for each authoritative source. Give them the authority to set standards and the accountability for quality.
• Define the conflict resolution path: when data in other systems differs from the authoritative source, what is the process?

The tool selection conversation—new CRM, better project management, consolidated BI—comes after this. Not before.

You might find, after completing this exercise, that the tools you have are adequate and the problem was the governance. Or you might find that one tool genuinely cannot serve as the authoritative source for what you need, and you now have a specific, scoped reason to change it.

Either way, you are solving the right problem.