Bloggo back to the blog
Dashboards within an Application Lifecycle Management (ALM) solution.-->
Before you can create an effective dashboard, you must decide what purpose it is intended to address and how it will do that. Without this information, you cannot be sure that you are showing the right data or that it will help the intended users by supplying them with information that they need.
To keep dashboards focused and organized, consider using separate dashboards for different purposes. For example, if you choose to focus on a specific set of operational objectives, create one dashboard for that purpose. If you also want to focus on a set of practice-based objectives, then create a separate dashboard for that purpose.
The following issues should also be considered:
Business objectives: What is the purpose of the dashboard? What problems or issues will it address? For example, you may be interested in operating costs or customer satisfaction.
Operational objectives: What process improvement goals will the dashboard address? For example, in order to address the operating cost objective, you might want to assess productivity. If you want to address customer satisfaction, you might want to assess product quality achievement.
Operational measures: What metrics will it display to measure progress against the operational measures? For example, to assess productivity, you might want to monitor information on things like iteration velocity and burndown rates. To assess product quality achievement, you might want to monitor defect density and repair rates.
Practice-based objectives: What practice adoption or improvement goals will the dashboard address? For example, your organization may want to implement the Release Planning practice, so you can create a dashboard that shows progress in implementing that practice.
Practice-based control measures: What metrics will it display to measure progress against the practice goals? For example, to assess progress with the Release Planning practice, you could monitor release burndown information and defect trends.
Usability concerns: Who will use the dashboard? What will they be trying to accomplish with it? How should it be organized in order to be used effectively for achieving goals? Who will need permission to view or edit the dashboard?
When you are confident that you understand the goals of the dashboard, you need to specify how the dashboard will meet them. There are a variety of widgets that you can display on a dashboard, such as reports, Web pages, RSS feeds, and so on. Reports (the primary channel for metrics information) can be charts, small tables, cross tabulations, or trend indicators, for example.
Decide whether you want to create a team, project or personal dashboard. Each team or project can have one dashboard associated with it, and that dashboard is automatically viewable by members of the respective team and/or project areas. A team or project dashboard can also be edited by team or project members whose assigned process roles have permission to edit. Personal dashboards are private by default, but can be shared with a team or project area so that members can view the dashboard but not edit it.
Generally, a dashboard presents information that is intended to convey high-level concepts quickly without overwhelming the viewer with details that might not be necessary. A viewer should be able to grasp the meaning of the data at a glance. Providing low-level, detailed data at the top level can take up too much space. Screen real estate is limited, so reports must be small. Charts and trend indicators are generally more effective than data tables for achieving this goal. For access to more detailed information, you should have access to reports that have drill-down capabilities so that you can choose to look at more granular data if you need it.