I question the wisdom of building Excel based dashboards without using VBA. To avoid using VBA, Charley’s approach spreads the data across multiple sheets. With a VBA approach, all data can be properly consolidated and VBA procesures can extract the necesary data to generate the charts. This video shows an example of a VBA dashboard generated from a consolidated sata sheet.

http://processtrends.com/Files/Process_Dashboard.zip

VBA can significantly enhance the quality and reliability of dashboards, when sound information technology management practices are followed.

Charley is concerned about those oganizations that let their staff develop VBA tools without documentation and staff training, those organizations that rely on a single super user to handle their reporting. This is poor IT management. Why solve this problem by banning VBA when the real problem is poor IT management practice. Let’s solve the the poor IT management practice, and use the best tools that we can.

The more realistic approach is to establish good program development, testing, documentation and training practices and make sure that more than one user understands the tool and the VBA code.

I have several VBA based dashboard videos and a downloadable workbook at this link.
Here’s a link to a simple video and Excel workbook that uses VBA to build Excel dashboard screen layouts.

http://processtrends.com/Video_list.htm

Users who can master Charley’s techniques can surely understand the VBA code in this workbook.

Let’s not ignore a powerful Excel capability (VBA) to compenate for poor IT management practice, let’s make sure we use sound software managment practice as well as the best tools.

Kelly O’Day

What I mean is that if a user understands how to use advanced functions like OFFSET probably she should also be able to use some basic macros to automate simple tasks. What I try to show in my Demographic Dashboard is that you don’t need a programmer for actions like changing a value in a pivot table. But if digital literacy is very low and there is only one person in the organization at that level, I agree with you, it can be too risky.

I like PivotTables because they minimize the need for lookup functions. I feel that this is a safer strategy when Excel-friendly OLAP databases are not available.

The bug and the performance issue severely limits the use of the camera tool. I was playing with a chart format that is easily created using the tool but I can’t use it because of the bug.

Charts in the financial pages are usually cleaner, so probably they are safer to “steal”, but I really can’t recommend magazines as a source of inspiration for business information visualization.

I don’t see why “printed displays provide insight more quickly than do on-screen displays” (assuming we have exactly the same output). I can buy the “insights per minute” idea, but how do you measure that when you have an unexpected outlier? How long will it take until you are able to understand it? In a printed dashboard world, it will take you hours, but even with a very basic interactive dashboard it will only take you a few seconds.

Printed dashboards are probably better suited for stable, business-as-usual scenarios. In a more dynamic environment, you are not paid to surf, but you should have at least some swim skills…

One way that I depart from many Excel gurus is in the use of macros.

As a consultant, I visited too many clients where an Excel user had written some macros, used them for a while, and then left the company. The people who remained treated those macros as magic, until the magic failed.

Therefore, I always try to find solutions that avoid user-written macros…even recorded ones.

I also depart somewhat in regard to PivotTables. If you’re stuck with a relational database, they’re the best solution available. But an Excel-friendly OLAP database provides much more power and ease-of-use. It also provides a better audit trail.

With regard to the Camera tool, its primary advantage is that it allows us to display tables and titles whose rows and columns are out of sync with the underlying dashboard spreadsheet’s rows and columns. A dashboard report that includes only charts seldom needs the Camera tool.

With regard to “magazine-quality” designs, we’re looking for incremental improvement in our dashboards, not perfection. Excel users with no concept of graphical design can improve their reports significantly if they “steal” designs from magazines.

I agree that many graphical designers ignore the sound visualization advice that Tufte, Few, Robbins, and others have offered. But so do Microsoft developers, who *really* should know better. (See Few’s: http://www.perceptualedge.com/articles/b-eye/excels_new_charting_engine.pdf)

Finally, with regard to printing, managers are interested in *insights per minute*. I know, this is an idea that one can’t measure precisely, but you get the idea.

A display method that provides insights in ten seconds is far better than one that takes ten minutes. As a rule, printed displays provide insight more quickly than do on-screen displays. Further, printed displays don’t tempt managers to drill into the data themselves. Managers are paid to manage, not to surf the data warehouse.

I think too that dashboards may not need to be printed (“it depends”, as you said), but they should be printable. That is, dashboards should be designed with the option to print in mind. This assures that the right data is present, that it fits into an appropriate area and is appropriately laid out, and that it is portable.

What a pronouncement…