In my vast experience as a BI and data integration consultant … (Okay now is when you think to yourself, “Wait, she looks pretty young, so how vast is it really? I mean, she can’t be more than 32 or 33…”) Anyway, as I was saying, in my vast experience I’ve noticed a few consistent truisms. The one I’ll share with you today is that people like the “people stuff.”

That’s right. When faced with a choice of “What,” “How,” “Why,” or “Who?” people invariably opt for the “who.” Before you can get the words “data stewardship” out of your mouth, someone is asking, “Well, who should do that?” It’s as if team members are so many pieces on a chessboard and by moving them around you can solve the company’s problems. When managers are tentative about how to move forward, they go with what they know: the people stuff.

Like everyone else, I’ve read “Good to Great” and have taken the “get the right people on the bus” maxim to heart. You can’t do what you need to do, and you can’t do it effectively, without smart, productive, creative workers. But the question remains: what do you need to do?

We see this a lot when we’re asked to design BI Competency Centers (a.k.a.: BICCs, a.k.a.: BI Centers of Excellence). Our clients want us to draft up new roles, introduce new titles, assess incumbent skills, develop training plans, and create hiring guidelines. Last year we even collaborated with a bank’s HR department to determine new KPIs for members of the new BICC team.

But BICC design involves more than just a bunch of smart people delivering reports. At least it should. Here are some other components of a BICC:

  • An intake process: How do new requests for BI help get vetted? What does the vetting process look like, and how do you communicate that to your vast (yes, that word again) community of BI constituents?
  • A prioritization process: How are new requests prioritized relative to other incoming requests? What are the metrics? How are they weighted?
  • Pipeline management: How is the BI development pipeline managed? What are the steps? Does the existing SDLC support business-driven requests? Are there SLAs?
  • Development hand-offs: How does a new requirement get translated from initial vetting and scoping and make it to developers?
  • Approval and escalation policies: Are there sanctioned ways of getting approval or exceptions for certain units of work? Say someone wants a simple report built, but then a higher-level executive requests a data extract? How are exceptions handled? What about a tiebreaking process?

There are others, but you get my point. Yes, there are “who” conversations tied to each one of these. But you shouldn’t start with the “who” until you know the “what” and the “why.” Moreover you really can’t adequately qualify the right “whos” until you understand the “hows.”
If your consultant or internal specialist starts a BICC conversation with an org chart, run. Run across the vast plane of asphalt that is your building’s parking lot, and drive across the vast geographical expanse that is the space between your company and its biggest competitor. And then get a job where you can practice your vast talents with a company that truly deserves them.