What the first meeting said

For nine years I was not a supplier to an institution. I was on its payroll, first building its internal systems from an office inside the same building as the people who used them, later teaching in the same faculty. Seven systems in that time: budgets and expenditures across every unit, purchasing and custodian inventory, tuition payment, student monitoring, staff requests routed through HR and Finance, and mail tracking for two different offices.

That is an unusual apprenticeship for someone who now sells builds, and it taught me one thing above everything else. The process described in a meeting and the process people actually run are two different things, and the gap between them is where systems fail.

The ticketing system taught me this properly

Staff requests were meant to go to HR, then to Finance, then get fulfilled. That is what the meeting said, that is what the memo said, and it is what I built.

It was not what happened. Urgent requests went to a particular person in Finance directly, because she would deal with them the same afternoon, and HR was told afterwards. Not a workaround born of laziness: a sensible adaptation to the fact that the official route took four days and some things could not wait four days. Nobody described it to me because from the inside it did not feel like part of the process. It felt like Tuesday.

A system that enforces the memo turns that adaptation into an offence. People then do the urgent thing outside the system entirely, and within a month your audit trail is complete and also fiction.

You cannot interview your way to this

Asking better questions does not fix it, because the people answering are not withholding anything. They are describing the process as they understand it, and the exceptions have become invisible through repetition. Ask somebody how they get to work and they will not mention the shortcut through the car park.

What surfaces it is proximity and time. Being in the building meant I saw the request come in the back door. Being there for years meant I saw what happened at year end, which is when every process reveals the branch nobody mentioned, and at the handover between one person in a role and the next, which is when the undocumented parts either get transmitted or get lost.

What I do now that I am not employed by the client

I cannot spend nine years in anyone's building any more, so the practice has to substitute for the proximity.

Nothing gets built without the person who does the work in the room, not only their manager. The manager knows the policy. The person knows the exceptions, and the exceptions are the requirements. Weekly there is something to click rather than a status report, because people recognise wrongness on a screen far faster than they recognise it in a specification document they have been asked to approve. And approval chains get built to match how the organisation actually escalates, including the path that exists because the official one is too slow.

On a migration the equivalent is the rehearsal. You can ask an organisation how many customer records they have and get a confident answer that is wrong by a third, not because anybody is lying but because nobody has counted since the last system change. Opening the database is the only way to find out, which is why I will not quote a fixed price on one I have not opened.

The uncomfortable part

This is why I ask for more access than a supplier usually gets, and why I say no to projects where I am handed a specification and asked to price it without speaking to anyone who uses the system.

I can build what that document says. I have done it, early on, and delivered exactly what was asked for to people who then went back to their spreadsheets. It was the most professionally executed useless thing I have made, and I would rather lose the work than do it again.