The Anatomy of a 6-Week Enterprise AI Project

The precondition: this isn't about the model

If you don't have a named workflow owner, a quantified success metric, and a production deployment path — stop. None of what follows will work. Build those first. A 6-week project presupposes that the organisational homework is done.

If that sounds obvious, consider how many six-week “pilots” you've seen that spent all six weeks litigating scope.

Week 1 — Scope and data reality check

The first week is not about modelling. It's about making sure the thing you're about to build can actually be built, at all, in the available data environment.

Three deliverables by Friday of week one:

A one-page scope doc. One workflow. One decision. One owner. One metric. If you can't fit it on one page, the scope is wrong.

A data walk. Physically look at the data you'll train on. Row counts, event distributions, nulls, timestamp integrity. Most disasters in week four are visible in week one if anyone bothers to look.

A deployment pre-read. Where will the service run? What auth model? What monitoring? Write down what has to be true for this to reach production. If any answer is “we'll figure that out later,” fix it now.

Week 2 — Baseline and first model

By the end of week two, you should have two things running: a baseline and a first working model.

The baselineis the simplest thing that could answer the question — a rules-based classifier, a moving average, a SQL query. If your sophisticated model doesn't beat the baseline, it isn't working.

The first model is trained on historical data with a simple evaluation harness. Not tuned. Not productionized. Just running end-to-end, producing an output on a validation set, with a number that says how well it did.

Weeks 3–4 — Iteration on the spike

By now you know roughly what works, where the data is lying to you, and what the model's natural failure modes are. Two rules:

• 1.Don't beat the baseline by less than the error bars. If the baseline scores 0.71 ± 0.04 and your model scores 0.73, you don't have a better model. You have noise.
• 2.Re-read the scope doc at the end of every week. Scope drift here is the single biggest killer of production delivery later.

Week 5 — Integration and fallback behaviour

Week five is the week that separates projects that ship from projects that present.

The model now has to live somewhere. That somewhere has authentication, monitoring, rate limits, versioning, and — critically — defined fallback behaviour for when it fails.

Questions to answer this week:

• →What happens when the model's confidence is below threshold?
• →What happens when the model returns nothing?
• →What happens when the model returns the wrong thing?
• →Who finds out, and how quickly?

Week 6 — Shadow mode and exit

Week six is not for “final tuning.” It is for running the model in shadow modeagainst the real workflow — producing outputs that aren't yet actioned, but are compared against the current manual decision.

At the end of week six, you make a decision:

• →Go live with monitoring turned on, fallback active
• →Extend by a defined amount if evidence is promising but incomplete
• →Kill if shadow mode shows the model doesn't clear the success criteria

That third option needs to be real. Projects that can't be killed become zombies.

What makes the 6 weeks possible

The weeks aren't interchangeable. Week one's scope work cannot be done in week two. The sequence matters.

The work is owned by a small number of people. Five engineers can ship this shape. Fifteen cannot.

The sponsor is present every week. Engaged enough to make week-four scope calls in hours, not weeks.