Three Signs Your BI Dashboard Development Process Needs Help — and What to Do about It
In an ideal scenario, BI dashboards offer a highly curated experience to communicate data effectively and keep users engaged — so it is logical that the dashboard development process is also largely defined by the specific needs, preferences and interests of key stakeholders. However, most dashboard development projects are run in a traditional waterfall manner that often leads to inadequate communication and little iterative flexibility, which hurts the quality of the end product and the experience with the development process itself for both the customer and the internal or external build team.
In this post, we’ll take a quick look at the most common signs of a BI dashboard development suffering from one or more of these issues — and present solutions built on a user-focused, agile approach.
1. Meaningless, unreadable charts
Overengineered and impractical data visualizations typically result from the project relying too heavily on one client-side stakeholder for direction. The person fulfilling this role has the authority to instruct the developers but often does not know the end users’ exact needs. The result is that once the developer is given a user story-based design to execute, they tend to approach the challenge as primarily technical. This often leads to dashboards crammed full of badly presented information based on a mere assumption — but not validated proof — of usefulness.
Worst of all, the fact that the needs of the end users and target audience have not defined well and consequently the dashboard is poorly suited to solve their problems will only become apparent at the end, after considerable time and money has already been wasted.
What to do?
Involve end users in the entire development process, starting at the earliest story-building stage. A client-side project sponsor supplies the business knowledge, the developers supply the dataviz expertise, and together they should spend time with the eventual users of the dashboard to ensure a practical approach by defining their problems, challenges and user stories.
The sponsor and the developer can then use these stories to guide development and have end users regularly get first-hand experience with and provide feedback on early results to make sure every bit of development will ultimately serve their needs.
2. Underutilized dashboards
This symptom of BI development gone wrong stems from an issue very similar to the one above: the client-side stakeholder defining the business need lacks the perspective to optimize the scope of development. In contrast to the previous example, however, the end product here may represent satisfactory value — but is a missed opportunity.
The more users your new dashboard can effectively serve, the more bang you’re getting for your buck, but high-level consumers of dashboards often specify the business need too narrowly, and commission development that will ensure results that serve their own needs well, but fail to achieve broader organizational usefulness through multi-stakeholder relevance, cooperation opportunities, etc. Such cases might leave the client in need of additional development, at additional costs.
What to do?
The challenge here is finding the sweet spot between a dashboard serving too narrow and too broad needs. This can be ensured by building on the earlier point about engaging the end users and involving a wider range of relevant stakeholders in the development process and maintaining a robust iterative feedback loop.
For most BI development projects, the ideal list of stakeholders to involve includes the client-side sponsor of the project, an expert of the business process, a technical expert of the source system, an end user, IT personnel responsible for the relevant infrastructure and the internal or external data visualization development partner. When these people are included, a more agile approach to BI development can be implemented to promote streamlined delivery of a product that serves a wider range of needs without compromising quality.
3. Runaway Development Cost and Time
Getting the best value from a BI development project doesn’t solely hinge on the quality of the end product. If it takes too long to get the results you need, you start missing out on opportunities for innovation and profit.
Delays are often the result of a misalignment between story-building/design and development — we’ve already talked about how, in a waterfall project, developers can often do little to salvage a design that began with a subpar definition of needs. But even development based on a well-defined user story can grind to a halt if it turns out that the backend — be it due to structure, data quality, or other reasons — simply doesn’t support the original design. Because the product still needs to be delivered, there is no choice but to fix the issues, or at least work around them, which will take up additional resources and keep users waiting.
What to do?
In addition to involving all relevant stakeholders at the right points during the project and using agile processes wherever it makes sense (more on this below), the biggest leap you can take towards cultivating more effective BI development is to have a single team be responsible for both the story-building and development phases of the project. These two main phases are commonly split between a team providing consultancy-type service and a developer, with little overlap between their respective expertise and responsibilities.
By contrast, having a single team handle both phases will promote the delivery of stories that are both effective and feasible — because it will be the responsibility of the same team to demonstrate that the resulting development can indeed produce the expected results in a time- and cost-effective manner.
Conclusion — Embracing a User-Focused and Agile Approach to BI Development
The three signs discussed above encompass a range of smaller issues of BI development gone wrong, but the broad solutions proposed should provide at least a considerable head start to fixing them. These solutions are based on a new, user-focused and agile approach to BI dashboard development that requires greater input and responsibility from client and dataviz partner alike, but in turn promotes effective deliverability of higher-value results.
If you’re interested in learning more about these solutions and concepts, we’ve created an in-depth white paper that documents an Agile framework that Starschema has adopted for BI dashboard development projects — access it here and see if the approach laid out in it works for your needs:
REACH OUT TO STARSCHEMA HERE:
READ MORE STORIES FROM STARSCHEMA
