Learning Center / Directing an Outcome with Software

Course 3 · Lesson 2 of 5

Describing the work

A fleet of rental cars needs its vehicles serviced on time. Written down as *keep the fleet serviced*, nothing happens. Written down properly, the description is five short parts and it fits on a page.

Part one: the trigger

When does this start? A date, or an event, or a state.

When a vehicle's odometer reading passes 18,000 miles since its last service. That is a trigger that can be watched. When a car needs a service is not a trigger. It is a circular statement.

Part two: the source

Where does the information come from? Name the system, the file, the mailbox, the field, the person. Name it exactly.

The mileage comes from the daily check sheet photographed by the depot at handover. Naming the source does three useful things: it exposes when the source is unreliable, it makes the work possible at all, and it shows a person where to look when the result is wrong.

Part three: the rule

What is decided, and how? Write the rule as a rule, even when it seems obvious.

*If the mileage is within 500 miles of the interval, book the service at the nearest approved garage with availability inside five working days. If no garage has availability inside five working days, take the vehicle off hire and tell the depot manager.*

A vague rule produces a different decision each time the work is done, which makes the output impossible to trust. A written rule can be wrong, and being wrong in a written way is how it gets fixed.

Part four: the output

What exists at the end, and where does it go? *A booking reference in the fleet register, the garage named, the date, and the vehicle's status changed to "off hire" for the day.*

Name the record, not the activity. If the output is a document, say who receives it and in what format. If the output is an entry, say which field.

Part five: the exception

What is not covered, and what happens then? This is the part that is always left out and always needed.

*If the garage reports additional work costing more than four hundred pounds, the vehicle stays off hire and the fleet manager decides. Nothing is authorised above that figure without the manager.*

Examples beat principles

A written description is followed far better when it carries two or three real examples, taken from work that has already happened. Take the last three services and write down what was done, including one that went awkwardly.

*Last October, a van's odometer was misread as 41,000 instead of 14,000 and it was nearly booked early. The correction is that the check sheet figure is compared against the previous reading before booking.* One real example of a real mistake teaches the rule better than a paragraph of instruction.

Exceptions are the whole job

Any description of recurring work that has no exception path will be followed until it meets its first surprise, and then it will either stop silently or do something unexpected. Write the exceptions down before the work starts:

• What if the source is missing.
• What if the rule produces an answer that looks wrong.
• What if the deadline cannot be met.
• What if two rules conflict.

Each of those needs an answer that ends in a named person, not in a shrug.

A description a stranger could follow

The test is not whether the person who wrote it understands it. The test is whether a competent person with no history of the work could follow it and produce the right result, and know when to stop and ask.

That standard sounds strict, and it is the same standard used for the instructions given to a new member of staff. It is worth applying both ways. A description good enough for machinery is usually good enough to train a person, and it is the reason writing things down improves a business even when nothing is ever automated.