1. Program / Project Planning and Management

1. Assessing Rediness
   1. to have a strong executive business sponsor
   2. having a strong, compelling business motivation for tackling the DW/BI initiative
2. Scoping and Justification
3. Staffing (Business sponsor, Business driver, Business lead, Business users)
4. Developing and Maintaining the Plan

2. Business Requirements Definition

2.1. Requirements Preplanning

1. Choose the Forum
2. Identify and Prepare the Requirements Team
3. Select, Schedule, and Prepare Business Representatives

2.2. Collecting Business Requirements

1. Launch
2. Interview Flow
3. Wrap-Up

2.3. Conducting Data-Centric Interviews

2.4. Documenting Requirements

2.5. Prioritizing Requirements

3. Technical Architecture Design

3.1 Establish an Architecture Task Force

3.2 Collect Architecture-Related Requirements

3.3 Document Architecture Requirements

3.4 Create the Architecture Model

3.5 Determine Architecture Implementation Phases

3.6 Design and Specify the Subsystems

3.7 Create the Architecture Plan

3.8 Review and Finalize the Technical Architecture

4. Product Selection and Installation

4.1 Understand the Corporate Purchasing Process

4.2 Develop a Product Evaluation Matrix

4.3 Conduct Market Research

4.4 Evaluate a Short List of Options

4.5 If Necessary, Conduct a Prototype

4.6 Select Product, Install on Trial, and Negotiate

5. Dimensional Modeling

6. Physical Design

6.1 Develop Naming and Database Standards

6.2 Develop Physical Database Model

6.3 Develop Initial Index Plan

6.4 Design Aggregations, Including OLAP Database

6.5 Finalize Physical Storage Details

7. ETL Design and Development

8. BI Application Specification

9. BI Application Development

10. Deployment

11. Maintenance and Growth

Common Pitfalls to Avoid

Although we can provide positive recommendations about data warehousing and business intelligence, some readers better relate to a listing of common pitfalls. Here is our favorite top 10 list of common errors to avoid while building a DW/ BI system. These are all quite lethal errors—one alone may be suffi cient to bring down the initiative:

■ Pitfall 10: Become overly enamored with technology and data rather than focusing on the business’s requirements and goals.

■ Pitfall 9: Fail to embrace or recruit an infl uential, accessible, and reasonable senior management visionary as the business sponsor of the DW/BI eff ort.

■ Pitfall 8: Tackle a galactic multiyear project rather than pursuing more manageable, although still compelling, iterative development eff orts.

■ Pitfall 7: Allocate energy to construct a normalized data structure, yet run out of budget before building a viable presentation area based on dimensional models.

■ Pitfall 6: Pay more attention to back room operational performance and easeof- development than to front room query performance and ease of use.

■ Pitfall 5: Make the supposedly queryable data in the presentation area overly complex. Database designers who prefer a more complex presentation should spend a year supporting business users; they’d develop a much better appreciation for the need to seek simpler solutions.

■ Pitfall 4: Populate dimensional models on a standalone basis without regard to a data architecture that ties them together using shared, conformed dimensions.

■ Pitfall 3: Load only summarized data into the presentation area’s dimensional structures.

■ Pitfall 2: Presume the business, its requirements and analytics, and the underlying data and the supporting technology are static.

■ Pitfall 1: Neglect to acknowledge that DW/BI success is tied directly to business acceptance. If the users haven’t accepted the DW/BI system as a foundation for improved decision making, your eff orts have been exercises in futility.