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.

Upgrading from SQL 2008 to SQL 2012

One of my clients was upgrading from SQL server 2008 to SQL server 2012.  I want to describe some of the items to look out for when migrating.  In this case, the client had already installed a new virtual environment so the infrastructure was in place.   Now what

1. Freeze all changes on production - At some point you are killing yourself if you are trying to migrate one set of reports, packages, and jobs that are consistently changing.   
2. Analyze what packages are currently being used and what packages can be sunset.  Analyze what jobs can be used and what jobs can be sunset.  If any of the jobs send data to another system, attain the contact name for that data for testing after migration.  Analyze what procedures you currently use and what can be sunset.
3. Determine who the business users of the reports are.  Analyze what reports are being used and what can be sunset.
4. Create your timeline.  (Remember that not all jobs are created equal.  Some jobs have 1 step and others have 101 steps.  Don't overload one developer with a one step job to the same timeline as the developer with the 101 step job.)
5. Allow time for testing by peers of the jobs,packages and procedures.
6. Also note that SQL 2012 is not as forgiving on package performance as SQL 2008.   In 2008, you can have a package that performs 50 tasks and it works just fine.  However in 2012, the packages need to be broken up into fewer tasks.  Suffice it to say, that you need to allow time to peformance tune the data warehouse cycle.   Some of this testing has to happen in production.   
7. Allow time for Pre-UAT by your IT team
8. Allow time for UAT by the business teams

Best of luck in your migration/upgrade.   As a follow-up, the upgrade to 2012 is great for the business.  My clients business users love Power Pivot and this also opens up some Power BI capabilities as well for Sharepoint solutions.