Wednesday, September 16, 2009

Give me a dashboard...

"Dashboard" - as a Project Manager or just person frequently getting requests directly from the leaders of the huge multinational company I can testify to the profound and growing popularity of this term. We talk and breathe dashboards whether we acknowledge that or not. And as the downstream requests are flourishing with "Show me the dashboard" pattern so are the trends at the middle or lower organizational levels. Software is not an exception - every application has a Dashboard of its own (as I am writing those words I have just noticed that http://www.blogger.com/ is not an exception either). As I am teaching a Project Management course using SharePoint technologies, I have noticed that the most frequent question people are coming with to the course is "What is the best practice and how can I build a dashboard".

So what the hell is a "Dashboard"? Here is a small service I did for you, people - Wikipedia definition says the following: "A dashboard, dash, "dial and switch housing" or fascia, (chiefly in British English) is a control panel located under the windshield of an automobile. It contains the instrumentation and controls pertaining to the operation of the vehicle". In a nutshell, it means that the area contains all the necessary information for you to understand what is going on with your car and shows you key parameters identifying operational status. Let me try and translate it into business language: Centralized area showing status of Key Performance Indicators (KPIs) pertinent to current business area or agenda.

Ok, let's dive deeper and follow the thought thread. "Business Agenda" applies to everything we are interacting with and has a complete different flavor for different businesses, operational units within the same business and even people requesting the information. Its content and focus can be changing pretty frequently as does our business focus and key areas of attention/concern/opportunity. Some organizations have a very clear set of Key Performance Indicators - I find it more prevailing in Manufacturing and Financial Industries; for some - the agenda has a project-driven orientation and can change every couple of weeks. Here is couple of examples:
1. As a Project Manager or PMO member we might be interested in seeing Past Due Tasks, Tasks Due in the next week or Runs (if you are working using SCRUM), Outstanding Issues, Critical Risks, Budget Status chart, Run Down chart, Release Schedule, Customer Satisfaction level. As you can already see some of you are disagreeing with me already which proofs the point that as we are different so is the way we are driving things and so will be our Operational Dashboard
2. As a person working in the industry driven by strong financial characteristics, I know my Directors would like to see information using characteristics like EBIT, ROFE, Sales Awarded, Quoting Business
3. Working closely with Operational team, I know their focus it most likely to be Time Spent on support Tickets during the last 3 months, Servers uptime, Upcoming Maintenance, Vacation Calendar

Let's look at the second aspect which I kind of touched on in a previous paragraph - "Pertinent". It means relevant to a person receiving information. Using our car analogy: some people are only interested in the odometer, some also would like to see gas consumption and some don't really care about this weird red light spot in the form of a pitcher or meat grinder. Every information thread has two ends: Provider and Receiver. Let us focus on the second one. Using Project Management terminology, Receiver is a Stakeholder and Managing Stakeholders is an extremely critical project activity. My personal experience shows me that it is probably the most important one when managing a Project. I have seen project declared as a complete failure after a very successful implementation and people being promoted after talking more than half a million down the drain. And all because of a proper or improper handle of key business players/stakeholder and proper or improper information delivery and expectation management. So does our Dashboard - the content might differ based on the audience. Well, actually the better way to put it is: "The content should change based on the audience".

To summaries the rules to adhere to when building a Dahsboard I would recommend the following steps:

  1. Figure our the audience (Stakeholders) that will be using the Dashboard

  2. Understand their needs (type of information, preferred format - graphs, tabular, etc; when this information is required, process for it to be reviewed - for example if it has to be reviewed during the montly Steering team meetings; what is the expectation of the information currency, souce of data, ways to retreive data, additional "tweaking" that might be required prior to publishing the information, expectations to alerts around content changes, potential export requirements - need to export into Excel or email it, need to go back in time and review data from the previous periods). One of the key points is also to verify that the way the data is being accumulated or passed to the Dashboard has to be part of the existing or highly supported process

  3. Based on the data collected in #2, do a thorough review to understand the best platform and the location of the future Dashboard to come. This is going to be crusial in assuaring acceptance as well as success of the initiative

  4. Identify a small but eager group of people representing Key Stakeholder and test functional "prototype" level solution (addressing only some of the areas the Dashboard is to cover) with them

All of the above can be reletavely easy implemented in SharePoint using out-of-the-box functionality and some free or really cheap chart or/and gauge webpart. Will try to give you some examples in my next posts ... see you