Interesting one-hour video from Mary Poppendieck on The Tyranny of "The Plan" from a conference presentation. It's full of good anecdotes and a couple of great examples of how planning could really work, instead of they way it usually (doesn't) work today. I have been talking to some colleagues about improving how we do CCPM, and I think there are some relevant ideas here.
Poppendieck makes an interesting claim that the availability of computers has driven many organizations far off the deep end of creating far too much detail in their planning systems. Just because you can write it down doesn't mean it should. MRP systems that are so fragile that any hiccup throws them into disarray and replanning must be done. Project management systems where there are thousands of interacting tasks, and any one delay cascades through the entire network, necessitating replanning. Replanning here means changing the order and sequence of hundreds of activities. Not exactly easy to do.
What to do instead? Focus on flow.
Maybe the simple pull-based Kanban systems aren't such a bad idea. (When she was a manager at a plant that implemented Kanban, they went from shipping about 65% to plan at best to over 95%.) What is the primary focus of these systems: pull and flow.
Then she asks the question of how people did big projects before there were computers - such as construction of the Empire State Building, where the physical structure was complete in 18 months. And she shows examples of their planning mechanism: another flow-based system that ensured the work was flowing to the building and to each floor at a reasonable pace.
Key points
- Schedule by starting with the constraints, and THEN create a design that fits into those constraints. Don't design something and then squeeze it into the constraints.
- Decoupling the workflows, so that delays don't build up: steel, cement, metal and window work, limestone exterior were all largely decoupled activities. Even with the steel, they alternated steel mills every few floors, so that any delay at a still mill could be mitigated by the switch. Even today, large building construction follows this kind of flow (though not nearly as fast).
- Focus on the workflow, rather than the detailed interdependencies. Workflow should be thought of as the flow that moves consistently through the project. The schedule is too fragile, too deterministic.
So why do we build schedules? (And why are we so inclined to build these detailed plans that don't work?) First, we are trying to control when things will happen, but it absolute determinism is essentially impossible when dealing with any variability. The larger the system, the more fragile the plans become. (And it isn't possible to remove common cause variation.)
Second, they are used to predict when things will happen. But schedules built from work breakdowns are built on guesses, so we cannot use this information to predict events. Even when we have good experience and standard work, we can't be certain. Thus, we can't get exact predicionts - it's the system that we are working in, not the work. "When reality doesn't match the schedule, the schedule must have been wrong." (Not "someone must have screwed up".) Use this as a learning opportunity, instead of a punishment opportunity. This is the only way to learn and improve the system: learning from the situation where the system performs differently from the expected result
PERT charts came up as part of the Polaris Submarine program in the 1950's. It was a mechanism to keep the funders (US Congress) happy. But no one in the project organization actually used the charts: requirements changed frequently, suppliers thought it was useless, ... It was just promoted so heavily that it became a standard way to describe projects and even got baked into PM standards.
I heard Mary Poppendieck at the 2012 Lean Software & Systems Conference, but I didn't write it up at the time. I think I might have had content overload by that point.