TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Running a BI Organization in 2016 (Part 2 of 2)

How your team can determine which BI projects to support and what development is needed.

• By William McKnight
• April 12, 2016

In Part 1, I talked about creating a charter for the BI organization that includes the breadth served within the organization and suggested there could be several BI teams in the entire organization.

In this part, I will review the other charter dimensions of determining which projects are BI projects that you support and determining what development steps you do and what are done by others and in partnership with others.

All company projects are BI projects at some level because projects are now wrapped around the analytics capabilities of the organization. However, the working definition we need here has to do with which projects we are going to be involved with. BI is not a discrete application. It is an aspect of many applications, and having organizations dedicated to this slice of those applications is efficient and continually answering the question "Why should we continue to have a centralized BI versus just allowing what would happen otherwise?"

I have said many times that BI queries, basic reports, dashboard tweaks, etc. should be self-service and not come under production change control and be subject to a "path to production." Even projects that utilize an important structure for BI, such as the data warehouse, should be unencumbered as well. It's when they need to change or build those structures (and their data of course) that BI teams need to be involved.

Usage patterns for the data that needs development, even when not changing structure or data, also could fall under BI projects.

Clearly, whatever projects that were supported in development need to be supported in production for change control. This leads us to our last leg of the stool for establishing the charter and that is what part of the BI life cycle your organization does for the accepted projects.

Although many organizations are using an agile approach to BI development, there are still steps to take. For orientation to the kinds of things I'm talking about, I'll use the Atre-Moss Business Intelligence Roadmap. It defines the steps as Business Case Assessment, Enterprise Infrastructure Evaluation (technical and nontechnical), Project Planning, Project Requirements Definition, Data Analysis, Application Prototyping, Meta Data Repository Analysis, Database Design, ETL Design, Meta Data Repository Design, ETL Development, Application Development, Data Mining, Meta Data Repository Development, and Implementation Release Evaluation. Although these steps cannot be skipped in any reasonable methodology, they can clearly be executed today by multiple teams.

The last big question that needs answered to establish your BI organization charter is "What steps do we do?" I suggest being involved in all. However, some of the early and late steps are best suited to the business area and the production area, respectively. Just make sure they know this and that the functions are covered well. The project life cycle is only as good as its weakest link and certainly the BI team will be implicated if something goes off the rails in steps assigned to others.

The charter for your business intelligence group, comprised of which parts of the organization, which projects, and which steps in those projects you serve, will bring clarity. It will bring focus to the team and their objectives. It may very well influence that long list of tasks you have to complete.