This is the second post in a series about creating effective leadership dashboards. You can catch the first post in the series on the goals of an effective agile dashboard aquí.This post focuses on how to organize the creation of a great dashboard. How the dashboard is created is often overlooked in favor of diving directly into what metrics to include, and the look and feel of a complete dashboard; but being deliberate in the process can dramatically improve the finished product and prevent the alarmingly frequent incidents of total failure. For example, a client I am currently supporting in dashboard creation had previously worked with a large accounting firm to create an executive dashboard for their development group…six months and hundreds of thousands of dollars later, the project was cancelled without the leaders ever having seen a single working metric!
There are three main pillars for how to create a successful leadership dashboard:
- Use Scrum to develop the dashboard
- Develop a prioritized backlog of metrics and deliver incrementally
- Leverage an “interactive” interface and drill down hierarchy
Use Scrum
It should come as no surprise that I recommend using a Scrum team to develop and deploy the leadership dashboard. (After all, we use it for everything here at Scrum Inc.) But interestingly enough, when most companies embark on developing a dashboard, they tend to treat it like an internal side project and not give it the full focus, attention and agile discipline that they apply to their customer-facing work. With unclear roles and objectives, and competing with a dozen other projects for employee attention these informal efforts often go nowhere.
If you are serious about developing a useful dashboard, designate a dedicated and cross-functional team to build it. Maintain the discipline of working off a backlog of metrics to deploy and identify a product owner to incorporate user feedback. Leverage the structure provided by a regular sprint cadence with demo and retrospective meetings. It may feel like a lot of overhead, but you will be glad you made the investment when enjoying your completed dashboard.
Deliver Incrementally
What caused the failed dashboard effort mentioned above, and countless others before it, was the attempt to deliver a working dashboard in a single “big bang.” The hallmarks of this approach are to “mock up” the look and feel of all of the metrics in a dashboard, get buy in from leadership on that design, then build the dashboard. Unfortunately, this waterfall approach is no more effective for dashboard creation than it is for software development, and for exactly the same reasons: 1) leadership doesn’t really know what they need to see to make effective decisions until they see it, leading to a “moving target” that can consume years of back and forth mock-up revision; 2) too often, teams agree on a mock-up only to discover that it is impossible to pull the data required to make it a reality; and 3) company data and systems are complex and interdependent…small changes to one element of the dashboard have ripple effects throughout the tool, making after the fact changes a nightmare.
Fortunately, dashboards lend themselves extremely well to iterative and incremental delivery. Each combination of metric and business unit within the company is a useful feature that can be delivered and refined independent of the other metrics. Integration, summary views and second-order metrics can then be layered on. A savvy product owner in dialogue with the dashboard’s end users can easily prioritize which metrics and which business units are of greatest concern and prioritize the backlog of metrics appropriately to deliver the greatest value as early as possible. Ensuring that there is an easy way for users to provide feedback within the first iteration of the dashboard makes this process even more straightforward.
The biggest challenge here is to set appropriate expectations with leaders in advance about what incremental development looks like and get a commitment to providing feedback. They might be resistant at first to a partially completed product or the effort of feedback, but it is imperative that they provide actionable guidance to produce an effective dashboard. “It isn’t good enough yet” is a common response, but not sufficiently engaged and actionable to help the team.
In the past, I have positioned the value proposition for incremental delivery as, “The initial version will be rough, and I can almost guarantee that you won’t like it; however: you will have something in your hands within x days, it will be REAL data that will improve your visibility over what you have now, and we will implement any actionable feedback you have over the subsequent iterations to make the dashboard exactly what you want it to be.” This usually works, though it is worth getting agreement in writing for the inevitable retrenchment later.
Leverage an Interactive Tool
The default expectation in the business world is that a dashboard is a single page or PowerPoint file that contains summary metrics and can be transported around for easy reference. While this is fine in practice, the advent of cloud computing and ubiquity of mobile devices have opened up significant new possibilities for interactive metrics reporting. Here again, a little up front expectation setting is essential to leveraging this potential.
A single flat dashboard can only show top-level metrics and tends to get very cluttered as more information is added. By contrast, an interactive data visualization tool like Tableau o Domo can have a clean and simple top-level design, but allow the decision-maker to click-down into disaggregated views as needed (stay tuned for more detail on tools in a future post). It provides more data, but gives the user control over how much detail to show. The data can be updated at different cadences or even in real time, rather than a single monthly update to a PowerPoint slide. Finally, with dashboards fed to mobile apps, the information is even more readily available than the printed dashboard page.
That said, remember that the dashboard’s ultimate purpose is to help leaders make decisions, so particularly in the early iterations it may be helpful to build a dashboard that looks familiar and comfortable to leadership. Having built credibility in the process and team, you can then flex your interactive muscles and deliver value-adding capabilities.
In the next post, we will cover what information leaders typically want updates on a regular basis, and how to achieve those objective with compelling agile metrics. If you want a sneak peek at some of these metrics, they are covered in our online course on The Scrum Leader’s Dashboard.
AlexBrown is Scrum Inc’s Chief Product Owner and Chief Operating Officer. He set up the company’s internal metrics dashboard to automatically consolidate and share agile metrics and support better decision-making. He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.
Spanish 
English 
French