Forgotten IT Skills: How To Ask Questions

Good IT Departments Know How To Ask Good Questions
Good IT Departments Know How To Ask Good Questions

It’s easy to get caught up in all of the servers, routers, applications, and firewalls that make up a modern IT environment. After a while we tend to start thinking that the path to our next great IT insight must lie somewhere in this jungle of IT “stuff”. And that is where you’d be wrong!

Ranjay Gulati, James Oldroyd, and Phanish Puranam are three researchers who have been studying this problem and they’ve made some interesting discoveries. They’ve come to realize that if IT folks like us want to help our firms uncover ideas for new products or services, then we may have to rediscover the ancient art of asking the right questions.

I will confess to being just as guilty of this as everyone else. In order to be more productive, I try to ask pointed questions that get right to the (what else) point. The researchers are saying that this is exactly the wrong thing to be doing.

What they are saying is that more often than not other parts of the company will have information and data that can help us uncover new products and solutions if only we know how to ask for it. If we re-train ourselves to start asking broad questions, then we will start to get exposed to more types of information.

An example of this comes from the folks at Harrah’s. The IT department was helping out with a project that was designed to find out what hotels were in need of expansion. They asked the question “What is the demand for our hotel rooms?” Note what they didn’t ask: “What is our occupancy rate?” The broad way that the question was asked allowed both the occupancy rate and the number of people unable to book a room because of the hotel being full or because they were unwilling to pay the room rate to be counted. A much different answer!

Getting IT staff to start asking broad questions is not easy. They will be giving up some efficiency, but the rewards can be great.

Do you ask pointed or broad questions? Have you ever been surprised by the answer when  you asked a broad question? How could you get your IT staff to start asking broad questions? Leave me a comment and let me know what you are thinking.

5 thoughts on “Forgotten IT Skills: How To Ask Questions”

  1. Very interesting, this has led to me thinking about this whole topic some more and adding my own contribution on my blog, see

    Part of the art of a good business analyst is in the ability to ask the right question at the right time. Yes we should be asking broad, open questions that will encourage the respondent to talk about their needs. In general we tend to make assumptions and ask pointed (or closed questions) that tends to limit the scope of any answer given.

    We should be asking questions like “please describe how a person can change an order?”. Once in a discussion the typical open question that is used to elicit a further response is “what happens next?” An open-ended question requires an answer greater than a a couple of words. These are designed to draw out the broad requirements.

    If you need to get specific then you may will need to ask a a more closed (or pointed) question such as “Once an invoice has been sent can we change it?”. Closed questions are typically answered in very few words, often yes or no. These types of question may need to be followed by a “Why” or a “How” in order to elicit the detail behind the closed question.

    Much analysis requires the right combination of open and closed questions in order to build the full list of requirements.

    Part of the art of asking questions is the art of listening and understanding, otherwise we may find ourselves asking the same question of the same people again and again.

    For my full item see:

    Peter B. Giblett.

    • Peter: you make a very good point. As technology professionals we just love to solve problems. This creates the issue where we stop asking questions in order to get more information and start asking questions to confirm that the solution that we’re thinking about would work. If we do this too much, than our jobs as a business analyst will be short lived indeed!

  2. Right on. I think another way of looking at this is by differentiating functional questions from technical questions.

    Asking “what does my company/my staff member/my customer *need* to do?” is much more important than “how could he get this or that done?”.

    An example might be installing an Email server. The functional requirement is “I need fast communication within the company”. One solution would be Email (which is an obvious choice because it’s the standard outside the company as well), but there are many other options available out there which wouldn’t have been considered if the requirement had been defined as “I need Email”.

    • Arjun: good points. To take your email example one step further, if you don’t ask the right questions, then you’ll end up with an email system. If you take the time and ask more questions, then you just might find out that an IM or a blog or a Wiki would be the best solution…


Leave a Comment