The Decision-First Method

Most data projects fail for the same reason: they begin by building. We work in four stages, and the first two happen before anyone opens a development environment.

Schedule a consultation
The Decision-First Method 01Decide02Assess03Build04Hand off before anyone opens a development environment where most engagements start

Stages one and two typically take about a week together. Stage three is sized by what stage two finds, which is the point of running them in that order. Below is what each stage produces, what it asks of you, and what goes wrong when it is skipped.

01

Decide

We establish what decision you are trying to make and who has to defend it, before we look at a single table. Data work without that anchor produces dashboards nobody opens.

What this stage produces

  • A written statement of the decision and the person accountable for it
  • The list of questions the work has to answer
  • An explicit note of what is out of scope, agreed before anyone builds

What we need from you

Access to the person who has to defend the decision, not only the person who requested the report.

What happens when it is skipped

You get a technically correct dashboard that answers a question nobody was asking.

02

Assess

We review the estate as it actually is — sources, models, refresh behaviour, and the people who use it — and identify the real constraint rather than the obvious one.

What this stage produces

  • An inventory of the sources and models that actually feed the decision
  • A register of what we found — model debt, refresh behaviour, undocumented logic
  • The real constraint, named and evidenced, with a sequenced plan against it

What we need from you

Read access to the relevant systems, and an hour each with the people who use the current reporting.

What happens when it is skipped

The plan targets the obvious constraint rather than the real one, and the build runs long for reasons nobody predicted.

03

Build

We build alongside the people who will own the solution after we leave, in reviewable checkpoints, so the knowledge stays in your organization rather than walking out with us.

What this stage produces

  • Working pipelines, models and reports, built in your tenant rather than ours
  • Source-controlled code your team can read, in reviewable checkpoints
  • Tests and validation that fail loudly rather than quietly

What we need from you

A named counterpart on your side who joins the checkpoints and is expected to ask hard questions.

What happens when it is skipped

The solution works until it does not, and the only person who understands it has already left.

04

Hand off

Working solutions, written documentation, and the knowledge transfer your team needs to carry it forward without us. An engagement that cannot end has not succeeded.

What this stage produces

  • Written documentation of the models, refresh schedules and known limits
  • A working transfer session with the team who will own it
  • An honest list of what we would do next, and what we deliberately left alone

What we need from you

The owning team's time, scheduled before the final week rather than during it.

What happens when it is skipped

The engagement never really ends, and you are paying for access rather than results.

Why the order matters

Most engagements start at stage three

A stakeholder asks for a dashboard. A consultancy builds the dashboard. It is technically correct, it is delivered on time, and within a quarter nobody opens it — because the decision it was meant to support was never established, and the constraint that made the decision hard was somewhere else entirely.

Stages one and two are cheap. Stage three is expensive. Spending a week on the first two routinely removes a month from the third, and it is the only reliable way we know to avoid building the wrong thing well.

Put the method to work

Most engagements begin with a conversation about the decision you are trying to make. Thirty minutes, no obligation, no pitch deck.

Schedule a consultation