When it goes wrong
A twenty minute task that produced the wrong deck is the normal case, not the failure case. What you do next decides whether it happens again.
Read the run before you rewrite anything. The plan it made, the steps it took and the files it produced together tell you which of the five things in lesson 4 was missing. Almost every bad result traces back to one of them.
Four failures, and where they come from
| What you got | What was missing |
|---|---|
| It used the wrong files | Input. The folder was named loosely, or it found an older copy |
| The numbers are right, the document is useless | Audience. It did not know who reads this |
| It quietly dropped rows | Edge cases. The mess was not described, so it decided |
| It invented a figure | The stop-and-ask sentence was not there |
Notice what is not on that list: the model being bad at the job. It happens, but it is far down the list of causes, and rewriting the brief is cheaper than assuming it.
Fix the brief, not the output
The temptation after a bad run is to ask for corrections in the same session until the result is right. That works once and teaches you nothing. The result you want is a brief that would have produced the right thing the first time, because next month you are going to run it again.
Not: "no, put revenue in thousands"
But, in the brief: "Revenue in thousands, rounded to one decimal,
with the unit stated in the column header."When the answer is a smaller task
If two rewrites have not fixed it, the job is probably two jobs. Split it: clean the data and check the result, then produce the summary from the cleaned file. Each half is easier to describe and much easier to verify.
- Find a run of yours that went wrong and name which of the five it was missing.
- Rewrite the brief so that failure is impossible, then run it on the same folder.
Little by little, you're building something great.