In this third installment of our series on things engineers need to know to be effective, we're going to look at the domain that is the least difficult but perhaps the most common cause of disgruntled staff and failed networking projects: policy and process.
Simply put, policy and process are dull as dirt. Nobody enjoys it and it's almost always discussed in the context of hampering some useful activity with extra tasks of questionable value. And much as it might be an accomplishment, no one will want to see "I actually got something through change management!" on your resume. If you're not convinced this is a problem area, try this simple test: Monitor a network engineer's pulse or blood pressure for a minute and then whisper the word "procurement."
Nevertheless, to be effective, an engineer needs to know how to get things done in an environment where it often seems that all the procedures are set up specifically to keep you from getting anything done. This is particularly challenging because network engineers rarely have any input into processes or ability to improve them. Worse, the processes are often oriented toward other IT domains such as mainframe applications, so the hoops you jump through are often totally irrelevant in the world of routing and switching. So here's what you need to know:
First, participate. Most of the processes in question add some value in theory but actually fall short because of poor input. In other words, garbage in, garbage out. If you don't take the time to put meaningful information into a process, no one will ever get any meaningful information out.
Thus, processes in many companies are in a catch-22 where no one uses the information that comes out of a process because the information is garbage, and putting good information into the process is viewed as a waste of time because they know that no one uses the information that comes out. Change management is commonly an example of this, where network and se
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
rver engineers will fill out forms that don't adequately describe the impact of their changes, but then complain that the change management committee doesn't know anything about their changes and can't accomplish its goal of making sure multiple changes don't conflict with one another. Breaking that cycle isn't easy, so try not to get into it in the first place -- participate!
Second, plan. When providing estimates for how long it will take to do a job, engineers will too often consider only the time it takes to complete the physical and logical configuration. Rarely do people include the time it takes to get a bill of materials, go through the processes to get approval for capital and purchase approval, fill out change management forms and then sit in meetings, or update the network management and monitoring tools after the change. Normally, these activities take three or four times as long as the "real" work, so be careful not to short yourself.
Third, avoid out-of-process activities. Astute observers will note that most of the procedures are not so much for intra-departmental activities as they are for inter-departmental activities. In other words, they're specifically designed to make sure all the departments involved are communicating properly. In the case of procurement, for example, it's the network engineering and finance departments, and probably your hardware suppliers. Your post-implementation processes make sure the operations department is on the same page as the implementation department.
This is important to understand because problems arise when things get done outside a process. For instance, maybe the engineer and financial analyst golf together, and when a project is behind schedule, they get an approval by email instead of filling out the forms. Sometimes this is necessary, of course. But you should always realize that when you deviate from the process, your risk goes way up. You can't manage the risks unless you recognize them.
Given that inter-departmental communication is the objective of a process, where is a breakdown most likely to occur when you abandon the process? So what should you watch out for? Misunderstandings. Miscommunication. And forgetting important details after time passes because those details are not documented where they normally should be.
Finally, if it's really not working for you, try over-communicating. Keep in mind that the objective of most processes is forcing people to communicate clearly and consistently (and keeping a record of that communication). So when you get in a situation where the process is suboptimal and you haven't had success in improving it, a possible strategy is to change the process from within by flooding it with information. This is effective when other participants can't see the problem under normal load. Additional communication -- for example, overwhelming detail for a change -- may cause them to start asking the right questions about what detail is really beneficial. It will usually motivate participants to make changes that help a process work for everyone involved.
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
