Bridging the BI Delivery Gap

This post is excerpted from our White Paper, Enabling Agile Business Intelligence with Balanced Insight Consensus.

Everyone in BI circles is aware of the need for effective requirements gathering, but we don’t think the difficulty of requirements definition is fully understood. In the past, the main issue has often been nebulous or poorly defined requirements. This was largely a semantics problem that arose because business and IT don’t always speak the language.

While the translation issue remains a challenge today, the need for speed has greatly intensified it. Today, business cycles are turbo charged and markets change so quickly that uncertainty is a constant. Companies may seek to shift strategic direction very rapidly. All of these factors directly – and drastically – affect BI needs. Requirements change so fast that developers can’t possibly deliver against them before users are looking for more or different functionality from their BI apps. Traditional waterfall development methods, with their “big dig” release cycles, are particularly vulnerable to this phenomenon, which we call the delivery gap.

The delivery gap is a common problem in business intelligence. It occurs because requirements gathering is complete at a point in time, while the business continues to evolve during the months a project is being implemented.

This phenomenon occurs when IT or development teams deliver solutions that meet requirements as stated during previous gathering phases, but not what the business needs at the time of delivery. For example, business requirements are gathered in January for a new BI application. The development team receives those requirements, diligently asks questions about and records the needs of the business, and then goes away and develops a solution to meet those needs. In June, they deliver the solution.

Meanwhile, over in the business, market conditions and business priorities have been changing frequently. A new product line launched in February. The company entered a new region in March. A senior sales analyst joined the team in April, with different ideas for how to look at customer data and inventory numbers.  In May, the company acquired a competitor’s product line. Each of these changes meant additional capabilities or data was necessary for the BI application to meet its objectives. It’s no wonder, then, when the business is underwhelmed by the solution built from January’s specs, when it’s delivered in June.

BI veterans are all too familiar with this situation, but it’s not just a frustration.  It can have a significant negative impact on the business. Sunk development costs into components that need complete overhauls or major rewrites. Missed opportunities due to lack of insight into the business. Lost credibility for IT, which can hurt senior sponsorship and funding for future initiatives and undercut adoption rates.

In a fixed and finite world, where one set of requirements applies forever (or even for a year), there would be no need for Agile BI. But Agile BI reflects the reality that requirements change when business conditions and informational needs change. That change is nearly constant today. The delivery of a series of controlled-scope releases in quick succession puts practice over theory and gives users a chance to refine requirements, restate preferences and make suggestions on usability based on hands-on experience with a working prototype. The idea is to master a few core functionalities with highest business priority, then enhance and expand those, while augmenting with new features based on business need. In other words, Agile BI is your best bridge across the delivery gap, and to move at the velocity of business today.