Why sustainability projects fail at data collection

The pattern repeats across companies of every size. An LCA is commissioned, a footprint promised to a customer, a disclosure cycle begun. The kickoff goes well, the consultant sends a data request, and then the project stalls, because the analysis was bought before anyone checked whether the data to feed it existed. The utility figures live in a spreadsheet nobody fully trusts, production records use different units at different sites, and the supplier information consists of hopeful emails. Most failed sustainability projects fail here, not at the analysis stage, and the failure is avoidable if data is treated as the project rather than a formality before it.

Where does each number actually come from?

The first discipline is knowing the origin of every figure, because origin determines trust. A useful hierarchy, from strongest to weakest:

• a meter reading, measured at the point of use
• an invoice, billed by a counterparty with its own reasons to be accurate
• an ERP or production record, entered internally for another purpose
• a supplier declaration, someone else's calculation accepted on stated terms
• an estimate, which is legitimate only when labelled as one

Every figure in a dataset should carry its place in this hierarchy. Estimates are not a scandal; a first inventory without them is almost impossible. The scandal is an estimate promoted silently to fact, because once that happens nobody can say which parts of the result are load-bearing. Stating the basis for every figure is one of the standing commitments of our practice, and it is the difference between a number that survives an auditor's question and one that dissolves under it.

Units, boundaries and the unglamorous work of standardisation

Figures cannot be aggregated until they are comparable, and in most organisations they are not. One site records fuel in litres, another in kilograms. One report covers the calendar year, another the financial year. One plant's "energy use" includes a leased warehouse, another's excludes it. None of these is an error on its own; together they make every total quietly wrong. Standardising units, periods, boundaries and naming across sites and years is dull, and it is the single highest-leverage piece of work in the whole field, because everything downstream, from a customer's footprint request to an annual disclosure, inherits its quality.

Why last year's number must still be explainable this year

Emission factors, the coefficients that turn activity data into emissions, are published in databases that are revised over time. If your calculation records only the final result, then when a factor is updated your historical figures become unexplainable: you can no longer say which factor produced them, and you cannot distinguish a real change in your operations from a change in someone else's database. The remedy is versioning. Record the source, version and retrieval date of every factor used, keep superseded versions, and when factors are updated, restate history knowingly rather than discovering the drift later. A number calculated last year must still be explainable this year; that is the test, and factor versioning is how it is passed.

The supplier engagement reality

For any product-level work, some of the data you need belongs to your suppliers, and the uncomfortable truth is that most will not respond to the first request. Plan for that instead of being surprised by it. Send requests that are specific about the product, period, unit and format, so that answering is easy. Establish an escalation path through the commercial relationship, since a data request carried by procurement lands differently from one sent by a sustainability inbox. And decide the fallback in advance: where a supplier cannot or will not provide data, a secondary database value is used and labelled as such, to be replaced when a real figure arrives. The same dynamic runs in the other direction when your own customers ask you for a product carbon footprint, which is a good reason to be the supplier who answers well.

An audit trail that survives questioning

Sooner or later the numbers meet a reviewer: an auditor, a customer's analyst, a certification body, an assurance provider working through a disclosure prepared under a framework such as BRSR or CSRD. What survives that encounter is not confidence but provenance: who collected each figure, when, from what source, transformed how, checked by whom. An audit trail is cheap to build at collection time and nearly impossible to reconstruct afterwards, which is why it belongs in the collection process itself rather than in the week before the audit.

Making collection repeatable instead of heroic

A one-off data gathering effort, however good, decays the moment its author changes jobs. The durable version is a defined process: who collects what, when, into what structure, validated against which rules, approved by whom. Building that foundation is the substance of our data collection engagements, and making it run without a consultant, with named owners, controls and a calendar, is what our systems work exists for. Tooling can help, but process comes first, and we stay vendor-neutral on software because the discipline matters more than the product that hosts it.

Frequently asked questions

Should we buy sustainability software before organising our data?

No. Software structures a process; it does not create one, and a tool bought before definitions, sources and owners exist usually becomes an expensive spreadsheet. Settle the process first, then specify the tooling requirement it creates.

Is estimated data acceptable?

Yes, when it is labelled as an estimate, its basis is stated, and there is a plan to replace the estimates that most affect the result. Every mature dataset started this way; the discipline lies in never letting an estimate pass as a measurement.

Where should an organisation with nothing in place begin?

With an inventory of what already exists: which records are kept, by whom, in what units, covering what. Most organisations hold more usable data than they think, scattered across billing, production and procurement, and mapping it is the honest first step.

This article describes reporting obligations in general terms and is not legal advice.