5.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?

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 policy section 2 says so. "Do not change the invoice list" is a control. "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.