Problem to Solve – My users are complaining that they need more bandwidth and that “everything is slow”.  I need a report to show the actual capacity planning & bandwidth usage that is understandable to a non-technical person.  

ALVINNN!!!!!! Did you water down the Bandwidth Usage Report

Ok, we probably cannot pick on Alvin for who watered down the bandwidth report. It’s more likely due to a function of math, display size, or incorrect expectations. I have had many a customer ask if they can get a report on actual bandwidth usage, and the answer is always, “of course you can.” There are tons of great tools available (open-source or commercial) that will accurately report on bandwidth consumption. These types of solutions usually will offer various metrics for display purposes (utilization, bits per second, volume, etc). SNMP polling of routers, switches, NetFlow collection, packet capture appliances are all more than feasible options from a data source perspective. Where things will sometimes get challenging is when customers want a report on bandwidth usage, but are not completely sure why they want it. Or what information they want to glean from the report. I know what you are thinking right now. “Hey tough guy (it’s my blog, so I can refer to myself as a “tough guy”), the client asked for a bandwidth report, just give them the report.”  Sure, we can do that, but I like to make sure that my clients look good in front of their customers and management. That entails asking a few more questions so the proper information is provided in the report.

Absolute Classic User Comments

A few classic requests from my past customers, usually from non-technical clients outside of IT:

• Why can’t I just show total utilization, this “in and out” stuff is too confusing
• We pushed 100′s of Gigabytes of volume last week, but I only have a 20 Mb Internet connection. Clearly I need a bandwidth upgrade
• I want to see all of my traffic for the last month, so I can see all the strange things on a single page.

This is not intended to poke fun at these comments. The real object lesson here is aligning the solution to the customer’s expectation and line of business.

KISS Principle – Keep it Simple Stoopid

Whoever was the creator of the KISS principal should be enshrined in the IT Hall of Fame. Nothing in this world will derail a discussion faster than this example. Imagine the most brilliant technical person you know trying to explain a technical thing in his own language/vernacular to a non-technical person. Bottom line: if you don’t make the report/analysis/discussion understandable to your audience, you will get no points for the effort. Here are some suggestions to help.

1) Use a Bandwidth Threshold to show limits. From my experience, it is much easier to paint a picture of the bandwidth used or a capacity report if you know what the customer is trying to decipher and analyze. For example, assuming the report will be used for non-technical audience, I would suggest putting in a threshold marker that shows actual bandwidth capacity of the link. If it is a 10 Mbps link, then show the 10 Mbps threshold barrier limit on the graph.   

Why is this Valuable? This threshold line helps non-techies understand the concept of “your network has this much bandwidth available to use.” Now that the general population understands the concept of what “available cell phone minutes” means, you can draw an analogy to explain bandwidth as well. The phrase “Mr/Mrs. Customer, you run out of bandwidth when it hits this line,” combined with “Your apps will get slow if you run out of bandwidth capacity” is liquid gold to the nerd-averse. Having this in a pretty graph picture says all they need to see in order to understand.

2) Choose the Right Granularity for the Use Case. This concept becomes a real art form, because non-techies usually do not make the connection that the granularity of the data displayed will greatly affect their report, analysis, and/or decision. If your report displays Megabits Per Second (Mbps) type metrics that are totaled up and averaged for any time frame GREATER than 1 second, there is a strong possibility that you might lose your audience. That is because summarized/averaged data points will effectively flatten out the actual data in the report. Typically, the longer the time window selected, the flatter the data will appear. For example, creating a report at 1 second granularity will show the peaks and actual usage. Take that same data and change the time granularity to 15 minutes, and you would likely see that the drastic peaks and valleys in the report would “flatten out.” The key is to choose the right granularity for the report, based on the actual perceived problem. 

Why is this Valuable? The whole purpose of the bandwidth report is to review the information and help the user make an informed decision. You want to avoid the worst case scenario where the user will make a bandwidth capacity-related decision that he thinks is based on a Mbps data, but is actually data that is averaged (or watered down) over a minute, 5 minutes, 15 minutes, an hour, etc. I.E., he thinks the pipe is running at 5 Mbps (because that is what shows up in 15 minute intervals), when it is actually hitting peaks of 20 Mbps (at 1-second intervals). That would be an extreme recipe for future poor performance.

3) Annotate the Report to help Explain it. This would seem like common sense to those of you not in the IT world. However, I see this as the most critical piece to any technical analysis report – and unfortunately, the most overlooked. Pardon the phrase, but I wish I had $1 for every time I heard a non-techie tell me that “John/Jane provided me the report that I asked for, analyzing the data, but I didn’t understand all the bits and bytes statistics or what that data really means to me.” (Let’s just say that I could contribute a sizable deposit into my kid’s college fund with that money.) After you analyze the data to provide the requested report, do this before sending it.  GO BACK TO THE REPORT AND INSERT SOME TEXT TO EXPLAIN WHAT IT MEANS, AS IF YOU ARE TALKING TO A 2ND-GRADER.    

Why is this Valuable? Most of us in IT will simply assume that the person reading our technical report has the same knowledge base, experience, skill set, perspective as we do on technical statistics and metrics. We assume that if we provide the data, the person on the other end will completely understand that data. WRONG ASSUMPTION!!!! A simple 2-sentence explanation at the top or bottom of the report summarizing what the data says and what it means will drastically INCREASE the level of understanding by the reader. It will also show that you are a “go the extra mile” type of person, caring enough to add in the extra explanation to help others understand.

And that is how IT “Rock Stars” are born…     

Points to Ponder

• What types of reports do you have to provide to non-techies?
• Why do they need these reports? What information do they need out of them?
• Do you have any “Communications Enhancing” best practices or tips that have worked for you?

Until next time….