Two projects, one question
Two scoping studies run in parallel, on ground with nothing in common. The first replaces, for an HR function, a single skills-tracking matrix: five departments, some twenty workshops, several hundred positions, a few hundred skills, kept in a workbook where only nine per cent of the cells were filled in. The second replaces, for an industrial maintenance company, a technical expertise file and manufacturing routings scattered across Excel, Word and PDF, with no cross-search and no cost analysis possible.
Nothing alike, on the face of it. And yet the question asked at the start is the same in both cases: how do you get a tool that works quickly, without giving up the path to the complete solution you already know you need?
Write the whole target before cutting it up
The most common reflex under a tight budget or deadline is to shrink the ambition: describe a small tool, not the big one. That is the opposite of what works. In both studies, the complete target is written first, before any split: all the modules, all the rules, the whole ambition, laid on the table before deciding what goes first.
On the HR side, that target takes the form of a specification written in the second person, explicitly open to the client’s annotations, which the client amends over two successive versions after a working session. On the maintenance side, the density of rules (technical thresholds, exchange formats with an existing system) called for a more structured form: a single document of sixty-five questions, in nine categories, three of them flagged as blocking.
In both cases, the split into lots comes after this complete write-up, never during it. You do not trim an ambition to make it fit into a lot; you write the whole ambition, then you sort it.
Why write the ideal solution before splitting it into lots?
Because a lot designed on its own, with no full target behind it, closes in on itself: every following lot then has to renegotiate what the first one froze. Writing the whole target first keeps the freedom to cut in the right place, not in the place that was easiest to describe.
The criterion that settles lot 1
One criterion comes back in both studies to decide what goes into the first lot: what can be entered or tolerated manually without losing business value goes now; what needs automation to deliver a real gain waits.
On the HR side, the first lot covers everything needed to run a complete annual campaign, with history and export, but leaves out direct access to the tool for managers: they receive a PDF export designed for their presentations, rather than accounts to create and manage from the first lot. On the maintenance side, the first lot covers job management, the digitised expertise matrix, manufacturing orders with their routings, and a simple estimated cost calculation; tracking actual times and comparing them with planned times, which only make sense once automated, wait for the second lot.
Who decides what goes into lot 1?
One criterion settles it every time: what can be entered or tolerated manually without losing business value goes into lot 1; what needs automation to deliver a real gain waits for the next lot. It is never a question of technical convenience, but of what users can reasonably do by hand during one cycle.
A business decision can settle a technical one
The HR study illustrates a point that is often underestimated: the entire deployment architecture, SaaS, a container on the client’s infrastructure, or an executable on a single workstation, depended on a single business question still open at scoping time: who, exactly, assesses the skills? As long as that question had no answer, none of the three architectures could be frozen.
A business decision settles a technical one, never the other way round. Freezing the infrastructure before having the answer would have locked an architecture choice onto an unconfirmed assumption.
The method adapts to the density of rules, not to the client
The two studies are alike in their approach and differ in their form, and the reason fits in one sentence: the method adapts to the density of the domain’s business rules, not to the size of the client or its sector. A domain with narrative rules, where the exceptions can be counted on one hand, is scoped with a specification annotated as you go. A domain with dense numerical rules, technical thresholds, the formats of an existing system, calls for isolating each blocking point in a categorised question document, with a proposed default answer so the study does not stop on every open point.
Does the number of lots depend on the size of the company?
No, it depends on the density of business rules, not on the size of the company or the budget. A domain dense with rules needs more questions settled before the first lot, whatever the size of the organisation behind it.
Check before you build
In both studies, the same step comes before any development: check what the tool already in place, or a tool the client already owns, might already cover. On the HR side, the question asked before any estimate is simple: do the modules already subscribed in the client’s existing HR software cover part of the need? On the maintenance side, comparing the written specification with the client’s real data revealed a discrepancy in the thresholds of a technical formula between the two sources: a blocking point, explicitly listed, to be settled before freezing the architecture.
It is the same reflex in both cases: the written specification is never taken as true until it has been checked against the client’s real data.
What stays constant
Four things do not change, whatever the domain: a joint study before any line of development, a mock-up or a demonstration on real data before any contractual commitment, a specification explicitly open to the client’s amendments rather than a frozen deliverable, and a short warranty period after the first lot goes live, to stabilise it before opening the next one.
This foundation depends neither on the sector nor on the size of the company. The only thing that changes is the form the study takes to match the real density of the business rules it has to cover.