Nobody gets a second week. Whatever you learn in those five days becomes the evidence you'll be arguing from for the next six months, which means the shape of the week matters more than how hard anyone works during it. Prep is the whole game here, and prep is unglamorous. Here's what it looks like.

What a week can and cannot cover

A five day audit is not a survey of the business. It's a narrow, deliberate look at one slice of work, and the narrower you draw that slice, the better your odds of ending up with something specific enough to build. Teams that try to cover the whole company come back with observations. Teams that cover one process come back with a spec. Observations get filed somewhere polite. Specs get funded.

Pick the slice on Monday morning, before the first interview. Then defend it, because the scope will try to grow a little every day, usually with good intentions attached.

Draw the boundary around a handoff

The most useful unit of analysis isn't a department or a tool. It's a handoff. Where does work move from one person to another, and what has to be true before it's allowed to move? Delays hide in those gaps, and so does most of the rework nobody counts.

Put a number on doing nothing

Before you look at any fix, write down what the current state costs per month. Rough numbers are fine at this stage. A defensible range beats a precise figure you invented in the room to sound confident.

Name the person who signs off

Somebody has to own the outcome once the audit ends and everyone goes back to their normal job. If that person hasn't shown up by Wednesday, you can still finish the week, but nothing you find will actually get built.

The trap of the tidy process map

Process maps feel like progress. You interview people, you draw boxes, you connect the boxes with arrows, and by day three the picture looks organized enough to put in front of a director. However, a clean map usually means you documented the official version of the work rather than the real one.

The real version lives in the exceptions. Ask what happens when a request arrives late, or arrives wrong, or comes from someone who skipped the form entirely because they know a shortcut. In most teams the exceptions aren't rare at all. They're a third of the volume, they get handled by whoever has been there longest, and they're the reason the tidy map never predicts how long anything actually takes. Map those first. The happy path can wait.

Score it, then argue about the scores

Give every candidate two numbers. Hours saved per month, and how much damage a wrong output would cause. Multiply, sort the list, and then let the team argue about the ranking for an hour. That argument isn't a waste of time. It's where the assumptions nobody said out loud finally get said.

What Friday should look like

Not a report. A single page with three items on it, each one carrying an owner, a rough build estimate, and the specific number that will tell you whether it worked. If a candidate can't be squeezed into that format, it isn't ready, and pretending otherwise just moves the problem downstream.

One more thing, and it's the part teams skip almost every time. Write down what you decided against and why you decided it. In four months somebody will propose the same idea again with total confidence and no memory of this week. That one paragraph saves you from running the whole audit twice.