The guys at 37 Signals were almost on to a good thing with this post about Planning as Guessing. Sure plans are guesses. Sure they are just a hopeful take on what we think might happen. Nobody that is good at what they do has ever questioned the transient, unsteady nature of plans (and yes, to be perfectly clear, by this I am implying saying out-right that those that think that their plans are cast in stone and not to be wavered from are bad at what they do.) But what their post gets wrong is that by dismissing plans and planning as a waste of time and diminishing the importance of planning they encourage the very thing that we need WAY LESS of in the world of, well the world of EVERYTING: a lack of planning. They seem to think there is too much planning. Well Im going to go the other way and say that there is nowhere near enough (good) planning. Maybe the problem is that it is assumed that the only outcome of planning is a plan. That is often the tangible product that one can hold in their hand or email to the team but it is not the only output of planning. The process of building that plan (the one that SHOULD be assumed will not last through the first week or so of the project) makes us smarter about what we are doing. It makes us think about what might go wrong. It makes us walk through different scenarios and different possibilities. Creating that solid plan that we know will get at least heavily modified if not out-right replaced is the very thing that equips us to make those heavy modifications or to come up with the replacement plan. Without the planning, if we dismiss planning as just the creation of guesses, we leave ourselves exposed to the four winds like so many backpackers huddled around the campfire at basecamp.(Sorry, just kidding. I could not resist. LOL. 37Signals makes some cool stuff for sure. I mean them and their products no disrespect.) But seriously, the planning process is not about coming up with the be-all, end-all, rock-solid path through the project. It is about preparing yourself and your team for what might happen. It is about thinking through what could go wrong, figuring out what will likely go wrong and figuring out what you will do when it DOES go wrong. My fear when I read posts like the one at 37Signals is that they seem to minimize the importance of planning (and even, if just a little and very subtly, ridicule those that think planning is important.) If this leads to even one team doing less than the appropriate amount of planning because a plan is “just a guess” then it has done a disservice.
What they also missed was that in the high ceromony, largests budgets and high risk project (programs actually) busines on the planet - the US DoD - probabilistic schedule and cost analysis is mandated through DID 81650. You can find this document on google.
No one is allowed to speak about duration or cocst without a measure of variance and many times the probability distributions of these variances.
This appears to be one of those posts by people who "don't get out much."
I would not go so far as to say that they dont get out much. The guys over there are pretty sharp. Though their market tends not to be large aero or DOD stuff. Their tools are not aimed at the kind of projects you are doing for sure.
But to their point just because something is mandated does not mean it is inherently adding value. I just did a post for www.pmblvd.com (yet to be posted I think) that talks about this idea directly. Lots of methodologies demand certain deliverables that may or may not actually get used or add any value in and of themselves. There are those places that put SO much into the planning that they become 'married to' the plan. I dismiss these poeple in my post above as those that are just bad at planning but in hindsight that is not a complete enough portrayal of the dynamic at play. These managers or teams can mistake the time and effort put into the 'plan' that they start to mistake it for reality.
Good post Brian. People often insist that there is a "right" amount of process and modeling, and I agree, but the definition of "right" varies with project size, scope, type, culture etc.
Totally off topic now: Sometimes I wish you would hit the carriage return key a couple of times,