Chapter 2 Business Case and Project Management

Leadership is attending to conditions that would keep growth from happening.

Peter Senge

Project management skills are essential to successful data warehousing and business intelligence efforts. Putting together the right people, process and technology is critical.

In Chapter 1, you were introduced to Data Warehousing and Business Intelligence. You saw that great benefits can be gained through use of data warehousing and business intelligence. Organizations such as 3M, Nike Shoes and The Olive Garden are great examples to aspire to.

In this chapter, you will learn about the management of successful data warehousing / business intelligence projects. The chapter is organized in two sections:

•   Developing the Business Case

•   Data Warehouse Project Management.

Data warehouse and business intelligence projects are not just about creating a new data warehouse or data mart from scratch. Increasingly, organizations have an existing data warehouse in place and need to improve or extend it. The following are the types of projects that may be undertaken:

•   Conducting a pilot or proof of concept

•   Creating a new data warehouse or data mart

•   Adding new data to an existing data warehouse or data mart

•   Creating new outputs from an existing data mart – dashboards, scorecards, reports, data mining analysis, etc.

•   Consolidating or partitioning data marts

•   Providing reporting and/or BI as part of a larger project

•   Improving performance of existing data warehouses or data marts

•   Correcting data problems in existing data warehouses or data marts.

Six Steps to Developing the Business Case

Data Warehousing Business Intelligence (DWBI) requires an investment before benefits are returned. To start or improve a DWBI program, it is essential that the business case being presented to executive management, show that the DWBI program will provide benefits that exceed costs. In this chapter, you will learn how to develop a Business Case (BC) document and presentation that shows that the program is worth investing in.

A Business Case, also known as Cost Benefit Analysis (CBA), is built using the steps described in Figure 02-01, Business Case Steps. By following these steps and using the templates downloadable from the book's website, you will be on your way to preparing and presenting the case for implementing or improving DWBI.

Figure 02-01: Business Case Steps

BC Step 1.0 – Initiate Business Case

Initiating the Business Case includes forming a cross functional team, setting objectives for the business case, and determining the scope of the business case. These deliverables are produced:

•   BC Objectives

•   BC Scope Statement.

Scope identifies the boundaries of an effort: which subjects are inside and outside the boundaries of the DWBI initiative. Certainly, data that does not support decision-making will be excluded. For example, see Table 02-01, Data Warehousing Business Intelligence Scope.

Table 02-01: Data Warehousing Business Intelligence Scope Example

In Scope	Out of Scope
1.       Shared Data 2.       Account 3.       Asset 4.       Codes 5.       Customer 6.       Employee 7.       Pricing 8.       Product Identifiers	1.       Operational details 2.       Regulatory Data 3.       Supplier 4.       Product Details

Controlling scope is a way to reduce the risk that the effort will spiral out of control and become a “runaway project.” The executives to whom you present the business case are likely to ask penetrating questions to ensure that the effort is a success. Scope items can include:

•   Analysis Subjects – what topics are included: product shipments, customer complaints, hotel reservations?

•   Organization Scope – is this a department, business unit, or enterprise effort?

•   Level of Effort – is a new data warehouse being created or is this a specific extension to an existing system?

After the Business Case is accepted the scope will be further refined. The section of this chapter titled “Defining Scope and Objectives” provides details.

BC Step 2.0 – Analyze Current Approach

After initiating the business case, the next step is to examine the Current Approach to the analytics that support decision-making. Quantification is important, so this includes an analysis of the financial impact of the current approach and a projection of that impact into the future.

A template that will help you to develop the business case is available on the companion website for this book. It includes a section for specifying the costs and benefits of the Current Approach.

The Current Approach is a description of the way the ‘world’ is now and is likely to be if changes to the Current Approach are not made. This includes: costs and benefits, people and organizations, as well as data and systems. The Current Approach can be described through multiple means including:

•   Narratives

•   Cost / Benefit Spreadsheets

•   Context Diagrams that show the inputs and outputs of the Current Approach

•   Business Process Diagrams that show the steps used to acquire and analyze data.

Outputs include current costs and benefits such those as described in Table 02-02. The costs and benefits of the current state are then projected into the future.

Table 02-02: Current Costs and Benefits

Current Costs	•   Analyst time to acquire and manipulate data •   Rework cost due to poor quality data •   Fines and penalties due to late or unavailable data •   Cost of lost business due to dissatisfied customers •   Problem counts (returns, cancellations, warranty claims, drop outs, repeat crimes, medical errors, law suits, etc.) •   Hardware costs •   Software costs •   IT people support costs
Current Benefits	•   Revenue by product, market, channel, etc. •   Rate of output (cases analyzed, products created, sales campaigns planned, etc.)
Current Outcomes	•   Customer satisfaction level measured by Net Promoter Score (NPS)

Dig into the numbers and gain a thorough understanding of the metrics that describe how your organization achieves results. This includes financial and metrics such as:

•   Number of workers performing an activity

•   Number of units processed

•   Cycle time per unit of work

•   Compensation rates

•   Software license costs.

BC Step 3.0 – Analyze Alternative Approaches

The third step is to generate ideas for alternate approaches and next examine those approaches, including a financial impact analysis. This analysis includes a projection of cost scenarios with both direct and indirect costs and benefits. The output of this step is compared to the output of BC Step 2:

•   Future cost scenario component of BC

•   Future benefit view of each alternative approach.

The Future Approach is a description of the way one wants the world to be. In the current state, this includes costs and benefits, people and organizations, as well as data and systems. In the future world, it is likely that benefits will be higher than in the current state and that those benefits will exceed the costs.

DWBI provides many benefits that can be included in the Business Case. Evaluate which DWBI benefits are applicable to your organization, such as:

1.       Avoiding the costs and risks of not using DWBI

2.       Improved communication inside and outside the organization based on shared information and definitions

3.       Improved risk management by understanding risk root causes

4.       Accelerated time to market by rapidly identifying opportunities

5.       Increased sales by improving product offerings

6.       Increased sales by improving campaign effectiveness

7.       Decision-making supported by providing a consistent basis of comparison

8.       Improved customer relationships by identifying customer needs

9.       Improved customer retention through ‘stickiness’. The customer sees a unified view of accounts and services, making it less likely that the customer will leave.

10.   “Single Version of the Truth” – consistent information

11.   Improved up sell and cross sell results by responding to customer buying habits

12.   Reduced costs of publishing product and catalog data by avoiding duplication

13.   Reduced costs of errors and rework by identifying and correct the root causes of errors.

On the other side of the equation are the costs of DWBI, which include:

1.       Time and attention of management to oversee development and implementation

2.       Software and hardware

3.       DWBI programs and projects

4.       Custom development

5.       Transition costs

6.       Ongoing costs such as maintenance and support.

Benefits can be both direct and indirect. Table 02-03 shows examples of both kinds of benefits.

Table 02-03: Direct and Indirect Benefits

Direct Benefits	Indirect Benefits
•   Revenue increases •   Output rate increases – goods produced, crimes solved, students graduated, etc.	•   Productivity increases •   Risk reductions

The business case could be presented with a range of improvement estimates based on scenarios such as:

•   Pessimistic (worst case) 20% improvement, i.e., $20M benefit

•   Target (typical case) 30% improvement, i.e., $30M benefit

•   Optimistic (best case) 40% improvement, i.e., $40M benefit.

Inability to identify the root cause of problems can be a challenge in business case development for business intelligence. Use of BI methods may reveal root causes and patterns that require follow up efforts to address the root causes. The business case may speculate on root causes and potential findings of BI efforts.

The Benefit Impact Matrix (see Table 02-04) is a tool that can help you to associate root causes with their financial impacts.

Table 02-04: Benefit Impact Matrix

Root Cause	Effect	Enterprise Impact	Metric	Annual Impact
Non-integrated customer data	More customer service calls	Higher customer service expense	Customer service staff cost	$12 Million
Non-integrated customer data	Dissatisfied customers	Lost customers	Customer turnover cost	$210 Million
Product design flaw	Product replacement requests	Increased service cost	Product replacement cost	$5 Million

BC Step 4.0 – Determine Transition Costs

The fourth step is to determine the cost of moving from the current approach to the future approach. To move from the current approach to the future approach requires an investment known as transition cost or project cost. The resulting deliverable is:

•   Transition cost component of BC

Transition costs are a key part of the business case. It costs money to go from here to there. Transition costs include elements such as:

•   Business process redesign

•   Business requirements

•   Computer hardware

•   Computer software

•   Software development

•   Data integration

•   Training.

BC Step 5.0 – Assemble Business Case

The fifth step is to correlate and refine the business case results. Examples of financial calculations for the business case are provided in Table 02-05. Deliverables are prepared that compare the current approach and proposed future approach, along with the costs required to transition from the current to future approach. The deliverables from this step are:

•   BC Detail Document

•   BC Presentation.

Table 02-05: Financial Calculations (Examples)

Item	Calculation
Return on Investment (ROI)	(gain – cost) / cost Extend over 5 years
Payback Time (number of years until gain exceeds costs)	(yearly payback) / cost
Net Present Value (NPV)	Discounted value of gains over 5 years Discounted cost over 5 years
Internal Rate of Return (IRR)	Cost of Capital – Net Present Value

The presentation includes a table of contents that outlines the business case such as the example in Figure 02-02. It is important to create a consistent story that sells the benefits to the enterprise.

Figure 02-02: Business Case Executive Summary Contents

BC Step 6.0 – Present Business Case

The final step is to present the business case and proposals to the decision makers. Here the decision makers are educated about the key points of the business case and (presumably) give their approval to proceed.

Case Study: 3M, Global EDW Business Case

The 3M business case for its Global Enterprise Data Warehousing (GEDW) included transition costs, ongoing costs, business benefits, and IT benefits. The original $50 million in transition costs invested beginning in 1995 were quickly recouped. Ongoing maintenance costs were $2.6 million per year. The ongoing maintenance costs are more than offset by annual savings of over $10 million per year in maintenance and customer service costs. Projected lifetime benefits of over $1 billion have been realized.

The results and impact are substantial. Applications encompass logistics, inventory analysis, supplier analysis, cross-selling, and customer penetration. The system went live in 1996, and net benefit within the first five years was expected to exceed $100 million. Projected benefits included reduction of indirect procurement cost by $350 million, improvement of sales force productivity by 10%, and reduction of supply chain, marketing communications, finance, and IT costs by more than $500 million. Revenue improvements related to improved customer penetration, faster product commercialization, customer retention, and price management also contributed substantially to the bottom line.

Additional benefits identified by Allen Messerli, former 3M Director of Enterprise Information Management, include:

•  Meeting Sarbanes-Oxley Act (SOX) auditing requirements without adding systems or costs

•  Increased cross-selling, customer penetration, and customer relationships

•  Improved supply chain excellence indices

•  Providing global customer and supply chain visibility

•   Six sigma implementation.

The well documented and presented business case enabled the GEDW team to gain the needed executive support to carry the program forward.

Data Warehousing Project Management

In this section, you will learn about the management of successful data warehousing / business intelligence projects. Topics include:

•   Defining Scope and Objectives

•   Finding the Right Sponsor

•   Producing the Project Roadmap and Plans

•   Organizing the Team

•   Executing the Plan

•   Finishing the Project

•   Avoiding Major Data Warehouse Mistakes.

Defining Scope and Objectives

Scope specifies the boundaries of the project. It tells what is in and what is out. The scope definition started in the business case will be expanded, if needed, when the project is underway. This effort includes:

•   Overview of the project (Mission, Scope, Goals, Objectives, Benefits)

•   Scope plan

•   Scope definition

•   Alternative development.

Defining the correct scope and setting realistic objectives are critical to any project's success, and a data warehouse project is no exception. Scope defines project boundaries including:

•   Business requirements addressed

•   Anticipated/planned users

•   Subject Areas such as inventory transactions or customer service interactions

•   Project success criteria, including quantified planned benefits.

Defining an overly large project scope and letting scope grow in an uncontrolled fashion (scope creep) are certain to cause project failure. Remember you cannot please everyone:

I cannot give you a formula for success,

but I can give you a formula for failure: try to please everybody.

Herbert Bayard Swope

Enterprise vs. Departmental Focus

The choice of Enterprise Data Warehouse vs. Departmental Data Mart is critical to the success of data warehousing projects. This choice is a major component of project scope. Examples of factors that arise with each focus, based on my experience, are shown in Table 02-06.

Table 02-06: Enterprise vs. Departmental Focus

Factor	Enterprise Focus	Department / Functional Focus
Organizational Scope	Enterprise Wide	Business Unit or Business Process Focused
Time to Build	Multi-year phased effort	Single Year effort
Sponsorship Required	Executive Sponsor	Management Sponsor
Complexity	High	Medium
Typical Cost	Often a multimillion dollar effort	Often less than $1 million effort

The project may require both an Enterprise Data Warehouse and one or more Data Marts. The Technical Architecture chapter explains more about this choice.

Finding the Right Sponsor

The role of the project sponsor is critical to the success of the data warehousing project. This individual is a senior management person who takes overall responsibility for a project. Seek out a project sponsor who has both a large stake in the project outcome as well as authority over the resources needed for the project.

The project sponsor fills a number of roles including:

•   Owner of the business case

•   Harvester of benefits

•   Overseer of the project

•   Link to upper management.

Data warehousing champions complement the work of the project sponsor. Look for people who will promote data warehousing efforts across the organization. They make sure that the project is aligned with enterprise goals and help to sell the project to the rest of the organization.

The scope of a DWBI effort is also highly dependent on the level of authority of the project sponsor. If the sponsor is the CEO or CFO, then the scope can be enterprise wide. If the sponsor is a business unit head, then the scope is likely the business unit. If the sponsor is a department head, then the scope is likely limited to a single department.

Conversely, an Enterprise Data Warehouse project requires a higher level executive sponsor with more authority and resources than is required for a Departmental Data Mart project.

Producing the Project Roadmap and Plans

A roadmap is a high-level plan that coordinates multiple project plans. The project roadmap is larger in scope than a single project plan. It encompasses a series of projects that carry the organization forward to longer range objectives. It is often best to build the data warehouse through a series of smaller projects that are coordinated using a project roadmap.

A project plan is a document, or set of documents, that describes a project in terms of its objectives, scope, schedule, budget, and resources. The project plan supports the execution and control of a project to ensure its success by:

•   Acting as a communication tool between decision makers and team members

•   Guiding the project phases and activities.

Project planning includes these activities:

•   Developing the Work Package Plan which includes an Activity List and Work Breakdown Structure

•   Developing Project Schedule which includes a Project Timeline and Critical Path

•   Determining Resource Requirements

•   Assembling a Cost Estimate and Project Budget

•   Approving the Project Plan.

Key Project Questions

Your project plan should ensure that these key questions are answered.

•   What are the expected outcomes of this project?

•   What are the inputs and outputs?

•   Why is this project being done?

•   When will the project begin and end?

•   How will the outcomes be accomplished?

•   Where will the project take place?

•   Who is involved with this project?

•   Who is the customer?

•   Who is the sponsor?

•   Who will contribute to the project?

•   What methodology will be used (waterfall vs. agile)?

Developing The Work Package Plan

The Work Package Plan is a detailed plan that breaks a project down to the activity level. The first part of developing the plan includes building an activities list using techniques such as brainstorming, templates, and checklists. This is followed by these further efforts.

•   Identifying activities

•   Selecting activities

•   Reconciling activities

•   Organizing activities.

This book describes many of the activities and corresponding deliverables that are needed to carry out successful data warehousing and business intelligence projects. Use the activities listed in Table 02-07 as an idea starter when planning your project. Each of these activities is described in later chapters of this book.

Not all activities identified in the first pass should be included in the project plan. Review each activity and select only activities that are within the project scope and contribute to desired outcomes.

The list of activities may contain activities that are duplicates or very similar. Reduce the number of activities by combining duplicate activities. Create manageable tasks that require between 8 and 40 hours to complete. Shorter tasks lead to micromanagement while longer tasks lose visibility. The result is a reconciled list of activities that is easier to manage.

Table 02-07: Data Warehousing and Business Intelligence Activities

•   Determine enterprise mission, vision and strategies •   Conduct proof of concept •   Build capability maturity model •   Elicit functional requirements •   Elicit non-functional requirements •   Specify data architecture direction •   Create data architecture context diagram •   Specify technical architecture direction •   Determine data warehouse technology stack •   Acquire infrastructure •   Determine databases required •   Determine data sources •   Establish Data Governance •   Establish Metadata Management •   Establish Information Lifecycle Management (ILM) •   Identify candidate metrics and KPIs •   Define metrics and KPIs •   Determine dimensional tables needed •   Create Dimension Fact Matrix •   Model and design dimensions

•   Model and design fine grained facts •   Model and design aggregated facts •   Model and design atomic data warehouse •   Obtain data source documentation •   Conduct data profiling of data sources •   Obtain XYZ source system data •   Design and develop BI metadata •   Design and develop reports •   Design and develop scorecards •   Design and develop dashboards •   Design and develop portals •   Design and develop analytic models •   Tune databases •   Secure the data •   Document processes and procedures •   Train end users •   Create test plan •   Implement test plan •   Rollout solution to end users •   Conduct post-project evaluation

 

Organizing activities into a Work Breakdown Structure (WBS) is the next step. A WBS is a hierarchical organization of project activities that facilitates management of the current effort. Figure 02-03 depicts this hierarchical organization of project tasks.

Figure 02-03: Work Breakdown Structure Hierarchy

The WBS should support project goals and objectives. For example, the project goal may be to create a framework that supports Enterprise Performance Management (EPM) and objectives include:

•   Establish a foundation for EPM

•   Establish EPM for Customer Experience

•   Establish EPM for Financial Excellence

•   Establish EPM Operational Excellence

•   Establish EPM for Employee Growth and Retention.

In this case, the WBS would be organized to support these objectives. The objective “Establish a foundation for EPM” would include activities such as:

•   Conduct proof of concept

•   Build capability maturity model

•   Elicit non-functional requirements

•   Create data architecture context diagram

•   Specify technical architecture direction

•   Determine data warehouse technology stack

•   Acquire infrastructure

•   Establish Data Governance.

The more specific objectives like “Establish EPM for Customer Experience” and “Establish EPM for Financial Excellence” address specific business requirements and are aligned with specific activities needed to deliver on those requirements. Focusing on objectives supports early delivery of value.

Each high level objective can be organized into activity groups based on major data warehousing work efforts:

•   Vision – Document the future state and supporting business case

•   Requirements – determine the needs and features of the data warehouse

•   Architect – Specify the business and technical architecture of the data warehouse

•   Design – Specify system details including: data models, data mapping and dashboard layouts

•   Build – Create deliverables including: databases, data integration jobs and dashboards and acquire supporting technology

•   Quality Assurance – Test the data warehouse to make sure that it meets requirements

•   Roll out – Deliver value that meets the objective in a sustainable manner.

Developing the Project Schedule

After activities are defined and organized into a WBS it is time to develop the overall project schedule. This requires estimating the duration of each activity and arranging activities in sequence.

Estimates for activities are best prepared by the people responsible for that activity. This takes advantage of expertise and leads to commitment by the estimators. Steps include:

•   Determining project roles – reference Table 2-10 for project roles

•   Obtaining an estimator for each project role

•   Estimating duration and elapsed time for each activity

•   Correlating the estimates.

Next, arrange activities into sequence. To do this, consider dependencies between activities, risk reduction and delivery of value. There will be dependencies at a high level. Design activities must come before build activities. There will also be dependencies at a detail level; for example, database tables must be created before they can be loaded with data.

Data warehousing and business intelligence projects have specific risks that can be mitigated, in part, through intelligent project scheduling using methods such as those identified in Table 02-08.

Table 02-08: Risk Mitigation through Project Scheduling

Risk	Mitigation
Data sources have data quality problems	•   Schedule data profiling activities early. •   Include data source reviews with business experts in the project schedule.
High data volume causes slow load of data warehouse	•   Schedule data volume estimation early in the project. •   Include performance testing with data volumes that exceed estimates early in the project as part of technical architecture activities.
Root cause analysis finds unanticipated problems	•   Include points in the schedules where the project schedule can re-evaluated based on project findings.

Schedule the project so that value is delivered early. Avoid schedules that stack all value delivery at the very end. This mitigates the risk that opportunities are lost due to late project completion.

Determining Resource Requirements

Staffing resource requirements are determined by adding the duration time for each person role and time period. The number of people in each role required depends on the hours needed and the overall schedule length. A shorter delivery period may require more people.

Assembling the Project Budget

The budget is an itemized projection of the resources needed for the project, including the amount of money needed for each item. Here are some of the major items that should be included in the budget:

•   People (Employees, Consultants)

•   Hardware

•   Software (Development, Infrastructure)

•   Data acquired from external sources.

The people budget can be determined by multiplying the hours estimated in the Resource Requirements Plan by the rates. The projections for hardware, software and external data depend upon the Technical Architecture selected. Be sure to add some contingency time in case the project does not go as planned due to factors such as:

•   Discovery of additional requirements

•   Data quality problems

•   Loss of critical personnel

•   Competing priorities.

Waterfall vs Agile approaches

There are two high level approaches to project management, the waterfall approach and the agile approach. Specifically these apply to data warehousing projects. The waterfall approach organizes the project into activities that are planned in detail and then executed as planned. The waterfall method is proven to produce results, however, it is vulnerable to risk that require adaptation to changed circumstances.

The agile approach recognizes that adaptation to change is a critical success factor in projects and builds in flexibility for change. Agile methodologies have worked very well for me in practice. The agile approach produces rapid results and enables team learning. Critical components of the two approaches are described in Table 02-09.

Table 02-09: Waterfall to Agile Approach Comparison

Strategy Area	Waterfall	Agile / Iterative
Time to Value	•     At the end of a lengthy process	•     Multiple deliveries at regular intervals
Time Periods	•     Time is divided into sequential phases	•     Work is divided into iterative time periods called “Sprints”.
Documentation	•     Focus is on thorough specifications	•     Focus is on delivering “code” / functionality not documentation •     Documentation is generated from the code •     Code can consist of metadata / declarations rather than procedural code
Team Location	•     Team may be distributed	•     Team is often co-located in a “war room” (except in Distributed Agile).

Organizing the Team

The right team is critical to any successful project and data warehousing projects are no different. Table 02-10 describes the roles that are needed for an effective data warehousing project team. The project manager should seek extended team members who can help if the project is blocked for some reason.

Table 02-10: DWBI Project Roles

Role	Description
Data Warehousing Champions	The data warehousing champions complement the role of the data warehousing sponsor. They provide executive support for the project. They make sure that the project is aligned with enterprise goals and help to sell the project to the rest of the organization.
Project Manager (PM)	The Project Manager provides project leadership. This includes preparing project plans and then following up on those plans to keep the project on schedule. The PM manages risks, issues and project communications.
Business Subject Matter Experts (SMEs)	The SMEs understand the business and provide detailed business requirements.
Business Analyst	The business analyst elicits and documents business requirements.
Enterprise Architect	The enterprise architect makes sure that the project is aligned with enterprise directions in the areas of business architecture, data architecture, technical architecture, and infrastructure architecture.
Technical Trainer	The technical trainer provides training in data warehouse tools and techniques. We recommend training team members before they start using new tools or techniques to develop the project.
Data Architect	The data architect provides a broad perspective on data.
Data Modeler	The data modeler builds and communicates data models, which are visual representations of the data. The data modeler works with business and subject matter experts to elicit and define data requirements.
Database Administrator	The database administer configures and manages databases. This is an important role that makes sure that data is efficiently managed and protected.
Technical Architect	The technical architect determines the technical solution at the project level. These individuals work with enterprise architects and others to make sure that the details support the overall architecture.
Data Integration Designer/Developers	The Extract Transform Load (ETL) designers and developers move data to where it is needed to support the data warehouse system. In many cases, this is about 70 percent of the project effort (Kimball 2004), so it is important to do this efficiently.

Training the Team

Make sure the data warehousing team is trained in the skills needed for success. Review each role and team member for needed skills and train as needed. Team members may require skills in areas such as:

•   Project Management

•   Data Warehouse Architecture

•   Data Warehouse Modeling

•   Requirements Analysis

•   Specific Tools.

Executing the Plan

When the data warehousing project is under way, execution becomes paramount. In the best projects, the participants are inspired and are focused on positive outcomes for the organization. The project manager must keep the project under control while insuring that stakeholders are informed of progress.

A focus on positive outcomes is a critical ingredient in project success as the data warehousing project plan is being executed. For example, if improved decision making and productivity of actuarial data analysts are goals, make sure that project team members are aware of that. You might have team members do a “step in” with actuarial analysts to show them what the life of the actuarial analyst life is like and how it will be improved by the project. Team members then know that skimping on quality delivery will have negative results for fellow workers.

Status reports and meetings coupled with proactive follow up are important tools in the effort to keep a project under control. Each week team members should report their status toward assigned tasks.

The Workflow Chart is a way to gain control and visibility to tasks that require repetitive steps. Figure 02-04 shows a Workflow Chart for data discovery and mapping which shows each data source to be discovered and mapped along with assigned analyst, subject matter experts (SMEs) and Status. For each task there is a planned date identified by a letter P and when complete, an Actual date identified by an A. The workflow steps include:

•   Obtain Documents – Locate data source documentation.

•   Define Inputs – Obtain definitions for data source attributes.

•   Profile Inputs – Query data source to gain understanding.

•   Map Data – Map data source to data target.

•   Data Quality – Assess data quality.

•   Publish Results – Produce a report documenting findings.

Figure 02-04: Data Discovery and Mapping Workflow Chart

Data Source Name	Obtain Doc Date	Define Input Date	Profile Input Date	Map Date	Data Quality Date	Publish Results Date	Analyst Name	SME Name(s)	Status
CRM	P 7/12 A 7/09	P 8/1 A 7/28	P 8/15	P 9/1	P 9/15	P 10/1	J Smith	B Rose M Heart	In Progress
PIM	P 7/12 A 7/13	P 8/1 A 8/2	P 8/15	P 9/1	P 9/15	P 10/1	A Nelson	W Neuton	In Progress
Sales Order	P 7/12	P 8/1	P 8/15	P 9/1	P 9/15	P 10/1	J Smith	B Rose M Heart	Planned

The project manager must take aggressive action to keep the project on track. Two tracking tools are the Issue Log and the Risk Log. The Issue Log is a document that tracks problems which must be solved. It includes a description of the problem, person assigned to solve the problem, date discovered, date corrected and status. If the assigned person cannot solve an issue in a timely or satisfactory way, the project manager should determine the root cause of the problem and push for resolution.

The Risk Log identifies problems that have a possibility of occurring. It includes a description of the risk, potential impact to the project, likelihood of occurrence and a mitigation approach to deal with the risk should it occur. Gaining visibility of risks and taking steps to handle them is critical to project success.

It is also critical to make data content visible to team members and project stakeholders. For example, if data is being obtained from a data source, display the data to make sure that it is what is expected. Also, data that is being placed in the data warehouse should be shared to avoid surprises later. Walkthroughs of data warehousing deliverables also serve to keep project stakeholders interested and committed. Make sure that the project complies with earlier specified goals and architectures by comparing the actual project with plans and recommendations.

Finishing the Project

When finishing the data warehousing project it is important to set the data warehouse on a sustainable course and to learn from experience. Read Chapter 19 of this book learn about setting the data warehouse on a sustainable course.

A “Lessons Learned” session is a good way to learn from the data warehousing experience. Request that project stakeholders identify aspects of the project that went well and those that need improvement by completing a survey. Then correlate the information and host a meeting to review the results. The Lessons Learned meeting is an opportunity for project stakeholders to express themselves as well as learn from the viewpoints of others.

Case Study: 3M, Enterprise Data Warehouse Continued

The 3M Global Enterprise Data Warehouse (GEDW) is an effort that goes well beyond a single project. It is an ongoing effort guided by critical principles and a roadmap. Gaining executive support and buy in was an early step and a critical success factor.

Executives supporting the GEDW program were top level executives who provided multiple perspectives. Allen Messerli indicated, “It was important that the GEDW not be dominated by a single business area. If the Chief Financial Officer (CFO) were the sponsor, then the solution would be a financial data mart, not the desired Enterprise Data Warehouse (EDW).”

The initial GEDW was developed over a five-year period. Allen Messerli recommends that an EDW be built in phases, not in one big bang. Each phase should deliver value within six months or less. Then each successful delivery paves the way for approval and support for the next phases.

Project Management Tips

In order to succeed in data warehouse projects, it is wise to be aware of best practices and common pitfalls. Use these tips to improve your projects.

•   Before starting, diagnose the readiness of your organization for data warehousing and business intelligence.

•   Make sure that your data warehouse project is aligned with the strategies of your organization.

•   Use SMART goals including metrics. SMART – specific, measurable, assignable, realistic, and time-based goals.

•   Work with key users – people in the business who are actually going to use the system for decision-making.

•   Work with executive management who can sponsor and promote the data warehouse.

•   Make sure to educate your organization so that it understands data warehousing and business intelligence.

•   Start the project with an experienced project manager and data warehouse architect.

Avoiding Major Data Warehouse Missteps

You can avoid or reduce common data warehousing missteps by being prepared. Follow the suggestions described in Table 02-11 to prevent or recover from problems.

Table 02-11: Data Warehouse Missteps

Misstep	How to Prevent
Focusing on technology instead of people and process	Put people and process ahead of technology. Make sure that people's needs and business requirements are at the center of the effort.
Lack of sponsorship and management support	Remember to find and involve executives from both business and IT who support and sponsor the data warehousing and business intelligence effort. The sponsor must have a stake in the outcome along with authority to push through the program.
Overly ambitious or undefined scope	Insist that the effort proceed step by step so it can build on a record of success. The scope must be clear and documented to prevent confusion and set focus.
Undefined requirements	Use the requirements elicitation and documentation process described in Chapter 3 of this book. Remember if what is needed is unclear, the project, will likely fail.
Failure to consider future requirements	The way to prepare for future requirements is to be aware of the organization's long-term vision and to design flexible systems that can be adapted to support that vision.
Unrealistic expectations	Emphasize to sponsors and other stakeholders that the data warehouse will be built step by step and, therefore, will not satisfy every desire immediately. Keep communicating to avoid unrealistic expectations. The recommendation to “Under promise and over deliver” is a good one.
Failure to architect a long-term solution	In order to avoid tactical solutions that do not last, create a flexible architecture using the approaches explained in Chapters 4 through 11 of this book.
Failure to obtain high quality data	Establish a data quality effort based on the Six Steps to Data Quality Management, as described in Chapter 9, Data Sources and Data Quality Management.
Trying to turn the prototype into the final solution	The prototype is designed to show the potential of the data warehouse, not to be the actual data warehouse. Prototypes often lack data quality management and other important features needed for the final solution. Communicate the prototype approach from the beginning to avoid this trap.
Designing around one tool/vendor	Domination of the project by a single vendor or promoter of a single tool can lead to an inflexible solution that cannot grow to support the needs of the organization. Instead, take charge of the effort and build to a strong architecture.
Failure to scale up	Some data warehouse systems work well for small volumes of data, but cannot be expanded when volume expands. Avoid this problem by building on database and other technology that can expand, rather than desktop databases that limit expansion.
Failure to store data at the right level of detail / grain	It may be tempting to store data at a summarized grain of detail rather than at a finer grain of detail. This can cause problems when it is desirable to drill down to detailed information to better understand root causes. Be sure to analyze the level of detail, including the need to drill down.

 

Key Points •   Avoid common data warehousing mistakes such as focusing on technology instead of people and processes. •   Build an effective Business Case to sell the DWBI effort. •   Obtain executive sponsorship and management support. •   Clearly define scope to a challenging but achievable level. •   Answer basic project questions (what, why, when, how, where and who) which are critical to project success. •   Successful execution is critical to the winning project. Keep in control of the project through monitoring and strong follow up.

Learn More

Expand your knowledge of how to organize a data warehousing and business intelligence project. These resources can help.

Visit a Website!	See the Gantthead Data Warehouse Process for steps needed to manage a data warehouse project. http://www.gan tthead.com The Project Management Institute (PMI) is a leading association of project management professionals. http://www.pmi.org
Read about it!	This book shows how to manage data warehousing and BI Projects: Hughes, Ralph. Agile Data Warehousing: Delivering World-Class Business Intelligence Systems Using Scrum and XP. iUniverse, 2008.