The AgileBI approach has fundamentally changed the way and the more importantly the focus of why we deliver Business Intelligence strategies.

In the Beginning

Originally the BI strategy was aimed at defining the scope and expectations for Business Intelligence within an organisation.  It was often a prerequisite to a business case that was required to justify and gain approval for funding for a new Business Intelligence implementation or initiative.

To deliver this strategy document in the past we would spend considerable time interviewing stakeholders and create a large Business Intelligence Strategy tomb which included:

• an outline of what business intelligence is
• the current state of business intelligence within the organisation
• the desired future state
• the benefits to the organisation of investing to move to the future state
• a high level business intelligence architecture
• a recommended approach for the people and processes required to make this change
• a road map of initiatives that should be funded to invoke this change

The BI strategy document was often a large and confused document that included trying to explain what Business Intelligence was to a group of business stakeholders who had often never encountered its outputs or its benefits.

(CTS) Confuse The Stakeholder

It would also have technical jargon that we in the Business Intelligence world (and IT in general) love to use, and of course it would have the full versions of these TLA’s (Three Letter Acronym’s) as if that would make them easier to understand.

One of my favourite TLA culprits is OLAP (Online Analytical Processing), and it is probably one of the worse.  It is not online or a processing engine in the way a stakeholder would expect, as you typically cannot manually enter data into it.  It is not Analytical in the way predictive analytics is typically defined, and we must remember it was coined before the mashup of BI and Analytics into the definition now dominated by in-memory data discovery tools, which has only occurred in the last couple of years.   What OLAP really is, is just a big old centralised and reusable pivot table, but we would never say that.

I have sat through many initial BI steering committee meetings where rather than discuss the benefits and funding required to gain these benefits, the entire session was undertaken explaining the basics of a Data Warehouse and Self Service BI.   You know you are in trouble when you start trying to explain to a stakeholder what a Slowly Changing Dimension Type Two (SCD2) is and why they should care.  And yes as much as I hate to admit it I have been there done that and got the tshirt.

The big guess upfront

To develop the BI Strategy document we would try and guess what should be delivered across the organisation over the next 3 – 5 years, which is ok, but then somehow it would turn into a detailed promise that could not change, no matter how the business processes changed over that time or how the environment that organisation lived within changed.  It was in fact one of the largest big guesses upfront (BGUF).

The curse of the Signatures

As well as spending a large amount of time and effort undertaking the interviews and creating this tomb, we would also spend a large amount of time and effort getting the document approved by stakeholders.  There is something that happens to many stakeholders when they are required to add their signature in the approval column of a document.  All of a sudden every line gets read and the context of each and every line is discussed and litigated.  It’s not their fault, as they know that typically when they sign that document, it’s is written in stone with any changes required in the future akin to pulling teeth.  They also know that once the new Business Intelligence Intiative budget has been fully expended their chances of getting more funding are minimal, so they want to make sure that all the things they need delivered are included in this document, and therefore the delivery team can be made accountable for delivering it.

Large requirements up front, no changes allowed, everything locked in stone, accountability based on a document, all the things that by using an AgileBI approach we aim to fix.

And the amount of effort required to constantly meet, review and the change the BI Strategy document to garner these signatures was often disaportionate to the amount of the effort deployed to deliver a solution.

Lock it in the safe, and lose the key

In my experience once this document was reviewed, approved it was then “placed on the shelf”.

We then noticed a number of problems were often encountered in the future as a result of this approach:

• The validity of the strategy was not reviewed when major technology or organisational changes occurred
• The stakeholders often had minimal knowledge or experience within the Business Intelligence domain and so were not able to validate the strategy. This often lead to a mismatch of expectations between what was delivered and what was expected.
• If a core assumption the strategy was based upon was proved to be invalid, the strategy and document could not be reviewed and refined as it was approved and could not be easily changed

In my experience the need for a BI Strategy was not so much a technique for identifying where the organisation wanted to go, but more a document to secure funding for a large Business Intelligence project.    Providing an effective business intelligence capability within an organisation is not a one off project, it is an ongoing capability that requires constant investment and improvement.  This requires any Business Intelligence Strategy to also be able to be constantly invested in and improved as the business, technology and delivery approaches change over time.

Don’t reinvent the wheel or throw the baby out with the bath water

One of the critisms of the Agile approach is that there is no discipline, people just make stuff up.  Another critism is that Agile doesn’t produce documentation.

Both of these critisms are wrong.

Agile done right has discipline built into every step and the right documentation is created at the right time.  Agile doesn’t change what we do, it changes when and how we do it.

So using an AgileBI approach we still need to:

• Educate our stakeholders on what Business Intelligence is
• Identify benefits that would arise from the investment required
• Gain approval to dedicate resource to deliver an ongoing Business Intelligence capability
• Set an organisation wide vision of where we are and where we are headed
• Create a roadmap that outlines the steps we will take to get us there
• Define an Business Inteligence architecture that will ensure we avoid building silos

Sounds like the BI strategy document I mentioned at the beginning doesn’t it.

AgileBI, same things, done differently

An AgileBI approach delivers all these things, just not at the beginning of a project and not in the form of a 100 page BI strategy document which is locked in stone.

Each component is delivered as part of the AgileBI process, when it is required and not before. And of course each component can be changed in the future, by having the right conversation with the right people, as we find out things we didn’t know or didn’t expect.