The Anatomy and Lifecycle of A Dashboard Project

Despite its seemingly simple nature, a dashboard project consists of many more lifecycle elements than just the graphical implementation of the appropriate indicators. All of these elements of a dashboard’s lifecycle WILL be manifested in any given project. Planning for them and making them an important set of milestones will help to ensure the success of your project. Projects where these elements were not planned for were never on time, did not meet expectations, were over budget and generally viewed as unsuccessful.

There are certain key individuals, and often departments, that will be involved in different parts of the project. For example:

• Executive leadership - a dashboard project must have direction from the leadership of a company or department.
• IT - unless all the data for the dashboard comes from, or the dashboard is hosted on non-IT administered systems, it is imperative to have IT support.
• Viewers - there are no successful ROI stories for dashboards that do not have viewers for whom an integral part of their professional success is supported by the dashboard.

The following is a simple lifecycle breakdown of an ideal dashboard project:

1. Executive buy-in and project definition workshop
2. Readiness assessment and plan creation/execution
3. Best Practice look and feel design
4. Actual dashboard implementation
5. System infrastructure design and deployment
6. Dashboard deployment and feedback

Let’s take a look at each of the steps in a little more detail and determine what the outcomes of each step should include.

Executive Buy-In and Project Definition

No dashboard project will get off the ground without executive sponsorship. Resources will be needed and this project must be addressed with the same importance and rigor that any mission critical project requires.

Ideally there arises a project champion among the executive or driving group, a person who has a realizable vision of what the dashboard project will accomplish within the company. This person is quite essential to the success of the project. Certainly, there are dashboard projects that are successfully delivered with no real champions. But these projects have typically taken longer, cost more and been launched without a concise focus that allows recognizable and immediate return for the effort. Often this happens when someone decides their company needs a dashboard, but without going through the process of understanding what the goals and measurable outcome of monitoring that dashboard will be.

Part of this phase of the project is a determination of what things should be monitored by the dashboard. The measures that, when tracked, are able to produce actionable and meaningful ways to affect the outcome of the measure. It makes little sense to track measures for which the decision maker has no way to influence the drivers of that measure.

A very effective “best practice” is to bring the executive or driving group together for a couple of days to apply a workshop technique of determining the correct measures that are to be included in the dashboard project. During this process it makes a lot of sense to include a technical resource that can provide the answer to a very important question that comes up with every measure that is defined, “Do we actually have the data that is needed to produce this measure?”

A required product of this activity is a definition or blueprint of each of the measures that are decided upon. This blueprint should define: the data that is to be monitored, what the frequency of the data is, where the data currently resides, possibly a preference of what the display mechanism should be (bar graph, bullet gauge, map, table etc.), what level of detail the measure view should start at, what filters should be available to both slice and limit the view.

Another key component that should be produced during this phase is a conceptual prototype of the dashboard itself. The prototype takes each of the defined measures, or KPIs (Key Performance Indicators), and indicates how each of these should be laid out and relate to one another with regards to navigation and drill-down paths. Do not confuse this step with overall look and feel. This step is really the place where it is decided what the flow of the information will be and how the viewers will drive from one detail level and area to the next. These decisions must be made with a solid knowledge of what is important on a day-to-day basis for the business unit that will use the dashboard. The conceptual prototype dashboard can be as simple as a paper mock up with pasted cut outs of graphs and notes indicating details.

For example; does it make sense to show a sales organization a first measure which shows all of the actual sales transactions for the day in a large confusing table or chart, or does it become much more effective to have the first measure be a summary of the overall day’s sales performance by main category and then allow the viewer to spot problem areas and drill into them for greater detail? It might be said that one of the purposes of a dashboard is actually not to show all the collected data but to allow the viewer to filter off or remove all of the non-useful information to the point that only the high value, meaningful information remains uncluttered and clearly identified. This is the idea or notion of driving from summary to detail in a viewer specific way.

Summary of the resources that are created during this phase:

1. KPI blueprints, definitions of each of the measures which identify the following
   • Data used
   • Data frequency
   • Display type
   • Slicing filters
   • Limiting filters
2. Conceptual prototype
   • Navigational organization
   • Drill path for each KPI

A final part of this phase of the lifecycle optimally would be to build an abbreviated prototype of the dashboard using the actual selected dashboard implementation software. This should not be a complete build out, but a simple build of perhaps a single KPI connected to actual data (perhaps a CSV or Excel file representing the source data) and leveraging drill down and any other specific functionality that would be required in the final delivered dashboard.

This final step is very useful in ensuring that no functionality that is key to the workshop design is impossible to create with the software package that has been chosen. This operation often serves as a product selection phase where the products that are not able to meet the functionality requirements are weeded out.

Readiness Assessment/Readiness Creation

After the KPIs are determined, each of the KPIs must be evaluated and a determination must be made on the consumable readiness of the needed data. This includes an assessment and answers to the following questions.

1. Is the data currently in a format that will be directly usable by the dashboard
2. Is the data in a system that is not ideal for direct access
3. Does the data reside beyond a firewall that will hinder access
4. Is the data owned by another organization
5. Are there performance limitations that will hinder on-demand access
6. Will the enterprise user directory be integrated to control access
7. Is a data connector needed
8. Do accounts need to be created to allow the access

A strategy and plan must be created to address each of these items. Strategies with matching plan tasks may include the following:

1. Creation of summary or normalization views of data in source databases
2. Scheduled processes to create summary data
3. ETL processes to acquire and prepare data for dashboard use
4. Firewall rule adjustment
5. Create roles or identify existing roles in user directory to govern access and hierarchy of dashboard content
6. Data connector creation that leverages the target system APIs
7. Decision to use scheduled data loads into summary data snapshots to avoid performance bottlenecks.

Ideally, at the point the dashboard implementation begins there will be no outstanding items related to readiness. In cases where readiness cannot be addressed prior to implementation it makes a tremendous amount of sense to remove the related KPIs and schedule them into an upcoming additional effort.It is usually more effective towards the success of the dashboard project to do this rather than hold up the entire effort. In some cases it is possible to put a plan in place to coordinate implementation with readiness completion, but this course of action has real risks. Many dashboard projects have been plagued with unfulfilled deliverables because of these types of readiness issues.

Best Practice Look and feel design

A dashboard is much more than a pretty picture. There are a number of important considerations that come into the mix when determining overall look and feel of the dashboard.

Each of the KPI blueprints that were developed during the workshop phase will likely define a “desired” indicator type. This will be the point in the project to determine, among other things, if the selected indicator type makes sense.

Ultimately, it comes down to this; the dashboard is primarily a communication device. While traditional communication consists mainly of words, a dashboard uses mainly graphics and pictures. While everyone can understand the communication of pictures, not many are naturally adept at speaking picture. A lot of consideration must be taken during this phase to ensure the communication of your dashboard is clearly understood.

A simplified example might illustrate; you are attempting to show differences in productivity between pieces of manufacturing machinery. Each of the machines typically creates over two hundred thousand gizmos per week. The selected indicator from the workshop is a pie chart because the desire is to quickly see the machines performing below average. The problem is that the variation is typically under ten thousand units. Could you look at a pie chart and see that difference if there were 3 machines? Unless one machine is dramatically off target you would not be able to see this at a glance. A solution may be to use a bar chart so you can very quickly see even small differences. A further best practice refinement here would be to view only the relevant portion of the bar chart, say the top fifty thousand increments on the scale. This would allow you to use the limited amount of screen space you have to see even the minute differences that you may be looking for.

Never underestimate the value of an attractively designed dashboard. The final audience for your efforts are people, and people naturally accept and have great confidence in something that feels well presented. This is not to say that the project should leverage every available pixel in some graphically pleasing way. What is really meant is that every needed pixel should be usefully designed. Ask yourself this; if a summary screen in your dashboard was intended to draw the viewer’s eye to a series of summary bullet gauges that would have a red bulb illuminated next to areas falling under desired threshold, and the same page was full of other red graphical elements that compete on both a color level and a useable space level on the page, would the viewer have to work harder to hear the message you intended?

There are numerous publications available, which delve deep into the best practice methodologies that should be applied during this phase of dashboard project implementation. There are also expert consultative services available that companies can leverage to ensure this phase is successfully completed.

Actual dashboard implementation

It is important to complete this phase of the dashboard project on time. Historically, dashboard projects have taken longer than expected, cost more than planned and delivered less than desired.Because of past efforts, companies often have a preset opinion that dashboard projects are difficult to complete successfully. What complicates this process is the fact that the skill set needed for implementation is one of the toughest to fill within any organization. Identify your needed resources before beginning the implementation phase. This may include internal resources, outsourced services from domain experts or training new resources within your company.

Project management should be utilized for the entire dashboard project, but is critical in this phase, with each of the desired KPIs being grouped into logical milestones. This is especially important when there will be multiple resources contributing to the effort at any given time.

Adequate source and version control of the dashboard content is mandatory when there are multiple contributors to the project, and should also be strongly considered for single developer implementations. A dashboard project in the implementation phase looks a lot like a typical software project in that there are daily iterations, use case validation, testing, bugs, roll-backs and other technical challenges. Many of these challenges will be minimized if the other phases of the project have been completed successfully.

Now for a dose of reality, no matter how accurate your KPI blueprints are, no matter how definitive the look and feel design is, there will be points where the viewers need to change the game plan slightly. It can save a lot time that would otherwise be consumed in off-target iterations of the dashboard if the target viewer group is allowed to participate in the testing and viewing of early versions of the dashboard. The proverbial “Scope Creep” must be kept in check, but it is a healthy aspect of the dashboard project to allow the actual users of the dashboard to participate in its creation process. These early users can also validate that the information being presented is correct and help make adjustments if needed. This also leads to a stronger sense of ownership in the project, which helps create the needed adoption.

System infrastructure design and deployment

System design from a hardware perspective depends on a number of factors. The things that must be considered when sizing and planning the dashboard system are the following.

1. Dashboard server software selection and required operating system
2. User load (cluster nodes, RAM allocation)
   • How many users will be present upon launch
   • How many users will the system need to scale to support
   • What will the load pattern look like
     • Most users once at the beginning or end of a work day
     • Users spread evenly throughout the day
     • Users only come on when certain events occur within the company
3. Is a staging/QA system needed
4. How much caching of large data sets will be leveraged (RAM intensive)
5. How much scripting, custom coding or processor intensive operations will be running to support the dashboard (CPU intensive)
6. Will high availability and failover be necessary
7. Where will temporary data collections be stored (on system or off system)

There is no “silver bullet” solution to be applied to the above considerations. Instead, each of the items must be considered individually to ensure a successful and stable environment.

Dashboard deployment and feedback

Dashboard project deployment should initially be limited to a small chosen group. This can be accomplished either through the use of a validation (QA) environment or limited access to the production system.

Like software products, it is much more effective to accept feedback and issue reporting from a smaller group of people, people who are ideally interested in the success of the dashboard project.

Dashboards are typically used to present important business information. One of the things that can sink any dashboard effort is to present a dashboard to a large group of people while it may still have data integrity issues. First, because of the transparency dashboards introduce into any company or organization, a faulty data display can cause a great deal of discomfort for some person or department. Second, your entire user base could generate the opinion that the dashboard is not reliable and not believable, which will greatly reduce its effectiveness and adoption.

You should be prepared to field a host of comments and suggestions from people who actually use the dashboard. They will invariably identify items that they feel are needed in the dashboard to support their efforts. They will also help you tune the dashboard to more accurately support their needs. This is a normal part of the dashboard lifecycle that helps you drive the project to greater acceptance, use and ultimately, value. Further iterations follow the same steps as described here, with the opportunity to leverage existing effort in readiness, look and feel, and system setup.

Learn how Corda can support your dashboard project with complete Dashboard Life Cycle Services.