5 ms·
> 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
by kneebonian 4y ago
> 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.
- AlbertCory 4y agoMaybe that's why General Eisenhower said, "Plans are worthless, but planning is essential."
- ahartmetz 4y agoThe second part doesn't really follow from anything mentioned here AFAICT, but I believe the idea is that making a plan forces you to think about many large and small issues. When things don't go to plan, or you don't have a plan, all that knowledge will help you make decisions on the spot (if necessary).
- AlbertCory 4y agoI believe that's right. D-Day certainly didn't go all according to plan, but without a plan to start with it wouldn't have happened at all.
- Jtsummers 4y agoAn important part of planning, especially in the military context, is that you don't, or shouldn't, make a singular plan. You make a collection of plans and contingencies. You practice them with various levels of simulations from tabletop wargaming (these days computer simulations) to large scale exercises. Then while you're in the simulation you throw in constraints, problems, etc. to force the plan to fail and the people to react (bad exercises, and these do happen, are set up with a target outcome so one side can't "lose", which isn't supposed to be the point of the exercise). So the planning ends up being one of the more useful things to do because it prepares you for both your intentions but also to handle things when they fail (in some fashion). The plans, themselves, are useless because they will very rarely be carried through as written. You can't just read a plan and memorize it and expect to carry it out in an adversarial situation. If you're lucky, or your adversary is severely outmatched, then this can work. However, you can't count on luck and you can't count on your adversary being unprepared or incapable or incompetent. Planning, contrasted to plans, prepares you (or should) for when the plans fail and you have to adapt and overcome in the field.
- AlbertCory 4y agoI've heard what the military likes to say about battle plans is: The enemy gets a vote
- at_a_remove 4y agoOne of my favorite lines from The Way of the Gun was "I think a plan is a list of things that don't happen."
- ithkuil 4y agoA related quip: "writing is nature's way of letting you know how sloppy your thinking is". This generalizes beyond what's strictly though of as a "plan" (but if you squint enough may have some plan-like elements to it). There are many forms of documents that we engineers produce and they serve different purposes at different times. And some of their uses may not be very effective in most cases, leading to wasting too much time in over-specifying a system that has not yet been built. Yet, writing design documents / specs may be still useful despite the output not being useful. It's the act of writing it that yields most value.
- AlbertCory 4y agoyou just explained exactly what Eisenhower was saying, but in many more words.
- ithkuil 4y agoIf I had more time I would have written a shorter comment. I thought I added a nuance to what Eisenhower's said (or at least to how I noticed people interpret it) but apparently I did a poor job and adding more words would just make it worse.
- AlbertCory 4y agoYou explained an aphorism, which is fine, but you added the gratuitous "sloppy thinking" which is not. An aphorism by definition doesn't contain all the nuances. If we looked through Eisenhower's whole life, which is pretty well documented, I'm sure we could find lengthy explanations of his approach to war.
- ithkuil 4y agoActually I replied with another aphorism (attributed to Dick Guindon and later expanded by Leslie Lamport as "Mathematics is nature's way to tell you how sloppy your writing is") What I try to add here is the fact that other forms of technical writing can be seen as forms of planning and thus there is a connection between the two aphorisms
- Ozzie_osman 4y agoThis is why many militaries (including the US) now advocate Mission Command [1] for execution. "Subordinates, understanding the commander's intentions, their own missions, and the context of those missions, are told what effect they are to achieve and the reason that it needs to be achieved. Subordinates then decide within their delegated freedom of action how best to achieve their missions." In this world, there is no way to have a tyrannical plan. [1] https://en.wikipedia.org/wiki/Mission_command https://en.wikipedia.org/wiki/Mission_command
- wayeq 4y agoso basically OKRs?
- Ozzie_osman 4y agoMaybe. Depends how you do OKRs. OKRs are a process or mechanism. Mission command is a philosophy. The two dimensions you want to think about are "how much detail is top-down" and "how much detail is up-front", and depending on how you implement OKRs, you can turn the dial in any direction.