Artifact §06 · Practice note

The first fifteen minutes

There is a footnote on my homepage that says the useful half of this job is not the writing, it is earning enough trust from a warehouse supervisor, in the first fifteen minutes, that he actually walks you through how the work gets done. This is the longer version of that footnote.

I have sat in a lot of these rooms now. Seven business functions on one ERP, a payroll team who had done it by hand for years, and more recently seventy odd conversations with skiers who had no reason to give me their time. The pattern holds across all of them. What someone tells you in minute twenty depends almost entirely on what you did in minute two.

Why the first fifteen minutes decide the rest

Nobody walks into a requirements session neutral. By the time you arrive, the person across from you has already worked out a theory about why you are there, and it is rarely the flattering one. The common theories are that you are here to make them justify their job, that you are here to write down whatever your sponsor already decided, or that you are here to build something they will have to work around for the next five years.

If any of those theories is still standing at minute fifteen, you will get the polished version of the process. The version where nothing goes wrong and every exception is handled cleanly. That version is useless. The exceptions are the requirement.

What I do not do

• Open a laptop first

  A screen between two people changes what gets said. I take notes on paper for the first stretch, and I say out loud that I am going to. It sounds small. It is not.

• Lead with a template

  Arriving with a form to fill in tells someone their job is to answer my questions rather than explain their work. I have the template. I fill it in afterwards, on my own time.

• Ask what their requirements are

  It is the single least productive question in the discipline. It asks a person to do my job, in my vocabulary, on the spot. Most people respond by naming a feature they saw somewhere, and then we spend six weeks discussing that feature.

• Pretend I already understand

  Nodding along to protect my own credibility costs more later than admitting I do not follow. I would rather ask someone to explain their own acronym twice.

What I do instead

1. Say why I am here and who sent me, before anything else.

   Because they are going to work it out anyway, and finding out on their own is worse. Naming the sponsor also lets them tell me if the sponsor has the wrong idea, which happens more than sponsors think.

2. Ask them to show me rather than tell me.

   Because people describe their process from memory and demonstrate it from muscle. The gap between the two is where the workarounds live, and the workarounds are the real system.

3. Ask what the worst day of the month looks like.

   Because average days do not generate requirements. The system has to survive the bad day, and the bad day is the one they actually want fixed.

4. Ask what they have already tried, and take it seriously.

   Because somebody usually built a spreadsheet that solves eighty percent of it. Treating that spreadsheet as a nuisance rather than as evidence is how you lose the room. It is prior art and it was built under the real constraints.

5. Ask what would make this worse for them.

   Because nobody volunteers that a change will cost them autonomy or make their day harder. Asked directly, most people will say it, and it is usually the risk that sinks adoption six months later.

The hard version

Some of these conversations are with someone who has correctly worked out that the thing you are building removes a task they are known for. The self service payslip portal I helped roll out took a queue away from outside the HR office. That queue was somebody's afternoon, and being the person who could answer that queue was part of how they were valued.

I do not think you can talk anyone out of that concern, and I have stopped trying. What I can do is be straight about scope, be clear about what I do not know, and never promise on behalf of someone else's manager. If I do not know whether their role changes, I say I do not know and I say who does. Guessing kindly is still guessing, and being caught doing it costs you every other conversation in that department.

The thing I try hardest to avoid is treating resistance as an obstacle to route around. It is almost always information. On the ERP, the two functions that pushed back hardest were the two whose edge cases nobody upstream had accounted for. They were not being difficult. They were the only people who had read the specification properly.

What I send afterwards

Within a day, I send back what I heard, in their words rather than mine, and ask them to correct it. Not a formatted specification. A short summary that uses their terms for their own steps, including the parts I am not sure I understood. There is an example of one at the end of the process map.

This does three things. It catches the misunderstanding while it is still cheap. It shows them their time produced something. And it means that when the formal document arrives weeks later, they have already seen their own fingerprints on it, so sign off is a confirmation rather than a negotiation.

The reply I want is a correction. If somebody sends back a note saying no, we only do that when the shipment is short, that is the single most valuable email of the project.

Where this still goes wrong for me

I over prepare. On a twelve person delivery team, walking in having already read the process documentation paid for itself repeatedly. On smaller teams it has made me arrive with a shape in my head, and a shape in your head is a hard thing to hear past. I have had at least one session where I asked confirming questions for forty minutes and learned nothing, because I had unknowingly decided what the answer was on the train.

What I do about it now is write down my assumption before the meeting and leave the note face down on the table. It is a slightly ridiculous ritual. It works often enough that I have kept it.

Written by Nasmaan Ibrahim for nasmaan.com.
Back to the record · One requirement, written out in full · Seventy six conversations, one page · Resume, PDF