In the Beginning

Originally the BI strategy was aimed at defining the scope and expectations of 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 enable this change
• a roadmap of initiatives that should be funded to invoke this change

The BI strategy document was often a big 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 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 discussing the benefits and funding required to gain these benefits; the entire session was spent explaining the basics of a Data Warehouse and Self-Service Business Intelligence.   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 t-shirt.

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. This approach is ok, but then somehow it would turn into a detailed promise that could not change, no matter how much 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 considerable 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 initiative 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 to be delivered are included in this document, and, therefore, the project 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 meet constantly, review and then change the BI Strategy document to garner these signatures was often disproportionate to the level 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 and approved it was then “placed on the shelf”.

I then noticed many 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 the core assumptions the strategy was based upon were 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 be able to be continuously 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 Bathwater

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

Both of these criticisms 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 a Business Intelligence architecture that will ensure we avoid building silos

It 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.