The storyboard is composed of a series of static presentation pages designed to show: graphic themes, categories of the data that will be used to populate, and a sample progression of views. The term storyboard is borrowed from motion picture and television commercial production. A storyboard lays out the visual sequence of a feature or commercial and shows major images and dialog. The storyboard sequentially tells “the story” of how the dashboard will display images and provide interactivity.

Wireframes are an outline view of a dashboard. We use simple boxes/circles/labels to describe main visualization areas, primary navigation, and key data elements of a dashboard. Much like preliminary architectural sketches of a building, wireframes demonstrate structure, and key features of each major hierarchal view.

Non functional graphic representation of the dashboard. This is final design review, and Client approves design from these mockups, prior to building prototypes.

The user map is graphic representation and written description of user levels, viewing authority, and access. Users are given access to specific “views” based on corporate authority, functional responsibility, and decision span of control.

The working prototype is an interactive dashboard mock-up with functioning user interface, navigation, and up to three user views. A prototype may be populated with sample data, but the basic interactivity, graphic displays, data filters, and queries are an important prerequisite for dimensionally modeling the data feeds.

In this stage of the process we look at all of the ways in which we will have to query and filter data based on the working prototypes developed in the previous phase. A dimensional model takes one or more data feeds from source transactional systems and creates a data schema that is based on the concept of "measures" and "dimensions." A measure is numeric piece of data that is relevant to our dashboard, and a dimension is a mechanism by which we can slice and filter the results of our measures. Typically this is accomplished with a modified star or snowflake schema. The end result of this stage is a comprehensive data model that integrates all source system data into one high-performance data repository that our dashboards can use to render their data visualizations.

While the working prototypes provide a set of functional requirements for our Dimensional Model, the Dimensional Model helps define the specifications for the format of the source data feeds. Based on the number of measures, dimensions, and the frequency of the data, we create a set of data feed definition files which clearly enumerate all data required for the system to operate on a field by field basis. This document is often used by the client's internal IT department as the basis for developing their source data feeds.

Data Extracts are the execution of the Data Feed definitions against source systems. This step is most often performed by the client’s internal IT department as it requires a deep understanding of the source system data and structures. The client uses the data feed definition as guide in building their source data extracts, and tests the accuracy of their extracts against the data feed definition.

Once data extracts have been provided (either in sample form or live) we then build the "Extraction - Transformation - Load" routines that take the data extracts and transform them into our dimensional model. The dimensional model itself is a relational database and used as a staging area for batch updates prior to us moving the data into an OLAP engine. This ETL step is where all the critical logic takes place to make sure all of the source systems data forms the necessary relationships between each other. This is also the place where we validate the accuracy of the data and perform the needed logic to handle such things as slowly changing dimensions and exception rules.

OLAP stands for "On-Line Analytical Processing" and is a specialized database primarily used to pre-calculate the aggregates/sums/groupings of the intersection of each dimension and measure in the dimensional model. Often times this database is referred to as a "cube" as the data is no longer in a 2 dimensional row/column format. OLAP solutions are often necessary when having to analyze large sets of data in aggregate form. These data cubes are usually necessary to build the high performing foundation for dashboards to calculate, render, and provide on demand interactivity at high speed.

During the data integration phase, the fully prepared “live” OLAP cube data is connected to the configured dashboard software. The dashboard is now fully calculating and rendering graphics. Interactive tools are fully operational, and all hierarchical views are nested in a single implementation.

System Configuration Access rules are incorporated during system configuration. User accounts are set up and views are defined based on authority, scope of responsibility and level of detail required to make decisions. Access security, passwords, and specific user accounts are established.

The fully operational dashboard is tested and validated by MarketingNPV technical staff on a production server. Beta versions are subsequently released to a client test team. Release plans, training materials and support protocols are developed.

The dashboard is live! Designated internal “Power” users and support staff are trained. Maintenance, spot testing, and validation procedures are put in place. Performance and usage are reported, and quarterly dashboard summits are scheduled to ensure that metrics and view hierarchy maintain complete relevance as the organization and business objectives evolve.