Please help explain the 1) urgency of need and 2) elimination of risk for building a data warehouse.

We are in the process of building a data warehouse. We would like our project to be one our number-one priority and need to come up with a business plan. I have been asked to explain 1) urgency of need 2) elimination of risk. Can you help?

Sid Adelman's Answer: Urgency of need - Research what others in your industry are doing, especially your competition. Nothing motivates senior management more than the fear that your hated competitors are doing something better or smarter than you are.

Elimination of risk - You will never be able to eliminate risk, but these are some of the things you can do to minimize that risk:

1. If the mission and the objectives for the DW have not been defined:

Identify the sponsor of the DW.
Insist (strongly recommend) that the mission and objectives be defined prior to any serious activity.
Develop a straw man for the mission and objectives and propose it to the DW sponsor.

2. If the mission and objectives of the DW do not map to those of the enterprise:

If there are no explicit enterprise objectives, there are probably assumed objectives to which most people in the enterprise would subscribe. These should be documented and mapped to the DW objectives.
If enterprise objectives exist but the DW does not support them, rethink what you are trying to accomplish with the DW.

3. When there are problems with the quality of the source data (there always are):

If the quality of the source data is unknown, use a quality evaluation tool to determine just how bad things are. Identify operational data with quality problems to someone high in the organization (perhaps the CIO), and then step back (it is not your responsibility to clean up dirty operational data).
Because the quality of the source data will be highly variable, try to convince the user to implement the cleanest data first (this will sometimes work).
If the user insists on putting dirty data in the DW, at least flag the data in metadata, indicating its level of quality.

4. To provide the skills to support the DW:

Define the functional responsibilities of data administrators, database administrators, application developers and user liaisons. Define the skill levels required for each of these positions.
Sell management on the need to have skilled people on the DW team.
Sell management on the need to have these people sufficiently dedicated to the project.

5. To be sure you have an adequate budget in place:

Compile industry publications, presentations, etc. that indicate what a DW will normally cost. Watch out for those who give figures for selected subsets of the effort or who disregard costs assigned to some other departments.
Itemize each of the costs for your project. Don't pad the numbers, but don't underestimate just because you think the true cost will frighten management into paralysis.
If the numbers are too high, consider a smaller project or one that does not require some big ticket items (such as a new DBMS, other expensive software, or major new hardware).

6. For supporting software (extract, cleansing, BI tools, DBMS, etc.):

Understand the benefit of this software to the project. If it does not benefit this specific project, justification can only be accomplished if major follow-on projects will significantly benefit from its use.
Quantify the costs of not using the software. These costs should include the additional effort to write the code, the ongoing costs to maintain the code, the costs of delay and the potential for reduced quality of the implementation.
Identify only the software that can make a major contribution. Avoid recommending a piece of software that is fun, leading edge and a resume enhancer, but does not significantly make a contribution to the project.

7. Focus on the source data:

If source data has been neither inventoried nor modeled, it is probably because IT management does not recognize the importance of these activities. Any such recommendations would probably be seen as delaying the project. In fact, the inventory and modeling effort is long and laborious. If management has not already recognized their benefits, it's unlikely that the DW project will sell it. The DW should not be used as justification for data modeling or for inventorying the data.
If a data modeling tool is in place that has reverse engineering capability (the ability to take database definitions [DDL], capture them in the data model encyclopedia and generate rough models), this reverse engineering could be the least costly and most acceptable course of action.

8. To be sure you have a strong, well-placed, reasonable user sponsor:

Take your time. Make a list of sponsors that match the above criteria, and put the strongest ones on top. Research their decision support requirements, and determine which problems could be well-served by the DW. Invite #1 to lunch, sell that user on the DW, outline what would be needed from them and from their department, and ask for their sponsorship.
If #1 is not agreeable, invite #2.
When you are down to The User from Hell, stop and do something else.

9. Focus on the primary business users of the data warehouse:

If your users are not computer literate, budget more money for user support.
Allow more time for the expected volume to be achieved. Readjust your expectations.
Revamp the training so as not to frighten the students.
Provide mentors in the training process.
Develop a more comprehensive set of predefined queries.
Choose an extra-user-friendly front end (choose warm and fuzzy over power and function).