 |
What Is A Dashboard
|
|
Our Methodology
|
|
Dashboard Security
|
|
The Art of Dashboarding
|
|
Key Dashboard Players
|
"Dundas Consulting did a fantastic job and was able to deliver the final project in two weeks, as planned. We were particularly impressed with the responsiveness of our consultant, as well as his willingness to share his opinions about our needs. Since this was our first dashboard application, we appreciated his candor and experience - especially on the subject of user interfaces."
Mitesh Patel
Executive Technology Director, TMX Communications
By Alexander Chiang, Dundas Consulting
The process of creating an effective dashboard application is always collaborative, at least that's what I've discovered in my years of working closely with clients to deliver dashboard solutions.
One common approach to dashboard creation consists of BI professionals collaborating with their IT team and looking at the project from the data slant: "This is the data we have, what kind of business metrics can we get out of it?" After involvement with countless dashboard projects, I've found fault with this line of thinking - to me, it's backward or upside down. When you look at the data first, you risk choosing an incorrect delivery platform for your organization, one that may not address the needs of the end users. After all, if your dashboard's end user can't decipher the data, your project has failed.
I believe a more successful approach is to start by collaborating with stakeholders and ask: "What reports or information do you want the end user to see?" When you consider your end user’s needs first, you go some way toward determining your dashboard solution's success in the end.
However, interaction with end users is just the start of the process. This article will focus on the main stakeholders and personnel who are necessary to ensure the success of a dashboard initiative. It is not a definitive guide to all possible things to consider, nor will it tell you how to organize a dashboard program. Rather, it highlights the people involved, the roles they play and the common things they should consider. Since I have served a functional part in each group, I can offer a sense of the big picture.
From my experience, the major groups of people involved in the dashboard-creation task are:
Although some would argue the database team should be part of the IT team, I prefer to separate them as the units serve two distinct functional roles in this type of project. For each group, I will go into detail about their responsibilities and interaction with the other groups. I consider this an effective way to create awareness of critical areas for consideration as well as clarify who needs to be involved in addressing them.
The end users are those who will be using these dashboards on a frequent basis. The group usually consists of C-level management, data analysts and any other person who needs to get a summary of various business metrics. From a dashboard designer's perspective, it is important to understand what metrics matter most to end users and how they use the information, because the point of the project is to make sure the result is making their lives easier.
Occasionally, detailed reports already exist within the organization. These will give insight on what business metrics are relevant to the end user; however, they should be used only as a reference point and not replicated. Keep in mind that sometimes these reports help the end user to do more work, as they may apply their own formulas to the data or filtering data so it’s easier to manage. The dashboard solution should take these needs into consideration and give the end user the power to look at the raw data and the ability to automatically apply their analyses of the data.
If there are no existing reports to use as a reference, it is prudent for the business analyst and/or technologist to set up interviews with the end users, and this is a good practice in any case as it identifies core technical requirements. Here are some common questions that are part of the interview process:
a. If you had to pick your top 10 (this is an arbitrary number) business metrics, what would they be?
The answers to this question help to identify key performance indicators (KPIs) and the supporting business metrics behind them. If the end users had their way, they would likely ask to see everything, which would break the traditional definition of a dashboard.
b. How do these business metrics enable you to make informed decisions?
It is important to understand how the end user is employing this data. The dashboard will help identify critical conditions by issuing alerts when a value hits a certain target or falls below a threshold. In addition, the way the end user manages the data gives insight into how he/she thinks about their business metrics, and represents essential input that is factored into the collaborative process.
c. How frequently do you need this data to be updated?
This answer identifies whether the data needs to be updated in real time, near real time or at a larger fixed interval. This information also lends itself to decision making in the configuration and deployment of the underlying data warehouse driving the dashboard.
d. How sensitive is the information you are viewing and who else may view what parts of it?
This identifies the level of security needed for a dashboard. There may be certain dashboards that only specific individuals may see. Alternatively, other dashboards may be accessible by everyone, such as a corporate dashboard that shows top-line sales metrics.
e. Will you be using these dashboards in presentations or reports, like annual shareholder reports?
This answer helps identify the need for exporting and printing the dashboards.
A major responsibility of the business analyst is bridging the gap between the business needs and the technology behind the solution. The business analyst usually works directly with the end users to ensure their needs are met in terms of business metrics. (These business metrics are then channeled to the database team to make sure there is data behind the metrics.)
The business analyst is generally involved in designing the dashboards and defining the dashboard's functional specifications including the user experience; however, there are cases when a dedicated user interface designer and/or graphic artist will be tasked with designing the dashboard. Dashboard design typically involves layout decisions, choosing the right data visualization tools to represent data, and styling. The design of dashboards is a topic unto itself and covered in more detail in another article that can be found here.
With that being said, the person tasked with the design must thoroughly understand the importance of data visualization technology and user interface designs as they relate to the project. As I’ve said many times to clients, dashboards need to tell the right story! Many of the specifications can be identified by the answers to the interview questions above. Obviously, knowing the specifications is of critical importance when working with the IT team, as they have to make sure the requirements are technically feasible.
In addition, the business analyst needs to work closely with the project manager to ensure the appropriate personnel are on the IT team. (This is further discussed in the IT team section.)
The database team is responsible for the data aspect of the project. Their main focus is identifying data sources relevant to the business metrics and structuring them in an easy-to-access manner. If there is no existing data to support a particular metric, then the database team must inform the business analyst of this dilemma. The business analyst will have a discussion with the end users to gauge the importance of the metric; it may be that the database team will have to address acquiring and storing this data and extend upon the current database accordingly.
Working directly with the business analyst, the database team will take the requirements gathered from the interview and take appropriate actions. Based on the above interview questions, the team needs to address the following additional scenarios:
1. The required data is located across disparate data sources such as, but not limited to, spreadsheets, legacy databases, flat files, and/or a third-party business intelligence data warehouse.
In this particular scenario, the DB team should consider consolidating the data sources into one uniform data store. This will improve the data access time and simplify accessing the data for the IT team, who will be delivering the dashboard system.
2. The business metrics are expected to be real time or near real time.
The DB team should consider using a solution that will allow the dashboard direct access to the business metric's underlying data. A web service can be a viable transport mechanism, but that would require a software developer. A push system (a system that automatically notifies any other systems listening that data has been updated) can be implemented as well. Again, this would usually require another database utility/application or require a software developer to provide this solution.
3. Dashboard security.
There are usually two places where dashboards can be secured: one is on the database level and the other is on the dashboard system level, which would be handled by the dashboard system. The database team can secure the data behind the business metrics by granting rights based on the end users' privileges; however, this is most effective if there is a centralized database.
The database team always faces the most complex and time-consuming part of the project. This is often because of legacy databases that have existed since the inception of the organization, and dashboard solutions may not integrate well with the current data structure.
The IT team has the responsibility for providing the dashboard system and supplying the hardware and/or the network infrastructure. The IT team must understand the dashboard system's technical requirements and take the following key aspects into consideration:
Technology today leans heavily in favor of rich internet applications (RIAs) as they are easy to deploy and maintain. That said, there are still times when clients request desktop applications (thick clients). One reason for using a thick client is the need for dedicated processing power for complex calculations. A web farm may solve this problem for RIAs, but a web farm may add additional costs in terms of servers, network bandwidth and licensing. In general, RIAs are used because of their ease of deployment and maintainability.
There are many dashboard solutions on the market that may satisfy any requirements in terms of the dashboard user experience and functionality. These turnkey solutions should allow for new dashboards to be developed and delivered quickly, provide a built-in security system, and offer other potentially valuable functionality such as exporting, printing and alerts. That said, turnkey solutions tend to be quite expensive, lengthy to integrate into your existing IT infrastructure (if applicable) and some expertise is required to deploy and maintain them. If your organization needs only a few dashboards, getting your development team or a consulting firm to create a custom solution may be more cost-effective and quicker to implement. A custom solution may be more suitable if the turnkey products evaluated do not satisfy the organization's requirements. I'd argue the main areas where turnkey products fail is in the dashboard user interface and user experience. From my experiences, there is no one product that end users are completely satisfied with in that regard. Ultimately, it is a build vs. buy decision.
IT infrastructure refers to the hardware, software and network needed to support the delivery platform chosen (and a database server is necessary if there is a consolidated database, regardless of the platform). If a desktop application is chosen, then it would be prudent to have an update server that checks to see the version of the application and updates accordingly. For the more general case of RIAs, a web server is needed at the very least; a web farm is more suitable for large volumes of concurrent users and intense data calculations.
The personnel involved will generally consist of software developers, network administrators and/or consultants with expertise in particular product lines such as those from Cognos, Microsoft or SAP.
Delivering a dashboard solution is a highly collaborative effort and the project manager is responsible for making sure everyone is working together efficiently and effectively, while keeping an eye on the schedule. The main areas the project manager should be wary of include:
As mentioned, the data is the most complex part of the project and this is due to the fact that databases were architected with the requirement for dashboards unanticipated. Significant effort is needed to ensure there is data behind the business metrics and if there is no data, the database architecture may have to be extended or redesigned to accommodate for this new data. Expect to allocate a significant portion of the project time for this work and you can expect the database team to advise you on the amount of effort needed.
Requirements will change and that’s a fact of any software project. Working with business analysts and the IT team to ensure the dashboard system chosen can handle these changes is a key requirement. The only way to minimize the risk of change is through experience and the reading of dashboard-system literature.
I’ve played the role of project manager for dashboard initiatives and I find that, on top of the standard skill set, understanding dashboards and data warehousing helps tremendously in mitigating risk, as does a solid knowledge of various products and technologies associated with business intelligence.
The collaboration I’ve outlined in this article advocates a non-orthodox approach where dashboards are considered first, the data is then examined and, finally, a dashboard solution is decided upon. Other approaches should be critically reconsidered, since the goal is to provide usable dashboards to end users. If the decision process works from the data to the presentation, the final result may not meet expectations of the end users, damaging their ability to make effective business decisions. Their consultation early on will yield many dividends down the road.
This article was originally published in the Business Intelligence Journal, Volume 14, Number 1. Visit www.tdwi.org for more information.
