Draw a process map that people actually use
Most process maps get drawn once and never opened again. Here's how to build one your team keeps going back to.
Guides
Short, specific, and written for the moment you're stuck. Videos are hosted on YouTube.
Reading a control chart in five minutes
What the lines mean, which signals matter, and the three patterns worth acting on.
Writing a problem statement worth solving
Get this wrong and the whole project drifts. A short method for pinning down what you're actually fixing.
Where to start
If you're new to structured improvement work, the honest answer is that most of the value comes from the first two steps, not the clever statistics later on. Define the problem properly and measure it honestly, and the rest tends to follow.
A good problem statement says what is happening, where, how often, and what it costs — and says nothing at all about the cause or the solution. That last part is the hard bit. The moment a statement contains a fix, everyone stops looking, and you end up solving the first idea rather than the real problem.
The same discipline applies to measurement. Before changing anything, get a baseline you'd be willing to defend in front of a sceptical finance director. It doesn't need to be elaborate; it needs to be honest and repeatable.
This library is being written. The three guides above are the first ones
planned. If there's a tool or technique you'd find useful, tell me and I'll bump it up the
list — get in touch.