Most splinter spreadsheets do not begin with bad intentions.

They begin with urgency.

A missing report.
A delayed system change.
A customer needing an answer now.
A process nobody officially owns.

So somebody exports data, adds a few columns, and creates a spreadsheet “just for tracking.”

And then the business continues around it.


Databases Want Structure

Databases are designed to create consistency.

They enforce:

They aim to establish a single operational reality.

A customer has one account.
An order has one status.
A stock item has one quantity.

At least in theory.

The database becomes the system of record; the place the organisation agrees reality exists.

But operational pressure rarely waits for perfect system design.


Spreadsheets Want Freedom

Spreadsheets thrive because they solve problems quickly.

No development cycle.
No project board.
No change request.
No approval process.

Just:

That flexibility is precisely why spreadsheets are so valuable.

And also why they become dangerous.

The spreadsheet is not the villain. In many organisations, it is the fastest tool available to people trying to solve real problems.

But once spreadsheets begin collecting operational data independently from the source system, something subtle starts to happen.

Reality begins to fork.


The Rise of the Splinter Spreadsheet

Most businesses do not notice the moment it happens.

A spreadsheet originally created for temporary tracking slowly becomes embedded into operational process.

Extra columns appear.
Manual statuses are added.
People begin updating it directly instead of the system.
New reports start depending on it.
Copies get emailed around.
Local versions emerge.

Eventually, different teams begin operating from slightly different datasets.

Sales has one version.
Operations has another.
Finance has a third.

All technically “correct.”

All producing different answers.

At that point, the problem is no longer:

“Which number is right?”

It becomes:

“Which reality are we operating in?”


Logic Starts to Disappear

Databases expose structure.

Spreadsheets often conceal it.

Inside a mature database system:

In a spreadsheet, logic quietly hides itself inside cells.

A critical calculation may exist only in:

One incorrect paste operation can silently alter outcomes for weeks.

And unlike structured systems, spreadsheets rarely announce when integrity has been compromised.

They simply continue producing answers.


Governance Quietly Evaporates

A spreadsheet copied onto a desktop immediately detaches itself from most organisational controls.

No validation.
No enforced permissions.
No central ownership.
No guaranteed backup.
No audit trail.

Yet because the file still opens, still calculates, and still gets emailed around, the operational risk remains largely invisible.

That invisibility is what makes splinter spreadsheets so dangerous.

They often feel reliable right up until the moment they fail.


Nothing Is More Permanent Than “Temporary”

Many operational shadow systems begin with the same sentence:

“This is only until the system gets updated.”

But businesses are busy.

Priorities shift.
Projects get delayed.
Processes adapt around workarounds.

And over time, the temporary spreadsheet becomes infrastructure.

Entire reporting processes start depending on it.
Management meetings reference it.
Teams reconcile against it.
People trust it.

Even when nobody is entirely sure how it works anymore.


The Key-Person Problem

Eventually, ownership collapses into individuals.

“There’s only one person who understands that file.”

That sentence should concern any organisation.

Because it means operational continuity no longer exists within systems; it exists inside human memory.

The spreadsheet becomes:

People become afraid to touch formulas.
Macros become untouchable artifacts.
Columns survive long after their original purpose has been forgotten.

At this stage, the spreadsheet is no longer a tool.

It is an unofficial application.

Just without the engineering discipline normally required to support one.


Reconciliation Becomes the Work

One of the clearest warning signs of fragmented operational truth is when teams spend more time explaining numbers than acting on them.

Mature organisations can spend surprising amounts of time reconciling:

This creates organisational drag that rarely appears on any KPI.

Energy shifts away from:

and toward:

The business becomes slower, not because data is missing, but because too much disconnected data exists simultaneously.


The Real Problem Is Usually Elsewhere

Spreadsheets do not appear because employees enjoy creating operational risk.

They appear because the business needed something faster than the system could provide.

A missing workflow.
A reporting gap.
Poor usability.
Slow change processes.
Lack of ownership.
Operational urgency.

And often, they appear because people genuinely believe they are helping.

A team starts capturing “extra useful information.”
Someone adds a tracker to improve visibility.
A department creates its own status column because the official system does not reflect operational reality closely enough.

Individually, these decisions are usually sensible.

People are trying to:

But when multiple teams begin capturing their own versions of operational data independently, fragmentation begins to spread quietly across the organisation.

The splinter spreadsheet is usually a symptom before it is a problem.

And organisations that attempt to ban spreadsheets entirely often discover they are treating the outcome rather than the cause.


Good Organisations Pay Attention to Shadow Systems

The goal is not to eliminate spreadsheets.

That would be unrealistic.

The goal is to understand why they appeared.

Because every splinter spreadsheet tells a story:

Some spreadsheets should remain lightweight tools.

Others are signals that the business has already outgrown part of its operational design.

The danger is not the spreadsheet itself.

The danger is when unofficial systems quietly become the place the business truly operates from, while the database merely becomes where the data originally came from.

Related posts

Q-Day Is Coming

A recent cyber security roundtable led me to read more about Q-Day, quantum computing, and why the future of encryption may be a business issue long before it becomes a technical crisis.

Read →

Clarity Is a Design Choice

Confusion is rarely accidental. It’s often the result of deferred decisions, vague ownership, and flexible definitions. Clarity doesn’t emerge by chance; it is deliberately designed.

Read →

Small Systems Are a Leadership Skill

Leadership isn’t only visible in large programmes and budgets. The ability to design and maintain small, stable systems close to real work is often the clearer test of operational maturity.

Read →