Entry 0177·October 20, 2026·Scheduling·Throughput, Variability & Constraints

Rank the Opportunity List by Predecessor, Not Size

I sat in on a two week diagnostic readout last week.
Truth · observed pattern

The question the sponsor asked

I sat in on a two week diagnostic readout last week. The work was good. The team had been through the plant and the back office, pulled three years of production records out of the ERP, and come back with a sized list of opportunities sorted into buckets: production efficiencies, plant labor, warehouse, procurement. Each bucket had a number on it. The deck moved through them in order of size.

The sponsor let the summary slide finish and then asked the only question that mattered. Are you going to explain the interdependencies here, because these are all good, but is this the order in which we would assume the next steps?

He was not challenging the numbers. He was pointing out that the document in front of him had no sequence in it. It had a ranking, and a ranking is not a sequence.

The answer confirmed it. Some of the work could run on its own: the procurement workstream could proceed without touching anything else, and so could the labor and product flow study. The largest bucket could not. It was waiting on plant leadership roles that were still being defined, and on a production plan that the commercial side had not yet locked. Neither of those was an opportunity. Neither had a line on the chart.

Size is measured, dependency is not

This is a structural outcome, not an oversight by a particular team.

A diagnostic is paid to find and size value, so value is what it instruments. Interviews, observations and data extracts all point at one question: how much is here. Nobody is assigned to record what each item requires before it can begin, so that attribute is never collected. The deck then inherits the only ordering its data supports, which is magnitude, and magnitude gets read as priority because it is the only ranking on the page.

Predecessors come in two kinds, and the plan handles them very differently.

The first kind is another project. Those are visible. They have owners, durations and a place on a schedule, and a competent planner will catch them.

The second kind is a condition: a role that is not filled, a production plan that is not locked, a cost basis nobody has agreed, a specification criterion that is still open. These do not look like work. They have no duration, no deliverable and no owner, so they do not get a line on the plan. They are also the predecessors that bind, because almost every large improvement item depends on at least one of them.

The failure mode follows directly. An item blocked by a condition still looks fundable. It has a number, a bucket and usually a willing owner, so it gets staffed. Then it does not move, and the reason it does not move is invisible, because a task waiting on an unmade decision generates no signal. Downtime shows up in a downtime report. Scrap shows up in yield. A dependent task waiting on an internal input shows up as the same status it had last week.

I have the counter-case in my own records, and it is not from a readout deck. On a packaging engagement, two tasks were flagged blocked by our own tracking on four consecutive weekly reviews each. One was a structural concept task waiting on confirmation of packout and packaging criteria for three table formats. The other was an input resolution task waiting on an implementation and savings tracking step. About three weeks each, no supplier in the loop on either, no external constraint anywhere in the chain. Both predecessors were internal decisions that had not been made, and in both cases the dependent task was the thing with a name and an owner while the predecessor was not.

That is the same pattern in a smaller frame. The work that gets a line on the plan is the work that was sized. The thing holding it up was never sized, so it was never scheduled, so nobody was late on it.

Separate the independent items and start them

Three moves, in order, and all of them are cheap relative to the plan they protect.

Write the predecessor sentence. For every item on the list, write one sentence naming what has to be true before work can start. Accept the word none, and expect to use it more than you think. The exercise takes an afternoon for a twenty item list, and the sentences that come back vague are the finding. If the author of an item cannot say what it needs first, nobody has thought about starting it yet.

Partition the list and start the independent group now. Items with no predecessor run immediately, in parallel, regardless of their rank on the value chart. This is the move that gets argued with, because starting a smaller item ahead of a larger one reads as poor prioritization. It is the opposite. The independent items are the only ones whose start date you control today. A larger item whose predecessor has no date has no start date either, so holding capacity for it is holding capacity against nothing.

Promote each binding predecessor onto the plan as its own line, with an owner and a date. A role that must be filled becomes a line item with a hiring date, and that date is the real start date of every item behind it. Say that out loud when you publish the plan, because the alternative is a plan that shows those items starting next month and quietly slipping every month after. A production plan that must be locked becomes a line item owned on the commercial side, not the operations side, and its date is a commitment from the person who can actually hold it.

Then hold the states apart in your reporting. Identified, sequenced, started, implemented and verified are five different conditions, and an item whose predecessor has no date is at best identified. Counting it as in the plan is the error that makes a plan read ahead of the work. It is also the error that makes the first reconciliation painful, because the gap between the sized list and what moved gets attributed to execution when it was created at sequencing.

One caution on scope. This is not a case for modeling every dependency. Most items genuinely have no predecessor, and a full network diagram for a twenty item list costs more than it returns. The whole value is in the three or four items whose predecessor is a condition rather than a project, because those are the ones that otherwise absorb the plan's first quarter and show nothing for it.

What a well-sequenced plan reads like

Every item carries a predecessor field that is either filled or says none, and every filled one names a person and a date. The independent items are grouped and already running. Each binding condition appears as its own line with an owner who can close it, and the items behind it show a start date derived from that owner's date rather than from the current month. The status report separates items that have not started from items that have started and stalled, and anyone can say in one sentence what the plan is waiting on. When someone asks for the order of the next steps, the answer comes from the document rather than from the room.

Ask for the predecessor before you ask for the number

The next time a sized opportunity list lands on your desk, do not start with the totals. Take the three largest items and ask the author what has to be true before each one can begin. If the answer to any of them is a role, a lock or an agreement rather than a task, you have just found the real first item on the plan, and it is not on the list.

Published October 20, 2026
Related reading in Throughput, Variability & Constraints