.avif)
The way we think about documentation has changed. We’ve moved from creating large, monolithic documents to managing a collection of small, reusable content components. This shift fundamentally alters the content deliverables meaning for modern technical communication teams. A deliverable is no longer just the final PDF or help site; it can be an individual topic, a reviewed code sample, or a set of approved assets within your Component Content Management System (CCMS). This article explores this granular approach, explaining how thinking of deliverables as modular assets makes your content operations more efficient, scalable, and ready for any channel.
How to Frame Your Content Delivery Sales Pitch
Within the technical communication bubble, tech comm speak is a natural, professional language. Once outside of your department, tech comm speak causes translation issues. Consider the times you’ve lamented that your department is overlooked when pitching new ideas or implementing changes—tech comm speak is likely at the root of it, again. A term that most technical writers use and understand might mean something drastically different to those you are communicating with.
Take deliverability, for example. In the technical communication field, deliverability is a capability that allows an organization to distribute content across multiple channels—a requirement in today’s business world. In marketing, deliverability is the ability to push messages into the individual email inboxes of those the company is targeting with its promotional campaigns.
Technical communication teams have various levels of deliverability maturity. Some organizations build basic content deliverability capabilities (think single-source, multi-channel publishing). More mature teams attempt to extend deliverability across all distribution channels—an omnichannel content delivery approach. Deliverability can change per audience.
The catch is that those responsible for approving changes in your organization often are not part of the technical communication literati. It’s your job to translate tech comm speak into something meaningful for stakeholders who don’t speak your language. Start by answering the question they’re all thinking: “What’s in it for me?” It would be best if you answered that question with real, honest-to-goodness, tangible functionalities with capabilities. What outcome can your suggestion result in that will provide stakeholders with a clear path to a win that they understand?
What Does Content Deliverability Actually Mean?
Before you march into a meeting with your organization’s upper management, you should prep your script.
Don’t improvise. Prepare a clear message. You might know what deliverability means to you and your team, but you have to shape those words into something that someone who is not a technical communicator can grasp.
Start with the function of deliverability. What is deliverability capable of providing to the organization?
It’s easy to blur the lines between delivery, deliverables, and deliverability, so start by separating them into simple categories as they relate to information development:
- Delivery is the process of publishing content to various channels and serving it to those who need it; it’s the where of your content.
- Deliverables are the content itself (e.g., physical copies, electronic); they are the what of your content.
- Deliverability is the processes of content creation that streamline both delivery and deliverables; it is the how of your content.
Consider using this level of specificity. Otherwise, your audience may misunderstand what you are attempting to communicate. Do an excellent job of explaining the differences, and you will avoid confusing your audience. Once you’ve defined deliverability as the how of your content, it's time to put your sales hat on.
What is a Content Deliverable?
A content deliverable is the tangible output of your work. Think of it as the "what" you produce and hand over at the end of a project, or even at key stages along the way. It’s the concrete result of all the planning, writing, and designing. While we often think of the final, published user guide as the main deliverable, the term covers a much wider range of outputs. A deliverable could be a set of updated API documentation, a new knowledge base article, a batch of translated content, or even a detailed content plan that guides the project.
In a modern technical documentation environment, the concept of a deliverable becomes even more granular and powerful. When you work with structured content, individual, reusable topics or components can be considered deliverables themselves. These small, self-contained pieces of information are created, reviewed, and approved before being assembled into larger outputs. This approach allows teams to think of their content not as monolithic documents, but as a collection of valuable assets that can be mixed and matched to create precisely the right deliverable for any audience or channel. This is a fundamental shift that makes content operations more efficient and scalable.
Tangible vs. Intangible Deliverables
Deliverables come in two main flavors: tangible and intangible. Tangible deliverables are physical items you can hold, like a printed quick-start guide that ships in the product box or a bound training manual for an in-person workshop. They have a physical presence and are often associated with traditional forms of documentation. While still relevant, the focus for many technical content teams has shifted toward the other category.
Intangible deliverables are the digital products and assets that form the core of modern documentation. These are the outputs you can’t physically touch but that deliver immense value to users. Examples include a fully published help website, a new software program, a set of API reference docs, a training video, or even the source content itself, neatly organized within a Component Content Management System (CCMS). The content model your team develops or the style guide that governs your work are also crucial intangible deliverables that shape the quality of everything else you produce.
Internal vs. External Deliverables
It’s also helpful to distinguish between deliverables meant for internal teams versus those intended for your external audience. External deliverables are the final products that customers see and use. This includes the user manuals, online help systems, in-app guidance, and knowledge base articles that help them succeed with your product. These are the outputs that directly represent your brand and impact the customer experience.
Internal deliverables, on the other hand, are the essential items created behind the scenes to make the external ones possible. Customers usually don't see these, but they are critical for keeping a project on track. Examples include a detailed content plan, a project schedule, drafts submitted for subject matter expert (SME) review, or a style guide. These internal outputs ensure consistency, alignment, and quality control throughout the content development lifecycle, forming the foundation upon which great external-facing documentation is built.
Common Types of Content Deliverables
In the world of technical communication, the list of potential deliverables is long and varied, reflecting the many ways users consume information. These outputs are the building blocks of a comprehensive user assistance strategy. Common examples include traditional formats like user guides, installation manuals, and release notes, which can be delivered as PDFs or printed documents. Digital-first deliverables are even more diverse, ranging from extensive online help portals and developer documentation sites to context-sensitive help embedded directly within a product’s user interface.
Beyond these primary documents, many other assets serve as important deliverables. These can include screenshots, architectural diagrams, code samples, and video tutorials that supplement written instructions. In more advanced content operations, a deliverable might be a curated set of chatbot responses or a package of content ready for translation and localization. By leveraging structured authoring, teams can efficiently generate many of these deliverable types from a single, managed source of content, ensuring consistency and saving significant time and effort.
Examples in Technical Documentation
To make this more concrete, let's look at a few specific examples from a typical technical documentation project. An obvious external deliverable is the complete user guide for a new software release, published as an online help portal. This is the final, customer-facing product. An equally important but internal deliverable would be the set of reviewed and approved DITA topics that were used to build that portal. These topics are individual assets that are managed, versioned, and finalized before being published. Another example is a translation package containing all the source files prepared for a localization vendor—an internal deliverable that is a critical step in producing the final, localized help portal for global customers.
How Deliverables Relate to Each Other
Content deliverables rarely exist in a vacuum. More often, they are part of a larger ecosystem where they are interconnected and build upon one another. The completion of one deliverable frequently serves as the starting point for the next, creating a logical flow of work throughout a project. This chain of dependency is what gives a project its structure and momentum.
For instance, a content plan (an internal deliverable) must be researched, written, and approved before the writing of the actual documentation can begin. Once the source-language topics are drafted and reviewed (another set of internal deliverables), they must be finalized before they can be packaged and sent for translation. The translated content, once returned and reviewed, becomes yet another deliverable that is then used to publish the final, localized documentation for customers (the external deliverable). Understanding these relationships is key to effective project planning and execution.
Dependencies and Composition
Diving deeper, we can describe the relationships between deliverables in two ways: dependency and composition. A dependency exists when one deliverable must be finished before another can start. The translation example from above is a perfect illustration of this; you can't start translating content that hasn't been written and approved yet. Mapping out these dependencies is a cornerstone of project scheduling, as it helps you sequence tasks logically and avoid bottlenecks.
Composition, on the other hand, is when a larger deliverable is made up of many smaller ones. A comprehensive online help system is a composite deliverable. It’s assembled from hundreds of smaller deliverables, such as individual concept topics, procedural tasks, troubleshooting guides, images, diagrams, and videos. In a DITA-based CCMS, this concept is central. You focus on creating and managing the small, modular components, which are then automatically assembled into the larger, final outputs your customers need.
The Role of Deliverables in Project Management
In project management, deliverables are more than just the end products; they are the fundamental units of progress. They transform abstract project goals into concrete, measurable outputs that can be tracked, reviewed, and approved. A project plan isn't just a timeline of tasks; it's a roadmap for producing a specific set of deliverables. By breaking a large project down into a series of smaller, well-defined deliverables, you create a clear path from start to finish.
This focus on deliverables provides clarity for everyone involved. Stakeholders know exactly what to expect and when, as each deliverable serves as a tangible checkpoint for review and approval. For the project team, it defines the scope of work and provides a series of achievable targets, which helps maintain momentum and morale. Allocating resources, estimating timelines, and managing scope all become more straightforward when the project is structured around the creation of specific outputs. This approach is also essential for strong content governance, as it establishes formal gates for quality control and sign-off.
Deliverables vs. Milestones
It's common for people to use the terms "deliverable" and "milestone" interchangeably, but they represent different concepts in project management. A deliverable is the actual, tangible or intangible *thing* you produce—the output of your work. A project milestone, in contrast, is a marker in time that signifies a major event or achievement in the project schedule. It doesn't have a physical or digital form; it's a point on the calendar.
Here’s a simple way to tell them apart: You hand over a deliverable, but you reach a milestone. For example, the "First Draft of the Installation Guide" is a deliverable. You can send this document to your reviewers. The "Review Cycle Complete" is a milestone. It’s the moment in time when you’ve received all feedback on that deliverable. Milestones are often tied to the completion or approval of one or more deliverables, serving as important progress indicators for stakeholders.
Deliverables vs. Objectives
Another critical distinction is between deliverables and objectives. An objective is the overall strategic goal or benefit you are trying to achieve with a project. It answers the question, "Why are we doing this?" An objective might be "reduce customer support tickets by 15%" or "improve user onboarding success rates." Objectives are the desired outcomes.
Deliverables are the specific outputs you create to help you reach that objective. They answer the question, "What are we creating?" To achieve the objective of reducing support tickets, your team might produce several deliverables, such as a new troubleshooting section in the online help, a series of "how-to" video tutorials, and more detailed error message documentation. Creating these deliverables is the work of the project, and if done well, they should lead to the achievement of the project's objectives.
Project Management Deliverables
While we often focus on the final product deliverables, it's important to remember that many deliverables are created specifically to help manage the project itself. These project management deliverables are the documents, plans, and logs that provide structure, communication, and oversight throughout the project lifecycle. They are typically internal and are essential for keeping the project organized, on schedule, and within budget.
Common examples include the project charter, which officially authorizes the project, and the statement of work (SOW), which defines its scope. Other key project management deliverables are the project schedule, a communication plan, a risk register for tracking potential issues, and regular status reports that keep stakeholders informed of progress. These documents aren't part of the final product, but without them, the process of creating the final product would be far more chaotic and prone to failure.
Defining Deliverables in a Statement of Work (SOW)
Among project management documents, the Statement of Work (SOW) is particularly important because it formally defines the project's deliverables. At the beginning of a project, an SOW is created to serve as an agreement between the project team and the stakeholders or client. It provides a detailed description of all the outputs—both internal and external—that will be produced as part of the project.
This level of detail is crucial for setting clear expectations from the outset. By explicitly listing each deliverable, along with its specifications and acceptance criteria, the SOW minimizes ambiguity and reduces the risk of future misunderstandings. It becomes the single source of truth for what is included in the project's scope. If a stakeholder later requests something that isn't listed in the SOW, it provides a clear basis for a discussion about scope change, ensuring that new work is properly planned and resourced.
Creating and Managing Your Deliverables
Knowing what deliverables are is one thing; successfully producing them on time and to a high standard is another. This requires a well-defined process and the right set of tools to support your team's workflow. A structured approach to content operations ensures that every deliverable, from a single topic to a full documentation portal, is created efficiently and consistently. By establishing a repeatable process, you can remove guesswork and empower your team to focus on what they do best: creating clear and helpful content.
A robust platform designed for technical content can make all the difference. Systems that support component-based authoring provide a framework for creating modular content, which simplifies reuse and management. They also offer tools for review workflows, version control, and translation management, which are essential for managing complex deliverables. Ultimately, these systems streamline the entire lifecycle, from initial draft to multi-channel publishing, making the entire process more predictable and scalable.
A Step-by-Step Creation Process
To ensure consistency and quality, it helps to follow a structured process for creating each deliverable. While the specifics may vary, a typical workflow can be broken down into a few key stages. It starts with clearly defining the deliverable's purpose, audience, and requirements. From there, you can plan its structure and scope before moving into the development phase where the actual content is written and created.
A simple, five-step process looks like this:
- Define: Work with stakeholders to clarify the goal of the deliverable. Who is it for, and what problem does it solve? Document these requirements.
- Plan: Create an outline or content model. Identify all the components needed, such as topics, images, and code samples, and estimate the effort required.
- Develop: Write the content, create the graphics, and assemble the components according to the plan.
- Review and Refine: Send the draft deliverable through a formal review cycle with SMEs and other stakeholders. Incorporate feedback and edit for clarity, accuracy, and style.
- Finalize and Deliver: Obtain final approval and hand off the deliverable to the intended recipient, whether that’s an internal team or the end-user.
Best Practices for Managing the Process
A good process is supported by good habits. Adopting a few best practices can help your team manage the creation of deliverables more smoothly and avoid common pitfalls. One of the most important practices is to use a centralized repository for all content and related assets. A CCMS provides a single source of truth, which prevents versioning conflicts and ensures everyone is working with the most up-to-date information.
Establishing clear and consistent review workflows is also essential. Make sure everyone knows their role in the review process and what is expected of them. Setting realistic deadlines and tracking progress against them helps keep the project on schedule, while using clear naming conventions for files and components makes content easier to find and manage. These practices create a predictable and organized environment where your team can produce high-quality work efficiently.
Overcoming Common Challenges
Even with the best processes in place, challenges can arise. One of the most frequent issues is scope creep, where the requirements for a deliverable expand over time. The best way to handle this is to refer back to the original SOW or project charter and implement a formal change request process. This ensures that any new requirements are properly evaluated, approved, and resourced.
Miscommunication among stakeholders is another common hurdle. This can be avoided by holding regular check-in meetings and maintaining clear, written documentation of all decisions and requirements. Finally, be prepared for resource bottlenecks, such as a key SME being unavailable for a review. Build some buffer time into your schedule for such delays and communicate any dependencies to stakeholders early and often so they understand the impact of their availability on the project timeline.
The Final Handover and Feedback Loop
The final step in the lifecycle of a deliverable is the handover. This isn't just about emailing a file; it's about ensuring the recipient understands what they are receiving and how to use it. For an external deliverable, this might mean publishing it to your help portal. For an internal one, it could involve a brief meeting to walk the next team through the content they are receiving. A clean handover prevents confusion and ensures a smooth transition to the next phase of the project.
Equally important is establishing a feedback loop. After a deliverable has been delivered, seek feedback on its effectiveness. For customer-facing content, this could come from analytics, user surveys, or support ticket data. For internal deliverables, it might be a quick retrospective with the project team. This feedback is invaluable. It helps you understand what worked well and what could be improved, allowing you to refine your processes and create even better deliverables in the future.
How to Get Stakeholder Buy-In for Content Delivery
It’s your time to shine, but on your audience’s terms and in their words. The language you use to convince them to care must be compelling. Consider the following:
- If you want them to spend money, you have to highlight the value.
- Don’t make assumptions about their preexisting knowledge—that could become your downfall.
- Use concrete examples of value instead of conceptual benefits.
Once you’ve explained content deliverability in plain language, it’s time to put together some use cases that will give your argument some weight. Deliver your points using the key performance indicators that the business values most, and connect them to the capability you’re seeking to develop.
Deliverability is only one capability required to create an information-enabled organization. Remember, you’re not orating in the ancient Roman Forum. You’re delivering a concise pitch that needs to pack a punch. Ditch the Aristotelian diatribe you had planned for this capability, and drill down on one of the most significant value points.
You have options. Tell them about the top functional powers that this new paradigm of delivery can enable— things like automated formatting, API-ready content, rapid content updates, or maybe something they didn’t even realize was possible, like personalized content experiences at scale.
Optimizing deliverability ultimately affects both your customers and your internal personnel. Personalization of content is a value proposition and aspect of deliverability that directly influences the experiences you provide to customers, employees, partners, and other stakeholders.
Let’s review a couple of business cases based on real-world situations that you might use to put a little more weight behind your argument and make a convincing case to stakeholders.
Pitching Content Delivery for SaaS Documentation
A Common SaaS Documentation Challenge
You’re a project management software-as-a-service (SaaS) company with frequent version releases. You have a small team that needs to stay on top of documentation updates and make sure that new documentation is always available and outdated documentation isn't.
The Capabilities to Highlight in Your Pitch
- Use multichannel publishing, making sure content in all of your deliverables is updated consistently, immediately.
- Filter content by audience segment and characteristics to ensure the right people are getting the right content.
- Use variable content to update standard components that you repurpose across information products (deliverables) in seconds.
How to Frame the Benefits for SaaS
The sales team can generate information faster for individual prospects. They can use content filters to match buyer personas and have the ammunition they need to tap each audience they’re hoping to influence.
Product teams don’t need to wait for documentation to be complete to release the product. Documentation teams can take the lead, giving extra prerelease prep time to marketing and sales.
Pitching Content Delivery for Hardware Documentation
A Common Hardware Documentation Challenge
You’re a medical device manufacturer with a product that doesn’t see many updates. While the product remains relatively stable and doesn’t change much over time, it’s a complex product with customer support as a significant cost center. The support staff and the documentation team exist in silos; the technical communication team focuses on compliance, while support concentrates on customer service.
The Capabilities to Highlight in Your Pitch
- Provide your organization with a single source of truth from which to deliver content.
- Improve content review cycles, and provide defensible audit trails that address compliance regulations.
- Automate content publishing everywhere, and break down silos between departments (like documentation and customer support), which is incredibly time-saving for large user guides full of regulatory jargon.
How to Frame the Benefits for Hardware
Audits are a pain, but they happen in our industry, and they’re necessary (you can lean into this pain point, noting how annoying audits are to management). According to a 2021 industry benchmark from Greenlight Guru, three out of four medical device professionals reported that they weren’t confident that they would pass an unannounced audit by the US Food and Drug Administration or (in the European Union) Notified Bodies.
E-signatures and review cycles all but eliminate audit anxiety and enable moving away from an over-emphasis on risk reduction in your documentation to using your content to empower sales, increase customer satisfaction, and improve the customer self-support and self-service experience.
Optimizing your content delivery system allows you to deliver content to multiple channels (websites, user manuals, online and in-product help, knowledge centers, chatbots, voice assistants) at the same time. Prospects, customers, internal support teams, and compliance auditors will all benefit.
Your sales team will view your newfound content deliverability prowess as a competitive differentiator: “Our documentation is better than theirs, and we have happy customers to back it up.”
These are just a few examples of how you might translate technical communication capabilities into business uses. To ensure leadership understands why they should approve a change in how you create, manage, and deliver content, focus on selling the value of the capabilities those changes provide and how they will transform the organization.
Putting Your Pitch into Action
A quote from STC Fellow and content strategy maven Ann Rockley applies perfectly to this problem: “You’re always going to sell a business case to management on the capabilities they can gain.”
Leaders invest in capabilities that deliver measurable results. While product features and their benefits are essential to understand, leaders are intensely focused on results.
Take yourself outside the technical communication echo chamber, and make the change valuable for the stakeholders you’re hoping to sway. Reconfigure deliverability to express its value outside of your department, then lean into functionality that leads to those value points. Make the potential benefits of adding a new capability straightforward and easy to understand.
Sure, it’s easier said than done. When the time comes to purvey what content deliverability can do in language that will sway stakeholders, this is an excellent place to start.
---
First published in Intercom in volume 67, issue 6 (November/December 2020) by the Society for Technical Communication.
Frequently Asked Questions
Why should I think of a single topic as a "deliverable"? Isn't the final user guide the real deliverable? Thinking of a single, approved topic as a deliverable is a fundamental shift that makes your entire content operation more efficient. When each topic is a self-contained, reviewed, and finalized asset, it becomes a reliable building block. This means you can reuse it across dozens of larger outputs—like user guides, knowledge base articles, or training materials—without having to rewrite or re-review it. This granular approach speeds up production and ensures your information is consistent everywhere.
What's the simplest way to explain the difference between a deliverable and a project milestone? It's a classic point of confusion, but the distinction is straightforward. A deliverable is the tangible or intangible thing you produce and hand over, like the first draft of a manual or a set of reviewed API examples. A milestone is a point in time that marks a significant achievement, like "SME review cycle complete." You create and pass off a deliverable, but you reach a milestone.
How can I explain the importance of "internal deliverables" to my manager who only cares about the final document? Frame the conversation around efficiency and quality control. Explain that internal deliverables, like a content plan or a set of approved DITA topics, are the foundation for the final product. Without a solid plan and well-managed source content, the final guide is more likely to have inconsistencies, errors, and delays. These internal outputs are the quality gates that guarantee the customer-facing document is accurate and delivered on schedule.
The article distinguishes between delivery, deliverables, and deliverability. Can you simplify the difference? Absolutely. Think of it this way: Deliverables are the what—the actual content you create, from a single topic to a full help site. Delivery is the where—the process of publishing that content to various channels. Deliverability is the how—it's your entire underlying process and system that makes creating and publishing your content streamlined, scalable, and ready for any channel.
What's the most common mistake teams make when pitching a new content delivery system to leadership? The biggest mistake is focusing on technical features instead of business capabilities. Your stakeholders don't need to know the specifics of structured authoring; they need to know what it can do for them. Instead of explaining what multichannel publishing is, show them how it allows the sales team to generate customized documents for prospects in minutes. Connect your pitch directly to outcomes they care about, like reducing support costs or enabling sales.
Key Takeaways
- Treat content components as deliverables: Move beyond viewing deliverables as only final documents. When individual topics, assets, and reviewed components are treated as trackable outputs, your content operations become more modular, efficient, and ready for any channel.
- Secure stakeholder buy-in by focusing on business outcomes: Frame your pitches around the capabilities and results that matter to leadership. Connect your content initiatives to tangible benefits like reduced compliance risks, faster product releases, or empowering sales teams with personalized content.
- Anchor your project plans to concrete deliverables: Use deliverables as the fundamental units for measuring progress. Defining every output in a Statement of Work (SOW) clarifies scope, sets clear expectations, and creates tangible checkpoints for managing your project timeline.
