Agile development and its impact on Business Intelligence projects has been a “hot” topic in recent months. It seems the more Agile is discussed the more confusion it creates among business and IT managers.

We, at BII Consulting feel it is appropriate at this time to provide some details on the dynamics of a typical BI project and how it perpetrates with Agile.

Let’s start with some basic attributes that are critical to any BI project:

  • Speed of implementations
  • Collaboration between IT and Business
  • Simple self-serving BI applications

Every time someone argues about the superiority of Agile they start with stating that BI project take months to years because of the use of waterfall approach.

Let’s be honest...waterfall approach should be the last item on the “blame list”

  1. Requirements gathering that takes way too long and focuses on every single detail to point of frustration
  2. The need for seclusion by developers during the design and development phase
  3. The huge GO LIVE expectation
  4. The lack of C-level sponsorship and engagement in the project

Agile means exactly what it means – nimble, responsive, alert and swift.

You can be all of the above with a waterfall approach as long as you move quickly, do not dwell on detail, are open to new requirements and are fast to implement them.

BII Consulting has over 20 years of combined BI implementations (hands-on) experience. All of our successful projects followed an approach emphasizing simplicity, speed and interaction with business.

We never felt that our approach needs a label or that it is that much different from anything else. To us it always meant what our slogans says: ”Business Intelligence done right!”

Let’s reiterate what makes BI projects successful and what it really means Agile BI in terms of individual project phases:

Project Planning

A.k.a. “requirements gathering” still continues to be critical part of every project. Define the scope well to avoid future “scope creep” but do not focus on the mindless details of individual reports or every single data attributes. Provide several real Measures of Success to establish accountability and make sure to identify any possible future risks.

Design and Development

We would argue that this is the core of the issue. Often design is separated from development when in reality these two should be overlapping. Start your development as early as possible. Devote some time to consider you design options but get your hands on the data quickly. Try to deliver early prototype to your users so they can see it, play with it and realize if their requirements need refinements or it is ok to proceed with full speed. After all developers should never expect business users to be able to define their application functionality early on and be 100% right.

Deployment

Here is the possible wrinkle to Agile. If you have separate development and production environments (and you should) you may have a considerable time lag between implementing modifications in DEV and moving them to Prod. We suggest that if your data source systems are mature then your DEV environment should connect directly to these and provides business users with interim solution to analyze data and refine model functionality with actual data. If you source applications are in development stage, it will take some juggling ability on the part of the developer to connect to both DEV and PROD data source as needed.

Above and Beyond Single BI Project

It is important to understand that each project’s scope is defined so well that it is only a small part of a much larger initiative in which a company’s ultimate goal is to leverage BI as a competitive advantage.

In order to achieve this status, consider these important elements of BI Strategy:

  1. Understand the different stages of BI environments (Analytically Impaired • Localized Analytics • Analytical Aspirations • Analytical Company • Analytical Competitor *)
  2. Identify in which Stage your company currently operates
  3. Understand the steps needed to move from one stage to another
  4. Prepare a Road-map that highlights the desired stage and time-frame to get there (Becoming Analytical Competitor is not necessarily a must for all companies)
  5. Understand your business processes and critical metrics for each of them
  6. Identify how each BI project aligns with these processes and which metrics it provides

* Thomas H. Davenport, Jeanne G. Harris, Robert Morison, Analytics At Work: Smarter Decision, Better Results (Boston, MA: Harvard Business Press, 2010).