Business intelligence sponsorship

There are many ways which you can become the sponsor of a business intelligence (BI) project. You could have inherited this role from a predecessor. You could have been appointed to fill the position. You could have been nominated or "volunteered" as the sponsor of the BI programme by not necessarily well-meaning peers, or... you may have grabbed the BI sponsorship role to increase your domain and power base. The big question is - do you really know what is expected of your position?

This article explains some fundamental principles each sponsor of a BI project or programme should be aware of.

In many tightly competing industries, information is the only differentiator over your opposition. You are now part of an elite core in the organisation that has to drive for the full-blown management of data and information as an organisational resource. Information has to be managed throughout the organisation with the same drive, vigour and rigor as finances, products, human resources and assets.

Can you imagine the wealth of information you would have if your organisation`s information was managed as well as its finances or its human resources? A scary thought - can you imagine how bad it would be if the company`s finances were mismanaged like its information is currently?

You have to have a thorough understanding of the extent to which information must be managed, as well as the frameworks, approaches and technologies to be used to do this.

One of the biggest stumbling blocks in the BI field is politics; intra-company politics and inter-departmental politics. As a BI project sponsor, you are first and foremost a politician. But as many politicians have had to learn - your own success is directly linked to the party`s success. You have to drive for the party`s goals and agendas, even if you don`t always agree 100% with them.

The most valuable and profitable strategic business initiatives require data integrated across diverse business functions - ie they require a breakdown of the departmental information silos. The most effective data warehouse programs might start small, but they all become increasingly more cross-functional and enterprise-wide over time. As a recent Forrester report puts it: "Organisations that manage customer relationships from within channel and functional stovepipes can`t deliver the consistent experience that`s expected by their customers."

Whether you like it or not, you are now playing a leading role in the "one enterprise data warehouse" party. If you want success - and thereafter comes recognition - push for the success of the party!

Like any big and extensive building, no business intelligence initiative can succeed without being based on a well thought-out and 100% applicable architecture. The trick of architecture in the BI world is that it doesn`t have to be big and bold - rather, it has to be appropriate, fit the company`s culture and be cost-effective.

BI architecture covers many areas, from infrastructure to data to applications, even methodologies and resource skills. Make sure that the plans and the blueprints are in place and in order before any building can begin.

One of the key components of a BI architecture is software. So many BI projects become problematic, because they are run using inferior or inappropriate software products - often because of too good product salesmen, but also because internal company politics prohibit the selection and acquisition of the appropriate software. While a poor craftsman may blame his tools, in the BI world, tool selection and configuration is part of the architect`s responsibility.

The other key component is appropriate data architecture. How data is modelled, stored and moved through the architecture is more important than the storage and flow of fresh water through a hospital. Allow your architects the time and energy to go through the Inmon vs Kimball approach debates - in many organisations a hybrid approach may be appropriate. The key is to allow the architects to pin down the principles first and then flesh out the architecture within that framework. Only a well-thought-through and well-designed data model allows the flexibility, subsequent tuning and sharing of common data across business units, applications and technological implementations.

As a BI sponsor, make sure that you understand what BI architecture entails, why it is so important and ensure that you have architects that can analyse, design, select, develop and put the appropriate framework, architecture and detailed components in place.

A key concept to get to grips with - especially from the viewpoint of the BI sponsor - is that the BI programme is exactly that: a programme, not a project. BI is not just another IT development activity. BI programs follow a very specific methodology, which has to tie in very closely with the business objectives of the entire organisation and also with the whole architecture framework. As a result, the BI competency consists of a set of very specific skills managed as a portfolio of capabilities that get employed in various roles as the programme iterates through its various short-iteration cycles, with new data and functionality delivered every three to four months.

From a business unit perspective these may seem as independent projects, but from IT and the sponsors` viewpoints the dependencies and interrelationships between these sub-projects have to be managed and exploited to maximise the long-term benefit and ROI that BI can deliver to the enterprise as a whole (as apposed to the short-term benefit to the business units).

As a BI sponsor, you need to understand this approach and the underlying implementation methodology, promote it (and work with the other BI sponsors, if there are any, as a united front) to guide the programme and balance its priorities in an attempt to firstly satisfy the organisation`s objectives and secondly the business unit`s objectives.

Data quality is one of the aspects of the BI programme that requires particular attention. A lot of data cleansing and scrubbing operations can be applied in the BI space (for example in the ETL processes) to address data quality problems, but at the end of the day, these only address the symptoms, and not the cause. The cause of data quality problems is usually in the operational source systems, and that is where the data quality has to be fixed. However, this requires a strategic thinking culture, who buys into this concept and who supports it full circle from the operational systems to the data warehouse and back again. The data warehouse QA staff, or the downstream business users of the information usually detect the data quality problems, as they work intimately with the data. The problem is that they usually have no control or influence over the source system owners.

This is where the business sponsor can play a major role. As a major force in the organisation, the BI sponsor can influence the business owners of the source systems to take ownership of their data quality problems and the effect these problems have on the profitability and predictability of the organisation. The sponsor has to get the source system owners to take full responsibility of the quality of the data they provide to the BI programme.

As with data quality, there are many facets of data and information management that has to be promoted way above the scope of control of the BI programme. These include BI enablement of transactional source systems, governance around the single data warehouse, its architecture and system components, data models and allowed information flow, information usage (including the controversial "licence to drive" certification required before access to the data is allowed) and metadata compliance from source systems through the BI process through to information exploitation and dissemination.

Whereas it is the BI architects` responsibility to define these governances, they are usually not empowered enough to put them in practice - as many of these affect the upstream source systems and their owners and the downstream information users. However, the sponsor should be at a high enough position in the organisation to have the clout and influence to have these governances accepted, implemented and enforced throughout the organisation.

As a strategic-level information officer, the sponsor of BI projects or the BI programme is an information custodian, a politician, a businessman, a treasurer, a quality controller and a business-IT team-player, all rolled into one, and as such, you should know your subject area very well! Just like any politician, you can be asked any question at any time about the party`s policies, and that is not the time to run off to find out how it works.

As a result, a BI sponsor should have a vision of how BI can improve the business, should have the authority to make it happen, should have the budget available to spend on BI development, the accountability to other executives, the ability to "up-sell" BI, and most of all, commitment to the programme.

There is saying in the BI world that "he who owns the applications, gets the glory..." which is true. The business users, and through that, the business sponsor, that achieve the benefits of downstream information exploitation get much more glory than the architects and technicians that put the whole solution together. However, before the glory comes a massive commitment and responsibility, which cannot be driven after without in-depth knowledge and understanding.