How To Make BI Less of a Gamble - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management

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.

• Data quality unknowns make BI projects risky. Dashboards, reports and analytic applications are only as good as the data they contain. Many projects, begun with high hopes and executive backing, founder in a muck of dirty data and go well over budget to cleanse and correct it. While data quality, profiling and other tools may be essential as the project gets under way, BI project managers would be wise to assess early the risk that data quality poses. This will give everyone a realistic picture before budgets are settled-and the ROI clock starts ticking.

• Top-drawer BI teams cost a bundle. Do you really want to point such specialists at discovering that you have bad data and figuring out how to fix it? Consider assessing risk with less expensive, more easily available means. Save the big bucks for the proven plan.

• Assessing risk to BI projects is often a one-off operation. Determining the quality of source data should become a routine part of BI project management. Business rules can help sort out the factors that need to be assessed; automating rules will save steps and money. Developing rules will also clarify business expectations about data-and what the organization is willing to spend to add missing data and correct inconsistencies.
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. A project I worked on a few years ago convinced me of the value of risk mitigation. The 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?

 Rules-based AuditProof of Concept
Source DataSample data onlySample of complete data set
PlatformConducted on an independent, isolated platform, such as a laptop computerConducted on an isolated platform or platform of choice for testing batch cycle times, network connections, CPU performance, elapsed time performance and other variables
Testing GoalApplying explicit business rules to sample source data in order to build target tablesScaling the results of a business rules audit to assess production-level data volumes, processing time constraints, platform stress and other issues

Take the Spiral Approach

To address BI project risks, I recommend using the spiral approach familiar to many software developers. 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 our $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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 3
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

10 Things Your Artificial Intelligence Initiative Needs to Succeed
Lisa Morgan, Freelance Writer,  4/20/2021
Tech Spending Climbs as Digital Business Initiatives Grow
Jessica Davis, Senior Editor, Enterprise Apps,  4/22/2021
Optimizing the CIO and CFO Relationship
Mary E. Shacklett, Technology commentator and President of Transworld Data,  4/13/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Planning Your Digital Transformation Roadmap
Download this report to learn about the latest technologies and best practices or ensuring a successful transition from outdated business transformation tactics.
Flash Poll