The death of the 100 page BI Strategy
As a Stakeholder or Product Owner
I want to understand where the BI strategy fits into the AgileBI process
So that I know when I need to have it created
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.
Other Blogs from this category.
As a Developer I want to understand how to run the Information Products workshops So that I can deliver reqiurements quickly Information Products As outlined in the Information Product post there are four major stages where the Information Product template is...
As a BI PractitionerI want to understand what order to gatther requirementsSo that I can gather them efficientlyWhen coaching or mentoring a new AgileBI team on the AgileBI Way one of the first things they ask is what is the standard order in which to gather...
The Issue: As a Stakeholder or Product Owner 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. My Answer: Adding members makes you slower. Initially, at least....
As a product owner I want I want to understand how to identify my stakeholders So that I know who can tell me what to do and who to tell what we are doing Other Blogs from this category
As a developer I want I want to understand how to use wireframing to confirm requirements So that I can build the right thing Wireframing is a technique we use to confirm two things: How does the user wish to see the content presented? Have we identified...
As a Product Owner or Developer I want I want to understand the different Agile testing methods So that I can decide which to useIn the word of Agile, there are currently three methods that can be used to improve our testing practices and to assist with enabling...
As a scrum master I want I want to understand how to make retrospectives fun So that I can keep the sprint team engaged The Data Requirements Gap There are two typical challenges when we gather data requirements. First, we capture and document the requirements in a...
As a Product Owner or Developer I want I want to understand how a Minimum Viable Product relates to AgileBI So that I can deliver faster and safer One of the ways to deliver quickly is to focus on what is often termed in Agile as a “Minimum Viable Product...
When talking about testing in a data project we have to first identify that the testing we need to do is similar but different to the testing we do in application development project. One of the useful way to identify these differences is to understand a number of the...