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:

BI Procurement

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:
Learn
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.

Test
Then I need to have a test run in a safe environment. For BEAM, we tested it on some safe internal projects.

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

Do Together
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.

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

Teach
Then we can harden the course and be able to teach at will.

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