Wednesday, July 22, 2009

Dream Dashboard

Okay, so this has turned into a mini series about keeping dashboards and what some of the dashboards I use look like. Unfortunately, none of these dashboards or home pages is perfect.

What are we really looking for in a project dashboard or home page?
  • Overall project status. This is the kind of thing that should take no more than 1 minute to communicate verbally (but of course displayed in writing/graphing/etc).
  • Recent events and immediately upcoming events. Everyone working on the project should have the ability to see what just happened, and what's coming up real soon now. This kind of immediacy helps put people in context of the project. Thus, a person can quickly understand what he needs to do or react to right now.
  • Table of contents. A project of any size will generate more data than can possibly be held on a dashboard or home page. However, that home page needs to point to the locations of the other data; it needs to be the place people go to find information about the project, even if the information is actually stored elsewhere. This can be one or more of: documents, wiki pages, bug lists, etc.
  • Ease of update. Hand updating and maintaining things leads to (gasp!) human error. So things that auto update, or can be updated from scripts (say, for example, the list of current open bugs) are good.
Basecamp and wikis (we happen to use mediawiki, but I've used Confluence elsewhere) are the two best things I've seen for this.

My dream tool, and I don't think this exists, has a top level overview, and clicking on each item displays more detail. Sort of a Google Maps for a project.

What do you want? And what do you use?

3 comments:

  1. I want integrated bug tracking, test case tracking, dev cycle, project status, all in one interface which supports milestones, individual completion status on subtasks, and which is approachable enough that non-techs can update it. You basically nailed it w/ the Google Maps comment; that level of simplicity when interacting with the complex is why Google rocks so hard.

    Currently, we use Bugzilla AND an old old version of DevTrack (which I am looking forward to retiring), and that's about it. I'm looking at Testopia to help track scripted testing (even though management's reliance on scripts far exceeds my own belief in their effectiveness), and we have a heavily modified version of DCL (DoubleChocoLatte, OSS issue tracking software), and I'm working on integrating them.
    We also use Mediawiki as a knowledgebase.

    Sadly, we've never had any kind of overall project tracking before, so I'm looking forward to using Novell Teaming soon to hopefully fill the gaps.

    ReplyDelete
  2. Hi Catherine, how are you? Hopefully you are doing good, J

    Thanks for the mini series of dash boards, the points you have written are good, Updated project status and its visibility to all stakeholders is a key to success, specially if we are working in a team of 60 to 70 resources, such dash boards play integral role in reducing communication friction between the teams.
    Last year I was involved in a project where the big problem was communication gaps, such as QA group often un-aware of Functional Analyst decisions or updated FS documents, Developers are un-aware of any latest change in Application framework, so having dashboard where we can see all project updates and updated Documents, is a great tool.

    Thanks for sharing dashboards, I am thinking to start such dashboard in my organization as well, what about media wiki, is it a good start?

    ReplyDelete
  3. Kashif: Mediawiki is adequate. It functions and is fairly simple. It's certainly not an "enterprise wiki", however; it lacks features like the ability to restrict pages to being viewed by one or a few users and not by others, and the ability to interact with it programmatically is very limited.

    We're actually slowly starting to move off Mediwiki because we can't do access control on specific pages or categories.

    ReplyDelete