Change management and dogfood
Posted by BPuhl on December 18, 2007
Talking to some folks at IT Forum in Barcelona recently, and discussing some of the “fun” that we’ve had with dogfooding Server 2008. Most of the discussion was about features – RODC, Fine Grained Password, Server Core, etc… but in any good dogfooding discussion I always get asked about some of the challenges.
Sure, we’ve hit our share of issues, but that’s really what we do this whole dogfooding thing for. I was talking about a bug we had recently hit which caused several internal applications to feel a bit under the weather, when the customer asked me why we didn’t do change control.
At first, I wanted to say that of course, we do change control. Because it’s true, on a good day, when the planets are aligned and gods are in the heavens, we can start off in a lab with testing, understand every aspect of every change which is occurring in the system, and reconcile that to all downstream applications, communicate those changes broadly, blah, blah, blah… excuse me, I think I had a MOFball caught in my throat.
Our reality though, is that we’re often bound to aggressive deployment schedules with an undocumented operating system upgrade incorporating changes across dozens of teams…some of who will leverage our experience in crafting the documentation which doesn’t exist at deployment time.
I’m a fan of change management, but I even more firmly believe that IT is not in place to support itself, but rather to service the needs of the business. If the business requirements can’t support a high (or even mid) level process overhead for testing, communication, etc… then that’s when the negotiations about availability and impact have to start.