Support Management Magazine, July 1997

The Network’s Down…Now What?

A Network Survival Guide, Part I

 

George Spalding

 

 

Think about this for a minute…could your company survive today without a network? When your network is down, (could happen!) doesn’t everybody’s head pop up out of their cubicle and start gabbing with their neighbor? Doesn’t coffee consumption go way up? "Cube" friendships get renewed? Why? Simple. Can’t do any work, the network’s down. It is amazing how quickly the corporate landscape has changed. It’s only been about ten years since Novell made local area networks viable for all but the largest companies. And only about 7 years since networks became what we could call robust and reliable. Yet every major corporation and mid-sized business and a staggering percentage of today’s small businesses have rested the entire company’s information workload and, by extension, the success or failure of their whole operation on the network. When the network’s down, it’s a crisis.

 

Traditionally, the role of network support has fallen on the "network guys". A separate department which is usually guys (I would say at least 80-90% male in my Novell/Microsoft network classes, come on, girls, vast opportunity awaits…Microsoft alone estimates a need for 150,000 more MS Systems Engineers by the year 2000…you go girl!) who have "substantial network experience" or have been recently trained and, often, certified in one of the major network operating systems (NOS). The network OS market is currently divided (roughly) as follows: Novell Netware - 60-65%; Microsoft NT - 15-20%; UNIX, Banyan, Sun - 15-20%. Novell is growing in total number of installations but ever so slowly losing market share (the total network market is growing faster than Novell’s sales), Microsoft Windows NT is growing in total number of installations and market share (the number of installations is growing faster than the total network market) which brings us to the current and future shortage of qualified Systems Engineers. Microsoft’s renowned marketing capabilities are beginning to outstrip its ability to support its products in the field. This is a serious problem for today’s companies and a boom time for those qualified (and certified) to support MS products, bidding wars for these support capabilities already exist in a number of metropolitan areas where high-tech companies need to stay on the cutting edge. UNIX and, more specifically, Sun Microsystems are strong players with loyal customers that really can’t find enterprise-wide, scaleable solutions in the Novell/Microsoft world (some people need the big, strong stuff). Regardless of Microsoft’s claims to the contrary, the UNIX/Sun share of the enterprise networking market should remain constant for the next five years (don’t forget Sun created JAVA, the hottest thing to hit the Internet since modems). Banyan is another story. The industry pioneer in enterprise Directory Services (StreetTalk) for networks, Banyan watched its lead begin to erode with the introduction of Novell’s Netware Directory Services in the early 90s. In 2Q98, Microsoft will release NT 5.0 which includes Active Directory Services as well. The "killer app" that made Banyan unique is no longer unique, it has failed to keep pace with other current technologies and its future is cloudy at best. (BTW, if you are now asking yourself, "Hey, he didn’t say anything about our company, we run stuff from the Ethernet corporation!" or "Well, that’s nice, we don’t have those guys, what about that TCP/IP company?" you have just flunked the network literacy test and need some network training…now.)

 

So how does all this affect support? Most frontline support organizations refer their network-related problems to the "network guys" whose reputation for customer service rivals Genghis Khan. This is especially troubling to me. I spend most of my days teaching folks on both sides of this issue: Frontline support people who recount endless stories of technical arrogance and customer indifference about the network guys and their management and, on the other side, network support folks/administrators who are totally frustrated with the lack of basic knowledge and general comprehension of the problem of the frontline people. Both sides have valid points.

 

Frontline support people are exactly that…on the frontlines. I’ve even been to desks where the folks actually on the phones are referred to as being in the "hotseat". (Let those arrogant network "guys" try it for just one morning. How ‘bout a Monday morning...after a weekend network "upgrade" which was supposed to be "transparent to the user"…but wasn’t.) Frontline reality is shaped by the day, by the hour, by the call. They (should) have specific goals and targets for time on hold, abandons, first call resolution, what to refer, what to keep, what to research, how long they can legitimately work a call before referring it to another resource, etc. The agenda of most frontline support in today’s corporate world is, unfortunately, firefighting. It shouldn’t be, but it is. I preach the need for training, I evangelize, I cajole, I demand…I beg…but to little or no avail. Not everyone and not everywhere, but at this year’s SSC East in Nashville, a help desk manager came up after one of my session’s and asked me where he could get training for his people that didn’t take any time. "No time?" I asked, bewildered. "Yeah, I can’t take any of them off the desk…ever." "Not even for an hour or two?" "Nope, not even for half an hour." I tried to be polite, I don’t think I was. I told him that I didn’t know of any training that took no time. I wanted to injure him severely or at least ban him from the industry. I espouse the need for time off the phones: to recover, to rejuvenate, to learn, to train others. I know some of you are listening, but not enough. Corporate downsizing has taken its toll on frontline support organizations, there is no fat, no extra person, no backup, no net…it’s full steam, all day, every day. No time for rest, training, improvement, investment…just answer those phones, put out those fires. This "chew ‘em up and spit ‘em out" management style devalues the role of frontline support. It says to the workers "you’re not worth investing in" AND it says to the customers, "we’d like to help, but we don’t know anything that isn’t in our problem database…and we’ll quit before we ever have a chance to learn anything on our own." (And, of course, let’s not forget "we haven’t been trained on how to enter stuff in the database.") The customers are frustrated by an endless parade of young, well-meaning but untrained "phone answerers" and an incredible lack of real "support". The workers (once they figure out how this all works) begin looking for a better place to work within a few months of hiring.

 

There are forward thinking support managers out there creating wonderful environments, encouraging their people to think of this not as just a job but as a real career, investing in them and giving them the time to learn and grow. I know what you’re thinking…they must all be altruistic bonzos with unlimited budgets with pansies for bosses, huh? No, they are hard-nosed, cost-conscious, bang-for-the-buck mangers who face all the same pressures from above that every support organization does. They’ve learned that if you want high first call resolution, train your people. If you want to shorten calls while maintaining a high first call resolution rate, train your people. If you want to reduce abandons while maintaining a high first call resolution rate, train your people. If you want to improve your customer satisfaction ratings, train your people.

 

So, the network guys are totally justified in their criticism of frontline support and get off scott-free in this whole discussion. No. Let’s look at the agenda of the network department. They were created to "manage the network". This usually means maintaining the infrastructure. Which translates simply to performance (speed) and reliability (uptime). That’s the basic agenda of the network guys…speed & uptime. Now we throw in all the new stuff: Internet/intranet, firewalls, switching to TCP/IP, routers/switches, new protocols, new cabling, etc. and we have a fairly high-level technical position with an enterprise-wide viewpoint. That’s the problem. The manager of the network department (never the same person as the manager of support) has the mission of keeping the network up and fast. He/she has delegated this mission to the network guys. This involves planning, designing, traffic analysis, upgrades, equipment maintenance, "network management", etc. and occasionally putting out fires in the form of server abends (abnormal ends) and crashes. Therefore, whenever a call is passed from the frontline support folks to the network guys its priority is immediately evaluated based on the criteria that I’ve outlined. If the problem does not specifically impact the prime directives of speed & uptime, it is shelved to be dealt with "later" which often means never or, more likely, until the frontline analyst nags the living crap out of one specific network guy who finally caves and actually fixes it.

 

The "customers" for the network guys are not real people but more of a concept called "nodes" or workstations. They seldom, if ever, actually speak to or interact with…a real user. They view of the world like road construction crews (I live in Minnesota where we only have two seasons: winter & road construction.). The road crews know that their work will impact traffic, but they believe that when they’re done we’ll all like it better. There is no accommodation made for the individual who is now screwed because he/she missed an important appointment or an urgent plane flight. Repairs and changes are made for the "common good" of everyone. That is the way network guys think. "Don’t call me because someone forgot their password or needs to be in the Laserjet group, I don’t have time for this trivial stuff." The problem is that it’s not trivial for the user. They can’t do their job…their very important job…their mission-critical job…and their boss is yelling at them…and next in line for yelling is…lemme guess…the network guy? Wrong! The frontline support folks take the brunt of the abuse because of lack of responsiveness by the network guys.

 

So both sides are right and both sides are wrong. The most important tool for providing responsive support for network-related customer problems is NOT an SNMP-based Management Console from Novell or HP but an SLA-based working relationship between the frontline support staff and the network guys. A Service Level Agreement between departments detailing how we will work together. I don’t mean high-level conceptual, touchy-feely working together but detailed, nuts-and-bolts, procedural, I-do-this-and-you-do-that working together...with accountability if things don’t happen.

 

If such an SLA is in place and supported by management, then a unique conversation can take place. "I’m going to have to refer your problem to the network department. They will contact you directly." "How long will this take? When will they call me?" "Our agreement with them states that their response will never be longer than 2 hours for this type of problem." "Thanks."

 

Now that I’ve gotten all that off my chest, next issue we’ll discuss training options, certification programs and the role of outsourcing.