How to avoid Data Chaos?
Even though you may be working in the capacity of a Tableau consultant, you should not be blindsided by the narrative that knowing just Tableau will be enough to succeed. Familiarize yourself with the whole data ecosystem, which is essential for success.
Recently, I was a witness to a data chaos of such a magnitude that it plunged me to work for insane hours for the whole month of May. Initially, according to the project owners, the project’s solution could be handled in the backend (without Tableau) which led to grave data issues. However, the final solution was provided on the front end i.e. Tableau. Though engaged as a Tableau developer, the holistic understanding of functional, as well as the backend systems helped me to provide a viable solution.
Let’s understand what set of knowledge can help avert data chaos and help you be productive by providing appropriate solutions.
Understanding of functional systems
By functional systems I meant the complete understanding of a client’s business operations. Especially the department functioning or business aspect around which your project is based. Many times, we take it for granted that certain aspects of operations or systems are already known to all parties involved. We assume that clients will provide the necessary data output requirements and we just have to apply the logic of how to implement it in Tableau. The key word being ‘assume’ here. We conveniently forget that clients also make a lot of assumptions on their part as far technology is concerned. We can avert a lot of unnecessary chaos and issues if we understand the client’s business thoroughly. Like this, as developers/ analysts or consultants, we can also make strategic, technical and logical recommendations to the client.
Understanding of BI data ecosystem
Every organization has a data ecosystem in place. Turning a blind eye to it can exponentially increase our workload. It’s imperative that we understand the origin point of data, the data structure or data type or hierarchy or nuances that can help you in your project. This may help you to identify the fields that are crucial to your project, though may or may not be deemed as unnecessary in client’s viewpoint. Also, if there is any data that can add value to the project, you will know where to search for them.
Requirement documentation from the business team
A lot of miscommunication can be avoided if you request for documentation from client or business side detailing the requirements, specifications and expectations from BI developers or consultants. The document need not be elaborate, but must define what the client expects. This document then becomes the referral point in case of any confusion and/or doubts. This will keep the client as well as you in focus and clarity about the expectations.
We lose a lot of time, energy and mental peace if we don’t ask questions. Asking questions for an impactful deliverable is essential. After all, it affects your performance evaluation too. Raise questions even though you feel them to be senseless or irrelevant. They may sound immaterial to the client but for you that may be essential to apply logic in your solutions. You can avert data chaos if you clear your doubts right in the beginning and save a lot of time for everyone involved. Request time for questions proactively. Ask questions not only about the systems, logic but also question the feasibility of the project.
Ability to say no
Do not blindly agree with all that is being asked. Technology is no silver bullet to any or all problems. There was and there always will be technology limitations. Rely on your learnings, skills, research, past experience to reach conclusions about the feasibility of the project requirements. But a simple no is not enough. So, be prepared to provide an alternative solution. This will make the client less defensive, and broadens their perspective to be more open for constructive dialogue.
Testing on a pre-defined dataset
Avoid testing your work on live data even if you are working on a mock server. Do ensure that your test data is not refreshing on an hourly or on a daily basis. Having a pre-defined and static dataset can help to assess if you are making any mistake in your calculated fields or SQL queries especially with JOIN statements. Like this, you can easily cross-evaluate the results. If in future you are amending the query or solution because of a new requirement, then if possible, use the same dataset to evaluate the cascading effect. You will be able to identify issues, if any, with your codes or logic immediately.
Concluding, I hope this equips you to tackle BI projects more suitably. But, is this all that needs to be known? Probably not, but this gives you an outline for preparation on how to handle BI projects judiciously, efficiently and effectively. Till next time….