I'm not really understanding the distinction between a "plan" and a "workflow". It sounds like they had a plan but we are bending over backwards in TFA to call it something else because a plan is bad in some agile circles.
in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).
this is the stuff you learn in operations class in business school (or some engineering programs), as did chris (the author of the article/blog), who went to ucla anderson.
whether it's waterfall or agile shouldn't really matter. in agile, there is planning, but often it's workflow based (tracking flow via story points, or what not).
I think the story of the submarine/Polaris missile was more interesting. They produced the plan and basically ignored it, and the PERT planning exercise has subsequently been cargo-culted for years.
> in contrast, "workflow" is akin to kanban in this context. you start with constraints (in this case time and money) and then design the system to those constraints. mary, the speaker, mentions that they had 4 different, decoupled workflows, which helped them avoid those pesky cascading delays. workflows are process oriented (repeatable events), so steel construction, for example, was thought of as an separate repeatable (if varying) process (swimlanes, in kanban parlance) as they went up in height. kanban also focuses on realtime learning and adjustments as well as just-in-time inventory systems (important to steel being delivered on time, like using 2 different suppliers to make sure there were no delays).
That sounds like a plan to me...
If one defines plan to mean "We schedule everything up front and then stick our fingers in our ears and say 'la la la la' when reality conflicts with our imagined schedule" then of course plans are bad. Similarly if one were to define agile as "a system that is incapable of delivering any feature that takes more than 2-4 weeks to develop" then agile would be bad too.
The plan is a procedural instruction list. It lacks consistency. It is whatever procedural set of things happened to have been written down. You wouldn't plan to reuse it like you would with the function because it only applies to that specific issue