Every data warehouse, business intelligence, and analytics initiative needs a checklist of additional, non-development-centric activities.
Every project manager has a checklist of the major activities that are part of every data warehouse / business intelligence / analytics implementation but there may be a few additional activities that have been overlooked. Do not ignore these essential non-development tasks and additional advice.
Important Non-Development Activities
Securing IT Commitment – This might seem to essential, especially if the data warehouse or BI program is an IT initiative. However, there are various forces at work in IT, since IT is not homogeneous. Some people in IT might believe that the data warehouse and BI are for reporting only, so there is no need for any level of business involvement or sophisticated approach.
Some people in IT might be afraid that the BI / analytics project will require too much business contact, 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. 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.
Commitment for any DW/BI/analytics effort must come from the CIO and all the direct reports, CTO, Chief Data Officer (or other data management leader), as well as the application development manager. Securing IT commitment means neutralizing or co-opting the fearful and those who would sabotage the program, especially those who agree in meetings but then dismiss the value of the DW/BI/analytics efforts and highlight its high costs and high failure rates within your organization as well as the costs and failures of other organizations.
Maintaining Communication – It is 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 project management 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 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 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. Do not bore the participants with details that will not interest them. If you do, they will leave early, multi-task with their laptops or other devices, and will not be there for the next meeting.
User Acceptance Testing – At delivery time, this should not be the first time the user has seen the product. The user should have multiple opportunities to see prototypes of the final deliverable. The user should have a chance to review and validate the deliverables at milestones during implementation.
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, resulting in unhappy users and BI/analytics that are not performing as desired / expected. The deliverable might be lacking the needed data, the level of detail might be inappropriate, the quality may be inadequate, the software might be too difficult to use, the metadata might be lacking, the mode of delivery might be ugly or unusable, etc… Prototyping will help ensure that users get what they need and can use the delivered result.
Closer Business Involvement – An Essential Component
The business must be closely involved in the development of any BI / analytics application but the challenge is how to get them interested. BI developers often complain 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 either means that the project will be delayed or go forward with an erroneous understanding of requirements.
What is needed is a way to spark 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 is a mistake to have only the power users or a select group from the user community. A broad sampling that is representative of the analytical user population is necessary to assure that all the users will get 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.
Possible Uses for Prototyping
Prototyping in DW/BI/analytics is a model or representation of the final deliverable, and a smart prototyping process would continue to present the user team with representations of the final product with continuous refinements until the users sign off. A prototype the users do not like should not be considered a failure; it is 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 management will be less likely to pull resources from the program, with less chance that the effort will lose key people and more chance that the budget will remain and the resources will be maintained to make the project a success.
Executive Training for BI / Analytics Use
Executive Training – Every DW/BI/analytics effort must have a plan to train the executives, the C level managers and the line of business (LOB) managers in the use of the final applications for the result to be successful. This presumes that these executives have an interest in the information the initiative is designed to deliver. If they do not have any interest, the question arises about whether the program has any value to the organization.
First, determine what are the executives’ business intelligence and analytics interests. Note: the level of interest should have been determined prior to finalizing the project agreement. Then, identify the method of delivery of that information for each executive (reports, dashboards, scorecards, inter-active application, etc.). Executive training should be one-on-one and should provide easy and straightforward ways of accessing their information, ending with how to get help when there are problems.
Conclusion
It is crucial to remember that not all activities in a data warehouse, business intelligence, and analytics program are focused on development. There are many critical tasks, continuing and one-time, that are non-development oriented, that must be included in every program plan.
