The Value of Failure in BI

Failure is not an option.

Thanks to Apollo XIII, this famous phrase has become something of a mantra in both business and technology circles. But now some business thinkers believe many companies overlook what we might call the value or power of failure. As a recent HBR article put it, “Innovation experts have long argued that companies should be more tolerant of failure.”

The piece points out that the differences between “positive failure” and more dangerous types of failure, like not gathering the right sort of data and inputs. Failing to adequately test and prototype ideas in the real world is another high-risk mistake.

Positive failures occur when organizations put lessons learned to work in the service of product innovation or performance improvement. The idea is that mistakes and missteps help organizations “fall forward” as they find their way in developing new products or refining existing services.

This brought to mind the notion of failure and errors within BI delivery. Given that a famous NCC survey has said that 87% of BI projects miss their objective, one would think there’s no such thing as positive failure in BI. But missed objectives are also opportunities to get valuable feedback on what users truly need.

The Agile BI approach is designed to make failure useful. Agile BI teams expect that their first prototype will not be the final iteration of the solution. They expect to get feedback from end users on what needs to be changed, and that feedback is the engine that drives future iterations of the solution, which are delivered in quick succession. Missing the mark with prototypes is the way in which Agile BI teams empower their users to articulate their needs in a meaningful way, and to do so as those needs change.

The process identifies usability and data issues quickly and early in the process. Better still, it saves companies money by highlighting issues at a time when rework is very cheap as compared to the expense of changes made during User Acceptance Testing. In traditional waterfall development, users get their first glimpse at what is being built long after initial requirements have been gathered. At that point, layers of technical plumbing have already been set in stone. As a result, fixes take longer and cost more.

In this way, Agile BI is analogous to the “fail faster” approach in pharmaceutical development – that is, the sooner you find fatal flaws and errors via clinical trials, the sooner you reach a successful final product, or even a blockbuster drug. In that industry, researches run sophisticated computer simulations to identify compounds that could be good candidates for full production. In Agile BI, the process of identifying and prioritizing specific functionality lets developers and IT leaders determine what to deliver first as well as what types of tools will deliver the best ROI.

However, Agile BI differs from pharma-development in important ways. For one thing, Agile BI developers don’t have to start from scratch in developing the core of the products. There is solid base code to build on. Nor do they have to invest months or years in understanding the failure, or go all the way back to the drawing board if a product fails. Instead, they can launch new prototypes after adjusting the elements of the solution. In Balanced Insight Consensus, this is even easier using Information Packaging, which is a technology-agnostic model driven development approach.

Information Package artifacts consolidate user requirements in a non-technical way and serve as an excellent discussion tool to facilitate collaboration with business sponsors. Users can more clearly see the relationship between data sets and types of information, and also gain a stronger sense of what BI tools are capable of.

Once an effective solution has been reached, there is another similarity between Agile BI and pharma-development – the ability to enhance it. Successful medications are often improved with extra-strength or time-release capabilities or shifted to different forms (e.g., gel tablets or liquids) suitable for different types of patients. This is how good products get better.

It works much the same way in BI. Useful applications that users have embraced can be enhanced with new capabilities and usability features. The benefits to businesses are easier access to quality data, improved operational insights and, ultimately, better decision making. And organizations that use an agile development approach can realize these gains sooner and more cost-effectively than those using waterfall.

In Agile BI, then, failure isn’t really failure at all. In fact, it’s an inherent part of the process and an enabler of iterative improvement. In other words, failure can play an important role in successful BI delivery.