[HN Gopher] The Tyranny of "The Plan"
___________________________________________________________________
The Tyranny of "The Plan"
Author : kiyanwang
Score : 17 points
Date : 2023-02-24 16:16 UTC (1 days ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| shoo wrote:
| here's a rough summary:
|
| 1. Mary recounts her experience of working with computerised MRP
| planning systems. These detailed plans were fragile and would
| need to be thrown out once reality began to diverge from the
| plan, then re-planned. Contrast with a pull-based approach
| (Toyota etc)
|
| 2. What did they do before computers? Anecdote/case-study of how
| the Empire state building was designed and delivered on schedule
| and under budget. Summary of success factors: teamwork of
| owner+architect+builder. deeply experienced builders - fixed
| price contract! focus on key constraint of material flow.
| Decoupling of workflow "pacemakers" - the building was designed
| to allow parallel construction of components - windows could be
| fitted in parallel to floors, once the steel frame was built.
| Cash flow thinking. Schedule was not based on design of building,
| the design of building and the workflow to construct it was based
| on the schedule and other constraints.
|
| 3. Sketch of how "pull scheduling" could work for a software
| product. Delivery broken into sequence of 2-3 month increments.
| Don't make all the decisions up front. At the end of each
| increment, decide what will be worked on in the next increment.
| Time-box not scope box. E.g. decision point after first two
| months to review customer interest and decide technical approach.
| Mary emphasised need to really understand customer problem,
| intention, technical approach, and have everyone in the project
| talking the same way ("if you don't figure this out, if you don't
| pass this test, you stop and fix it, and you don't go on with the
| rest of the schedule"). Then 3 months of working on proof of
| concept, then review proof of concept and decide alpha features,
| etc. Baseline features for production release not decided until
| after reviewing results of beta.
|
| 4. Discussion of reliable workflows. Inputs from suppliers,
| outputs to customers. Rapid feedback if inputs or outputs are not
| fit for purpose. Identify and fix root causes of problems.
|
| 5. "Where do plans come from?". Anecdote/case-study of the US
| Polaris missile system. Complex, highly political project,
| unconstrained budget. Use of PERT [1] to manage project
| publicised by program director: "a facade to keep Congress happy"
| - but PERT not actually used to manage the project in early years
| - constant requirement and scope change, PERT bypassed by
| technical officers and contractors. Summary of success factors:
| quality of leadership - one technical director had control over
| performance requirements and signed off on all major decisions
| for first 8 years, focus on development, decentralised
| competitive organisation (three different contractors developed
| competing designs for each major subsystem, then a winner was
| selected. each contractor had technical freedom to propose
| whatever they thought best), emphasis on reliability, espirit de
| corps.
|
| [1]
| https://en.wikipedia.org/wiki/Program_evaluation_and_review_...
| kneebonian wrote:
| > Mary recounts her experience of working with computerised MRP
| planning systems. These detailed plans were fragile and would
| need to be thrown out once reality began to diverge from the
| plan,
|
| So I've been studying a lot about WW1 recently and one of the
| things that struck me was the incredible similarity between how
| many of these generals operated in the early years of the war.
| With detailed down to the minute plans that would account for
| everything, trying to be more and more precise, and how the
| bigwigs on a software project operate, with a belief that if
| they can just nail things down more tight and make sure they've
| got every dependency mapped out they'll finally make it work
| and it will avoid other problems.
|
| The results are the same as the WW1 battles the first part goes
| well, things seem to flow along as predicted everything is
| great in the first day, but as things go on reality diverges
| more and more from the plan and the more people insist on the
| plan the worst things get because they haven't been able to
| adapt to the real world.
|
| My point is the tighter and tighter your plans are and the more
| comprehensive they are and the more autonomy they take from
| individuals on the ground doing the actual work, the more
| likely it is to go poorly and the more catastrophic it will get
| the longer you push on.
| jt2190 wrote:
| Mary Poppendieck (2009) Video
___________________________________________________________________
(page generated 2023-02-25 23:01 UTC)