Thursday, August 25, 2011

Interviewing for a BI position

I've found that interviewing for a position in a business intelligence department is an infuriating dance of half truths, hope and plans. Unlike traditional software development or IT, your experience in business intelligence seems far more dependent on the team members and department around you. That's not the interesting statement from this post, that should be self evident. Business intelligence departments concern themselves with bringing IT knowledge onto business's turf. We're not working on traditional (or even extremely quantifiable) technology products, like say, pushing out exchange server because it's better for the enterprise than that old sendmail box. We are embedding ourselves in the business unit we are working for. Discovering their process and supplying them materials to enhance decision making in that process or at times shedding light on inefficiencies in that process.

A big indicator of weather you can achieve that goal is measured in the BI world by the meta-metric 'BI Maturity'. In the past, where I've seen it, BI maturity has been calculated with some things like, turnaround time on projects, size of userbase, or other such numbers. Those metrics don't tell me how easy it will be to work in that department, projects can be short or long and failed, the userbase could be huge but only a minority percentage of the available community, or worse they could be users that never login. Worst of all they don't tell me how effective the department is in the community. Does finance hate the IT department? Does HR think BI is junk? I want to know that! I want to know how easy it will be to work in that department, these rankings of maturity don't really answer the main question that I've got when I'm interviewing for a BI position: "How effective is this department, and how interested are it's customers in analytics?".

So like any data nerd, I came up with my own BI Maturity scale. Rank the company in terms of the following categories (in no real order of importance):

While I'm interviewing I kind of keep a tally of these areas in my head and try to ask some questions to fill out the numbers.
  1. Leadership - The knoledge level and direction of the department/team leaders. The ability of the leadership level to accomplish their stated goals.
    • Possible Questions: 
      • What's the 1 and 5 year direction of BI here? What do you see the team looking like then?
      • How do you pick projects to work on? What is expected from a proposal point of view?
      • Describe a project where the customer wasn't meeting their end of the relationship. What did you do to remedy that project? (Here I'm looking for a leadership level that puts up effective exit points for projects rather than one that say they can save every project. Sometimes the best use of time is to come back later)
      •  What would you like to do that you currently aren't doing? What successful projects needed stewardship and how did that occur?
      • Do you have a system of mentoring?
      • Is there an enterprise mandate for BI or are we off on our own?
      • Are there several smaller BI teams within each department that may be working on their own projects?
      • Describe the roles of users at the university. What BI tools do these roles each use? (analyitics, reports, query, dashboard, etc) What types of people are in these roles?
  2. Staff - The experience and skill level of the staff of the department/team, these would be your direct co workers for a non-leadership position.
    • Possible Questions:
      • Of the senior resources, what are there past experiences on previous successful and unsuccessful projects? (I'm looking for team members with BI specific experience, has your dba done dba tasks for BI specifically? Is your etl developer an etl developer or a transactional programmer that knows sql)
      • What is the ratio of senior (in experience) employees to junior?
      • Who would I get to mentor? Who would be my mentor?
      • Describe the project lifecycle of a previous, successful project, what phases of development occured and what was the engagement like? (Here I am looking for them to describe a mature design, functional requirements gathering, and Testing process. You know, the stuff bad departments skip. I'm looking for them not to say the words 'excel layouts were given to the developer', but that may be asking too much.) 
      • What development methodologies do we practice? What standard tools or processes do we use? Do we use version control? Do we use a robust change management process?
      • Do we manage our own hardware/servers? Can we tune them how we want?
      • What is the restore plan?
  3. Money - Does the department have resources to do BI? Are they struggling to make do with a specific budget.
    • Possible Questions
      • What software do we use? Is there a cordinated, enterprise software purchase plan?
      • How often do team members get new hardware
      • What training or confrences did team members last attend?
      • Do we manage our own purchasing or is it through a central IT structure.
  4. Business Buy-In - What's the excitement/need level of the business users for BI? Are they clamoring for it and have ideas of what they want and pain points to address? Are they going to be engaged fully in the projects?
    • Possible Questions
      • Describe a successful engagement on a prior project from start to finish. How was it proposed, how were requirements gathered, how was it deployed and maintained. (I'm looking for a lot of answers here about how the business is very involved, wants this stuff and is driving a lot of the requirements.)
      • Describe an unsuccessful engagement and how it was mitigated or remedied?
      • What projects are in the pipeline? Is customer demand there?
      • How do they like the software we push out? Are we trying to supplement what they already have or replace something? 
      • How willing are the business users to be involved in the development of their applications. (This is a big one, mature BI departments realize that this has to occur. Resources need to be full time on this thing from both sides through all stages, design, development, testing, support. Non-mature BI departments will look at these applications as deliverables, IT projects that can be built and delivered to a business customer)
      • Can the users develop their own content? Are the willing to? Describe a project where this occurred or is occurring and how that's maintained.
So Simple. What's the scale? I dunno, lets say 10/10 is the highest, but the actual numbers are arbitrary. If you ask questions about the department around these areas you'll end up with a good picture of the effectiveness of the department.

Now, the thing for you to think about is where you want to a work. A less mature BI department may have it's pluses, you might be getting in on the ground floor and build some good practices and clients. A mature department may have it's minuses, everything could be so prossessified that your role would be robotic and limited in scope. (You could end up the framework modeler for specifically the database source layer!)

No comments:

Post a Comment