I agree, and I see this as a good thing. It’s akin to the tension one feels when asked “well, what does this positive change you’d like to see actually look like practically? How would you know it when it happens?”
The fact that this dependency chain exists means it puts some burden on us (or at least those of us who find value in this methodology) to address this as the primary bottleneck. And yet, ruminating on this very point has led me to reconsider whether this dependency chain is well-conceived.
If we were to start defining throughput and jumping into this set of tasks, we’d be implicitly affirming this tree’s validity, and all of those that led up to it. However, we don’t really have a way of testing the trees’ validity and updating them if we find flaws in them.
This was apparent from the very first meeting; @rufuspollock offered some revision suggestions, and Margaret also questioned some points. Now what? Since I’m the trees’ creator, should I get to decide whether or not to make those changes? Should Rufus decide? If these trees organize our R&D in the future they will be very consequential, so one or two points of failure wouldn’t be in line with what we profess to believe in.
This got be to thinking: perhaps the very first point in the dependency chain should be, decide on how these trees get updated.
So I made some changes to the Prerequisite Tree (redundantly I might add that I don’t anticipate making any more updates unilaterally!)
Decide how the trees get updated
** ↓**
Validate and revise the trees enough for provisional use
** ↓**
Define throughput
** ↓**
I will make more updates to the other affected trees and post within their threads.