My recent online column "Making the Case for an Enterprise-Wide Business Intelligence (BI) and Data Warehouse (DW) Capability" (June 2006) highlighted the need for businesses to "get serious" about their approach to handling BI and develop an enterprise BI and DW capability. When pursuing this capability, it is important to adopt a holistic view followed by disciplined investment and execution. To develop the future vision for this capability, you should consider seven interrelated areas:
This column explores the key considerations of the "people" focus area.
Centralize as Much as Possible
In order to start delivering enterprise BI/DW solutions more effectively, it is advantageous to have as many of the players that are planning, architecting, designing, developing and supporting the solutions working together on the same team. This group can:
- Focus on the discipline of BI/DW exclusively, without getting distracted with other IT solution types.
- Focus on developing strong capabilities in the chosen BI/DW technologies and practices through training, hiring or appropriate outside help.
- Balance the project assignments to make the most efficient use of these people through project lifecycles.
Partner Closely with Business Customers
Centralizing BI/DW development resources does not mean the group is isolated from the business. On the contrary, subject matter experts from the business should be an integral part of the project teams. These people must be engaged in defining the requirements, defining and executing user test cases and in conducting end-user training.
It should also be the goal of an Enterprise BI/DW program to enable business end users to "serve themselves," creating new reports and views as needed to support changing business needs on top of the consistent, reliable, stable BI/DW data and technology foundation provided by the centralized BI team. In this way, end users will actually be developers for much of the BI application user interface layer.
It is important to find a balance between the appropriate "states rights" versus "federal rights" for your company. Think of it as a balance; otherwise either dictatorship or anarchy will ensue.
Additionally, it is highly recommended to create a cross-functional advisory council of key business leaders to work with the BI team leadership ensure team activities align with business priorities.
Reserve Key Players for Cross Project Leadership
Because you are building lasting BI and DW solutions, you will want to ensure consistency from project to project. Creating a small team of some of your most experienced people, separate from the actual development project teams, is a good way to provide this consistency.
Sometimes, this team is called: competency center, capability center, foundation team, center of excellence or innovation center. The name is irrelevant, but its tasks are vital. This team should have people assigned to these roles and activities focused on:
- Program Management: Defining project methodology standards and coordinating processes related to managing the execution of projects.
- Data Architecture: Defining and enforcing standards related to data warehouse and data mart data and extract, transform and load (ETL) architecture.
- Technical Architecture: Defining and enforcing standards related to use of the BI development tools (such as reporting and OLAP tools).
- Business Data Definitions: Defining and enforcing standard business definitions of metrics and dimensions.
- BI Strategy and Planning: Working with business and IT leaders to define, estimate and schedule future projects, maintaining the multiyear plan.
Organize for Effective Project Delivery
If your "BI machine" is working properly, the majority of the BI/DW team members will spend their time developing new BI applications or adding more data to the enterprise data warehouse (EDW). These people should handle a set of standard roles regardless of project activities. Typical roles on BI/DW projects are: project managers, business analysts, data modelers, ETL leads and developers, OLAP leads and developers, and reporting leads and developers. Clearly defining these roles and their responsibilities will help guarantee a certain consistency and quality as they move from project to project. The more these roles are clearly defined and consistent, the more likely you will be able to take advantage of lower cost staffing strategies, such as utilizing offshore developers in these roles.
The people creating the BI applications should be on the same organizational team as the people creating the EDW. I have heard different opinions on this topic, but I strongly believe there are too many coordination points between these efforts to do otherwise. In some cases when organizing specific project teams, you'll want to have the people adding data to the EDW be on the same project team as the people creating the BI application. My rule of thumb - if the data being loaded into the EDW is nearly 100 percent aligned with one BI application, do these two things as part of one project team. If the EDW data is being used by multiple BI applications, it makes more sense to create separate project teams and manage the dependencies.
Organize for Support
In order to continue to make progress on new BI/DW development, you will want to reserve some people for user and application support. These people can be focused on keeping the existing solutions running, allowing others to focus on new development. While some people enjoy this role, others do not. One way to avoid burnout in a support role is to make support like any other project assignment - all team members take on the role on a rotating schedule.
People are Important
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access