In-Depth
Dashboards: The Key to IT Management Transparency
Dashboards can shape (or reshape) perceptions of IT and enhance its organizational relationship with business users. Dashboards deliver transparency -- a world of growing, if not lasting, influence in the technology-requirements lexicon.
By Greg Hribar
IT departments might have a love-hate relationship with dashboards. On one hand dashboard projects become a channel for IT to communicate value to its line of business counterparts. On the other hand, dashboards also invite greater scrutiny from executives.
To the extent that IT feels comfortable, or is forced into, sharing its world with those outside, a dashboarding project can go a long way to shaping, or reshaping, perceptions of IT and enhancing its organizational relationship with the business. Either way, dashboards deliver transparency -- a world of growing, if not lasting, influence in the technology-requirements lexicon.
Dashboard Flavors
An executive IT dashboard is a simple mechanism for intuitively relating how IT impacts the business. Just as the dashboard of a car provides important information about the vehicle’s underlying performance or capacity, such as speed, fuel level, and revolutions per minute (RPM); IT dashboards provide an at-a-glance-view of the health and availability of underlying mission-critical IT systems.
Dashboards generally come in two flavors: real-time and historical. Some customers refer to real-time dashboards as the “morning report” because it is the first screen they review at the beginning of each day. The dashboard shows the state of the IT systems necessary to run the business. In essence, it answers one burning question: Am I open for business?
Historical dashboards measure and visualize health and performance over time. This is important to benchmark performance metrics and set objectives for improving service quality. After all, you cannot manage what you cannot measure. Historical dashboards have also proven an effective means for eliminating the finger-pointing exercise that tends to occur after an IT outage. Business users probably care less about who is at fault and more about what can prevent the outage from happening again.
Practical Applications
To understand what data should be included in a dashboard we need to first understand the purpose the dashboard will serve. For example, the “check engine” light on a car’s dashboard probably isn’t useful to most people on a daily basis, but the one time you need that indicator to light up, it’s extremely important.
Two unique challenges can put IT in a conundrum. The first challenge is when the business asks IT for an executive dashboard, but in the requirements-gathering phase cannot articulate what data should be included and what the dashboard should look like.
The flip side of this challenge occurs when the business is definitive in its requirements. IT delivers as promised, but the business then realizes what they asked for is not quite what it needs. This challenge represents some of the more frustrating aspect of getting a successful executive dashboard off the ground.
To avoid these problems, it’s useful to have a “portfolio” of dashboard ideas to discuss with the business. Here are some practical, real-life examples of dashboards in use today:
- The watch dog. The CTO of a global investment bank has little control or influence over IT operations. In essence, his business is at the mercy of IT’s productivity. His executive dashboard dissects sub-lines of business into several views, such as geography, bank branch, or by function, such as the ATM network. This ability enables him to take some action. For example, if the Midwestern call center is overwhelmed, he can direct traffic to be routed to another call center. In addition, the dashboard is a means to hold IT operations accountable: if a problem is taking too long to resolve, it’s costing the bank money and he’ll raise his ire on the phone until the problem is solved.
- Business before IT. A global telecommunication company started out with simple key performance indicators (KPI) to understand the lifecycle of a DSL customer. The dashboard was not initially IT centric, but focused on sales and efficiency metrics, such as the lines ordered versus the lines installed. However, as the line of demarcation between business and IT has become more indistinguishable, the infrastructure components that enable those resulting business metrics are being mapped to the service provided. This offers both sides -- IT and business -- a window into real-time availability in a context that is meaningful to them.
- Customers view. A global managed services provider uses a dashboard to visualize the impact of business outages and also provides its customers with an interface to transparently monitor their services. The project integrated more than a dozen proprietary data sources and provides customers with both a real-time and historical view of network topology, alarm status, network availability, service level agreement status, and trouble tickets. As a result, the dashboard becomes a competitive differentiator for the company against other managed services providers.
Tips for Dashboard Success
We must stress that IT and the line-of-business users must work together to build an effective executive IT dashboard. The line of business has the requirements and IT has the plumbing -- so no dashboard project can be successful without both sides working together toward a common framework. However, a dashboard project can get off track even long after requirements are gather together -- so we present several best practices to keep things moving in the right direction:
- Know your audience. A dashboard isn’t the data; it’s the output of data that’s presented in a customized fashion for a specific audience. A CTO will require a different view from a sales manager, who’ll want a different view from the marketing director or even an end customer. Understanding your customers’ business pain is a key to drawing out the requirements that will ultimately make the dashboard project successful.
- Keep the business involved. One of the biggest mistakes IT can make when developing a dashboard is to go into isolation after gathering requirements. Rather than emerging three to six months later with a product that may or may not meet expectations, show the business users updates regularly -- that it, demonstrate continuous progress throughout the development lifecycle. Never underestimate the power of swiveling your screen to show a business user the progress you’ve made.
- Plan for several iterations. Few dashboards have received overwhelming accolades in their first version. The liberal use of terms such as alpha, beta and early evaluation plans are highly recommended. This will enable both sides to fine tune the requirements, and deliverables will serve as an aid to keep the business involved.
- It’s all about integration. Executive IT dashboards are in many ways a mashup of disparate data sources, so the technology selected to develop a dashboard must be open, standards-based, and support integration. Specifically, integration should be at an API level and offer bi-directional communication with the underlying systems. It’s one thing to visualize a problem, but a dashboard from which you can drill down to isolate a problem and take corrective action is even more valuable.
Final Thoughts
The rise of social networking and related Web 2.0 technologies only solidify the utility of dashboard projects. Dashboards offer broader features and functions that are portable, flexible -- and interoperable -- all relevant as IT becomes more important to core business processes. Whether mandated by the business or proposed by IT, executive dashboards provide a transparent mechanism to communicate the business value of IT.
- - -
Greg Hribar, MBA, has more than 25 years in IT and is vice president of professional services for BSM vendor Managed Objects. You can contact the author through [email protected].