What to Specify Before You Commission Software

A business commissions a system. Months later it arrives, it technically does what was asked, and within a year people have quietly gone back to the spreadsheet.

The post mortem usually blames the developer. Occasionally that is fair. Far more often the decisions that determined the outcome were made before anyone wrote a line, and nobody recognised them as decisions at the time.

1. Which process, exactly, and how often it runs

The most common failure is scope. Somebody describes a system covering everything the business does, because describing everything feels thorough.

Systems that succeed replace one process, completely, for one group of people. They go into use within weeks and earn the right to grow. Systems that fail launch with forty features, none of which quite fit, because the specification described an idea of the work rather than the work.

Name the process. Then find out how many times a week it actually runs. Under five and the build cost will outlive the benefit.

2. What happens in the exceptions

Every process has a standard path that everybody can describe and a set of exceptions that live in individual heads.

The client invoiced differently because of something agreed in 2019. The job type that skips a stage. The approval that goes to a different person in one region. Nobody mentions these in the specification meeting because they are not thinking about them.

Then the system launches, meets an exception in week two, and somebody has to work around it. Two or three of those and the workaround becomes the process again.

Ask specifically: when does this not work the way you just described. Keep asking until people run out of answers.

3. Who has to change what they do

Every new system asks somebody to work differently, and that person is frequently not in the room when it is specified.

If the people who will use it daily have not described their own process in their own words, the specification reflects how management believes the work happens. Those two versions are never identical and the gap is where adoption dies.

The test is simple. Can the person who will use this most name one thing it makes easier for them personally? If the honest answer is that it mainly helps reporting, expect it to be filled in badly.

4. What it connects to, and who maintains that

A system that does not write to the place work already happens has not removed work. It has added a destination and a copying step.

Integration is where value is created, and it is also the part that breaks. Agree upfront what it connects to, what happens when a connection fails, and who is responsible for noticing. A failure path that retries then escalates to a named person with the reason attached is the difference between a system people trust and one they abandon after a silent outage.

5. What you measure, and what it is today

Agree the number before the build. Elapsed time, error rate, hours spent, whatever the system is meant to move.

Then record where it stands now. Without a baseline you cannot prove an improvement afterwards, and a project with no demonstrable result is a project nobody funds a second time regardless of how well it works.

This costs an afternoon and it is skipped more often than any other item on this list.

6. Who owns it in eighteen months

Processes change. A supplier alters a format, a stage gets renamed, the business starts handling something that did not exist at launch.

If nobody is responsible for noticing that the system has drifted out of alignment, it degrades quietly and is eventually abandoned. Name a person, not a department, and accept that this is fifteen minutes a month rather than a role.

If you cannot answer this question, do not commission the software. That is the real gate, and it has nothing to do with budget.

Where AI changed the specification itself

One thing worth knowing before writing any requirements, because it changes what is worth building.

Software used to require every rule to be written down in advance. Anything involving a judgement call had to stop and wait for a person, which is why so many systems automated the easy part and left the bottleneck.

That constraint has gone. Steps that need something read and interpreted, a document understood, a request categorised, a decision made between several reasonable paths, can now be part of the system rather than a break in it.

Practically, this means a smaller build often does more. Instead of specifying forty rules to cover every variation of an incoming document, you specify what a correct outcome looks like and let the system handle the variation. Fewer requirements, less brittleness, and considerably less to maintain when the variations change.

What to hand a developer

Not a feature list. A description of the process as it actually runs today, the exceptions, who does what, what it connects to, what you will measure, and who owns it afterwards.

That document is more valuable than the software, because it is what makes the software correct. It is also worth having even if you decide to build nothing, which is why the businesses that do this exercise properly quite often conclude they do not need custom software at all.

Fixed price against time and materials

The commercial structure shapes the outcome more than most buyers expect.

A fixed price forces a complete specification upfront, which sounds like discipline and produces a system built to a document written before anybody understood the problem properly. Every change becomes a negotiation, so changes stop being raised, and the result matches the specification rather than the need.

Time and materials with a defined first release usually works better for internal tools. Agree what the first version must do, agree a budget for reaching it, and expect the second half of the requirements to be better than the first because they will be written by people who have used something.

What to avoid is an open ended arrangement with no defined first release. That is where projects run for a year without producing anything anybody uses.

Ask what happens if you stop working together

Ask early, while the answer is cheap and nobody is defensive.

Who owns the code. Where does the data live and can you export it in a usable form. Is the documentation good enough for somebody else to take over. Is it built on anything proprietary to the supplier.

A good answer costs the supplier nothing and tells you a great deal about how they work. A vague one is the single most reliable warning sign available at this stage.

AI Optimize maps the process and the exceptions before anything is built, agrees the measure in advance, and hands over documentation somebody else could maintain. That work sits under Custom Software.