The death of the 100 page BI Strategy
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.
Start your AgileBI journey with us.
Its that time of year again, New Year has been and gone, Christmas is but a memory, in half the world Winter is mid flow and in the other half (including my half) are mid summer wearing shorts and jandles.As well as good friends, good barbecues and great...
It's that time of the year (where the hell did 12 months go!) where Gartner announce the latest version of their Magic Quadrant for Business Intelligence tools, or this year what they call "Modern Analytics and BI Platforms".Im always interested in which...
As a Stakeholder or Product Owner I want I want to understand if constantly adding Agile Team members is a good idea So that I can have a valid conversation with my Product Owner and Scrum Master Initially at least! VelocityWhen building a new AgileBI delivery team,...
February has come around again, the Gartner BI conference is running in Sydney Australia, people I know are in Sydney drinking beer, I am not, and the Gartner Magic Quadrant for Analytics and Business Intelligence Platform is out.Can I take a little space to rant (of...
As a Stakeholder or Product Owner
I want to understand who should attend the steering committee
So that I know I have the best representation
As a Stakeholder or Product Owner
I want to understand what experience a Project Manager needs
So that I know if they are suitable as a scrum master
3. AgileBI Things: Agile Data Science, Governed Data Lake, The Agile Data Warehouse A Practical Approach
Source: Pixabay Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIN Pulse. This article below is a copy of "3. AgileBI Things - 2017-04-09". Shane also writes on AgileBI concepts at AgileBI Guru. 1. Agile Data Science When the new world of...
Source: Mosman Library Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIN Pulse. This article below is a copy of "3. AgileBI Things - 2017-04-02". Shane also writes on AgileBI concepts at AgileBI Guru. 1. Big Data Papers I still hear...
Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIN Pulse. This article below is a copy of "3. AgileBI Things - 2017-03-26". Shane also writes on AgileBI concepts at AgileBI Guru. 1. Automated Testing Goals So I have finally been lucky...
Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIN Pulse. This article below is a copy of "3. AgileBI Things - 2017-03-19". Shane also writes on AgileBI concepts at AgileBI Guru. 1. Big Model Upfront When delivering an AgileBI project one...
Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIn Pulse. This article below is a copy of "AgileBI Things - 2017-03-12". Shane also writes on AgileBI concepts at AgileBI Guru. Image source: Pixabay 1. SQL Server Temporal tables, automating...
3. AgileBI Things – Data Lakes vs Data Warehouses, Change Management in an Agile approach, So you wanna be a Scrum Master
Shane writes an AgileBI series called "3 AgileBI Things" published on LinkedIN Pulse. This article below is a copy of "3. AgileBI Things - 2017-02-19". Shane also writes on AgileBI concepts at AgileBI Guru. 1. Data Lakes vs Data Warehouses I think in the next few...