BI HAPPY

My wife thought it was strange that I got excited when I looked at the cash register receipt as we left the shoe store. Usually a receipt is the beginning of a discussion about why we spent more than we planned, but in this case it was different.

“Look,” I said, “This is neat. A portion of the $10 coupon that we used has been assigned to each of the two pairs of shoes.”

“Why is that neat?” she asked.

Taking the rare opportunity brought about by her interest in my fixation with data, I continued to explain that one of the challenges in BI was allocating costs down to the lowest level. People want to see margin at the product level, but that can be hard to calculate when costs (or discounts) are assigned at a higher level. Often, it is tough to pin down the business rules needed to do the allocation.

This shoe store chain solved the problem. The business rule was determined and applied right at the point of sale. Any downstream system, including a data warehouse, would have this information. Problem solved.

I had a good afternoon. Two new pairs of shoes and a little BI happiness to go along.

If you had to choose, would you pick strong planning or strong execution for your BI project?

Any project can be thought of along the lines of planning and execution. BI projects are of course no exception. Some projects emphasize one over the other, some look to strike a balance. Individuals working on the projects typically tend to be stronger on one or the other: some are great at planning, strategizing, architecting and gathering requirements, while others are great at building, prototyping, developing and executing. The nature of the projects matters as well. So, when you consider a BI project, would you emphasize the planning activities or try to focus on execution?
BI projects are typically more of an explorative journey than a plotted trip from point a to point b. They are riddled with unknowns and questions. Very often, it’s not clear what kind of information will be unlocked by organizing data. It’s also typically not clear what would be the best way to display the data to derive the most useful information. This typically leads to unknowns around the data organization. There are numerous technological, procedural, organizational and political hurdles to overcome. Defining business terms and then translating those definitions into the enormous amounts of  rows and columns that are spread across many databases is not only technically challenging, it requires constant dialogue between the people who are working with the technical details, and those who are working with the abstraction layers of information.
This unique nature of BI projects, constantly swinging between technology and business is why i would pick execution over planning if presented with the choice above. Strong execution means agility, attention to detail and pragmatic approach to solving ever changing challenges. Naturally, execution has to follow an underlining plan, or architecture, otherwise you will end up with a messy mash of components that cannot scale or work in concert, but as long as there is a reasonable amount of planning, focusing on strong execution in your BI project is what will bring you success.

I wrote about the importance of navigation in any BI application, whether it is a report or a complex dashboard, in various prior posts. Recently, i realized that discussing navigation without mention of context is incomplete. When talking about context in the context (no pun intended) of a BI application, we typically refer to a drill point.
In a classic application, navigation is concerned mostly with pagination and directional orientation. However, almost any BI application also includes drilling capabilities. These are essentially filters that “pan” the user perspective around certain attributes. For example, a drop down box can be used to present a list of business unites, and when a user selects a particular business unit, the data in the dashboard filters to reflect only data relevant to this business unit. In essence, this drilling is also a type of navigation. To make sure your users are not getting “lost” and confused, you should consider both the classic pagination navigation, how to get from one screen to another, but also the contextual navigation, or drilling, and how it affects, or play off and in tandem with the rest of your application navigation scheme.
As is the case in any application, the key point is being thoughtful and thorough, and building to spec, rather than having a one size fits all design answer. With that said, while in most cases you will find that maintaining your user contextual choices is desirable while navigation across pages, that may not always be the case. In particular when you consider bi-directional navigation. As users move “back” to prior screens for example, should you keep newer contextual choices they made on forward screens, or revert back to the context that was applied on a page when they left it?
And one last thought on this topic: as always, the key consideration should be the user’s needs and requirements, and not some tool or technology capability. If you are designing a BI application with a tool that does not allow you a good level of flexibility around navigation and context, you should probably be looking for a different tool.