To BICC Or Not To BICC (Part 2)

In my last post, I opened up some of my thoughts about how much BICC activity is happening in the real world.  Continuing on from there, I'm now going to turn my attention to some of the important things that I think need to be addressed in the management of BI (whether under a BICC umbrella or not).

BI Strategy

The starting point for any non-tactical BI initiative should be the development of a BI strategy map.  And it’s worth noting that this statement holds, regardless of the circumstance...whether a greenfield project, a migration to a new, pre-selected technology stack or where heritage applications are remaining in place.  That’s to say - the BI Strategy should be technology agnostic, not technology driven.  The form that your strategy takes is likely to be heavily influenced by the type of BI organisation that is planned or already in place.  Where a full-blown BICC is being built, then it is likely that the strategy will be a more formal mission statement.  Where something more subtle is being planned (say, a sub-team within an existing department), then we may be talking about some slide-ware which is used to disseminate the message.

Regardless of form, the BI Strategy should be all about laying down the foundations for:

➡  How information will be utilised by the business to drive competitive advantage

➡  How the business is going to make best use of its information and technology resources

➡  What ‘genetic makeup’ the BICC will have (i.e. will it be business driven, IT driven or, most realistically, blended?)

➡  How the BICC is going to enable the business to leverage maximum value from the investments made in BI

➡  How strategic delivery will be resourced (internally, externally or blended)

Clearly, the BI Strategy must be aligned with the organisations wider strategic objectives and it will often help in communicating the message, if a) a high level vision of the delivery roadmap and b) the BICC’s roles and responsibilities can also be developed at this stage.

Information Delivery

The second thing to be recognised is the importance of delivering information in a consistent, coherent and accurate way.  To me, this is central in building the business’ confidence in the BI they use.  Confidence will increase usage which will result in reliance and then dependency.  So, ultimately, ‘information delivery’ will factor heavily in the success or failure of the BICC itself.  Unfortunately, it is also probably the trickiest thing for the BICC to achieve.  And here’s why.

Under the ‘Information Delivery’ umbrella I would group the following activities:  Solution & Data Architecture; Data Quality Management; Data Stewardship; Metadata Management; Presentation & User Experience.  In a nutshell, then, this is where the BICC gets its most technical and so (if predominantly a business lead team) it is where the BICC will be least knowledgeable and least self-sufficient.  This is why the ‘genetic makeup’ of the BICC, as I have described it previously, is so important.  It also seems to be the area of most debate....should the BICC be 100% business focussed?  Should it be an extension of the IT department?  Should it be a blend and, if so, what is the balance of power?  The answer will inevitably vary from organisation to organisation (and, again, there is probably no “one size fits all” answer), but my view aligns with the consensus - that a BICC should be a blended team, but business lead.  As a minimum, senior people to represent solution and data architecture should be incorporated (unless you are lucky enough to have someone who can do both!). Such a composition should help to ‘sell’ the BICC at senior levels, smooth its inception and also ensure that the right architectural decisions are made along the way.  As vendor solutions and product portfolio’s continue to grow, the number of ways of ‘skinning the cat’ can increase exponentially.  A bad ‘technology’ decision could constrain future opportunities, whilst a decision based purely on the commercials will likely result in the same outcome.  Decisions in BI, therefore need to be balanced and require the representation of both business and technology expertise.

Data architecture is essential in the information delivery equation.  A data warehouse with missing data will not be capable of supporting user requirements.  Even where there is built in latency to allow for those unexpected requests, if the data warehouse is poorly modeled your users will be equally constrained and frustrated.  The same is true of your metadata design - build your semantic layer to support the reporting requirements alone and your users will not be able to easily fulfill their ad-hoc analyses.  DW and Metadata design need to go hand in hand and, if not, will result in an increased overhead for IT and BICC respectively.  Data quality is important in protecting the integrity of the information being consumed and user experience will have a large say in how comfortable the user community feel about actually using the BI.

Putting all this together makes ‘Information Delivery’ certainly the most tangible and probably the most complex aspect of the BICC’s remit.

Next time, I’ll look at some of the less tangible aspects, maintaining some level of control and generating passion for information.