Planning and Process
All projects requires some planning and process. The purpose of both is to mitigate risk — as they say, ‘a failure to plan is to plan for failure’. The problem is when people start hiding behind planning and process as a way to mitigate personal risk.
Recently I’ve been seeing a lot of situations where people are propping up planning and process as giant pillars from which to hide behind. In terms of process, this may come as someone who requires every action they take to be signed off on by another person who they can hold responsible if it was the incorrect, or by creating a process so rigid that you spend vastly more effort upholding the process than what was designed to protect against. The extreme example of planning gone wrong is the person who only plans and never does anything— and is thus never wrong. Too often has never being wrong been mistaken for always being right. In the case of perpetual planning you’re both never wrong and never right, you’re just useless.
Planning by its nature is speculative, and the more you do without a reality check (i.e. actually DOING something) the further from reality you become. Even worse, as you are planning rather than doing, reality is constantly changing. Actually doing something has a very convenient feature with which you can validate what you’re doing — either it works or it doesn’t. There is no analog with planning, eventually you have to just do something. The goal is to get to where you have a good plan, and acknowledge your plan cannot be perfect. Once you think you know where are going, start going there and see where you get. Then, reevaluate and try again. In programming, Dave Thomas describes this as ‘Tracer Bullets’ — a great analogy.
Process is supposed to give you a framework for execution. Customer sign-off on a feature request isn’t meant to be lorded over them if what you built turns out to be wrong, but a means for you to try and make sure you are both on the same page in terms of what you are doing. Spending two weeks plugging your prototype it took you one week to create into an enterprise build system is asinine. If you can’t immediately extract benefit from process, it is dead weight.
One of my favorite quotes that sums this up more eloquently than I could ever hope to is by George Patton: “A good plan violently executed now is better than a perfect plan next week.”
For the love of crap people, it is ok to be wrong! Take some damn risks! And while you’re at it, do me a favor and kick the next smug armchair quarterback you see where his testicles should be.
