AI Project Delivery · AI Project Management · Enterprise AI Implementation
Give the Process Back
Clients expect you to design the process they have never written down. Draft it from their own documents, mark what cannot move, and make them own every change.
Published
Somewhere in the second or third week, it becomes clear that the client expects you to map their processes for them.
It is rarely even put as a question. It is assumed, the way the furniture is assumed, and the people assuming it are usually being perfectly sincere.
Say yes and you have just agreed to design the business you were hired to build software for.
Here is what took me a long time to understand, and longer to act on. They are not asking you to write their process down. They are asking you to decide it. Those are completely different jobs, and only one of them is yours.
They want the world, and nobody has written down how their world works
The request is never small. It arrives as a handful of documents, a diagram somebody made two restructures ago, and a sentence like “we just need the journeys mapped end to end”.
What you discover, usually about a fortnight in, is that there is no single version of how the work currently happens. Different teams describe the same step differently. The documents describe an intention rather than a practice. And nobody inside the organisation has been forced to reconcile that, because until you arrived there was no reason to.
So when you take that on unconditionally, you are not filling a gap in their paperwork. You are absorbing the hardest unfinished thinking in their business, on their behalf, to their deadline, and then being held to it.
You will end up doing the mapping. Almost everybody does, and refusing outright only makes you difficult to work with. What matters is when, and on whose terms. Take what they already have, give it back better, and do not begin until the sequence further down is agreed.
Every accommodation buys you another round
The failure mode here is not a dramatic one. It is kindness, repeated.
They ask for a change. It is reasonable, so you make it. That change exposes something they had not considered, so they ask for another. Each individual request is defensible. The cumulative effect is that the flow never settles, and a flow that never settles means nothing underneath it can be built.
Then the timeline slips, and this is the part that used to genuinely enrage me: the slip is yours. Not theirs. Yours. Even though you sent the flows for review on time. Even though you asked for feedback and said what you needed by when.
I stopped treating that as unfair and started treating it as predictable, which is more useful. If you are the only party with a deliverable date attached to your name, then every unresolved question will drift towards you, because you are the only person in the room for whom it is urgent.
Who carries the delay: You. That does not change at any point along this bar.
They will not read it. They will hold a meeting about it.
Send a process flow to a client for review and you expect what you would do: open it, read it, mark the bits that look wrong, send it back.
That is not usually what happens. What happens is that it gets scheduled. A meeting is arranged, often a week out, at which the flow will be walked through on a shared screen for the first time by people who are seeing it live.
Which means the review is now a performance rather than a reading. Objections get raised in the moment, in front of colleagues, at the pace of whoever speaks most comfortably in meetings. Half of what is said is not about the process at all. And nothing is written down, because everyone is watching the screen.
You will leave that meeting with a list of changes and no record of which of them anybody actually agreed to.
They read it
- Concerns are written down, with a name against each one
- Each one points at a step, so it can actually be answered
- They arrive before the meeting, so the meeting has an agenda
- There is a record of what was objected to, and when
They hold a meeting
- Seen for the first time live, on a shared screen
- Objections arrive at the pace of whoever speaks most comfortably
- A good half of the discussion is not about the process at all
- Nothing is written down, because everybody is watching the screen
The people who serve the customer best are not the ones who sign
This is the uncomfortable one, and I want to be careful with it.
The process owner owns the process. The front line serves the customer. These are frequently not the same process.
Operators find workarounds, and the good ones find excellent workarounds. They discover that two steps can be collapsed, that a check is unnecessary for certain cases, that customers are better served by doing the thing in a different order. They do this quietly, because it works, and because nobody rewards you for filing paperwork about a shortcut.
Their process owner is often genuinely unaware. Not through negligence. Through distance.
And yet the owner signs. The owner is accountable, the owner holds the budget, and the owner has the final say over a process they may not have watched being performed in a long time.
You cannot fix that from the outside, and it is not your place to try. What you can do is make sure the thing being signed is explicit enough that the gap becomes visible to them. A flow that says precisely what happens at every step is the only document that gives a process owner a chance to notice that reality has moved.
If you map it for them
You own every assumption you were forced to make. Each round of changes is a new requirement wearing a correction's clothing. The date is still yours.
If you give it back
They own the process, because they always did. Your job narrows to what is technically possible, which is the only part you can actually defend.
So stop arguing about it and build the mechanism
None of the above is solved by being firmer in meetings. It is solved by having a sequence that everybody agreed to before anybody was annoyed.
This is the one I use.
- 01YouDraft it from their own documentsBuild the initial flow out of what they already gave you, aligned to how the solution actually works. Not what you think they should do. What their own paperwork says, made consistent.
- 02You, to themMark what cannot moveSend it back with the technical constraints shown plainly, so it is obvious which parts are open to change and which are not. Everything not marked is theirs to adjust.
- 03ThemThey amend, and state their concernsThey make the changes they want inside the areas that are open, and write down what worries them. In their hands, in writing, before any meeting.
- 04YouReview for feasibility, then meetWork out what is possible and what is not, and only then hold the meeting. Now the meeting has an agenda made of real disagreements instead of first impressions.
- 05YouMake the final changes and submitApply what was actually agreed in the room, and send the final version over for approval.
- 06ThemApprove it by emailNot a nod. Not a thumbs up in a chat during a call. An email. Only once that arrives does anybody start building.
Notice what step two is doing. By marking the technical constraints yourself, you are not restricting them. You are giving them a much easier job. Most clients are not trying to be difficult; they simply cannot tell which of their requests is free and which one quietly rebuilds our systems. Tell them, and most of the expensive requests never get made.
Notice what step three is doing too. Asking them to write their concerns down before the meeting changes who is prepared. It moves the first reading from a shared screen into somebody’s own time, which is the only place careful reading happens.
Why it has to be an email
Because approval that was given in a meeting did not happen.
I do not mean that cynically. I mean that six months later, when somebody asks why the journey works this way, a verbal agreement is a memory, and memories are partisan. An email is a date, a name and a version. It ends the conversation in four seconds instead of forty minutes.
It is also the kindest thing you can do for the person approving it. An email forces them to look at the thing one more time, alone, with nobody watching, which is often the moment somebody finally notices the step that has not been done that way since 2023.
This protects them more than it protects you
It would be easy to read all of this as defensive, as a way of making delays somebody else’s fault. That is not what it is for, and if that is the spirit in which you run it, it will not work anyway.
A client who owns their process gets a solution built on how their business actually operates, rather than on an outsider’s best guess at it. They get the chance to discover their own inconsistencies early, while they are still cheap. They get a document they can hand to the next supplier.
And the project gets the one thing that makes everything afterwards calmer: a single artefact that everybody has read, everybody has argued about, and somebody has signed.
Build from that. Never from a conversation.