BI Organization & Staffing

Last week I had the opportunity to spend some time with a leading management consultant discussing staffing and organization for a business intelligence practice. We covered a lot of ground around process, roles, maturity and organizational evolution. At one point in the conversation this well-respected individual started to talk crazy. “OK, now I’m going to say something that’s going to make you roll your eyes back in your head — your IT department isn’t part of your BI team.” To which I responded (since we were on a con call), “OK, I’m rolling my eyes!” Folks started to laugh and then another member of our team sounded off, “Barry probably feels like that about the data warehouse team A LOT!” There was more laughter and the clock on the conversation ran out. We hung up, but that last comment stayed with me festering. Now at this point I have to say that we have an awesome technical team including the data folks. They are dedicated, talented, and hardworking. So why doesn’t this guy consider them a part of the BI Team?Now I’m one of those people that can’t let this kind of thing just go. I found myself digging into the BOK (body of knowledge) on the subject, doodling notes at odd times and generally obsessing. I’m sure you’ve met someone like me. The guy who concentrates so hard that he doesn’t notice you’re there for a few minutes and then when he (I) finally looks over you can tell they haven’t quite made it back to planet Earth yet. That’s me. (I really do care, but give me a minute.) What I found is that a lot of the material is focused on the concept of the BICC and BICOE, BI Competency Centers and BI Centers of Excellence. A common diagram you’ll see is a Venn diagram where the BICC is at the center of an intersection of strategy, community and technology. Another is the many variations of the ’stack’. In this case you have the BI capabilities and processes represented as a series of bricks on either side of biz process - foundational things like data, decision support and analytical applications on the bottom and process management and business activity monitoring on the top. To one side of the brick you’ll see the BICC represented as a combination of IT and business resources supporting the integrated heap. I believe one of the reasons I think about things so intensely is that it takes a while for me to get it. It turns out that both of these are useful and merit attention, but they didn’t get me closer to understanding why my technically proficient friends didn’t get picked for the team. What finally got me there was creating a map of our BI capabilities to the technical roles it required to support. It looked something like this for two pieces of our BI stack:

  • Data Warehouse
    - Data Architect
    - Database Administrator
    - Server Administrator
    - ETL Developer
  • Ad Hoc Query Analysis and Dashboard
    - System Administrator
    - Report/Dashboard Developer
    - Help Desk Technician

At this point things became clearer and if you go through that exercise at some point you’ll find yourself digging out your copy of Bossidy and paging through “Competing on Analytics”. In the slowly turning wheels in my head I recognized that the roles above represent the work related to the care and feeding of BI infrastructure which is necessary and important, but it isn’t where the money is at. My hunch was that the organizational relationships represented by the pretty diagrams consultants use would be related back to the the analysis and action that must be driven by the suits and ties. What happened next was a lot of fun. I mapped out what I believe are the organizational and process best practices on the information-to-knowledge and knowledge-to-profitable-action side of the BI equation. I took this to our team that would participate in the next con call and shared it with them THEN we finished the conversation. The well- respected expert (who really is very good) answered pretty much as expected, but pointed out one pretty significant opportunity for us. When the dust settled and we reviewed the notes there was still a gap and its interesting. It was in the space of technical innovation and evolution. My notes called for the integration of the traditional BI roles with our application development and production support teams and a distinct technical team to support the growth of a fact-based business culture.With a little work you can get to what I did so before boring the world (OK the two other people who read this blog) please let me know if you want to post that information. Otherwise, I’ll move on to something else for next week’s post.

Tags: , , , , ,

4 Responses to “BI Organization & Staffing”

  1. kjdean Says:

    This is very interesting I would like to read more. I both agree and disagree. I think there needs to be a convergence of IT and the Business.

  2. b5nowak Says:

    Kevin,

    I agree. It’s like you’ve read my mind! You’ll what I see when I get back to blogging about this! That will have to wait though because I have a need to write about the coolest thing I’ve seen in twenty years.

    b5

  3. Marc Jellinek Says:

    Like any other technical effort, devil is always in the details. That means along with your Domain Experts, Business Users/Information Consumers, Business Strategists, etc, you need to take care of the daily care-and-feeding of your BI infrastructure.

    That means project manager(s) to keep everything moving on time, data steward to make sure there isn’t garbage going in, change management (because things are going to change), quality assurance (because if you can’t trust the data, you can’t trust the information, the knowledge, the action)

    Having IT as part of your BI Team is like having your mechanic as a part of your family. You are trusting your mechanic with the maintenance of a significant financial investment and the safety of yourself and your family, and is a part of the platform upon which many other activities are based(commute to work, bring the kids to soccer, go food shopping).

    The simple truth is that BI (and IT in general) is not as robust as your vehicle. I know I’ve gone more than 3000 miles between oil changes without major damage. Try going more than 3 months without a quality review of the data being fed into your data warehouse/data mart.

    Want a failed BI implementation? Then have the BI infrastructure fail to adjust to changes in the business strategy (and attendant KPIs), changes in data feeds (see quality issues above) and changes in business personnel (because if people coming into the business can’t get at the data/information/knowledge, they can’t benefit from it).

  4. b5nowak Says:

    Marc,

    I couldn’t agree with you more. I think building a successful BI program needs to incorporate the ability for the technical pieces of the program to change and adapt as the business evolves. Recognizing and building continuous persistent governance process so that as the business changes the data and infrastructure changes with it is mandatory for a successful strategic BI program. I believe that this fundamentally needs to be a business driven and business lead process or the implementation will fail.

    You really made a lot of great points.

    Thanks for posting!

Leave a Reply