The Business Intelligence Blueprint - Pt.3.

Recap

In part 1 & 2 of the Business Intelligence (BI) Blueprint, I outlined the steps to prepare for and execute the information gathering exercise. Through a series of stakeholder interviews, you should (hopefully) be sitting on a mountain of valuable information. Not only have you received input on data and information related needs, you've probably heard a lot about process, system, and data problems occurring within the organization. I'm sure the stakeholder wishlist you've captured looks like a 10 year old preparing for his annual visit to Santa.

So, what do you do with all of this information? How do take what you've heard, break it all down, prioritize it, and present it to the organization a concise and valuable way? You have questions, and I have answers. Read on.

Climbing the Mountain of Information

After your initial interview process and upon reflection of the information gathered, you probably noticed discrepancies in what you heard. You've probably also uncovered gaps in this information as you tried to piece the puzzle together. Questions arise such as, what system provides data for that report? What is the value of this Key Performance Indicator (KPI) to the organization? What interaction does the user expect? etc. Before you proceed with the creation of your document, you should ensure that all of these missing pieces are in place, or at least as many of them as possible. There's not much value in providing a roadmap that doesn't present the full picture or that makes recommendations based on partial or inaccurate information. If you do, and the organization proceeds with the project based on this guidance, your business intelligence project will in all probability be deemed a failure. Take the time to make sure you're working with complete and accurate information. I cannot stress this enough.

Assuming that you have done all of your homework and you've accurately captured the information, it's time to start breaking it down. I like to approach this in several ways. From creating a high level systems and data architecture diagram, mapping KPI requests, and even creating wireframes for some of the dashboards & KPIs that I will propose. The more detail you can provide in your Business Intelligence Blueprint, the better it will be. I'll discuss these and several other approaches in the remainder of this article.

Before I begin, a link to download a sample Business Intelligence Blueprint can be found at the end of this blog. It is a subset of the content that is typically provided, but should give you a sense of the deliverable and help provide clarity on the tactics I describe below.

The document that I prepare is typically broken down into several sections. These may vary by organization, but the general approach will always be the same.

1. Executive Overview
2. Detailed Recommendations
3. Reporting Requirements
4. Architecture
5. Effort & Pricing (Pricing if this is being offered as a service to another organization)
6. Assumptions & Constraints
7. Appendices

Let's dive into each of these areas in more detail.

Executive Overview

Let's be realistic, an Executive is not going to read through a 75+ page (that's how long my documents typically are) full of technical jargon. They want to know why this project is required, what benefit it's going to bring to the organization, and how much it's going to cost them. The Executive Overview should be as succinct as possible. Straight and to the point. Use plain language. Nobody is going to be impressed by your linguistic gymnastics (I'm talking to you lawyers of the world). You're trying to convey a message to get buy in for the project, so keep it simple.

Sections and information in the Executive Overview include:

Recap - Why did the organization ask for this project and how was the information gathered.

_Purpose _- What was objective of this exercise? What was the planned outcome?

About the Document- Why am I reading this? What's in it?

Summary - This is where you lay it all out for the Executive. What are the problems that the organization is experiencing? What were the common requests made by the stakeholders that you interviewed? What will the value to the organization be if this project proceeds? (i.e., increased revenue, reduction in COGS, increased CSAT, etc.). What are the high level deliverables and timelines in the proposed project?

Detailed Recommendations

This section outlines some of the general recommendations that you are making on areas such as performance, data quality, process improvements, best practices, roadblocks that may be on the horizon, major gaps, etc. These recommendations will differ for each organization and therefore I cannot provide a complete list of what you may discover. See the sample Business Intelligence Blueprint at the bottom of this page for a few examples of common recommendations and how they are presented in the document.

Reporting Requirements

Here, you begin to lay out the metrics that will address the needs of the organization. I usually provide a quick overview of findings at the top of this section, and then provide a summary and tally of all of the metrics that I uncovered. I tally (count) the number of times that a metric was requested by individual stakeholders because it provides a good idea of which KPI are going to positively impact the largest audience. This information, along with expected revenue increase, COGS reduction, CSAT improvement, are used in prioritizing the development of KPI. One additional note on the prioritization of KPI, remember that Executive sponsor that you secured at the beginning of this process? Well he/she should have also been interviewed as part of your interview process. If none of the metrics that they requested are high up in the priority list, or they had a really key request, I'd suggest you put one or two of them on the priority list anyway. They scratched your back, now it's your turn to reciprocate, so get to scratching.

To do this tally I create a simple spreadsheet. As I read back through all of the notes that I captured, I add KPI to the spreadsheet. If a KPI doesn't exist on the spreadsheet, I add it and increment by 1. If it already exists, I simply increment the count of requests by 1. I.e.,

The letter that appears in the first column is used to identify the request in my rough notes. (which I always include in an Appendix). This allows me to quickly identify the stakeholder(s) that made the request, should any additional detail be needed in future. (see Appendix B in the sample Business Intelligence Blueprint for an example of this.)

I also like to include a few wireframes or mockups of how the KPI might be presented in the BI solution. These are low fidelity mockups and not intended to be a final design document. I've found that the user better understands the proposal though these visual elements than by simply providing a text based inventory of the requests. I do not create a mockup for every KPI. Just a few examples.

An additional document that I prepare and embed within the Business Intelligence Blueprint is a Reporting Matrix. This document lists all of the requested metrics, descriptions, calculation formula, dimensional attributes (filters), source systems, and other notes. I've included a link to download a sample Reporting Matrix at the bottom of this blog.

Architecture

During the interview process, you should have interviewed resources from the IT department. These interviews should have been done last to verify information provided by the other stakeholders and to assist you in beginning to paint a picture of the systems and data sources that will be required to support the requested KPI.

I like to provide a high-level architecture (big block) diagram of the current systems in the Business Intelligence Blueprint. I also like to begin to formulate my thoughts around the architecture that will be used to support the BI initiative. This includes a big block architecture diagram along with a very high-level data model that may be used to support the requested KPI, including filters (dimensions). The intent here is not to provide a fully baked design, but to give the organization a sense of the magnitude of the enhancements.

Below is an example of a big block data architecture diagram.

Pricing

If you are creating the Business Intelligence Blueprint for your organization, you probably will not have pricing in the document. However, you should still provide rough effort estimates. If you're creating the Business Intelligence Blueprint as a service for another organization, I always like to include pricing along with the effort estimates.

I typically estimate and price every KPI and data source requested. What usually happens when I do this, is that I come up with a very high number. So, I break the project into phases. I find that this approach is more palatable to the organization from a budgetary and timing perspective.

If you're an outside vendor providing the service, breaking the project into phases creates an easier sell to the organization. I've found that when I take this approach, I am asked to perform the phase 1 work 90%+ of the time. During phase 1, I deliver the KPI as scoped, but I also use the time to train the organization in how to do the work themselves (if desired). Make sure that you include time for training the development team, if it's requested, in your estimate! For phase 2 and latter phases, the organization typically performs the work with periodic requests for me to provide additional training and/or work on more advanced KPI and analytics that their team does not yet have the expertise or confidence to deliver.

Estimating this effort can be tricky when you still have relatively high-level information. To help with this, I've prepared a spreadsheet that allows me to estimate the effort required for each KPI and data source. The estimates are ballparks, but they're based on actual work performed over many, many BI projects. So at this point, they're about as close to accurate as you can get with this level of information. I've included an example of this spreadsheet at the bottom of this article. Feel free to use it.

I also like to provide a proposed timeline for the project and explain that it will follow an iterative or agile approach to development. It's important that as you develop individual KPI that you get them into the hands of the users quickly. Despite your best efforts to provide mockups in the design documents you will create, users will not "get it" until they begin to interact with the content, then the light bulbs go off. It's better to rework one or two KPI than to have to go back and redo your entire BI solution. So prepare for small, frequent deliverables with some rework/enhancements, in your timeline.

Assumptions & Constraints

Despite your best efforts, you're not going to have all of the answers from your interview sessions. Quite often, deeper analysis is required to create an accurate requirement for one or more requests. It is important that you note any assumptions that you've made in create the Business Intelligent Blueprint, and any constraints that may inhibit delivery of the requested content. List everything that you are aware of. Always CYA.

Appendices

I include one or more appendices in the document. These appendices provide information on things such as:

Operational Enhancements - When you conducted the interviews, you probably heard about system, process, and data problems that are unrelated to your project. Hopefully, you took my advice and captured this information. I always provide this information in an appendix as it provides the organization with an opportunity to spin up side projects to address the identified deficiency. If you're a service provider, this can also turn into additional work for you if you have the ability to assist the organization in resolving the issue.

Rough Notes - I always include the rough notes that I captured during each interview. It's important that this information be provided so that if the organization opts to proceed with the project using their own resources, they know which stakeholder to approach for additional information. It is also used to support the recommendations that you've made in the document.

Data Mapping - In some projects, I perform some preliminary data mapping and include that mapping document in the Business Intelligent Blueprint. If the organization opts to perform the work on their own, this document provides a great springboard for them to begin the mapping process.

Document Deliverable

Well, that's about all I can think of for now. If you've made it this far, I hope you've found the information provided to be useful to you. Be sure to review the sample documents that are available in the links below. I'm sure that they will help clarify any questions that you might have from my rambling over these 3 blog posts.

Remember that the success of a BI project is not measured by delivering the solution, but by user adoption and confidence. I believe that with the Business Intelligence Blueprint in hand, you're well on your way to instilling confidence that you've got the right data to provide the metrics that your users want and need. They won't know how they ever lived without it!

Feel free to contact me directly if you have any questions or would like guidance as you begin your Business Intelligence Blueprint journey.

Thanks for reading, and happy blueprinting!

All the best

Mike

Sample Business Intelligence Blueprint can be accessed here

Sample Reporting Matrix can be found here

Sample Effort Estimation spreadsheet can be found here