Audit before you build

Every engagement we run starts the same way: we spend time with the people doing the work before we touch any tools. We call it the audit. Most clients are impatient for it to be over.

It never should be. The audit is the work.

What an audit actually is

An operations audit is not a requirements document. It's not a survey. It's a structured process of watching, asking, and documenting what's actually happening, as opposed to what people think is happening, or what the process diagram says should be happening.

These are almost always different things.

What we're looking for

• Where does the process actually start, as opposed to officially start?
• What decisions happen that aren't in any documentation?
• Where does the manual effort accumulate?
• What would break if one person left the team?

What good audits produce

A good audit produces clarity about what's worth fixing. Not everything that's manual should be automated. Some processes are manual for good reasons. The audit tells you which is which.

"The audit is the work."

The build that follows an audit is almost always smaller and more targeted than what teams originally imagine. That's not a failure. That's the audit working.