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

Change Management: Project Release Numbering

In a previous post I said I'd post something about my numbering scheme for release candidates. If you recall from the previous post, a release candidate is the set of code that will be moved from development to a higher environment. They are complete enough that by packaging and releasing them we are saying 'this set of items can move into production'. This is the key to change management in these environments. If you are working in an Agile environment you may have a release every iteration, if not you may be releasing things more infrequently than that. This system is meant to be simple and fit with the change management process defined in the earlier post.

Any version numbering scheme should be developed to fit your change management process. An initial version of a project will be Version 1. Changes after that are tracked using our numbering system below. A change will increment either the major or minor revision number (very loosely and very purposefully defined as 'depending on the impact of that change') as follows;

• A Version Number is incremented when a project is wholly changed or rebuilt.
• A major change to a version will increment the Major Revision Number.
• A minor change to a version will increment the Minor Revision Number.
• A Patch can be applied if a change to an existing version is required (rather than a rebuild and increment). Additional patches increment the Patch Number.

Any specific release can be recreated by starting with that version's code sequentially applying all patches.

*Note, In my environment I don't need release things to users before they are production ready. If you you wish to denote that something being released to customers is in a pre-production state, I would call that a version 0, use the numbering scheme above for changes to that product and attach a greek alphabet prefix (Alpha, Beta, etc) to each release version in this pre production state.

See Also:

• Agile BI - Ralph Hughes

Do you do mentoring in your BI department?

I came across an interesting article on types of mentorship in this twitter post:

Keeping Great People with Three Kinds of Mentors - Anthony Tjan - Harvard Business Review: http://t.co/PbQv3bg via @AddThisless than a minute ago via Tweet Button Favorite Retweet ReplyIan Di Tullio
ianditullio

Do you do mentoring in BI? I am very much in favor of mentoring. The secondary point of this article is almost more interesting to me,

One of the most critical elements in retaining great people is effective mentoring. 

The community of BI developers is small, and the community of great BI developers is even smaller. If you come across one, hire them or work for them! Mentoring can be a great retention method for talented employees. Simply put, good people want to work for more experienced good people.

See Also:

•  Keeping Great People with Three Kinds of Mentors

Back from Tufte

I spent the day yesterday attending Dr. Edward Tufte's excellent course/seminar/inspirational speech "Presenting Data and Information". Attend this course if you get a chance.

Making a presentation is a moral act as well as an ethical and intellectual act.

You'd do well to remember that as a BI developer. EVERYTHING you develop is a presentation. A report, a database table, a fancy dashboard, are all presentations and all tell a story. They become an attempt at concert between what you built (the system), and the user. Now that we've elevated reporting to a moral level, Dr. Tufte urges us to address the content ('do whatever it takes to show the content') with the moral weight of the previous statement. Therefore,

The presentation stands and falls on the quality, relevance, and integrity of the content.

Dr. Tufte is an engaging speaker and I came away with pages of quotes and notes to share. But it seems the blogosphere has done it already (also it seems this course hasn't changed much in a year), check out this post for most of the gems I wrote down during this course. So I can quote ET quoting TS Elliott, "Talent imitates, but genius steals".

A day with edward Tufte

Tufte Design Principals