What makes a good BI Project Manager

The BI Project Manager will most likely be involved at some point in both Data Warehouse Project Management and BI Project Management.   What is the difference?   The BI Project Manager would be involved with Dashboard/Reporting type projects while the Data Warehouse Project Manager would be infrastructure related (OS/Database upgrades, Infrastructure upgrades, New Data streams)  So what would make a good Project Manager in the BI space?

1) Understanding of the Data.  There is a difference between a project involving existing data vs new data.   Existing data sources could involve just a front end developer whereas, new data sources will involve your ETL guy, developers, QA for the backend data, QA for the frontend, etc.   Your time estimates will be vastly different since the project will be larger in scope.

2) Understanding of the Infrastructure.  A Data warehouse will involve more infrastructure than your typical database system.  A data warehouse might have an ETL server, a database server, a data mart, a reporting server, etc.    Now some environments will have the ETL/DB server combined there are many pieces.   There might also be various feeds providing input from source systems and exporting data to downstream systems.   Depending on this setup, you will need to update your business resources for those elements when upgrading for testing purposes.

3)  Don't lump all projects together under one work stream.   You can have an ETL guy working on a DB upgrade while your Dashboard guy is working on a dashboard upgrade.  That's two separate projects with different timelines.

4) Reporting or Dashboard projects should probably be handled using AGILE methodology especially if your user community has not provided sufficient requirements.   It just works out better for everyone if the business is involved in the development cycle.

5) Understanding of IT projects in general.  A lot of shops use Sharepoint for a document repository.   Although Sharepoint and BI are separate entities, there are Sharepoint BI projects because these two spaces are merging for general reporting.   Also understanding the testing cycle of system testing, regression testing, UAT, etc.

6) Understanding of what is a realistic timeline from your developers.  Sometimes developers pad their estimates which is fine but your pad should be closer to 20% than 50%-75%.   A good understanding of common developer timelines will help you be successful in the long run.

I hope this helps and would appreciate any feedback.