Power BI Dashboards - No Drill Down - Aghhh!

A new feature was added to Power BI last year: drill down in charts. Microsoft didn't give us drill down in tables, but they did in charts.

But even with charts, there's a snag: the feature disappears when you pin a report to a dashboard. To access it, you need to click the Title of the report in the Dashbord, which will take the user through to see the report. 

Simple Speak Vs Business Speak

The man said, “I am a digital and social media strategist. I deliver programs, products and strategies to our corporate clients across the spectrum of communications functions.”

When asked by the journalist what this meant, he replied, “I teach big companies how to use facebook.”

I like to use simple speak rather than its bloated counterpart, because people actually understand me when I do. This even applies to technical terminology. For example, I call a Sharepoint Document Library, a folder. I like to call a precedent constraint in SSIS, a line.

"Business Intelligence" itself is too much of a mouthful for me. I prefer to say, "Turning data into information" or, "making data easier to understand."

Why use simple speak in the context of business intelligence, you ask? Because I like to make data easier to understand.

Here is a video outlining the matter perfectly:

Agile, Waterfall or Neither for SSRS Reports?

Anyone who is familiar the Waterfall project methodology knows that part of it involves collecting all requirements up front. Compare that to Agile where the project consumes requirements in a more segmented way, through 'user stories'. In my view, these methodologies may have their use in other forms of programming, such as web-development, but when it comes to report writing, neither are ideal (though Agile comes closest).

In BI requirements always change. In fact, its unfair to demand that business user know exactly what they want. The probably do not know the data structure behind the data. It may be that what they want cannot be produced, and this is not realized until later in the development. Once the user has seen the result of the initial database query, they may realize (as they investigate the result) that they needed something quite different, or something extra. They simply couldn't have known that before. BI is all about investigation. That makes it different from other types of development.

In my view, those 'BI Professionals' who demand a REQUIREMENTS DOCUMENT up front, are amateurs. They have often come from development backgrounds, and have great skills in coding. But they don't know about the business realities of BI.

Being a great BI Professional is about so much more than just coding. You have to be able to work with the business; find out what they want, why they want it, and be good at explaining data realities to them, translating technical realities about the data into understandable language.

BI development is a learning process - that's why its called Business Intelligence, not Business Reporting or Business Dashboarding. Its not as simple as creating a report, a dashboard, a cube, a model, or writing a query. That often comes at the end of the process, once the data, usually copied into Excel and looked over by the user several times, has been verified and agreed to. Only then should it be instantiated into a report (turned into a report) or dashboard or tabular model or cube.