Your approval chain will stall on someone's vacation. Plan for it now.

Imagine the bad week first

A pre-mortem is a simple exercise. Instead of asking "will this work?", you assume it already failed and ask why. People find it much easier to name problems when they're describing something that already went wrong, even an imagined one.

So imagine it's the last week of the quarter, a few months after your new approval workflow went live. A team needs to sign a vendor contract by Friday to keep a project on schedule. The request went in on Monday. It's Thursday afternoon and it still isn't approved. The vendor is asking. The project lead is asking. Finance is asking why everyone is asking them.

The tool did exactly what it was set up to do. That's the problem. Let's take the reasons one at a time, because each one points to a design decision you can make now.

It stalled because one person was away

The request reached the department head on Monday afternoon. She was on vacation until the following week. Her out-of-office reply said so. The workflow didn't read out-of-office replies.

This is the most common way approval chains stall, and the most fixable:

• Every approver has a named delegate, set in the workflow, not in someone's memory. Delegation can switch on automatically from a calendar or an "away" setting.
• Every step has a deadline. If nobody acts in a set time, the request moves to the delegate or escalates to the next person up, and the requester is told.
• Nobody is a single point of failure. If a step can only ever be approved by one human being, that's a risk worth naming out loud.

Deadlines feel strict until you notice the alternative is a request that waits forever, politely.

It also helps to let people approve from wherever they are. If the request carries its context, which is the next problem, an approver can safely decide from a phone between meetings, instead of waiting until they're back at a desk.

It stalled because nobody could decide from what they were sent

When the delegate finally saw it on Wednesday, the request said "Vendor contract, Q4 project, see attached." The attachment was the vendor's proposal. She had questions. Which budget line? Was this in the plan? Were other vendors considered? What happens if we don't sign this week? She emailed the requester. The requester was in meetings.

Approvers can't approve what they can't understand, so the request has to carry its context:

• The form asks for what the approver needs, such as the amount, the budget line, the reason, the alternative, and the deadline, rather than leaving it for a reply.
• It pulls in what systems already know: remaining budget, the vendor's history, whether a similar request was approved before.
• The approver can ask a question inside the request, and the answer stays attached, instead of in a separate thread.

A useful number to watch, once you have a workflow: how often does an approver have to ask a question before deciding? Each question is a field the form forgot.

It was slow because everyone was on it

Look at who was on the chain: the project lead's manager, the department head, finance, legal, IT security, and the COO. Six sequential steps for a contract that, frankly, didn't need most of them.

Long chains usually grow one reasonable request at a time. Someone wanted to know about every contract, so they were added. Then they became a step. The fix is to separate two roles:

• Approvers must decide, and the request can't move without them.
• Informed people are notified, can comment, and can raise a flag, but don't block.

Then set thresholds. A small, budgeted, low-risk purchase might need one approval. A large one, or one touching customer data or a new kind of vendor, gets more. Run independent reviews, like legal and security, in parallel rather than in a line.

Some approvals should stay firmly human, and we've written about which ones. Everything else deserves a chain no longer than its risk.

Nobody could say who approved it

Two months later, an auditor asks about that contract. Who approved it, and what did they see? The workflow shows "approved" and a date. It doesn't show which version of the proposal was attached when the approval happened, because the requester later swapped in a revised one.

An approval is a decision, and a decision needs a record:

• Who approved, as whom (themselves or as a delegate), and when.
• What they saw, meaning the version of the request and attachments at that moment.
• What changed after. If the amount or terms change after approval, the approval should reset for the steps that care.
• Comments and conditions, like "approved if the term is twelve months."

Keep that record somewhere people can search it without asking an administrator. The question "was this approved, and by whom?" comes up in audits, in disputes with vendors and in ordinary budget reviews, and the answer should take a minute, not an afternoon.

This is also what lets you improve the process. Where requests wait is visible in the record, which is the same idea we described in map the waiting, not just the work.

What to do before you pick a tool

There are plenty of good workflow tools. The design is still the work, and most of it happens on paper.

Take ten approvals from last quarter. For each one, write down who touched it, how long it waited at each step, how many questions were asked, and whether anyone who approved it could have been "informed" instead. Then draft the rules on one page: steps by amount and risk, delegates, deadlines, what the request must include, and what the record keeps.

Start the new workflow with one request type, such as software purchases or contractor invoices, rather than all of them. Watch where it still waits, adjust the rules, and only then bring the next type in. A workflow that people trust on one kind of request is much easier to extend than one everyone met on the same chaotic Monday.

That's the shape of most of our business process automation work: we learn the whole process before automating a step, and build a workflow with visible progress and explicit ownership. If your approvals already feel like a relay race, bring us last quarter's ten, and we'll run the pre-mortem with you.

Related work: Sutton|Place.