Archive for the ‘Data Warehousing’ Category

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).


Data Warehousing : Watch out what you Commit !

February 23, 2012 Leave a comment

So what all did you promised while selling that hefty Data Warehousing solution? And was it just a promise, or over-promise? 🙂
Its not uncommon for people to say "We will ensure you have..":
– Rolling operational results mapped to the general ledger (GL)
– An effective compliance for the end-to-end system
– Key performance indicators (KPIs) are identified and implemented as needed by client facing departments like Sales, Marketing, Finance etc. And more importantly, they will all go "into" performance dashboards
– All the customer facing operational processes integrated into one single application / screen (and by the way, this mostly goes unimplemented!).
– All backend, frontend and operations tools will be brought under single licensing control to ease off the licensing procedures
– Server virtualization will be implemented for the DW/BI system. And this new system will be "green." (and both, are seldom understood clearly in DW/BI context)
– Storage management for the DW/BI system made completely automated (auto-extension, auto-allocation, auto-archival and what not!).
– Security rules, roles and responsibilities clearly identified and implemented (and then admin’s made capable of peeking into every single record).
– Long term archiving and recovery requirements for data looking forward 20 years.

If you look at any of the DW books/ toolkits, they talk about the processes and workflow which comprise likes of requirement gathering, designing, delivery, validations etc. But its pivotal to understand that they all are done with a manual intervention and that’s where art (and problem) creeps in. Watch out for what you commit. And remember that principle at every single phase of your delivery.

%d bloggers like this: