Project Mgmt for a DW Projects

I would like to start a discussion on how Project Mgmt for a DW is different from other projects. Ill start;
I feel that the design phase is longer and the coding phase is shorter than other projects. Agree/Disagree?

Hi,
I'm starting with a BI project for a subject matter area called: Credit Risk.
And so far I have spent far more time documenting and discussing the requirements, ETL will also be a lot of work but a tad less time will be spent on it.
(That is what I foresee ...)

My approach so far has been to create a strategy document (with an embedded excel workbook) to 'explain' BI and the approach we will follow with a document matrix.

The templates that I have started to create and populate is:

1. Business case assessment
2. Technical Infrastructure Report
3. Non-Technical Infrastructure Report
4. Project Charter
5. Project Plan
6. Requirements analysis
7. Database design
8. ETL Design
9. Meta Data Repository

these may change but this is all a separate physical document and so far it is a bit different from a standard SDLC approach.

In general, the bulk of the work in developing a data warehouse is specification, documentation and testing. If done right, the modelling and ETL stuff goes real quick. If the project includes developing a BI layer from scratch, this can also be time consuming, but it is fairly easy to coordinate this work... tool installation and configuration early on, metadata development once the data model is complete, and report development as test data becomes available.

A common problem I have seen in staffing DW development is the tendancy to understaff the ETL specification portion and overstaff ETL development. To make things worse, often these efforts are scheduled to start at the same time.

Developing ETL specs (source to target mappings) takes a lot of time and requires coordination between the ETL architect and the subject matter experts on the business side. While this is going on, the ETL developers are sitting on their hands waiting for something to do. It is usually best to stagger the initiation of specification by a few weeks before coding to allow a queue of specifications to build up. Once coding begins, the ETL architect needs to split his/her time between completing the remaining specifications and handling questions from the ETL developers.