Short pieces on the operational problems we keep encountering. Written for the person who has to fix them, not for a procurement process.
Almost always one of three reasons: they were written by someone who never did the task, they are longer than the task takes, or nobody validated them with a first-time reader. All three are fixable in an afternoon.
If you cannot say how many delivery exceptions happened last month, you cannot prioritise fixing them. A one-page template and a weekly fifteen-minute review is usually enough to start.
A tool documents the process you configure into it, which is rarely the process you actually run. Map first, then buy — the mapping exercise often removes the need for the purchase.
Before adding headcount, measure where hours actually go for two weeks. In our last four operational reviews, the average recoverable capacity was just over one full-time equivalent.
Most teams can survive losing a person. What they cannot survive is losing the informal handover that person performed between two other roles without anyone noticing it was happening.
Every failed improvement programme we have inherited had five workstreams and no completed output. One finished deliverable creates the appetite for the second; a stalled programme destroys it.
The problem is spreadsheets with no owner and no documented logic. A well-labelled sheet with a named maintainer outperforms a half-configured system nobody logs into.
Orders per hour looks useful until you notice it rewards picking easy orders first. Measure the tail — the slowest ten per cent — if you want to know how peak will actually go.
Status meetings that run over their slot are usually compensating for a system that does not share state. Fix the data flow and the meeting shrinks on its own.
We send one short note a month, occasionally less. No newsletter funnels, no sequences.