Skip to Content

First step:
The business user usually has a predetermined idea as to what dashboards are…
The initial idea comes from seeing some dashboards on the internet or from a competitor or a colleague who has done some flashy graphics / graphs ..

If the business user was dashboards and is not too sure of what dashboards are then it is quite a different issue … The user needs to be taken through what a dashboard is:

What is a dashboard:
Starting with what a dashboard is not :

  • A Dashboard is not a substitute for BEx
  • A dashboard is usually meant for display of static data with some filters , in more often than not , drilldowns are notoriously hard to emulate on a dashboard environment due to display formatting issues and integration issues.
  • A dashboard does not have all the information on one screen – it is meant to provide a layer by layer representation of structures information focused on dissemination of specific information ( I made that up by the way… not sure if something similar exists somewhere else too )

A dashboard can be :

A dashboard should ideally have a summary sheet with the necessary KPIS … then the user can be given a drilldown / click-through / dropdown option to go to the next level for a selected KPI thereby keeping the focus and then taking the user through the different grains of data available for further analysis. This is mainly done so that different classes of users may use the same dashboard by drilling down to their necessary levels..

The first two levels usually are pictorial by way of graphs / charts etc… ( Again these are guidelines and not something that should be – ore of less summarized from what I have seen and implemented )

Next step is to build a mockup of the same  – either using tools like VISIO or HTML editors etc. Believe me this is worth the effort because the outcome of the dashboard drives usage – it has to be experienced , fine tunes further by way of colors etc before development should start – else UAT might become a nightmare….

When the mock up is being done – a technical analysis of the same should be performed and a tool eval has to take place .. there are many tools available to do dashboards like :

  • Web Application Designer
  • Visual Composer
  • Yahoo Widgets / SAP Widgets
  • Crystal Xcelsius
  • BI Widgets from BO
  • OpenLaszlo
  • Adobe FLEX
  • …… and the list goes on…

Now is the time to fine tune the mock up to make sure that the outcome is achievable using any of the above mentioned tools and also drive the Mockup towards the same – by this time the user gets a fair idea as to what to expect and what not to expect. This will give further clarity to requirements and also to find out if dashboards are the right thing for the user at this point of time or are meant to be attempted later as the BI organization matures in terms of data visualization and analysis.

Why is tool evaluation so important :
First the requirements are fuzzy and moreover ….

There are so many tools available for dashboard creation ad more often than not  – the confusion is on what tools to use for the same so as to :

  • Implement the dashboard faster
  • Reduce rework for the same
  • Avoid realizing the tool limitations after a significant amount of development has been done.

This avoids the issue of the user coming back and saying that “I saw this nifty dashboard at …. and why did we not use that tool instead..!!!” and subsequently changes requirements!!!

Once the requirements are nailed down – it is time to start the development and then going on to further aspects such as performance etc.

The key point in a dashboard implementation is to vet the requirements in full detail so that the critical factor of usage is taken care of … else it might end up as a case of a lot of effort put in but in vain.. since no one wants to use the dashboard…

I am not trying to dictate what a dashboard is .. but when everyone is talking about dashboards – there is a tendency to look at dashboards as nice to have by every client and mistakes are commonplace when expectations are not set properly and not being aware as to what the client wants…..

My first Dashboard project took off because requirements were clearly driven , but then later on someone else wanted dashboards and saw it sort of burned down to the ground due to ill specified requirements and wrong expectations..

Disclaimer:
These are my views alone gained through seeing some dashboards fly off and some crash to the ground in smoke and do not represent the views of my employer

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply