This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Tuesday, May 13, 2003
In Defense of Planning -- "I don't want to get off on a rant here, but..." my initial idea for this post was a response and critique of a committee-written (that should have been a warning) piece entitled Death by Planning, as a great example of strawman setup, knockdown, and re-setup. The authors, in an approach that to some degree, echoes some of the agile/extreme/etc arguements that I've read. Under their provocative title, they start by describing a pair of approaches to project plans that any effective, experienced project manager would describe as non-recommended, bad practice, and then go on to lay out what they claim is a "refactored" approach to planning that that same group of experienced project managers would recognize as established, reasonably good practice. (I would quibble with their questionable use of percent complete to assess task progress, but I like their explicit use of contingency -- I would use buffers for this -- to deal with the inevitable uncertainty in such efforts.) My original intention was to simply call them (and others) on the possibility that their piece might be read by others as a defense of the premise that planning is of questionable use. It may have been minimally used, or erroneously used, or not really used in environments like software or other creative or discovery-based efforts, but that is no reason to throw the baby out with the bathwater. It's not a question of pitting bad practice against good practice, but rather it should be a question of why good practice is not common practice.
That aside, the real danger of such such writing that implies the abandonment of rational management practice is that some people will read the opening statements and deduct that planning and control are useless. Even some blog-friends of mine -- Joe and Hal come dangerously close to skating the same thin ice in pieces that support the notion that "10 minutes of doing is worth 10 hours of planning/discussing." and "substituting some fast learning on our projects for some brilliant planning," I trust that they know how to read the ice, because Hal included the qualifying word "some" in the latter statement and that Joe included a full citation that followed the 10 minute/10 hour statement with "Trying it in cardboard is better than trying to predict it in steel." I fear that too many people will miss the importance of Hal's "some" and fail to recognize that "trying it in cardboard" is merely an alternate means of predicting the steel version, and find themselves falling through the ice.
Planning can take many forms. Shewart included "P" in PDCA, Six Sigma starts with D for Design which is nothing but a model for the process. Goldratt emphasizes first understanding "What to Change" and "To What to Change To" before moving on to determining "How to Make the Change Happen," but still includes that last question as part of a manager's responsibilities. Promises -- project and otherwise -- require rational prediction in the form of models of expectations, if only to understand when and how deviation from the desired direction is encountered when that model bumps heads with reality. An effort that involves more than the simplest set of tasks is a system. It's a system of goals/objectives, deliverables/stories/outputs, resources performing work to that end, and most importantly, the interactions between the pieces of required work. The system is not in the details, but in the dynamics, not in the links but the linkages, not in the ink but in the white space, not in the components but in the interactions between its pieces. Management is an effort of prediction and re-prediction -- and effort to deliver against promises that is a matter of understanding a possible, plausible, and probable model of interactions so that we know when we're hit with the improbable, implausible, and -- yes -- the impossible.
In another recent piece Keith Ray points to that hoary old Standish "Chaos" Study and finds in it evidence that 85 percent of features in IT efforts aren't even used by the customer and points out that...
"If you knew which features the customers were really going to use, You could avoid wasting 85% of your budget, and you could ship 85% earlier than the average software project, getting revenue sooner. Sounds like a win-win for both customer and supplier."
Yes it does. But knowing which features to build and which not to build requires not less planning, but better planning -- rational planning with a focus on the necessary and the sufficient without getting hung up in the unnecessary. Such rational planning doesn't require customer/sponsor "involvement," but their "commitment" (a la the committed pig and the involved chicken in the old ham and eggs breakfast project) from the get-go -- their input, feedback, direction for the goals, objectives, and deliverables of the project, and back-and-forth conversations on possibilities, probabilities, uncertainties and uncomfortableness.
The first of those conversations, based on what Covey would refer to as "starting with the end in mind" is what we call a plan.
"...but that's just my opinion. I could be wrong."
(Nothing like half a bottle of Bonny Doon Vin Gris de Cigare to get the juices flowing...or to force me to go back to the piece six times to fix spelling errors and add missing clarity.)
posted by Frank - Permanent Link -