A dashboard is a vital tool for monitoring the daily health of your organization. From a single interface, decision-makers have access to key performance indicators (KPIs) - actionable information that can be used to actively guide business performance. A dashboard is like an executive intranet, a site where everything of interest to you is displayed in logical groupings. At a high level, it may seem relatively easy to build one. Companies that have a good handle on what performance indicators are of strategic importance to the organization may feel that collecting and summarizing supporting data and putting it in one place shouldn't be that difficult. However, such oversimplification can lead to a failed project before it ever gets off the ground.
The successful implementation of a dashboard is complex and requires a methodology that considers all aspects of the project life cycle.
When comparing proposals from multiple vendors (or the cost of a "do-it-yourself" project), it's important to ensure that all of the steps described in this article are included. Correctly designed and implemented, a dashboard has the potential to bring immediate ROI to your organization.
Dashboard Implementation Methodology
Plan: The planning phase is where it all begins. Make sure to allocate enough time in your project schedule to ensure this critical step is not rushed. First, the project team members must be identified and their roles clearly defined. Who will be the executive sponsor? What are the overall project objectives? It is not uncommon for the primary users - executives or line-of-business managers - to play a limited role in the dashboard development. Therefore, the team members must have access to and gain insight into the needs and wants of this group.
In the planning phase, team members determine the scope of the project. What KPIs are important to the primary users? What data is needed to support the KPIs and where is that data located? A dashboard is most useful if the metrics will be measured against predefined conditions and thresholds. What are these conditions and thresholds?
If you're working within a tight timeline, populating the dashboard is of utmost concern. Take care not to underestimate the complexity of the databases in which the data resides. The tremendous flexibility enterprise applications provide for customization results in data tables that are very complex. Accessing the data from a myriad of tables is not a simple task and requires technical resources with detailed knowledge of the underlying table structure and SQL skill. It can take days to gather the data relevant for a single KPI, so plan accordingly.
Budget plays a major role in defining the scope of the project. The work required to create custom queries to provide the desired metrics might be out of budget. Set realistic goals for your dashboard project by striking a balance between the primary users' needs and what you can afford to deliver. Determine up front what KPIs are critical and stick to the plan.
Requirements Gathering and Prototype: Once the scope of the dashboard project has been defined and the plan is in place, the process of requirements gathering begins. Interview the key stakeholders to determine their needs and expectations for the dashboard. These needs and expectations should map to the KPIs already identified.
Discuss the options available for dashboard presentation and functionality. A dashboard provides the user with a number of different ways to graphically display the data. This is the time to cover personal preferences - top-level navigation, use of bar charts, gauges, etc. For each dashboard, the desired data elements must be identified. Relationships between them must be defined so that appropriate drill-down and drill-to capabilities can be provided.
Some tools and technologies lend themselves well to prototyping and iterative development. Taking advantage of those capabilities can increase the likelihood that the final dashboard meets the users' expectations.
Design: Once the requirements for the content and appearance of the dashboard have been agreed upon, major aspects of the design must be completed: refine the user interface and control flow; confirm the data sources for each data element; determine how to "persist" data when historical trending information is desired, but not available from the transaction database; define the queries needed to retrieve each data element; determine drill paths.
Build and Validate: The "real" development begins at this stage of the project. Several tasks occur here, typically in parallel, closely coordinated with each other.
Front-End Implementation - Create the dashboard user interface. Final user interface decisions must be made. Personal preferences have been discussed, but now is the time to evaluate what graph and chart types best represent the data to be displayed. In addition, make decisions regarding grouping data to provide the greatest visibility for cross-analysis. What visual alerts, such as color changes when values exceed expected thresholds, will be defined? Have a game plan in place for when these thresholds are surpassed. What kinds of "summary-detail" options will be provided? What interactive drilling to other graphs or charts will be available?
Query Implementation - Create the queries to retrieve the necessary information from the appropriate databases. This step can be particularly complex and time-consuming, especially if there are multiple data sources for the various data elements in the dashboard -- even more so if those data sources include customized ERP, CRM or SCM enterprise applications that generally have complex database schemas. Writing advanced SQL statements is a challenging task for even the skilled programmer.
Configure Scheduling, Refresh and Security - To ensure the content of the dashboard is up to date, the queries created must be configured to run regularly to deliver information to the dashboard. In addition, security rules must be implemented in order for the dashboard to display the appropriate information for different users. To minimize the need for redundant administration, those security rules should take advantage of security frameworks that are already being managed.
Dashboard Validation - As with any software project, when the effort reaches "code complete," it must be tested to ensure that it meets the requirements and specifications outlined in the project plan. Some of this validation can be done independently by the technical team. Other aspects, especially ensuring that the data is correct, must be done by the primary users of the dashboard or their representatives.
Deploy: Once the dashboard has been built and tested, it is deployed into production. Security requirements must be implemented in the production environment. Integration within a corporate network environment must be completed (including considerations for portal frameworks, extranets for partner and customer access, etc.).
Maintain: With the dashboard in production or "live," steps need to be taken to provide for ongoing maintenance. Over time, requirements and expectations for the dashboard will change. The dashboard solution should be flexible and open to allow for such inevitable enhancement requests. If the dashboard was implemented by a vendor or solution provider, knowledge transfer to the customer for ongoing maintenance is essential. To minimize reliance on external resources, tools to promote self-sufficiency are beneficial.
Build versus Buy
Building and deploying an executive dashboard takes time, regardless of the vendor or technology that is chosen. Creating the graphical front end is relatively quick and easy, but that's merely the shell of the dashboard. As the iceberg theory illustrates, what you actually see on your desktop pales in comparison to the hidden effort - 80 percent of the complexity that lies beneath the surface. Populating the dashboard with relevant KPIs takes the majority of the development effort. This is no small task and is largely dependent upon the size and structure of systems where the data resides. Don't be misled by promises of an overnight dashboard solution. All aforementioned tasks require planning, organization, coordination, scheduling and solid project management. When comparing proposals or considering a "build versus buy" decision for deploying a dashboard, it is important to ensure that the entire scope of the project is considered.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access