Break a transformation into workstreams and it becomes legible. Each gets a lead, a plan, a color. The chart is satisfying to look at and easy to report. It is also slightly misleading, because the value of the program rarely lives inside any single stream. It lives in the seams between them, which appear on no one's plan.
Streams are the easy decomposition
Splitting work into streams is good management; it is how large work becomes ownable at all. But a stream optimizing for itself will quietly export its problems to its neighbors, hitting its own dates by handing a mess downstream. Every stream can be locally green while the program is amber, and the maddening part is that no single owner is wrong. The failure sits in the spaces nobody was assigned.
The risk in a transformation is rarely inside a workstream. It is in the handoff between two of them, which belongs to neither and is owned by nobody.
The seams need an owner
Someone has to own the dependencies themselves: the shared data, the sequencing, the decision that stream four cannot make until stream two finishes. This is the actual job of the center, and it is not collecting status. It is owning what falls between: forcing the cross-cutting decisions, resequencing when a stream slips, and refusing to let a clean local report disguise a broken seam.
Manage the graph, not the list
A list of streams invites you to manage them in parallel, as if they were independent. A dependency graph forces you to manage them in order, because it shows what is waiting on what. The same set of streams, read as a list, looks like nine healthy efforts. Read as a graph, it shows the one edge holding up the other eight.
Stop reading the program as a list of streams that are each fine. Read it as a graph, and go straight to the edges no one has signed for.