Kicking off a Dashboard Project

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 …
  • 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”.

3 thoughts on “Kicking off a Dashboard Project

  1. Good blog Andrew, you know I agree with pretty much all that you say. However, recently I am thinking more and more about closing the execution gap… how do we make dashboard or BI App content actionable within the wider context of a business process?

  2. Andy,
    Thanks for taking the time to post ☺

    You raise two very good points, most interestingly how do we close the execution gap, but also when is a dashboard a BI App.

    I have spoken at length with Donald McCormack from Antivia on the topic of “When is a Dashboard not a Dashboard ?“ and I am commonly engaging with customers who vision of their dashboard is a fully featured BI App and when they find the limitations of many Dashboard products on the market they fall back on the acedemic view popularised by Stephen Few. I certainly hope the major vendors keep up with the demands of users for more capabilities in a dashboard along with the desire for mobility. The Statement of Direction from SAP today around the future of their dashboard product is very encourgaing in this respect,

    Now to your point on the execution gap. I see this challenging for all organisations and have no real answer. As I said in the blog a Dashboard without action is not really a dashboard at all. If I comment on the SAP Dashboard product thet are various ways of enabling actions to for example a Red traffic light to kick off a function modules or such like in SAP ERP but I most frequently see dashboards where the actions are defined as “Pick up the phone to Bill in Dept X“ or “We need to research this further for discussion in the next Management Meeting“, but as time goes buy I certainly see the need for visualised data to be embedded into business processes, but this may not Dashbaords as software vendors define them today.

  3. Pingback: What is a Dashboard really ? | thinkingbi

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s