During a recent project review of an upcoming Enterprise BI / DW platform, one of the project tasks’s was to do an end to end tool selection. However, beyond technology the other aspects of a successful BI program necessary including people, process and data (ownership) were not properly being assessed.  The needs to properly assess and manage these areas would outlast any particular phase/sprint of development and would have an even greater impact than the technology.  With a brand new large BI program there will need to be new processes and new teams created in IT to make the current software in order to be effective in this program (note: projects end, programs evolve and change with the business, so BI/DW programs should be built and staffed that way from day 1)

What was missing in the evaluation is the desired impact in the IT culture.  All of the solutions involved in the evaluation would demand a high level of experience, technical knowledge and creativity during the design and development in order to make it a success.  While the technical evaluations were sound, I wanted to see that there had been consideration of other non-technical aspects of a Data warehouse necessary to make the program and systems a success.

Questions arose that needed to be answered

– Is the expectation that business users will be connecting with Vendor support directly?

– who is responsible for “quality” resource acquisition

– Who is responsible for help desk models to support Business Rules, Data Miniing , etc

– Who is responsible for ensuring that the quality of the data is kept intact over time from a technical architecture as the business change over time?

– Who is responsible for ensuring that the knowledge of business rules are kept as assets?  An enterprise data warehouse/ BI system is a huge investment and that investment should be protected as an asset of the company.

No matter what tool is chosen there are huge drains to a project, in time and quality, when users need to make business rule and solution design decisions on the fly.  This includes the creation of new business metrics, new reporting processes and mini-tool selections as new requests come up. (i.e. the users uses the excel export so they can recalculate a metric because the data warehouse team takes 3 weeks to get a change in place).

One of the best practices to balance the projects technical needs with the people and processes is to establish a Business Intelligence competency group at the outset of the project that sits outside of any software or services vendor and has staffed BI/DW architects to can “rapidly” respond to the changing needs of the business with the “correct” solution and the ability to pull in the correct IT resources to meet that need at the speed the business needs before they feel the need to go out on their own.