Home > Data Warehousing, Management > Data Warehousing: Business Requirement Interviews

Data Warehousing: Business Requirement Interviews

For whatever small amount of experience I have gained, I consider myself blessed enough that all my employers gave me enough opportunities for interviewing people. That’s a fun activity to participate in. And what did I got out of it?
1. Confidence and openness to go and start interacting with a complete stranger.
2. Experience in understanding what exactly person is after and where possible, a little insight towards the psyche of the person.

No wonder it was a great boost to what I have learnt over the course of last eight years. And one thing it has helped me a lot is looking under the skin of problem and to understand who is saying what and why. And that’s where it starts bending towards a business advantage !

But one can be terribly wrong to conclude that conducting interviews is nothing but a “templatized” course of action – with a little variation for Job Interviews and for Business Requirements gathering. No, they are not!

And here’s why I say that when I mention for Business Requirement Gathering interviews:
1. Don’t think you’re too smart, but be curious.
If you hear "Sorry, what’s the question again?" then that probably is a sign you are wrong track. Keep them short, and open ended. Pick at any interview published in a good magazine and you will notice, questions are one-liner and answers runs into Para’s. Keep it that ways and listen attentively. Also, don’t get into that "observe it all and truth will surface" syndrome. You aren’t a detective and the person in front of you isn’t a criminal. If you receive conflicting information, you always have a chance to clarify, keep it as an requirement gathering interview, not a cross-examination !
2. Converse honestly
Ask honest questions. Don’t pretend you are one among the "know-it-all" lot. You are there to know things in detail, and not "validate", so talk accordingly. Recording the meetings might not be the best idea as there are many times people mention for it to be kept off-the-record – and hence it breaches the whole idea of the honest conversation.
3. Leave the ego out of the room
There are many times when the client member you are interviewing is half your age. And it might be other way round as well. When you are interviewing, your key job is to listen attentively and keeping your presumptions and prejudices out of the picture. Use body language and verbal clues or gestures to encourage interviewees and express. Your attitude and approach as an interviewer are more important than the tactical and logistical concerns of setting up and conducting the sessions.  your interest.
4. Don’t judge
Concentrate on interviewee’s job and not if it’s right or wrong! If all goes well, DW/BI will address the issue anyways. Avoid jumping onto conclusions just on hearing a one-liner for a process, listen and find, there might be some genuine reasons for the way things are.

Especially, if you are going towards DW/BI or any large scale data application (e.g. Cloud Solutions) business requirements gathering, you might want to consider these as well:
– Its always best to have a lead in place with clear objectives and experience on the topic. Have a lead requirements analyst with the right tools, confidence and coupled with the right knowledge on business acumen and DW/BI’s potential. You don’t want somebody who himself is questioning if it really will reap the benefits as it "sounds". And this “lead” should own to clearly define the beginning and closure of specific stages of the project.
– Involve the right business representatives representing BOTH vertical (cross-management ranks) and horizontal (cross-department) perspectives. Don’t rely solely on the input from a lone power analyst who’s a pseudo-IT professional. Yes, the power dynamics is a key topic in management, and it might help you in getting a deal signed but it surely wont help in getting it executed successfully !
– Don’t presume you already know what the business wants just because you’ve supported them for the past decade. No business are same, and so is true for their requirements as well.
– Be explicit at what you will be delivering against. We have always learnt in Software Engineering that there is something called Explicit and Implicit requirements. See each "implicit" requirement as a loop hole where someone has a chance to bring you down to your knees. Convert them so they are explicit and then sign off as appropriate.
– Your delivered product and your mode of delivery are two separate pieces, and shall be addressed separately. The problem with long running engagements (as likes of DW/BI) is that we are so much lost in actual product that we loose concentration on modes of delivery. If not right away, ensure you have space defined to capture modes / frequencies / mechanics of deliveries as well. 
– If yourself feel comfortable to see your doctor in person, then same will be true for your clients too. Get face-to-face with business representatives (or at least voice-to-voice, but that too once you have rapport built up). There are many other modes of gathering requirements, and though they might be okay to find where your team wants to party, but that’s not enough to know where your clients want to reach.
– Be prepared, and try your best to impart some knowledge before you actually start with catching requirements. Prepare interviewees in advance so you don’t have to spend the time recursively at conceptually explaining "what’s DW/BI (or something similar and basic).

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: