Storagebod Rotating Header Image

Asking the Right Questions…

How often do we ask the right questions of our vendors? Do we ever ask the right questions, I suspect that I could pretty much reproduce a good 80% of everybody's RFP/ITT questions, especially in the storage world. We find ourselves asking the same question again and again; even if we want to ask different questions, we find ourselves lead down the same old paths. And then, we ask the same old questions from our business users. 

Is it any wonder that we regularly find ourselves in quandaries with products which meet neither our needs or that of our business? Lets take availability for example, we demand our vendors supply five nines available kit; then we ask the business, if they want five nines? Invariably they respond yes and then they start to talk our language because that's how you talk to IT. And we start seeing five nines as a business requirement. So eventually it becomes a baseline requirement. We see business requirements poorly translated into IT requirements.

Perhaps we need to learn to ask different questions. Firstly we need to ask our customers what they are really trying to achieve and the impact of not achieving these. Questions may need to be asked in different ways? Perhaps instead of asking whether they need sub-second response on a screen; perhaps we need to show them the differences between different response times and what they find acceptable? 

When gathering non-functional requirements; wait till the end of the meeting to ask the question 'The service has been down since the beginning of the meeting; what is the impact?'. Or have a clock ticking on the screen and ask the meeting attendees to stop it when the 'acceptable' length of time for a service being out has been reached? 

Yes these things are gimmicky but I think we need to learn ask questions in a very different way.

And then how do we ask questions of the vendors? What are the important questions? I don't think it's whether that piece of kit is five nines available, I don't think it's how much storage I get for my pound. Yes these things are important but actually these questions are not hard enough. 

So what are the really hard questions we should be asking?


7 Comments

  1. The hardest question I’ve ever heard from a customer is “will your solution meet my requirements?”
    It is especially hard to answer if the vendor hasn’t taken the time to understand the customer’s requirements in the first place. Of course, the question is exponentially more difficult if the customer doesn’t actually know his/her requirements.
    It’s when the customer doesn’t know AND the vendor hasn’t asked that the question is really easy to answer. Which is why customers all to often hear “Yes, of course!” from sales reps hoping that nobody is going the check…

  2. Martin G says:

    Indeed and it is often the most telling question because all the speeds and feeds don’t actually answer the question (actually sometimes they do but mostly they don’t).

  3. Here’s the sorts of questions I’d like to think will be asked in a sales situation:
    1. What is the current end of life date for the product being proposed?
    2. What is the planned upgrade strategy of that product? (I.e., will I have to buy a new product outright, or is there a planned upgrade strategy, and what is it?)
    3. Do you have known install scenarios with the I’m using?
    4. What is your support model? SLAs? Response times? Availability of replacements (for hardware)? Number of licensed contacts? Training or certification levels of support staff?
    5. What are your training options? (Physical course, eCourse, documentation only, etc?)
    Those questions for me, come from long term work on support related activities and a focus on long term data protection, etc. There’d be a whole bunch of other questions I’d expect based on ensuring that the solution being pitched is one that melds itself to the local environment and operational requirements, etc.

  4. randyjcress says:

    Blunt questions/statements the storage vendor could ask to the client.. albeit, you’d probably never get the answers without some hesitation:
    – Do you really know what kind of data you are storing or do you just think you know? Be honest.
    – Is it worth buying terabytes of storage to back up non-business data?
    – Do you know if your software applications are creating files efficiently? In other words, is your document imaging solution using loss-less compression AND are you only storing the pages that matter?
    – Do you have a grip with the retention times of all of your data, exponentially growing useless logs and tons of uninstall data on your servers?
    – If you answered that you did not know to any of the above, do you realize that we will figure this out for you if you’d like and not only sell you what you really need, but help you clean up the mess that you already have? It’s all included, no string attached!
    We won’t make any money and we’ll be out of business in a few weeks, but hey, we tried didn’t we?

  5. BasRaayman says:

    I think the main issue is way more trivial.
    Especially in larger environments we tend to lose the ability to keep an overview of what the requirements are for an overall solution.
    For example, if I take my own company, we have a department for storage, for networking, Operating systems, databases, applications, and I could go on for quite a bit. Then talking to your own internal or external customer you come up with requirements that get filtered a couple of times, and are subject to the loss of information.
    Usually you are also dealing with a solution portfolio that offers you several default configurations or the need to find out (the best you can) what a customer wants.
    Usually it’s hard to find the exact requirements from each different group since people just don’t have an overview of all technologies anymore. People might be able to tell you that they want a certain response time for their end users, but you will have a hard time finding out what the exact requirements are because a DB guy might tell you that he needs a certain response time from his disks, but doesn’t know how certain operating systems parameters might influence his application, or how a certain application patch level might cause problems.
    I agree that we need to start asking the right questions, but we need to start with our own colleagues and customers. Sometimes that also means telling someone “You can’t answer my questions, find me someone who can.”. That’s not something everyone can do. And as long as I don’t know what “I” want, it doesn’t matter what I buy because the outcome is usually different than expected for most, and they usually find out when something is already productive and causing issues.

  6. Martin G says:

    I think we need to get a lot more basic; what are you trying to achieve with a service? What is the impact of it being down? How long is an acceptable outage? I’ve just deleted your data, can you still function? If are you dealing with interactive applications, what is an acceptable response time but instead of just asking for a time; show the impact.
    Try and avoid using IT jargon and acronyms in your questions to your customers.

  7. Howard Marks says:

    Martin,
    I think we need to go one step further than “What’s an acceptable outage” to “How much is it worth to go from 1hr max outage to 5 minutes?” Of course customers want 5 nines till someone explains that 4 nines costs 1/2 as much.

Leave a Reply

Your email address will not be published. Required fields are marked *