Coaxing the funding for a backbone upgrade out of upper management used to be a simple task, but the recent economic downturn has made many executives slam the cash drawer closed.

Getting approval for major technology expenditures now requires more than a quick email stating, "the backbone is overloaded--we need new routers." You need to present a solid case built on facts and statistics. How do you make certain you win the boss over? I'll walk you through the steps I use when preparing a proposal.

As with a major military campaign, the first order of business is gathering intelligence. Guessing doesn't cut it when you're asking for big bucks--you need solid statistics on network utilisation from the backbone, server farms, local segments, wide area links, and Internet feeds. Get some RMON or SNMP probes such as Shomiti's Surveyor and deploy them on critical areas of the network. Make certain you attach the probes to switches that support port mirroring, so that you are able to monitor all network traffic. If the hardware doesn't support port mirroring, you'll need to install an optical splitter (if it's a fibre link) or insert a cheap repeater between the network segment and the backbone feed.

Monitoring wide-area links or an Internet connection can be a bit more difficult--it's not always possible to get a probe in the link between you and your ISP, and CSU/DSUs that provide traffic statistics for wide-area circuits are prohibitively expensive. What can you do? Install Multi Router Traffic Grapher, a free application that provides daily, weekly, monthly, and yearly statistics on router interface traffic. If you're not already running MRTG, download a copy and start gathering data on those WAN links.

Besides helping you prepare a case for upgrading your technology, keeping stats on your router interfaces provides an additional benefit: you'll have hard data to support your case if you have to decline requests for bandwidth boosts. Case in point: at our university we recently received a request from an offsite department to upgrade its connection from a T-1 to a 10Mbps Ethernet-over-ATM circuit. All WAN circuits are centrally funded, and upgrading this link would have put an additional US$1,100-per-month drain on our IT budget. A quick glance at our MRTG statistics showed that the existing link was averaging 5 percent utilisation--hardly enough of a load to justify an upgrade. Without the statistics provided by MRTG, it would have been difficult for us to deny the request.

Be careful how you interpret the numbers, however, because there's a big difference between average and peak utilisation. Bursts of traffic can slip under the radar of statistical monitoring tools like MRTG if the polling interval is set for a long period of time. Just because a network segment averages 5 percent utilisation doesn't mean that all is well--a seemingly quiet segment might be the next place someone deploys a massive bandwidth-gobbling application.

Network probes and MRTG statistics can only provide you with information about what's happened on the network--they can't predict the future. To get a grip on future growth, you need to talk with the users and the application developers.

Application developers and network staff are usually the last to know about application deployments, but their input is crucial to your proposal. So how do you get them to talk to you? A non-confrontational approach, such as offering to buy lunch, works much better than a finger-pointing fest. ("You're going to deploy a bandwidth-gobbling application in two weeks? Did you think about telling the network crew?")

The same technique works for gauging what users will do when a new application rolls out: take them to lunch, or offer to do a chalk-talk over a brown-bag lunch. Tell them about your plans for the network, and they'll be more willing to tell you what they're going to do with it. You know you've succeeded in getting the feedback you need when your inbox starts filling up with messages like this: "We're thinking about putting an image-based resume system on the human resources network segment. Would this put a big load on the routers?"

Now that you've collected data from the network monitoring tools and feedback from the application developers and end-users, it's time to build your case for a technology upgrade. In my next column I'll show you how to put all of the information you've gathered into a signature-securing presentation for upper management.

Copyright © 2009 CBS Interactive, a CBS Company. All Rights Reserved.
ZDNET is a registered service mark of CBS Interactive. ZDNET Logo is a service mark of CBS Interactive.