What Do We Mean by Data-Related Deliverables?

When people talk about data governance or data intelligence, the conversation often starts—and sometimes stops—at data stewardship: who owns what, who sits on the committee, and who has authority over which data domain. But ownership alone does not govern data. What governs data is having controlled, well-understood processes for producing, documenting, reviewing, and sharing information about your data.  Central to that effort is a category of assets we call data-related deliverables. These are not just the reports and extracts your teams produce, they are the entire ecosystem of documentation, definitions, policies, and specifications that describe how your data is defined, structured, moved, and governed. In this post, we explore what those deliverables are, where they are stored, and some best practices for creating, managing, and sharing them.

What Are Data-Related Deliverables?

Data-related deliverables encompass all the output and documentation that describe, support, and govern your organization’s data. This includes:

• Data definitions and business glossary entries
• Report and extract specifications
• Data system inventories and data models
• Data lineage documentation (how data moves between systems)
• Data quality rules
• Data access and security policies
• Request templates, requirements documents, and technical design specsifications

Simply having these deliverables is not enough. You must govern them—ensuring they are agreed upon, complete, searchable, and used by the people who need them.

Categories of Data Deliverables

Data deliverables fall into three broad categories: process-related deliverables, data object deliverables, and policy and governance documentation.

Process-Related Deliverables

These are things that get run or executed - outputs that result from a data process:

• Reports — Tabular or graphical outputs (including dashboards and visualizations)
• Queries and views — One-time or reusable data lookups built against a database
• Data extracts — Flat files or spreadsheets for one-time or recurring use, including external survey submissions
• ETL processes (Extract, Transform, Load) - Automated pipelines that move data from source systems into a data mart or warehouse for trending and analysis
• Data integration processes — Inbound or outbound file transfers and API connections that share data between systems
• Alerts and notifications — Automated triggers that send data flags or messages when specified conditions are met

Data Object Deliverables

These are the data structures that act as sources or targets for the processes above:

• Database systems — Operational databases (e.g., Banner, Colleague, Workday, SAP), data warehouses, and operational data stores, including their tables, columns, stored procedures, indexes, dimensions, and fields
• Protocol data objects — Intermediate flat files and APIs that serve as source or target in a data flow but are not a live database system. A flat file extracted from one system and loaded into another is a protocol—it defines the structure of the data in transit.
• Survey forms — Survey instruments can be documented as data objects when they define the structure of data being collected, such as a federal reporting submission like Integrated Postsecondary Education Data System (IPEDS).

Policy and Governance Documentation

This category covers the rules, procedures, and structures that define how an organization governs data:

• Data governance charters and organizational structures
• Security and access policies
• Data request and access processes
• Data quality issue resolution procedures

Policy documentation may be less visible to end users, but it is critical for the people responsible for implementing and maintaining data governance.

Specific Documentation Types Within Each Category

Within the categories above, specific documentation types serve distinct purposes:

• Report specifications — Describe the functional and technical design of a report or extract, including source data mappings, field definitions, calculations, and output format.
• ETL specifications — Document the transformation logic and lineage for a process that moves data from one system to another. Unlike a report specification, both the source and target are data systems.
• Integration specifications — Similar to ETL but typically focused on protocol-to-system or API-based data flows.
• Data model documentation — Describes the structure of a database, protocol, or survey form—essentially the blueprint of a data object.
• Data dictionaries and business glossaries — Shared functional or technical definitions that apply across multiple specifications. These create a common vocabulary across an organization.
• Collections — Groupings of related specifications under a single umbrella (for example, a dashboard with five report specs is documented as a collection with narrative context and links to each component).
• Policy documentation — Free-form documentation covering governance policies, access procedures, and organizational processes.

Where to Store Data-related Deliverables

Producing data deliverables is only half the battle. They need to live somewhere where people can find them. Your options range from lightweight to comprehensive:

• Shared document repositories (Box, SharePoint) - Easy to set up but difficult to search across document types and provide no built-in relationships between items.
• Ticketing systems — Useful for storing request-related documentation but not designed for cross-linking deliverables or tracking relationships.
• Native reporting tool inventories — Some tools include a report catalog, but this only covers deliverables built in that one tool.
• Database documentation tools — Open-source and commercial tools can auto-generate documentation from your database schema, but they do not typically cover business-level definitions or process documentation.
• Wiki or content management systems — Good for policy documentation and free-form content, but not purpose-built for structured data deliverables.
• Dedicated data governance knowledge base (e.g., Data Cookbook) - Purpose-built solutions that centralize all deliverable types, support structured workflows, enable cross-linking of related items, and make content searchable across the organization.

Whatever approach you choose, the knowledge base must be centralized, searchable, and accessible. If people cannot find the documentation, it effectively does not exist.

The Data Request Process

Understanding how data deliverables are requested helps clarify what documentation needs to exist at each stage. A typical data request process flows through five phases:

• Self-service inquiry — Users research existing reports, data models, definitions, and policies to determine whether what they need already exists.
• Request submission — If nothing suitable exists, users submit a formal data request using requirement templates and design documents.
• Development — A report developer (or the requestor themselves) designs and builds the deliverable, creating or updating definitions and specifications along the way.
• Review and approval - Have the requester review and approve the data-related deliverable and a data steward if applicable.
• Delivery and documentation — The completed deliverable is shared along with user-facing functional documentation and technical documentation so future developers can build on it.

In practice, many organizations skip most of the documentation steps—developers jump directly into building, and there is little or nothing in the way of requirements, design, or user documentation to show for it afterward. This is the gap that a strong data deliverables practice is designed to close.

Best Practices for Data Related Deliverables

Besides having a data request process in place and having a centralized, searchable, and accessible data governance knowledge base, here are some other best practices:

Use Templates—but Allow Flexibility

Templates drive consistency and completeness. Common attributes like purpose, description, functional area, owner, and tools can be standardized across all deliverable types. That said, be careful not to over-prescribe. Different developers prefer different documentation styles.  Some start with visual mockups, and others with narrative descriptions, others with field-level tables. Specific tools (Tableau vs. SSRS, for example) also have attributes unique to their platform. Templates should guide without rigidly constraining.

Build in Review, Approval, and Status Tracking

Documentation without governance is just files. Every data deliverable should have a clear status (draft, in review, approved), an assigned data steward, and a defined review and approval workflow. This can be managed manually, through a ticketing system, or through an integrated data governance solution, like the Data Cookbook, that automates the process.

Version and Track Changes

When a report is updated—a new field is added, a calculation changes—how do you manage that? Simply overwriting the existing document loses history. A proper versioning practice ensures that changes are tracked, approval is re-triggered when needed, and the impact of a change can be assessed before it is made.

Maintain Relationships Between Deliverables

This is one of the most important, and most overlooked, aspects of managing data deliverables. A change to a data system object (say, a table is deleted or a field is renamed) has downstream impacts on specifications, which in turn affect collections. If your documentation lives in isolated Word documents on SharePoint, there is no practical way to trace those relationships or assess impact. A data governance knowledge base that links deliverables together makes this possible, like the knowledge base in the Data Cookbook.

Control Access Thoughtfully

Not all documentation should be visible to all users. You may want to restrict access to HR or Finance data deliverables to authorized personnel or hide technical metadata from business users who find it more confusing than helpful. Think through your access model as you build out your knowledge base—who should see what, at what level of detail.

Have Points of Engagement with Data Governance Deliverables

Where possible, link or embed knowledge base documentation directly into the report or tool the user is accessing. If someone is running a Tableau dashboard, they should be able to click through to the report specification, the data definitions, or the data request contact—without having to separately navigate to a documentation repository. This dramatically improves adoption.

In conclusion, you do not need to document everything at once. But as your organization builds new data-related entities - reports, extracts, ETL processes, integrations - you should be building documentation alongside them, storing it somewhere accessible, and ensuring there is a process for people to review and interact with it. And a process to request new deliverables.

Without this foundation, the energy your teams invest in creating data deliverables is undermined - people cannot find what exists, do not trust what they find, and end up duplicating work or making decisions on misunderstood data. The documentation is not overhead. It is what makes the deliverable valuable. 

Hope this blog post was of assistance to you and your organization.  All our data governance and data intelligence resources (blog posts, videos, and recorded webinars) can be accessed from our data governance resources page.  IData has a solution, the Data Cookbook, that can aid the employees and the organization in its data governance, data intelligence, data stewardship and data quality initiatives. IData also has experts that can assist with data governance, reporting, integration and other technology services on an as needed basis. Feel free to contact us and let us know how we can assist.
 

Image Credit: StockSnap_LLUARZPR33_ManConfused_DataDeliverables_BP #B1245