You have the choice to present data regarding IT in ways which make it easy to understand the great job you and your team are doing, or you can present it in ways that require the reader to study it to come to that, or some less flattering, conclusion. My counsel to you is to take the time to present your IT results in ways which lead the reader to the conclusion you desire. Otherwise, it is way too easy to miss getting credit for what you have accomplished. I talked about that previously.
Take a look at this data. It describes the up-time of two pieces of our infrastructure, the local headquarters’ infrastructure (HQ) and our hosted infrastructure. HQ looks pretty good at almost 100%, and most people would think the hosted infrastructure looks pretty good as well at 99.95%.
But look at the graph I got from my infrastructure team:
What?! June for hosted infrastructure is almost at the bottom of the graph and July isn’t much better. Even HQ looks like it is only five-sixths of the way up the chart. Huh? Wasn’t the infrastructure down only .05% of the time? A glance at the graph would likely lead the reader to conclude we have serious problems with our hosted infrastructure. Since this data was right before end-of-year bonuses, the manager of the infrastructure team could be in deep with needing to explain the issues.
Wait. Look at the scale of the Y axis. The entire axis represents .12%, so every .01% is equal to 8.3% of the height of the graph. So, the graph overstates the “height” of the downtime by 833 times! Here is what it would look like entirely to scale with the Y axis varying from 0 to 100%.
Check out this next chart. Same data. Same timeframe.
Wow! That leads the casual reader to a very different decision. Promote that infrastructure manager now!
Not so fast, you might say, we are never going to accept 0% as an acceptable amount of uptime. Heck, if it goes below 90%, you may have the right to terminate the agreement. Varying the axis from 90 to 100% looks like this:
You can barely tell that it is not 100 percent, unless you can see that a couple of the columns are one pixel below 100 percent. This is probably the graph that your infrastructure manager would want you to use. But, if your audience is your CEO, and you know he/she has the occasional issue with the infrastructure, you don’t want to overstate your performance.
In this last graph I varied the Y axis from 99 to 100% and I added in a line for the service level agreement on up-time. Now, you can see that there is some variation, but it still conveys the (accurate) picture that the local infrastructure is up all the time and the hosted infrastructure is up the vast majority of the time.
Which one of these graphs is “correct?” All of them. It is the same data as in the original table. How you display information depends on the story you want to tell and the actions you want your reader to take. If you had wanted to argue that you need more money for infrastructure support, the first graph may well have been the exact right one to use. If, however, you are communicating to your internal or external customers, as in this case, you want the graphs to tell a story of great up-time.
The way to improve your use of graphs is to ask yourself, “What does this say about X?” where “X” is what you are measuring. If you need some help, ask someone else to take a look at your graph and answer the question, in this case: “How was our performance.” In any case, practice makes perfect. I have a chart for that somewhere I think…
Paul T. Cottey is an experienced business professional who has built and operated information technology capabilities at both mature and startup companies. Providing IT and management consulting services, he collaborates with companies across all parts of business operations to provide a perspective not seen from within IT only. He is currently CIO at Water Street Healthcare Partners in Chicago.