Margin's Dropping and You Don't Have Six Months to Find Out Why

Run a six-week sprint that diagnoses the root cause end-to-end and tests a fix directly in the operation, with a go/no-go checkpoint at week two so a wrong direction gets caught early rather than discovered at the end of a six-week commitment. The speed comes from working in the actual operation rather than in a separate project structure that has to report findings back before anything can change.

Start with end-to-end process analysis and interviews with the people doing the work, they almost always know where it breaks, even when nobody has formally asked them. Margin erosion is rarely a mystery to the people closest to the process; it's usually a mystery to management specifically because the information never travels up through the reporting layers that would otherwise surface it.

Trace the process stage by stage, paying particular attention to the handovers between departments, where ownership usually disappears and nobody is quite responsible for what happens in the gap. Most performance problems that look complex from a distance turn out to concentrate at one or two specific handover points once the process is actually mapped step by step rather than reviewed department by department in isolation.

A time-boxed diagnose-solve-execute-embed cycle, with a two-week go/no-go checkpoint and a defined solution or business case at the end, structured so the team knows within the first fortnight whether the chosen direction is working. The four phases run in sequence but stay tightly time-boxed throughout, which is what keeps the sprint from quietly expanding into the kind of months-long engagement it was specifically designed to avoid.

Standardisable processes and broken handovers can be fully fixed; problems in system architecture or org design typically yield a solid plan and business case instead of a finished fix, since those changes usually require investment and timelines beyond what a six-week window can responsibly deliver. Knowing which category a problem falls into before starting is what lets the sprint promise a specific, honest outcome rather than an open-ended one.

Scope the problem to what a six-week sprint can realistically deliver, and say upfront which of the two outcomes applies, a working fix or a fully costed business case, rather than letting the engagement's scope creep toward a longer, more open-ended project once it's underway. Most operational problems don't actually need six months of analysis to understand; they need six weeks of focused, in-operation work.

Map the process end-to-end across departments, the handover point usually reveals the real issue, not either department individually, since each department's account of the problem is typically accurate for its own piece of the process while missing what happens in the gap between them. Neither department is wrong; they're both just describing the part of the elephant they can actually see.

Yes, solve the urgent operational problem first with a sprint; strategy work only helps once there's room to look beyond this quarter, and a leadership team fighting an active operational fire rarely has the bandwidth to engage meaningfully with longer-term strategic questions anyway. Sequencing the sprint before the strategy work also tends to surface operational realities that should genuinely inform the strategy that follows.

Fix the process bottleneck and handover failures first, often the actual constraint, not headcount, since many productivity problems that look like a staffing shortage are really a process working against the people trying to execute it. Adding headcount to a broken process usually just produces more output moving through the same bottleneck, without actually resolving the underlying constraint.

Walk the full chain step by step, including every handover, rather than reviewing departments in isolation, since the bottleneck is disproportionately likely to sit at exactly the point where responsibility passes from one team to another. A department-by-department review tends to find each department performing reasonably well on its own terms, which is precisely why it usually misses the actual constraint.

For problems too structural for six weeks, the sprint itself produces the fully worked business case as its deliverable, complete with effort, resources, risk, and a defined start date, rather than leaving that work for someone else to do afterward with less first-hand knowledge of the problem. This means the six weeks still produce something immediately usable, even when the underlying fix itself takes longer to implement.

End with an embedding plan naming an owner, a measurement method, and a response if performance slips back, since an improvement that only holds while external attention is on it isn't really an improvement, it's a temporary state. The embedding plan is what turns a six-week fix into a lasting change rather than a result that quietly reverts a few months after everyone's attention has moved on.

Short, intensive sessions testing solution directions immediately for feasibility, with small-scale experiments before full rollout, rather than a lengthy analysis phase followed by a single large rollout with no chance to course-correct. Testing directions in small scale first means a flawed approach gets caught while it's still cheap to change, instead of after it's already been rolled out across the whole operation.

Diagnose the actual root cause first, symptom-chasing across multiple fires usually traces back to one or two real causes, which means the long list of things that feel broken often has a much shorter list of actual problems behind it. Fixing the root cause tends to resolve several apparently separate symptoms at once, which is a far better use of limited capacity than treating each symptom as its own independent problem.

Define the measurement method as part of the embedding plan at the end of the sprint, tied to the original problem statement, so success is judged against the specific thing that was broken rather than against a general sense of things feeling better. A measurement method decided upfront, before the fix is implemented, also removes the temptation to retroactively pick whichever metric happens to look most favourable afterward.