5 Factors In Agile BI

IT teams tasked with keeping the business informed have expended vast resources defining a methodical, painstaking BI system development life cycle that typically goes something like this: Gather requirements from business users. Design a data model to support those requirements. Scout out data sources. Load all that data into a starlike schema. Develop BI objects. Roll out the final product to end users.

Unfortunately, the quest to achieve perfection often results in anything but ideal results. We've focused on creating the perfect factory and assumed that once we had that, it would automatically produce the perfect product. The problem is, when it comes to BI, perfection is all about context. What was considered ideal back during the requirements process isn't so great now. Is it the business user's fault that the context changed? Clearly not, but the fact is, just as companies need to be agile to succeed, the process by which we deliver BI analytics also needs flexibility baked in.

BI agility is achievable. BI perfection is not.

Below we outline five elements that together promote an agile enterprise BI environment. We delve deeper into this topic in our full report, at informationweek.com/analytics/agilebi.

1. Agile Development

Typical data warehousing development cycles are black holes. We've seen it take months for business users to have their analytical needs transformed into operating reports that show meaningful data. We clearly need dramatic improvement.

At the highest level, common development methodologies such as Scrum and Extreme Programming are being applied to the problem. The basic underlying premise is the need for an agile, iterative process that shortens development cycles and speeds time to market for BI requests. There's no reason you can't deliver value to end users in weeks--or even days or hours--rather than months. An agile methodology can fundamentally change how your users perceive the value of BI services in a positive way.

2. Agile Project Management

Agile development requires agile project management. In a conventional hierarchical process, planning is done at the beginning of the process and often results in unwieldy, 100,000-line work schedules. In contrast, agile project management focuses on a continuous planning, execution, and feedback loop in which:

>> Planning is done at the beginning of each cycle, rather than once.

>> "Lessons learned" sessions are done at the end of each cycle, not just at the end of the project.

>> Scope can be changed during development--yes, agile allows and, to some extent, even welcomes scope creep and manages it by reprioritizing deliverables.

Agile project management delivers great benefits to both IT and the business. Requirements are precise and clear. The risk of underdelivering is reduced, as each cycle delivers new sets of usable functionality. Quality becomes part of development as bugs are discovered and fixed early.

But what about the project management office? Can you really bypass the review cycles, scrutiny, and official sign-offs? At the end of the day, what really matters is the return on investment, which tends to be greater when agile practices are leveraged because the results are aligned more closely with business needs--something users can continually confirm. Agile project management takes the monolithic and structured documentation and approval approach and skins it to the bare essentials: Single-page charters and verbal sign-offs after demos are good enough.