Sometimes you have to say "What the Heck"? Paraphrased from the movie Risky Business.
Risk is inherent in everything we do. Whether you invested heavily in technology stocks right before the market crash of 2000, drive down the road in your car, fly over 100,000 miles on your favorite airline each year, or build a data warehouse, you need to have a plan of attack for things that will go wrong.
Project manager for a data warehouse project is a highly risky job description. Very early, in my building of data warehouses, I used to say that the old skills of project management didn't apply to the data warehouse. It wasn't until I ran across an excellent project manager by the name of Scott Barker that I learned I was not quite accurate in my statement. He once said to me that if there is not a plan in place, there is a disaster waiting to happen (I paraphrase, but the gist is accurate). He forced me to think about the whole process and not to allow the whole project to just run willy-nilly. Having my eyes opened for the first time has helped me become a better project manager/consultant.
From my last tip, you know that there are many reasons that your data warehouse can be less than successful. However, a good project manager can help alleviate the risks associated with the data warehouse and thereby help the success of the data warehouse to be higher than expected. Some of those risks (and this is not an exhaustive list!) are:
- Not having a clearly defined mission or set of objectives. While it may not be necessary to write and publish a clearly defined mission or set of objectives, it needs to be done. Writing them down will help keep the focus of the project.
- Using "Bleeding Edge" technology because that is what the technicians want, not because they necessarily solve a problem. I must confess here that I have fallen to this risk more than once. Like any good technician, I sometimes would prefer to play with the newest widget than solve a problem. This is where good project managers can help refocus the team toward solving the problem, not just learning the latest technology (drats!).
- Not having the appropriate skills on the team. Your team will be made up of business specialists and technology specialists. Business specialists know the business and the algorithms for the data they wish to analyze. Technology specialists come in many flavors including (but not limited to) database administrators, ETL tool jockeys, and presentation developers. Missing one of these flavors, having too many tools to use seamlessly, or having a person who causes problems in one of those areas (project killers I call them), will cause great risk within a project.
The excellent project manager will create a risk assessment for all of the risks that are defined for the data warehouse. The risk assessment will be a table that will have at least 4 columns (though I have seen more before)
| Nature of Risk |
Probability of Occurrence (1=low, 5=high) |
Impact Scale (1=low, 10=high) |
Impact Commentary |
| Clearly defined mission or objectives |
3 |
8 |
Increase change for scope creep and unsatisfied users |
| Bleeding edge technology |
2 |
7 |
May cause major learning curves and problems (bugs) in software; delay in timeline and project over budget |
| Project manager never built a DW before |
2 |
9 |
May not understand risks and tradeoffs of project |
| Low skill set |
5 |
6 |
Increase training costs and delay of project if not in timeline or budget |
| Project killers |
2 |
8 |
May need to shuffle staff and hire new members. Project delays can occur. |
The first column defines the nature of the risk of all of the possible risks that might occur within the project. The second column defines the probability that this risk is going to occur. The third column defines the impact on the project if the risk were to occur. And the fourth column is a textual commentary of what some of the impacts might be if this risk were to occur. This risk assessment should be looked at weekly (or at least every other week) to help predict a risk and define a solution before it can cause big problems.
Sid Adelman and Larissa Moss have published a book titled Data Warehouse Project Management, Addison Wesley, 2000, which talks about (among other things) evaluating risk. I highly recommend this book -- if you have not added this one to your library, then now is a good time to do so.
The Return on Investment (ROI) for an excellent project manager is priceless. Like the MasterCard ad says (at least in my dreams), "Good ETL tool - $100,000; strong corporate sponsor - $500,000; excellent project manager - priceless?" (OK, you caught me. I say that about having metadata too!). Having an implementation plan and a skilled project manager will alleviate many of the risks associated with data warehousing.
About the author:
Chuck Kelley is president and founder of Excellence In Data, Inc. and an internationally known expert in database technology. He has more than 20 years of experience in designing and implementing operational/production systems and data warehouses. Kelley has worked in some facet of the design and implementation phase of more than 35 data warehouses and data marts. He also teaches seminars, co-authored a book with W. H. Inmon on data warehousing and has been published in many trade magazines on database technology, data warehousing and enterprise data strategies. Please feel free to email him at chuckkelley@usa.net with comments (negative or positive) about this column or ideas for future columns.
For more information:
