Archive for the ‘Technology’ 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.

Service Level Agreements (SLA) or Service Expectations

Every now and then you jump onto an article and on the first read they sound so… correct. Read them again, and may disagree to it !

A recent article on Gigaom is one of similar lot to me. It goes suggesting SLAs arent of much help, and one shall rather be worrying for Service Expectations. I suggest we revisit that.

SLAs are as what they stand for, an agreement – on basis of which a service level will be measured (and vendor paid up for). Service Expectations are some intangible facts and boundaries that a vendor shall understand and attempt to abide with before putting forth a SLA proposal – as they might have a direct impact on client’s business.

Now, there is a different between a mass offering and tweaked business/technical solution. A mass offering, as generally provisioned by Retailers & Utilities providers (cloud computing inclusive), only comes with a generalized SLA. E.g. amount of time service vendor would be able to keep the service online. Matching each SMBs (or small applications of big clients) service expectations would rather be next to impossible. As in any retail business, challenge here is to put out a service in market which excites majority (not, all) of potential clients by value it delivers. And it shouldn’t stop at point of excitement and buzz generated, but goes way to the point of meeting what you committed to masses. And you report it using SLAs.

A tweaked business / technical solution, on other hand, looks upon each and every business and service expectation for the specific client service is getting designed for. There are times when I have seen different SLAs being proposed for different times in a day / weekdays / weekends – for the same client. But that’s generally in the cases where you have a dedicated consumption line/resources (in some cases, private clouds inclusive). Though, once you have understood the expectations, have drafted the SLAs, you report back using those agreed SLAs – whether or not you are able to deliver.

Now, in any case, it would be bizarre to say I would give away SLAs as am concentrating on Service Expectations. Anyways, dodged SLA reports doesnt highlight Service Expectations more than the need for Business Ethics I would say. For retail business cases, an honest SLA report helps you consolidate current users confidence in your service, and in gaining new business. For bulk business cases, you definitely will have to start with understanding Service Expectations, but SLAs will hold equal importance so you can showcase whether or not you are able to meet those Expectations. Now, there are multiple things that goes out public in those monthly/quarterly/yearly review/reports, and SLAs should definitely be part of it !


Vikas Rajput

%d bloggers like this: