The Maturity to Coach
BI is Hot, Hot, Hot
The BI (Business Intelligence) market in NZ seems to have gone ballistic again with lots of customers looking to refresh their aging legacy BI technologies and reporting processes.
It is being driven by a combination of the BI modal concepts proffered by the likes of Gartner, the refresh of aging technologies by the majority of BI software vendors, advent of Agile in the BI space and finally the plethora of Analysts with the new cool title of ‘Data Scientist’ who want to play in the Big Data space.
As a result, I have a number of customers now asking me to assist with BI procurement evaluations, health checks of failing data warehouse environments and training plans for new BI Architects.
Each of these engagements will require lots of ‘DO’ing but as part of our new business model I want to make sure I also teach or coach the customer’s permanent team, as we deliver, so they are sustainable after I finish.
So that made me think about what I need to have in place to have the Maturity to coach in these three areas:
For the BI procurement process, I know that a bunch of MOSCOW requirements wth words like “must have a fast response time” and “must provide average annual revenue” are ridiculous requirements to base decisions for large BI software investments upon.
If a BI tool can not average numbers by now, I would be gobsmacked. Revenue data should be identified as part of the BEAM (Busines Event Analysis Modelling) requirements, and the relevant data layers should ensure it’s readily available for reporting.
If there is a need for business rules to enable revenue to be averaged, as it cannot be simply aggregated, then the business rule should be identified using decision tables and implemented in the business data layer.
There are many drivers that can affect performance, such as the amount of data, the complexity of the query, the number of concurrent users, size of hardware and latency in accessing data, not to mention the latency of the network. Therefore, a simple requirement that 90% of all reports be finished in less than 5 seconds is laughable.
I have a process which I have outlined here that I follow to clearly identify what is required and more importantly help make the trade-off decisions that always need to be made when buying and implementing a new BI capability.
But as I explained to a customer lately who only wanted me to spend a couple of hours a week to tell them how to do it, and to also QA their work, I am not at the level of maturity in this process where I could teach them to do it like I do. Yes, I could share the templates I tend to use as the final outputs with them, but it’s the concepts and processes that I use to populate them that is the valuable part of the process.
Just another data warehouse review
Another example that has arisen is a customer who wants me to do a review of their Data Warehouse environment as the current provider is not meeting their expectations. So for this, we need a checklist of things to review and audit.
I moved away from using the DW Review or “BI Strategy” approach as our sales strategy a few years ago.
If your not familiar with this approach this is where a BI consulting company will spend a couple of hundred thousand dollars in effort writing a 100 page BI strategy document (and nowadays a 10 slide pretty PowerPoint as well). I have blogged my thoughts about that before.
The key for these BI consulting companies with the BI strategy is not to deliver a useful strategy, but to use it as a way to identify the opportunities that will support their teams to do a multi-million dollar delivery project. In the new analytics-driven BI world, this approach is now focussed on cool “Analytics Strategies” and “Big Data” delivery projects rather than the old style EDW projects.
So when doing a DW review, for me it’s about a checklist of things that should be done and identifying those that have and those that haven’t.
The easiest way to get this checklist is to look at what we do when we deliver and use that as good practice and therefore the review checklist right? And of course, that is where you start looking at the maturity of the way your team delivers, and could you teach it to somebody else.
Teach me to do it like you do
The last example is a customer that wants me to put together a training plan for their new BI domain architect. This person has quite rightly just been promoted into the role, and has a wealth of knowledge about the organisation and certain technology domains, but not a lot of “formal” experience in the BI world. More importantly, they have the desire, aptitude, and personality that means they will be an amazing success in this role.
So, how do I give them a fast track to learning the things they need to know? What would I put together if I was going to teach or coach somebody to deliver BI Architecture like I do?
My current maturity process
As a result of these three examples, I started thinking about the maturity levels you need to go through for a subject or output before you can coach it.
For the training and coaching capabilities that I am well down the path delivering (AgileBI, Data Requirements Gathering, and Data Vault) they are focussed on three things, Concepts, Processes, and Templates. There is a fourth we are focused on at the moment, and that is automation, but that’s a different blog.
But how do I develop these 3 things? Here are my current thoughts, and some examples based on the Data Requirements Gathering:
First I have to learn what it is and what it isn’t, and options that can be used to do it. For Data Requirements Gathering I eventually found the BEAM method developed by Lawrence Corr.
Then I need to have a test run in a safe environment. For BEAM, we tested it on some safe internal projects.
Then I need to use it in anger. For BEAM we used it on a project with a customer that was willing to take a risk on something new with us.
Then I need to do it with somebody else, where I explain to other people as we do it. For BEAM this meant having members of the OptimalBI team do it with me on another project.
Now we should be ready to show somebody how to do it. For me, this involves building an MVP course that we run. It’s rough, but that is the point we are learning what we need to change to teach repeatably and consistently.
Then we can harden the course and be able to teach at will.
Once we can teach then, we can coach other people while they are doing. This is the final level of maturity and is the most fun, but is also where you get new surprises on a daily basis.
So, there we have it my current thinking on the process to achieve the Maturity to Coach or Mentor.
The Short Version
Learn > Test > Do > Do Together > Show > Teach > Coach
I should get around to reading how the best sports coaches in the world got to where they got to; I wonder if there is any similarity?
Change, learn or fade away, it’s your choice – Shane
Read all of Shane’s blogs here.
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...