every piece was there and it still wouldn't work

==========
· #building #planning #process

I had a build plan for one of my systems that went through a real review before anyone started building from it. Twenty-two separate issues came up during that review, and every one of them got fixed. By the time the plan was done, every piece the system needed was named somewhere in the document.

It still would not have worked.

That went uncaught until someone traced the plan step by step, against a much simpler question than "did we find every issue." The real question was smaller and harder to answer: if I build exactly what this document says, in the order it says to build it, does a working thing exist at the end. I had been treating that question as the same as "does the plan mention everything it needs." Those are not the same question, and the difference between them cost real time.

a plan can be thorough and still not connect

The review itself was real work. Twenty-two issues got surfaced and closed before anyone was allowed to start building. That is not a rubber stamp. Reading the plan afterward, it looked complete. Every piece the finished system needed was mentioned somewhere in the document, usually more than once.

When someone finally traced the plan from the first step to the last one and asked whether a working system actually came out the other end, five things were missing. Two small supporting pieces that later steps depended on had no step that built them. The piece that was supposed to run the whole sequence, moving it from one stage to the next, was never built by any numbered step either. Neither were the checkpoints meant to catch problems as the process moved between stages, or the piece that starts the whole thing running, safety checks included.

Every one of those five things was named somewhere in the plan. None of them had a step that produced it.

naming a part and building a part are not the same act

A plan can reference something without ever assigning a step to build it. That sounds obvious once you say it plainly, but it is easy to miss when you are reading for completeness instead of reading for sequence. Completeness asks whether something is mentioned. Sequence asks whether executing the plan, in order, actually produces it. I was reading for completeness. I should have been reading for sequence, and I did not have a way to tell the difference until this happened.

the smallest version could not run either

The plan also claimed there was a smallest version you could build first, before committing to the whole thing, just to prove the design worked. That claim was wrong too. The smallest version it described still left out the piece that runs the sequence and the checkpoints that catch problems along the way, so it could not have actually run either. The plan's own smaller version had the identical gap as the full plan, and nobody caught that either, for the same reason. Every individual piece of that smaller version looked correct on its own.

what I trace differently now

A build plan that names every component it needs is not the same as a build plan that produces a working system. Those two things can look identical on paper, especially after a rigorous review has already closed out twenty-two other issues. The only way I have found to tell them apart is to trace the whole thing end to end, in the order it would actually run, and ask one question at every single step: does executing this leave me with something closer to a working system, or does it just leave me with something else the plan mentions somewhere.

If I cannot answer that for every step, I do not have a plan yet. I have a list of parts.