← The Boring Department

Part one

Before you engage us

What changed in software procurement, how to pick the first problem, whether it needs AI at all, and how to write the brief.

Engraved illustration of a stack of procurement forms, a rubber stamp and a clock

§ 01 What changed in procurement

What changed in procurement

The scarce input used to be people-hours of coding. Traditional procurement follows from that one assumption: the long specification, the rate card, the change-control process. Implementation was expensive and changing direction was worse, so you tried to decide everything upfront.

For bounded internal software, that assumption no longer holds. An experienced builder with modern tooling produces working interfaces, integrations, tests and deployments far faster than a sequential team passing work through nine handoffs.

What stays scarce is the rest. Framing the right problem. Knowing the domain. Getting data access. Deciding what counts as correct. Owning the thing in production.

Note

This is not cheaper because a machine writes the code. It is cheaper because there is less wasted discovery, smaller batches and no coordination tax. Senior judgment, architecture and long-term ownership cost what they always did.

§ 02 Two routes, side by side

Two routes, side by side

Same problem, same budget, two orders of operations, read against each other.

  1. 01

    Requirements committee

    Weeks

    Stakeholders meet to agree what the system should do. Most of what gets written down describes the current workaround, because that is the thing everyone can picture.

  2. 02

    Specification

    Weeks

    The workarounds become a document: screens, fields, roles, reports. It gets priced as though it were certain, because the contract needs a number.

  3. 03

    Tender and evaluation

    Weeks to months

    Vendors respond. Scoring leans on headcount, day rates, track record and a feature checklist. None of those tell you whether anyone will use the result.

  4. 04

    Procurement approval

    Weeks

    Award, legal, purchase order. By now the requirements are several months old and nobody has touched working software.

  5. 05

    Build

    Months

    A full team runs the spec: business analyst, product manager, designer, frontend, backend, QA, DevOps, security, project manager. Every handoff loses a little of the original intent.

  6. 06

    UAT and handover

    Weeks

    Real users see it for the first time. What they ask for now counts as a change request, so it becomes a re-estimate and a delay.

The first time a real user touches the software is near the end. That single fact is what makes the old route slow and expensive. The coding was never the bottleneck.

Roughly 6 to 12 months before anyone clicks anything

Every fee, phase and obligation is written down.Engagement Terms § 02 — How we engage →

§ 03 The same money, spent differently

The same money, spent differently

Scroll the table sideways →

DimensionThe old routeHow we work
What you're buyingA specified system and a delivery team for a fixed durationA working capability, plus a maintained asset you own
Starting pointA detailed spec and a fixed scope, written before anyone has used anythingOne operational problem, real examples, and a target you can measure
Who's in the roomBA, PM, designer, frontend, backend, QA, DevOps, security, project managerA small senior nucleus, with specialists brought in at the boundaries that need them
Time to something usableMonths, after procurementA working MVP in three weeks, live in about three months
When you first touch itNear the end, at user acceptance testingWeek one of the build
Cost of changing your mindA change request, a re-estimate, a delayExpected. It is what the iteration phase is for
Best fitLarge, interdependent programmes with genuinely stable requirementsBounded workflows, internal tools, process digitisation
Fees, invoicing and what happens if you stop: Engagement Terms § 03 — Fees and payment.

§ 04 Deciding what matters

Deciding what matters

The first thing to hand over is rarely the thing that gets talked about most in meetings. It is the thing that happens often, blocks several people, and can be counted.

Six questions. If a candidate fails two of them, pick another.

How often does it happen?
Daily beats quarterly. Frequent work gives you feedback within the three weeks and a you can measure against.
How many people does it block?
Count the people waiting, not just the person doing the task. A two-minute approval that stalls eleven people is a bigger problem than an hour of solo work.
What does it cost when it goes wrong?
Rework, missed deadlines, an apology to a customer, an audit finding. Put a rough figure on one instance.
Can you measure it today?
If nobody can say how long it currently takes or how often it fails, the first job is counting. A week of tally marks is enough.
Is it bounded?
One workflow, one team, a clear start and end. If describing it needs a diagram with four departments on it, pick a smaller piece of it.
Is there a named owner?
Someone who decides. Not a steering group. Work without an owner stalls in week two and the build stalls with it.

Fig. 2 — Scoring a candidate

Five scoring dimensions for choosing the first problemHow oftenRareDailyPeople blockedOneA queueCost when wrongAnnoyingExpensiveMeasurable todayNo countCountedBoundedFour teamsOne workflowexample:triage queue
  • How often: from "Rare" on the left to "Daily" on the right.
  • People blocked: from "One" on the left to "A queue" on the right.
  • Cost when wrong: from "Annoying" on the left to "Expensive" on the right.
  • Measurable today: from "No count" on the left to "Counted" on the right.
  • Bounded: from "Four teams" on the left to "One workflow" on the right.
Score each line left to right. A candidate that sits left on frequency can still win outright if it sits hard right on cost when wrong.

Worked example

The work
Triaging inbound requests into low, medium and high risk
Frequency
About 60 a day
Who waits
Four case officers and, downstream, the requester
Today
Median 25 minutes each, mostly spent finding prior cases
Cost of error
A misrouted high-risk case gets found late, at review
Target
Under 10 minutes median on low-risk, no change in miss rate

Why this example works

That last line is what a good brief looks like. It names the change, the population it applies to, and the thing that must not get worse.

On rare work

Frequency is one input, not the verdict. Something that happens twice a year still qualifies if the pain is big enough: an audit return that costs three people a fortnight each time, a licensing cycle where one missed record is a fine. Rare and expensive beats frequent and mildly annoying.

Poor candidates

  • Work nobody owns. There will be no one to answer questions in week one.
  • Work that is about to be reorganised. Build after the reorganisation, not before.
  • Pain caused by a policy rather than a tool. Software will make the policy faster, not better.
  • Work that happens twice a year and costs little when it goes wrong. Rare and cheap is hard to test inside the build; rare and expensive is fair game.
  • A request that arrives as a screen list. Something further upstream has already been decided for you.

§ 05 Do you need AI in this?

Do you need AI in this?

means a doing one named job inside a workflow, with a defined input, a defined output, and somewhere the result gets checked. Terms with a dotted underline open a short definition; all of them are in the glossary.

Putting a inside a workflow is a real decision with real costs, and it is currently being made by default. It should not be.

A model is worth having when the input is messy and human judgment is the bottleneck. It is a poor fit when the rules are already written down.

Fig. 3 — Where the answer usually lands

Decision tree ending in four options for putting AI in a systemIs the input messy, and is judgment the bottleneck?Rules engineThe rules are written downSearch your documentsThe answer already existsModel, human approvesMessy input, checkable outputModel, customer-facingHigh volume, tolerable errors
  • Rules engine — when the rules are written down.
  • Search your documents — when the answer already exists.
  • Model, human approves — when messy input, checkable output.
  • Model, customer-facing — when high volume, tolerable errors.
Most requests that arrive as “we want AI” end in one of the first three boxes. The fourth is the rarest and the most expensive to run.

What you gain

  • It reads free text: emails, notes, PDFs, forms filled in badly.
  • It classifies and ranks without you enumerating every case in advance.
  • It drafts, so a person edits instead of starting from a blank page.
  • It absorbs variation. New phrasing does not require a code change.

What you pay for it

  • It is wrong sometimes, and it is wrong confidently. There is no error message.
  • The same input can produce a different answer tomorrow, which makes testing harder.
  • It needs a review step, and that step costs somebody time. If the review takes as long as the task, you have gained nothing.
  • It costs money per use, not per licence, so heavy use scales the bill.
  • Data leaves your boundary unless the design says otherwise. That has to be a deliberate choice, written down.
  • Someone must be accountable for what it produces. A model is not a person you can ask why.

Worth the complexity when

  • High volume of genuinely unstructured input
  • An error rate you can live with, and a human positioned to catch errors
  • Value that survives the review step
  • A case where being roughly right quickly beats being exactly right slowly

Not worth it when

  • Rules you can write down. Write them down.
  • Wrong answers that are expensive or irreversible
  • Low volume, where a person is cheaper and better
  • Output nobody reads, which is most dashboards

The options people skip

Search over your own documents
Often the real request. Finding the prior case beats generating a new answer about it.
Templates and validation
Structure the input and half the messiness disappears before any model sees it.
Model behind an approval step
The model drafts, a person releases. Most of the benefit, most of the risk removed.
Narrow classification
One decision with three possible outputs, measured weekly, is testable. An open-ended assistant is not.

Note

If we think your problem does not need a model, we will say so and build the boring version. That version is usually faster, cheaper and easier to defend at review.

Worth knowing before this conversation: , , , , and .

How model usage is charged and capped: Engagement Terms § 06.5 — AI service.

§ 06 Writing the brief

Writing the brief

A specification tells us what you guessed the answer was. A problem statement tells us what you are trying to change, and lets us prove whether it worked.

Harder to work with

“Build us a case-management portal with dashboards and reporting.”

Much better

“Cut median triage time on low-risk requests from 25 minutes to under 10, while keeping role-based access and an audit trail.”

The users and the boundary
Who does this work, and where the workflow starts and stops. One workflow beats five.
The current baseline
How long it takes today, how often it goes wrong, how big the backlog is. A rough number is fine. No number is not.
The improvement you want
What better looks like, and over what period you would want to see it.
The non-negotiables
Data handling and residency, who may see what, systems it must talk to, availability, and whether the software may act or only assist.

Missing some of it is fine. Start the conversation and we will work them out together. Phase 01 exists for this.