The highs and lows of change control

The process of change control in software project management is vital. But the forces that make it necessary also make it annoying. We worry about change because a tiny perturbation in the code can create a big failure in the product. But it can also fix a big failure or enable wonderful new capabilities. We worry about change because a single rogue developer could sink the project; yet brilliant ideas also originate in the minds of those rogues, and a burdensome change control process could effectively discourage them from doing creative work. The author's ambivalence about this issue is only deepened by the fact that change control processes are easily corrupted. Change control means risk analysis, and there's no easy or certain way to do that. Coupled with the amazing capacity we humans have for oversimplifying the complex, change control can become mindless resistance to change and an automatic rejection of all risk, regardless of potential reward. Or, just as easily, change control may degenerate into a set of empty rituals that allow any change to be made as long as the rituals are honored. Such a process is less a practical device than a sort of gargoyle meant to scare evil spirits or impress clients. Midway between allowing nothing or everything, change control may also become a political filter where change is resisted unless you're in with the in-crowd, regardless of the situation's merits. At SmartPatents, change control processes are (at least officially) the author's responsibility. He describes the process used at this software company.