• // Business Intelligence
  • // Data Warehousing
  • // Business Analytics

Four Practical Approaches to Improving BI System Quality

This post is third in a series about BI teams executing faster.

Do you have to write the dreaded entire company system-not-available email? Do you spend most of your time fighting fires? Does something break every week?  These are often symptoms of organizations not spending enough effort on quality.  Counter intuitively, quality efforts often reduce total implementation time. Prevent problems by putting more effort into design and fixing the root cause of problems.

Quality control is not fun and it is not glamorous. Hardly anyone enjoys testing, or having others review and criticize their work. No one likes to see their important work delayed by change control processes and reviews. Worse, the results are not tangible.  No one notices the system quietly and boringly humming away. So quality is often the first place that gets cut.

However, the results of cutting quality are crippling in the long run.  The worst case is loss of valuable information, like losing leads or misallocating inventory. Nearly as severe, users stop trusting the information and stop using the system. In less severe cases, development teams spend 75% of their time fixing bugs.  Fixing code is time consuming, then rerunning processes to fix the results of bugs often causes system down time and wastes even more developer time on monitoring.

Here are four practical approaches to improving system quality.

1.  Track Bugs.

Use a bug tracking system and review the aggregate results for causes and trends. Every BI environment should have and use a bug tracker. Without bug tracking, customers feel their concerns are lost. Further, it provides a way of tracking important but non-urgent fixes. Without bug tracking, managers do not know if efforts align with needs.  Tracking also provides a basis other than customer complaints to justify new resources.

2. Explain Unplanned Down Time.

Managing unplanned down time is crucial. Down time prevents the normal course of business, and has direct cost and revenue impacts. However, many BI systems do not track down time or categorize the underlying causes.  After the system comes back up, conduct an after event review. Root causes often vary from the presenting symptom.  For example, late completion of nightly batch is often reported as a series of bugs in the ETL code, when the real problem is inadequate processing power that leaves no room for normal nightly variation.  Similarly, report down time often presents as many small hangs and glitches when the underlying problem is unpatched software or poor configuration management.  Down time is a big deal to your users. Prevent it by understanding the root causes.

3. Invest time on quality.

One important tactic is to reserve time to invest in the system and to pay down technical debt.  There are times when writing fast and dirty code is appropriate: pilots, business emergencies, mergers, external events. However, every program should invest in fixing the band-aid and jury rigged code.

Ironically, tightly managed teams that are responsive to business requirements have trouble taking resources away from directly serving the business to invest in the system.  We recommend systems over one year old should reserve 15-20% of efforts for system improvement, beyond simple bug fixes. This time should go to reliability, manageability, performance tuning, tool upgrades, and documentation.

Set this investment expectation in advance. Planning in investment reduces the perception from end users that quality efforts are cutting into development that directly serves business needs.

4. Remove developer irritations that damage quality.

Developers respond strongly to tedious time wasters. It is not purely rational, but it is an important fact of life in BI environments.  Find out what they are and fix them. Is the source control system not being used because it takes 2 minutes to check out a file?  Are data models not updated because only half the team has licenses?  Is the test environment so slow that developers do not test on real data? Does the design document template consist of 10 pages of fluff and 2 pages of useful information? Does the database drop user connections after 30 minutes, forcing developers to reconnect 5 windows after every meeting?

Quality efforts usually involving telling developers that they are not doing good work and that you need them to jump through more process hoops. Fixing annoyances is important to get buy-in, because it makes the quality process something that helps developers and feels good.

Improving system quality is fundamental to the success of BI systems. Build it in with tracking, time, and fixing your processes.

by Tom Victory, Principal Consultant

© DecisionPath Consulting, 2011

Created by Matrix Group International, Inc. ®