Data And Analytics teams are tasked with developing insights that drive decisions. These insights are often based on datasets gathered from multiple sources across the organization, including customer databases, sales histories, marketing campaigns, financial reports and more.
The sheer volume of information can make it challenging to find the needed answers, especially if the Data and Analytics team has grown over time.
As a result, many organizations end up with a fragmented or duplicated information architecture, making it hard for their data teams to exchange knowledge on the inter-department and cross-department levels.
The vital part of every data role is documenting the development process and outcomes. Or, in other words, creating technical and non-technical documentation per different areas; data engineering, data science and data analysis.
Truth be told, writing documentation is nothing new. However, it can be time-consuming when no clear guidelines are previously defined.
With this in mind, data professionals should create templates to ensure systematic and transparent documentation delivery.
Because let’s face it, predefined templates are already half the work done.
Subsequently, this blog post aims to show how to create and template a Data and Analytics Knowledge Base from the perspective of external, shared and internal documentation.
The Knowledge Base Organization
The knowledge base should be a central collaboration hub for the Data and Analytics and other teams. This is the place where the team’s pieces of information, methodologies and technical/business knowledge are stored and shared accordingly with different groups of business users.
And having in mind different user groups, our Data and Analytics (D&A) team has organized knowledge base documentation templates into three groups: D&A external documentation, D&A shared documentation, and D&A internal documentation.
Let’s start by elaborating on each documentation group and its templates.
D&A external documentation
As a Data and Analytics team, it is crucial to have transparent processes and standards. Whether you are working on new development or supporting existing ones, it is essential to document how the team operates, so everyone in the organization understands the analytical development process.
And this is the primary goal of the external documentation – sharing the general information on the team’s organization, cross-department data insights, development insights and team development updates.
Having this goal in mind, our D&A external documentation consists of the following structure:
As visible from the image above, the external documentation has four main sections:
- #1: About D&A Team – the section covers general information about the Data and Analytics team and the development framework and roadmaps for business intelligence and data science areas. In addition, this section explains the analytical development process to all business users and contains our quarterly and yearly development tracks.
- #2: End-user data insights – the section covers a detailed explanation of the used analytical and business abbreviations, a list of dashboards per different types (trend or evolutional dashboards), and different business areas. Furthermore, the explanation of each data model is provided here for users with access to self-service data models.
- #3: Development insights – the section covers data engineering, data science/analysis and custom development notes. Data and Analytics architecture is presented in this section, too, along with explained data sources and testing templates.
- #4: Data & Analytics monthly updates – the section covers monthly updates on the developed tickets per different data and business areas.
Following the elaboration of the external documentation structure, we can now switch to elaborating on the shared documentation structure.
D&A shared documentation
The cross-team cooperation is relevant in the Data and Analytics team as there is a daily/weekly/monthly need to exchange business and development updates.
And for this reason, our Data and Analytics team has created shared documentation to log the meeting notes, development ideas and team-related business knowledge for planning future analytical use cases.
Our D&A shared documentation consists of the following structure:
As visible from the image above, the shared documentation has sections named after other teams/circles in the organization and contains different sub-sections for ramping up the analytical and business development.
Depending on the industry and organization type, your Data and Analytics team will have completely different sections and sub-sections listed here. However, the main goal is to have the sections within shared documentation visible only to specific groups of users (teams).
With this said, we can now switch to explaining the last part of the knowledge base – internal documentation.
D&A internal documentation
The internal Data and Analytics team documentation is more detailed and specific, as it should hold team-only relevant information.
It should be the reference hub for the Data and Analytics team members to monitor the team’s organizational and technical development plans continuously. In addition, it can contain organizational and technical guidelines for the new team members and a place where the team can share helpful resources.
Our D&A internal documentation consists of the following structure:
As visible from the image above, the internal documentation has four main sections:
- #1: Company and D&A Vision | D&A inter-team guidelines – **** the section contain the Data and Analytics vision aligned with the organizational vision. It also holds the relevant guidelines for booking holidays and out-of-office hours, plus information on the core working hours.
- #2: Onboarding & Technical guidelines – the section holds a sub-section on organizational onboarding, which contains links to the time management system, resources for understanding company structure and access to all relevant data sources and contact persons in other departments. A technical onboarding sub-section is also provided here, and it contains the relevant tutorials and literature for catching up with the current development. Lastly, the definition of done criteria per different data areas is listed here too.
- #3: Retro meeting notes – probably the most used section in the Data and Analytics team because it contains the weekly organizational and inter-team updates, sprint (re-)planned tasks and the summary of the past weeks’ concluded tasks.
- #4: Docendo discimus or "By teaching, we learn" – the idea behind this section is to share helpful everyday resources and non-work related ideas or conference plans.
We are concluding our "best practices" for structuring the knowledge base repository with this part.
To conclude: make it visible and make it common practice
Let’s conclude this blog post by sharing the benefits of why the three different knowledge base clusters (external, internal and shared documentation) should be implemented in any (data) team:
- The provided knowledge base structure makes the Data and Analytics workflows transparent and easily referenced to everyone in the business.
- The provided knowledge base structure holds the Data and Analytics updates, meeting notes, development documentation, etc., available for business users to use whenever they need it. This will keep the Data and Analytics team members from repetitive update sharing.
- The provided knowledge base structure eliminates inter-team development bottlenecks by ensuring that anyone within the team always has an eye on the planned tasks in the current (and past) sprints.
- The provided knowledge base structure eases the team lead’s inter-team information sharing as every team member can easily access organizational and technical guidelines.
- The provided knowledge base structure eases the onboarding of the new team members and new business users with data insights.
- And lastly, the provided knowledge base structure saves time when creating new documentation, as the templates **** are created for every section.
Finally, this post aims to help data teams structure their knowledge base documentation because even small things like this can make a big organizational difference in information transparency and Knowledge Sharing.
