How to make BI less of a gamble

To avoid expensive BI debacles, use rules-based audits and proofs of concept to understand potential project pitfalls

Successful business intelligence and data warehouse projects share at least one common characteristic: explicit consideration of risk. And nothing ? not a detailed project plan, expensive technology or high-priced BI talent ? addresses risks as well as a rules-based audit RBA- or proof of concept POC- test. BI projects are peppered with risks, from data quality problems to lower-than-expected analytic value. These dangers often bring entire projects to a halt, leaving planners scrambling for cover, sponsors looking for remedies and budgets decimated. To convince one of the value of risk mitigation, the next example is presented. A company had 20 disparate sales applications around the world, leaving executives unable to report current sales without estimating. The goal was to accurately report current sales as well as chronological history of sales order line detail changes. The company hired one of the big-six consulting firms to create a single sales data mart on a Windows platform. After spending nearly $1 million and failing to achieve its goal, the company scuttled the project. The problem wasn t data volume or technology, it was data quality. As it turned out, a few of the sales applications restated history whenever a change was made. Consequently, accurately reporting all reversing entries and changes to every sales order line was impossible simply because the application didn t maintain that information. But the company didn t need to spend a million dollars to make this discovery. Consider the various approaches: Approach One: Spend $1 million to bring in a high-priced BI team, conduct planning sessions to create and agree to an elaborate project plan, conduct business requirements gathering sessions, document all requirements in professional binders, build a fantastic entity-relationship model, gather and map source data to that model, purchase and install your platform and start writing transformation scripts. Go to all this trouble and expense before you discover that the source data can t be transformed into the required target table. Approach Two: Take a laptop computer with sample source data, apply your business rules and, for less than $50,000, see if it s possible to create the target data table. Take this risk mitigation step before you commit to the full-scale project. Risk mitigation is all about saving money, time and grief. You be the judge: Spend big bucks to find out you have a problem, or spend a modest sum to test your approach? To address BI project risks, using the spiral approach familiar to many software developers is recommended. Developed long ago by Barry Boehm, this approach ? a key part of today s agile methodologies ? organizes software development steps into a spiral that s divided into four quadrants: Quadrant One: Determine objectives and constraints. Quadrant Two: Analyze risks, alternative prototypes. Quadrant Three: Oversee development. Quadrant Four: Plan the next phase. The spiral approach ? especially Quadrant Two ? is helpful because it explicitly addresses risk, whereas all other process models and software development methods are document driven. What s the difference? Document-driven approaches assume you can get complete, formal documentation. But to obtain clear, concise documentation, the solution must be clearly understood and defined prior to development, and anyone with experience knows this is seldom the case. In the $1 million example, the project was based on a document-driven approach. The company developed very detailed, professional documents beforehand, yet it encountered data quality problems in development. Had it taken a risk-driven approach, data integration problems would have been identified in advance, and it could have considered alternative solutions. BI projects invariably involve questions, issues and unknowns that must be addressed before you can be confident of success. Rules-based audit and proof of concept are risk-analysis techniques conducted in Quadrant Two of the spiral approach that provide answers, resolve problems and help you understand the scale and scope of the project at hand. The RBA is designed to answer a single, fundamental question: Can you take known data sources, add explicit business rules and create the target data necessary for subsequent analysis? If you can t answer this question with confidence, then you have no business risking company resources on the project. The POC takes the results of the RBA and scales the testing to prove the viability of production issues such as actual data volumes, processing time constraints and platform stress testing. Source and full article: www.intelligententerprise.coma>