Lesson 5.25.2 Brief the outcome, not the steps

In everyday life. You give a taxi driver turn-by-turn directions and miss the closed road the driver knew about.

An outcome describes what exists when the work is done. Someone else should be able to tell from it whether the work is finished. "Get the payment run ready" fails that test. This passes it: "Mark every open invoice pay, pay after approval, hold or not due, with a reason. Pay covers invoices due on or before October 30." Anyone can check the result: does every invoice have a mark and a reason? End the outcome with that test, in one sentence that starts "Done when": "Done when every open invoice has a decision and a policy section." It tells the worker when it has finished, and it gives you the first check for the result. A check like this takes one of two forms. It can be a yes or no, as this one is. Or it can be a number to match: "Done when the CSV has as many rows as there are open invoices" (5.7). "Done when it looks good" is neither. The worker cannot tell when to stop, and you have nothing to check. Ask for a result you can review before anything is approved. The proposal comes back first, and Dave's approval is the last step, not a question halfway through.

Steps describe the method, how to do the job. They feel safer. But the result can only be as good as your steps, and a worker that follows orders rarely questions them. Maria's step 2 used the wrong payment terms, and the worker carried out the error instead of noticing that the vendor record disagreed. An outcome lets the worker choose the method, and lets you compare the result with what you asked for.¹

Some steps still belong in a brief. Write a step when it is a control. A control is a step required by policy, by law or by a system that uses the result. "Take payment terms from the vendor record, never from the invoice" is a control, because Brightline's AP policy says the vendor record is the authority on terms. It is a rule about which source to trust, so it goes in the context. "Do not change the invoice list" is a control too. It limits what the worker may do, so it goes in the constraints (5.1). "Sort by vendor" is only a preference. If it matters to you, put it in the format. If not, leave it out.

The test is one question: would a capable new colleague be wrong to do this another way? If yes, write the step. If no, leave the method open. A new colleague who took the terms from the invoice, or edited the invoice list, would be wrong. So those steps go in. One who sorted by invoice number instead of vendor would not be wrong. So that step stays out.

Figure 5.1. Between too little and too much. The Four-Part Brief describes the result and names only the steps that are controls.