Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

I have been working in the BI arena since the late 1990's specializing in Front End Reporting and visualizing data using the SAP BusinessObjects toolset for well over a decade.  Along with countless others I have experienced first hand the changes in BI from Client Server Apps to Web Based and now the drive for mobility, the decline of EIS systems and now the prominence of Data Visualization and Dashboarding.

This last week I spent a day with a client delivering a Data Visualization and Dashboard Design workshop and so many aspects of how to approach a Dashboard project crystallized in my thinking.    I often see many companies and individuals I engage start their journey into Dashboarding following an edict from above stating  "We need a dashboard on that plasma screen" and then delivery team often fall into the trap that Dilbert points out so well below.

Where do you start ?

For me it is the "Mission Statement"

There absolutely must be a clearly defined reason for the Dashboard to exist that can be expressed concisely.  This can often be harder to do then first thought as I found in the session described above where this took over an hour to agree between a small group of people.  But if you start from this the following steps become easier.

For me the key to the successful delivery of dashboard projects are iterations, iterations and iterations ....  Be mindful up front that the first design that was drawn on a napkin over coffee that evolves into a  straw man/ prototype will not be the final solution.  I see this is of often due to members of the project team from the stakeholders down to then end users having different agendas and opinions for on all aspects of the design from the look and feel along coupled with the desire not to have a Red traffic light against the KPI they are responsible for.  Also don't get me started on the impact on the design when you involve the corporate marketing brand police !

My experience so far suggests using an Agile development methodology and timeboxed iterations (Sprints) is the best way to succeed.

And one last thing ...

The diagram below is one I come back to time and time again in dashboard design sessions as my summary of the backbone of data visualization specifically for dashboarding.

  • The ultimate goal of a dashboard is to drive an Action from the information consumer.  If there is no action driven then why does the dashboard exist.   If you get philosophical about this point ponder this ...  http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest
  • Without the values displayed on a dashboard having associated Targets, Trends, a context and a comparative then they might as well be displayed in a list report in Crystal reports
  • Finally, don't expect your first dashboard to follow in line with the academic thinking of Stephen Few and such like.  In my opinion the first dashboard will have multiple agendas, not only to meet it's mission statement but drive user adoption and become "Sticky" to the user community.  This "stickiness"  is not gained from a boring looking dashboard but over time I am seeing that both the user community and the developers loose interest in the BLING and move away from the "Flashy to FEW".