Advice for a newbie!

Hello

Earlier in July, I was asked to take charge of a brand new DW/BI project for our company that spans all business units. We currently have some departmental and/or system specific MI solutions, but nothing like an Enterprise wide DW/BI solution.

To help me get started, I bought two books (The Data Warehouse Lifecycle Toolkit and the Data Warehouse Toolkit (Dimensional Modelling). I have also done some research on the web and watched some webcasts. My own background is in architecture and development for banks, with the last 15 years focused on Microsoft technologies (.NET, SQL Server). I also have Agile Project Management experience using Scrum.

Our company's standard tool for DW/BI is Business Objects, so I guess that solves the BI track of the Kimball Lifecycle. But, as this is my first DW/BI, I am looking for advice from experienced people to help me get going on this project. The CEO is the sponsor so the project profile can't get any higher! As the books say, get this wrong and I will have a short career in this company!

By the way, training or recruiting DW/BI consulatants is not an option due to budgetry constraints. I do however have access to our Group Architecture team that have DW/BI people. But, I am interested in feedback from the Kimball lifecycle devotees too.

Thanks in advance.

Hi, Amir,

I suspect no one has touched this because it is way too open ended. Someone would need to write a book or two to provide the advice you need. Wait! They already have! At the risk of self-promoting, the two books you bought are reasonably good starting points. I would stick to the first 3 chapters of the Lifecyle Toolkit at this point. Make sure you have a narrowly defined business opportunity to address as your first lifecycle iteration. One that's easy to do and has business value. Then, repeat the lifecycle many times for each new set of data you need to bring into the warehouse to address additional high value business opportunities.

Once you get into the technology, you are luck in that we have another book that translates the Kimball approach down to the technology level for the Microsoft DW/BI product stack called the Microsoft Data Warehouse Toolkit. (Someday we might have similar books for the other major players, but I wouldn't hold my breath.)

If you have any specific questions, let us know. ;-)

Good luck,
Warren

Our first DW/BI project has definitely been a learning experience. We are a month away from the first rollout and working on finalizing the changes to the datamodel to begin ETL. In addition, our project has gone through two senior business analysts, with the second one leaving this week. I have been volun-told to step up as lead and see the project through to the end.

One of the top priorities is to identify the remaining tasks and determine: a) which are essential (critical); b) task priority; c) BA's responsibility; d) resource effort; and e) the plan going forward to accomplish the less essential tasks, such as administrative project documentation.

I have started a task list but want to make sure I haven't missed anything when I present it to the Business Sponsor (GM).

With only four weeks left, which tasks would you consider the absolute most essential to NOT MISS?

Any and all suggestions would be greatly appreciated.

Hi amir2,

You might want to consider an Agile approach. If after 5 months you are "... a month away from the first rollout and working on finalizing the changes to the datamodel to begin ETL. ", it seems really really unlikely that in a month you will finish your design and build and test and produce an "Enterprise wide DW/BI solution". The good news is it sounds like you haven't cut any code yet - so no effort wasted on that front.

I suggest de-scoping your first sprint down to a single dimension with a handful of attributes and maybe a fact with a single measure. Try to pick something clear and unambigous from a requirements perspective. If you can get this built, tested and released in a 2 week sprint you will build confidence with the business. You'll also prove your team's processes, tools and skills.

From my observations/experience, Agile methodologies suit BI/DW projects much better than waterfall methodologies.

Good luck!
Mike