As much as I've been trying to come up with some creative comparison between this weekend's football playoffs and IT business management, (especially the Eagles' heart-thumping overtime win) anything that I can come up with seems like a desperate stretch for content. But since I have a website now that all the world can see at any moment if they so choose, I do have one thing to say.... Chris Collinsworth can kiss my ass. The Eagles are a good team, Chris. Face it. Troy does and he was a friggin Dallas Cowboy. I know it's going to be tough, but try to find it within yourself to say at least one good thing about them on the air this Sunday.

Whew. Now that that's off my chest, I can move forward. I've been reading some articles lately about Change Management and the push in corporate environments toward the right people and the right processes to make Change Management work. As a technical guy, I find it a little amusing when I come across articles about this subject. First, let me say that I believe in processes like Change Management. This whole site is dedicated to processes such as these for a better working environment. What's missing, which is what's missing in most of these endeavors, is the personalities of the people that you are asking to be advocates of such processes.

When trying to inject change management into an LAN support environment, two problems come to mind. The first is how network people look at Change Management. I've long been an advocate of such ventures. The issue, however, is that network people have typically felt that Change Management was reserved for development environments. We've never realized that documenting a change in a router configuration was, in fact, Change Management. We just don't look at it that way. We look at our environments as something that we can change when we want to and that other people shouldn't change because it'll screw us up. Agreed, this is wrong, but this is how we've come to evolve as a species. Most of this is the fault of the network organizations, but part of it stems from the fact that network engineering involvement in technical projects is a relatively new phenomenon. I can remember countless times throughout my career where we, as a team of people responsible for the Local Area Network, would hear about a project coming to fruition and not one of us, including upper management, would ever say, "hey, shouldn't somebody from our group be in those project meetings?" We tended to get involved after the fact.

The other problem is more intangible and more frustrating to both technical people as well as management.

Quick... off the top of your head... what's the fastest way to de-motivate your technical staff?

How 'bout calling them into a meeting room after a morning of fighting "WAAAAHHH my email doesn't work" fires and telling them that they have to document change more so they can comply with some new Change Management initiative?

I've been in these meetings too. It's more than a coincidence that technical people gravitated to their laid back, neat, cutting edge highly challenging jobs. They like figuring things out fast... like puzzles... and then moving on to the next. They like getting into the cool new stuff and many of them hate the establishment. In meetings where new initiatives toward processes are the subject, network guys feel dejected. "Don't they realize how much I run around here and help people?" A frustrated network person might say, "documenting everything is much less important than having me in the trenches." As much as your blood might boil if you're a manager reading this, keep in mind that I'm just trying to make a point here. The tendency of management in these situations is to pull the hierarchy card. This might work as IT continues to mature over the next few years or decades, but right now, people don't see the immediate benefits of documentation and Change Management.

Is there a way to remedy this? I think there is, but it's not easy. Rather than force the issue, the only way that you can get people to respond is to make their jobs easier through a foundation of structure around the support and documentation process. Work on getting people to think that fixing a machine is important, but working with that machine as a part of the larger network, is something that affects the bigger picture. Help them see the network as a whole. Not just the machines, the servers, and the routers, but everything down to the customers and the comparison between the high-level executive computer moron to the secretary who can do anything on a computer including take your job if you're not careful. The Local Area Network is your environment. It's health depends on a technical person's understanding of every nook and cranny, or at the very least, it depends on a technical teams wilingness to care for the network by telling meaningful stories about it's existence.

Doesn't that sound better than groan-promoting words like Change Management and documentation?