Confirm the data exists at all

The most common failure is discovering, months in, that the records needed do not exist in usable form. The field is optional and mostly empty; the history was truncated; the outcome was never recorded systematically.

Run a small extract and look at it before committing to anything. A day of this routinely saves a quarter.

Labels are the bottleneck

Supervised learning needs examples with known answers, and organisations almost always have less of this than they assume. Raw volume is rarely the constraint; labelled, trustworthy examples are.

Where labels must be created, cost it honestly — including expert time — and check that two experts agree with each other. Where they do not, the problem definition needs work before any modelling starts.

Check whether history predicts the future

A model learns the past. If the process, the market, or the product changed materially, older data may be actively misleading rather than merely stale.

Ask what changed and when, and be prepared to discard data from before a significant change even when that leaves you short.

Look for the rare cases

The valuable classes are usually the rare ones — fraud, failure, churn — and they are exactly where examples are thinnest. A dataset that is ninety-nine percent one class needs deliberate handling, and accuracy becomes a misleading metric.

Count the minority class early. If there are fifty examples, no modelling approach will rescue that.

Resolve the permissions

Whether you may use the data for this purpose is a question with a real answer, and it is much cheaper to establish before the project than after.

  • What was the data collected for, and does this use fall within it?
  • Is consent required, and does the existing consent cover this?
  • Where must the data physically stay, and does that permit your chosen tooling?
  • What must be removed or masked before it leaves the source system?
  • How will a deletion request be honoured once data is in a training set?

Build the baseline first

Before any model, measure the simplest approach: the most common outcome, a threshold, a handful of rules. This is your comparison point, and a meaningful share of projects turn out to beat it by too little to justify the cost.

Finding that out in week one is a success, not a failure.

Written by the Global IT Solutions engineering team. Working through this decision right now?

Start a conversation