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

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_technique https://en.wikipedia.org/wiki/Program_evaluation_and_review_...