The Plan Was Fine. The Project Slipped Anyway.

You had a plan. Tasks were assigned. Status went out every week. And the project slipped anyway. Or it came back from review needing another pass. Or the decision that was supposed to unblock everyone got reopened for the third time. None of that shows up as a planning failure. The plan was reasonable. Something underneath it kept generating the same loss, on schedule, no matter how carefully the plan itself got updated.

Most of what a project manager has access to tells you that you're behind: burndown charts, RAG status, a dashboard someone built in a program review. None of it tells you why you keep ending up behind in the same way, on the same kind of thing. That's a different question, and working harder on the plan doesn't answer it. Finding the operating condition creating the loss does. Is work stalling on a decision that won't stay made? Is nobody clearly on the hook when something falls between two people? Is the work breaking every time it crosses from one function to the next? There are ten conditions like this. Most projects are dominated by one, maybe two, not all ten at once. The work is naming the right one instead of guessing and re-planning around a guess.

This is a six-page instrument for doing exactly that, on one project, in about half an hour. It isn't a framework you adopt or a process you roll out to a team. It's a single pass: define the Result this project was actually supposed to produce, name the one avoidable loss you can point to right now, work through the ten conditions to find the one actually creating it, gather three pieces of evidence that back that finding up, and commit to one bounded move you'll make in the next 14 days. Then you set a date to check whether it worked.