BLOG
Why most reporting automation projects fail in month three
15 January 2025
15 January 2025 ·Automation·Reporting·Lessons learned

Most reporting automation projects I’ve inherited have the same shape: a clever solution built under time pressure, documented lightly if at all, and maintained by one person who has since moved on.

The first two months are usually fine. The data is stable, the builder is still around to fix edge cases, and the business is happy that the manual process is gone. Then something changes — a column gets renamed in the source system, a new product category appears, a new jurisdiction is added — and the pipeline breaks silently.

What “silent failure” looks like

A broken pipeline that produces no output is easy to spot. The dangerous kind produces output that looks right but isn’t. Numbers are slightly off. A subset of records is missing. The wrong date range was applied.

Nobody catches it because nobody expected it to fail. The old manual process had a human eyeballing the output; the automated one doesn’t.

What I build differently now

Every pipeline has an output contract. Before the data lands anywhere downstream, it passes a set of validation rules: expected row count ranges, sum checks against known control totals, referential integrity checks. If anything fails, the pipeline stops and alerts — it does not deliver bad data silently.

Ownership is a team, not a person. I document enough that a second person can diagnose and fix a failure without calling the original builder. That means: what does this pipeline do, what are the inputs and outputs, where does it break most often, and how do you restart it.

Change detection is built in. Schema changes in the source system are the most common failure mode. A lightweight daily check that compares the current schema against the expected one catches renames and drops before they cause problems.

The real cost of skipping this

The cost is not the failed run. The cost is the three hours of an analyst’s time reconstructing what went wrong, the loss of trust in automated reporting, and the quiet reversion to the manual process — which is now poorly documented because everyone assumed the automation was the source of truth.

Build the guardrails in from the start. They’re not overhead; they’re what makes the automation durable.

← All posts