Why ask why? Because it may save time and money

This morning, between tightly packed conference calls and fiddling with some ridiculously complicated network drawings, I had a moment to turn my left brain off and flip through my Facebook feed.

Immediately I dipped into the hilarious saga of one of my longtime friends, who has the misfortune (her word) to be blessed with fraternal twins. The pair are going through the “why” phase, as in, “Why can’t I bungee jump off the roof?,” “Why can’t I sleep in the bathtub?,” “Why can’t I tape the TV to my head?,” and so on.

Reading these, I laughed like anyone would — until it dawned on me that the questions I had just asked in a recent conference call had probably sounded a lot like that, judging by the exasperation in the voice of the software vendor on the other end of the line. Yet, as it turned out, those fantastically irritating questions changed the character of the project entirely and ended up saving the client a very large sum of money.

Make time to ask the questions

Too often, the breakneck pace of troubleshooting and managing a deluge of new projects robs us of the chance to consider the bigger picture. Instead, we learn to streamline the conversation, get the information we really need, and finish the job as quickly as possible so that we can move on.

Aside from not being very much fun, here’s why this is a really bad way to run IT: Think of how much time you spend revising hardware specs that turned out to be inaccurate, dealing with servers and storage that have been over- or underprovisioned, or mollifying stakeholders who had expectations that were misaligned with what they got. It adds up.

As a consultant, I don’t have any choice but to ask the dumb questions. When I’m working with a relatively new client, I might not have any idea what’s going on. I have to make everyone step back and fill me in on the basics of what’s being done so I can get up to speed. As irritating as this might be, it’s rarely a waste of time.

Why are we doing this?

One of my inside sales guys coined an easy-to-remember acronym: WTGBRFDT?

OK, so it’s not easy to remember. In fact, it’s terrible. But “What’s the Good Business Reason for Doing This?” is a vitally important question to ask.

The cynical might argue that the answer doesn’t really matter. After all, by the time the request hits your desk, someone somewhere has decided that it’s worth spending money on. It might be server and storage gear, or it might be an upgrade to the wireless network. But no matter how complex or simple the request, if you don’t know why it’s being made, you can’t competently advise the business stakeholder.

A great example of where this approach can make a big difference is in setting reliability expectations. Most stakeholders generally don’t know the difference between a system that’s highly available and one that isn’t, either at the software or hardware level. So when a business unit says a system must be “reliable” or that an application is “critical,” that actually says very little about actual requirements and cost. To ensure you and the stakeholder are on the same page, you need to ask why and uncover how the business plans to use the resource.

Why are we doing it that way?

I recently helped a client put together a bill of materials for a brick of additional blades and storage that would host a new application. The hardware requirements provided by the software vendor were very specific about what was required — in essence, it boiled down to four pieces of server hardware, two processor licenses for MS SQL Server 2008, some operating system licensing, a tape drive, and a sizable brick of high-performance SAN space.

For the type of application the system would host — a fairly complex accounting package that would integrate with several other lines of business systems — this didn’t seem like it was all that unreasonable. The easiest thing to do would have been to take the specs and translate them into the hardware that the client would need to satisfy them. But some prodding revealed that all was not as it seemed.

Starting nowhere in particular, the fact that the BOM included a tape drive was interesting. This client had made a significant investment in a centralized backup architecture that could easily accommodate backing up these new systems. As it turned out, the tape drive requirement was just a boilerplate spec.

And why processor licenses for SQL Server versus CAL-based licenses? After all, the accounting department had only seven members. Was processor licensing (which would allow an unlimited number of users) really required? Nope — more boilerplate.

As for storage, the database server specs included a requirement for a few SAN LUNs, two of which were immediately recognizable as data and log volumes. But there was a third volume that was spec’d at easily 10 times the size of what I assumed was the data volume. A little interrogation determined that that volume was meant to hold several months’ worth of database and transaction log backups. Was this immense amount of expensive SAN storage really necessary if an external backup system would be archiving these daily? Uh-uh.

Finally — and perhaps this question should have been first — why was hardware a requirement at all? Could we virtualize the application? After a bit of wrangling, not taking no for an answer and talking to a few different people at the software vendor, they agreed that three of the four servers (interface and Web servers) could be virtualized, but the database server couldn’t be. After all, it required 64GB of RAM and was expected to produce many thousands of disk I/Os per second — both factors that might lead one to locate it on its own hardware.

However, this software package was designed and marketed for companies several orders of magnitude larger than the client I was working with. Were these load expectations based on boilerplate specs used with larger customers? A quick call to a reference customer of a similar size revealed that the loads would probably be less than a tenth of what the hardware requirements would have you believe.

Averting the overbuild

As it turned out, an application that seemed to require a big chunk of server and storage hardware coupled with some expensive licensing and implementation services turned out to require about a tenth of the original capital budget and would be up and running with a fraction of the lead-time required for the all-hardware solution.

Digging in your heels and asking basic questions every time a new project crosses your desk will not make you popular, but stick to your guns. It’s worth it in the long run. I’ve seen more examples than I can count of systems that were implemented without the right questions being asked ahead of time — resulting in the waste of literally millions of dollars in capital and effort. Feigning a little childlike innocence up front can go a long way toward avoiding humongous mistakes.

This article, “Why ask why? Because it may save time and money,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.