Data Warehouses

FPT University
Hanoi 2010
Lecture 3: PLANNING AND
PROJECT MANAGEMENT
Overview
 Planning Your Data Warehouse
 The Data Warehouse Project
 The Project Team
 Project Management Considerations
PLANNING YOUR DATA
WAREHOUSE
 More than any other factor, improper planning
and inadequate project management tend to
result in failures.
 First and foremost, determine if your company
really needs a data warehouse. Is it really ready
for one?
 You need to develop criteria for assessing the
value expected from your data warehouse.
 Yourcompany has to decide on the type of data
warehouse to be built and where to keep it.
PLANNING YOUR DATA
WAREHOUSE
 You have to ascertain where the data is
going to come from and even whether you
have all the needed data.
 You have to establish who will be using
the data warehouse, how they will use it,
and at what times.
 So what are issues?
1. Value and Expectations
 Some companies jump into data warehousing
without assessing the value to be derived from
their proposed data warehouse.
 Of course, first you have to be sure that, given
the culture and the current requirements of your
company, a data warehouse is the most viable
solution.
 After you have established the suitability of this
solution, then only can you begin to enumerate
the benefits and value propositions.
1. Value and Expectations
 Will your data warehouse help the executives
and managers to do better planning and make
better decisions?
 Is it going to improve the bottom line?
 Is it going to increase market share?
 If so, by how much?
 What are the expectations?
 What does the management want to accomplish
through the data warehouse?
 As part of the overall planning process, make a
list of realistic benefits and expectations. This is
the starting point.
2. Risk Assessment
 Planners generally associate project risks with the cost
of the project. If the project fails, how much money will
go down the drain?
 But the assessment of risks is more than calculating the
loss from the project costs.
 What are the risks faced by the company without the
benefits derivable from a data warehouse? What losses
are likely to be incurred? What opportunities are likely to
be missed?
 Risk assessment is broad and relevant to each business.
Use the culture and business conditions of your
company to assess the risks. Include this assessment as
part of your planning document.
3. Top-down or Bottom-up
 The top-down approach is to start at the
enterprise-wide data warehouse, although
possibly build it iteratively. Then data from the
overall, large enterprise-wide data warehouse
flows into departmental and subject data marts.
 On the other hand, the bottom-up approach is to
start by building individual data marts, one by
one. The conglomerate of these data marts will
make up the enterprise data warehouse.
4. Build or Buy
 This is a major issue for all organizations.
 No one builds a data warehouse totally from
scratch by in-house programming.
 There is no need to reinvent the wheel every
time: A wide and rich range of third-party tools
and solutions are available.
 The real question is how much of your data
marts should you build yourselves? How much
of these may be composed of ready-made
solutions? What type of mix and match must be
done?
4. Single Vendor or Best-of-
Breed
 Vendors come in a variety of categories.
 There are multiple vendors and products
catering to the many functions of the data
warehouse. So what are the options? How
should you decide?
 Two major options are: (1) use the
products of a single vendor, (2) use
products from more than one vendor,
selecting appropriate tools.
4. Single Vendor or Best-of-
Breed
 Choosing a single vendor solution has a
few advantages:
 High level of integration among the tools
 Constant look and feel
 Seamless cooperation among components
 Centrally managed information exchange
 Overall price negotiable
4. Single Vendor or Best-of-
Breed
 Advantages of the best-of-breed solution
that combines products from multiple
vendors:
 Could build an environment to fit your
organization
 No need to compromise between database
and support tools
 Select products best suited for the function
5. Business Requirements, Not
Technology
 Data warehousing is not about technology, it is
about solving users’ need for strategic
information.
 Do not plan to build the data warehouse before
understanding the requirements. Start by
focusing on what information is needed and not
on how to provide the information.
 Do not emphasize the tools. Tools and products
come and go. The basic structure and the
architecture to support the user requirements
are more important.
5. Business Requirements, Not
Technology
 What types of information must you gather in the preliminary survey? At a
minimum, obtain general information on the following from each group of
users:
 Mission and functions of each user group
 Computer systems used by the group
 Key performance indicators
 Factors affecting success of the user group
 Who the customers are and how they are classified
 Types of data tracked for the customers, individually and groups
 Products manufactured or sold
 Categorization of products and services
 Locations where business is conducted
 Levels at which profits are measured per customer, per product, per district
 Levels of cost details and revenue
 Current queries and reports for strategic information
6. Top Management Support
 No major initiative in a company can
succeed without the support from senior
management.
 This is very true in the case of the
company’s data warehouse project. The
project must have the full support of the
top management right from day one.
7. Justifying Your Data
Warehouse
 Even if your company is a medium-sized
company, when everything is accounted
for, the total investment in your data
warehouse could run to a few millions
dollars.
7. Justifying Your Data
Warehouse
 Some sample approaches for preparing the justification:
 1. Calculate the current technology costs to produce the
applications and reports supporting strategic decision
making.
 Compare this with the estimated costs for the data warehouse
and find the ratio between the current costs and proposed costs.
 See if this ratio is acceptable to senior management.
 2. Calculate the business value of the proposed data
warehouse with the estimated dollar values for profits,
dividends, earnings growth, revenue growth, and market
share growth.
 Review this business value expressed in dollars against the data
warehouse costs and come up with the justification.
7. Justifying Your Data
Warehouse
 Some sample approaches for preparing the justification:
 3. Do the full-fledged exercise.
 Identify all the components that will be affected by the proposed
data warehouse and those that will affect the data warehouse.
 Start with the cost items, one by one, including hardware
purchase or lease, vendor software, in-house software,
installation and conversion, ongoing support, and maintenance
costs.
 Then put a dollar value on each of the tangible and intangible
benefits including cost reduction, revenue enhancement, and
effectiveness in the business community.
8. The Overall Plan
THE DATA WAREHOUSE
PROJECT
 Data warehouse projects are different from
projects building the transaction
processing systems.
Assessment of Readiness
 The readiness assessment report is expected to
serve the following purposes:
 Lower the risks of big surprises occurring during
implementation
 Provide a proactive approach to problem resolution
 Reassess corporate commitment
 Review and reidentify project scope and size
 Identify critical success factors
 Restate user expectations
 Ascertain training needs
The Life-Cycle Approach
Project plan
The Development Phases
THE PROJECT TEAM
Organizing the Project Team
 A good starting point is to list all the project challenges
and specialized skills needed.
 Your list may run like this: planning, defining data
requirements, defining types of queries, data modeling,
tools selection, physical database design, source data
extraction, data validation and quality control, setting up
the metadata framework, and so on.
 As the next step, using your list of skills and anticipated
challenges, prepare a list of team roles needed to
support the development work.
Organizing the Project Team
 Once you have a list of roles, you are ready to
assign individual persons to the team roles.
 It is not necessary to assign one or more
persons to each of the identified roles.
 If your data warehouse effort is not large and
your company’s resources are meager, try
making the same person wear many hats.
 In this personnel allocation process, remember
that the user representatives must also be
considered as members of the project team.
 Do not fail to recognize the users as part of the
team and to assign them to suitable roles.
Roles and Responsibilities
 The classifications of the roles:
 Classifications: Staffing for initial
development, Staffing for testing,
Staffing for ongoing maintenance,
Staffing for data warehouse
management
 Broad classifications: IT and End-
Users, then subclassifications
within each of the two broad
classifications, followed by further
subclassifications
 Classifications: Front Office roles,
Back Office roles
 Classifications: Coaches, Regular
lineup, Special teams
 Classifications: Management,
Development, Support
 Classifications: Administration,
Data Acquisition, Data Storage,
Information Delivery
A Basic Set of Team Roles
Skills and Experience Levels
User Participation
PROJECT MANAGEMENT
CONSIDERATIONS
Guiding Principles
 Project Manager. It is a serious mistake to have a project manager who is more technology-
oriented than user-oriented and business-oriented.
 New Paradigm. Data warehousing is new for most companies; innovative project management
methods are essential to deal with the unexpected challenges.
 Team Roles. Team roles are not to be assigned arbitrarily; the roles must reflect the needs of
each individual data warehouse project.
 Data Quality. Three critical aspects of data in the data warehouse are: quality, quality, and
quality.
 User Requirements. Although obvious, user requirements alone form the driving force of every
task on the project schedule.
 Building for Growth. Number of users and number of queries shoot up very quickly after
deployment; data warehouses not built for growth will crumble swiftly.
 Project Politics. The first data warehouse project in a company poses challenges and threats to
users at different levels; trying to handle project politics is like walking the proverbial tightrope, to
be trodden with extreme caution.
 Realistic Expectations. It is easy to promise the world in the first data warehouse project; setting
expectations at the right and attainable levels is the best course.
 Dimensional Data Modeling. A well-designed dimensional data model is a required foundation
and blueprint.
 External Data. A data warehouse does not live by internal data alone; data from relevant external
sources is an absolutely necessary ingredient.
 Training. Data warehouse user tools are different and new. If the users do not know how to use
the tools, they will not use the data warehouse. An unused data warehouse is a failed data
warehouse.
Warning Signs
a Successful Project
Adopt a Practical Approach
 In the context of a data warehouse project, here are a few tips on
adopting a practical approach:
 Running a project in a pragmatic way means constantly monitoring
the deviations and slippage, and making in-flight corrections to stay
the course. Rearrange the priorities as and when necessary.
 Let project schedules act as guides for smooth workflow and
achieving results, not just to control and inhibit creativity. Please do
not try to control each task to the minutest detail. You will then only
have time to keep the schedules up-to-date, with less time to do the
real job.
 Review project task dependencies continuously. Minimize wait times
for dependent tasks. There is really such a thing as “too much
planning.” Do not give into the temptation. Occasionally, ready–fire–
aim may be a worthwhile principle for a practical approach.
Adopt a Practical Approach
 Similarly, “too much analysis” can produce “analysis
paralysis.”
 Avoid “bleeding edge” and unproven technologies. This
is very important if the project is the first data warehouse
project in your company.
 Always produce early deliverables as part of the project.
These deliverables will sustain the interest of the users
and also serve as proof-of-concept systems.
 Architecture first, and then only the tools. Do not choose
the tools and build your data warehouse around the
selected tools. Build the architecture first, based on
business requirements, and then pick the tools to
support the architecture.