Data Warehouse Project Management

Information Management Magazine, March 2006

Ken Pohl

Why is project management for a data warehouse different than most other applications? The answer is - a data warehouse is never really a completed project. Although there are phases with start and end dates, the data warehouse itself never reaches an end state until it is terminated.

Data warehouses are a different breed. They are organic and need to be nurtured to grow. Being organic, they are ever changing: dynamic, in other words. This is what makes project management for a data warehouse so unique and challenging.

There are two paths to project managing a data warehouse. The first is to approach the project strictly from a project management perspective by managing the project scope and timeline. The second route is to follow through with the traditional responsibilities of project management and, at the same time, do a deep dive into the inner workings of the data warehouse.

Understanding in detail what is "under the hood" will allow you to speak with authority on the capabilities and issues of the data warehouse. Intimate knowledge of the data and its relationships is the distinction between a generic project manager and data warehouse project manager.

A technical project manager is not the same as a data warehouse project manager because a data warehouse does not function like any other system. Only firsthand knowledge of what makes a data warehouse hum can brand someone as a data warehouse project manager.

This is not to be disrespectful in any way to all the good project managers out there, but the reality is, project managing a data warehouse is very different than other applications. If you have a peer who is a data warehouse project manager, take him to lunch and pick his brain to see for yourself.

Whether you consider yourself a data warehouse project manager or not, the following content is relevant to you as the project manager. You still need a team, solid requirements and a roadmap to deliver a quality product on time and within budget.

Project Team Members

As a project manager you sometimes have the luxury of putting your team together. Often, your team "appears" because the prior project has completed and these people are available. Keep in mind what was previously mentioned about the data warehouse being a never-ending project. When formulating your team, try to recruit people that you think will be around for the long haul, not just a quick stint.

Ideally you would like all of your people to have experience in data warehousing, but that is not always the case. At a minimum, you would like to seed your group with key people who have the desired experience and can spread their knowledge.

Project Manager Expertise

Because the project manager is the single point of contact and the visionary of the team, being knowledgeable in data warehousing would be very advantageous. As a competent project manager with no data warehousing experience, it is still possible to deliver a data warehouse as planned, but this requires strong reliance on the project team for subject matter expertise.

You may be thinking, "Well, I am the project manager, and I do not need to know the details." This is true, but to ensure a quality product and to be in a position to speak with authority about the data and workings of the data warehouse, you will need to get your hands dirty. If you are not intimate with data warehousing, at least ensure that a senior member of your team is.

Data Warehouse Business Requirements

As with any system, requirements are a good indicator of success (or failure). As the project manager who is overseeing the requirements gathering and analysis, prior knowledge of data warehousing is again a major plus. Knowing what questions to ask other than what you received as requirements will not be apparent. There are significant unspoken words that go into the design of a data warehouse that only prior experience or a true visionary will bring to light. If members of the project team have prior experience in data warehousing, make sure they participate in the requirements review.

To flush out these hidden details, you will need to gather the requirements from your users in bite-size chunks based on their attention span and availability. This will be an iterative process because you too will have work to do when gathering the business requirements. As the requirement sessions progress, you should build a mockup of the application based on what you have to date. This will become your platform for explaining how you view what the customer has requested. This mockup will help your customer make the leap from concept to reality by allowing him to visualize his ideas.

Your platform mockup does not need to be a working model at this point. A simple slide presentation or static Web pages will suffice. Don't be surprised if your business requirements change drastically at this point because your customers may now view what they were asking for in a whole different light. Before you call the business requirements a wrap, have a walk-through of the document to ensure all the content is still required and that no ambiguity exists.

A tip for who should be included in the audience when gathering your business requirements in addition to your users: representatives from development and testing. You may not need/want them initially, but you certainly want them involved once you get to the mockup phase. Getting early buy-in from all participants is of the utmost importance for any project to succeed.

Data Warehouse Technical Requirements

Now that you have a robust set of business requirements, it is time to begin developing the technical requirements. Your technical requirements document should maintain the same structure as the business requirements wherever possible. If you need to deviate, ensure there is traceability back to the business requirements.

Page 1 of 2.