What Important Activities Did You Leave Out?
By Sid Adelman
You have a checklist of the major activities that are part of every data warehouse implementation but there may be one of two you left out. These four are ones that many organizations left out to their dismay.
- Securing IT Commitment – This might seem like a no-brainer especially if the data warehouse is an IT initiative. However, there are various forces at work in IT. IT is not homogeneous. Some in IT might be stuck in the mindset that the data warehouse is just a reporting mechanism and anything the data warehouse can do, can be done with COBOL. Some in IT might be afraid that the data warehouse project will get close to the business, that they will have to learn the business and that dealing with the business takes them from the technical world into an arena that is not to their liking and requires a new level of attire and hygiene. Others in IT who produce reports for the business may feel the data warehouse is encroaching on their empire and their relationship with the business. The commitment needs to come from the CIO and all the direct reports, CTO, data manager (to whom the DBA and data modelers, and data architects report), as well as the application development manager. Securing IT commitment means neutralizing or co-opting the assassins especially those who agree in meetings but then skulk around dismissing the value of the data warehouse and highlighting its high costs and high failure rates within your organization as well as the costs and failures of others.
- Maintaining On-Going Communication – It’s critical that the BI/DW Team maintain communication with the business and especially the business sponsor as well as with IT management. The communication should be maintained continually throughout the development lifecycle. The BI/DW Team needs frequent feedback, input, and validation from the business and IT. This includes active participation in meetings as well as approvals on deliverables. The BI/DW Team manager should take every opportunity to praise the business participants as they are critical to the success of the project. Status reports to the business should be as frequent as it becomes necessary and valuable to impart information on the status of the project. This would include milestones and budget burn rates. In addition, status reports to IT management should include technical status including hardware and software issues, and any issues that are in the IT domain and can be solved by IT. As the status report identifies issues, it should also indicate plans to resolve those issues. Face-to-face meetings with business and IT management should be crisp and only address status and issues that are relevant. Don’t bore the participants with details that won’t interest them. If you do they will leave early, play with their BlackBerrys®, and will not be there for the next meeting.
- User Acceptance Testing – The primary idea is that at the time of deliver, this should not be the first time the user has seen the product. The user should have an opportunity to see prototypes of the final deliverable. The user should have a chance to review and validate the deliverables at multiple points along the implementation way so there are no surprises and very little chance the user will say (as we have so often heard), “This isn’t what I want. Weren’t you listening? I can’t use this crap.”Business users have a difficult time articulating their requirements especially the types of analyses they expect to perform, the business metrics, and the key performance indicators on which they run the business. The traditional approach has been to gather the requirements up front and not be in contact with the business until the testing phase, at which time the users are often unhappy with the deliverable. The deliverable might be lacking the needed data, the level of detail might be inappropriate, the quality may be inadequate, the cubes might be hard to negotiate, the BI tool might be too difficult to use, the metadata might be lacking, the mode of delivery might be ugly or unusable, making for an unhappy business user and a lightly used data warehouse. Prototyping is a means of making sure the user gets what he or she needs.
The Need To Have The Business More Closely Involved
The business must be closely involved in the development of any BI application but the challenge is how to get them interested. BI developers are constantly complaining about the business people who are invited to meetings but do not show up or who send underlings ill equipped in their understanding of the business requirements or unauthorized to make decisions. This means that the project will either be delayed or go forward with an erroneous understanding of what’s needed. What’s needed is a way to peak their interest and prototyping can be that means. As business users see an evolving set of deliverables with their data and a progressing solution to their informational needs, they will choose to be involved and will need little prompting to attend meetings and participate in demonstrations of the prototypes that will become their final deliverables.
It’s a mistake to have only the power users or a select group from the user community. A broad sampling representing the users is necessary to assure that all the users will be getting the information they need. An additional advantage of having a diverse spectrum is that those involved will help to sell and champion the project to their respective groups.
How Prototyping Can Be Used
Prototyping in the data warehouse world is a model or representation of the final deliverable and a smart prototyping process would continue to present the user with representations of what they will be getting with continuous refinements until the users sign off. A prototype the user doesn’t like should not be considered a failure; it’s a source of information to be able to correct a problem that could have caused a real failure if the original design made it into final production. The primary idea of a prototype is to make mistakes and then to correct them.
Prototyping has the added benefits of keeping both IT and business management involved and interested in the project. This means they will be less likely to pull resources off your project. There is less chance that you will lose key people and more chance that you will get the budget you need and the resources you need to make the project a success.
- Executive Training – How do you plan to train the executives, the C level managers and the line of business (LOB) managers? This presumes that these executives have an interest in the information the data warehouse is delivering. If they don’t have any interest, you might ask yourself if what you are doing has any value to the organization. First you need to know what interests the execs. Note: the level of interest should have been determined prior to finalizing the project agreement. You need to know how they want the information delivered. For example, a daily report pushed to them, a result accessible on your intranet. Training of execs should be one-on-one and should provide easy and straightforward ways of accessing their information. The last part of executive training is how to get help when there are problems. When looking at support, it’s often best to have the trainer being the primary support.
About the Author
Sid Adelman is a principal consultant with Sid Adelman & Associates, an organization specializing in planning and implementing data warehouses, performing data warehouse and BI assessments, and in establishing effective data strategies. He is a regular speaker at “The Data Warehouse Institute” and IBM’s “DB2 and Data Warehouse Conference”. Sid chairs the “Ask the Experts” column on www.dmreview.com, and has had a bi-monthly column in DMReview. He is a frequent contributor to journals that focus on data warehousing. He co-authored one of the initial works in data warehousing, Data Warehousing, Practical Advice from the Experts, and is co-author of Data Warehouse Project Management with Larissa Moss. He is the principal author of Impossible Data Warehouse Situations with Solutions from the Experts and his newest book, Data Strategy, was co-authored by Larissa Moss and Majid Abai. He can be reached at 818 783 9634and email@example.com. His web site is www.sidadelman.com.