Defining Deliverables: Agree on What Gets Handed Over

This section demonstrates the actual troubles and specific losses that occur in projects that proceed with ambiguous deliverable definitions.

A web design project that started with the request "Please design our homepage" leads to the following situation. The freelance designer (contractor) creates design mockups for the top page and three sub-pages, then reports "It's complete." However, the corporate client responds with successive additional demands: "Where are the smartphone versions of the designs?" "We also need icon assets for implementation." "We thought font files would be included too."

At this point, the contractor has their time consumed by unplanned additional work, while the client faces schedule delays as their expected deliverable list isn't complete. This creates a structure where both parties suffer losses.

Looking at actual numbers, this type of misunderstanding has serious impact. In small and medium enterprise web production projects, data shows that deliverable definition deficiencies lead to additional costs averaging 20-30% of the original budget. Contractors also commonly lose monthly income opportunities as additional work delays starting their next projects.

What's expected as design deliverables seems to have industry standards, but is actually ambiguous. Even when ordered as "complete design package," without specific definitions of whether this includes original Photoshop files or just PNG exports, how far font and image asset licensing extends, it becomes a source of trouble.

The problem isn't limited to the creative industry. In system development, there was a case where the contractor assumed "test data for operation verification is included in deliverables," but the client considered "including production data migration as completion." In marketing support work, the scope of "analysis reports" varies greatly between providing raw data or including interpretation and action plans.

For contractors, ambiguous definitions mean the risk of unpaid labor. They're forced to perform work outside their budget to meet client expectations of "this should naturally be included." For clients, problems arise such as being unable to fulfill internal accountability when expected deliverables aren't obtained, and needing approval procedures for additional budgets.

Particularly serious is the deterioration of trust relationships. Emotional conflicts develop with comments like "If you had said so from the beginning" or "Common sense would include that," often leading to the breakdown of ongoing business relationships.

This section analyzes the structural causes of why deliverable definitions become ambiguous in many projects.

The biggest factor is that clients and contractors have different standards for what's "obvious." Contractors proceed based on common sense in their specialty field. For example, "responsive design" is a natural prerequisite for web designers, but clients might think PC version design alone is sufficient. Conversely, clients assume contractors understand their industry's common sense. A manager from the printing industry might think "production data" is universally understood, but it's an unfamiliar concept to web-specialized designers.

Time constraints at project start are also a major factor. Many clients start projects with the attitude of "let's begin and decide details as we progress." Contractors also prioritize speed over detailed confirmation to win projects in competition with other companies. As a result, agreeing on "what to deliver" gets postponed.

Industry practices are also problematic. There are supposed implicit understandings like "in the design industry, ◯◯ is common sense" or "in system development, including △△ is normal," but interpretations actually vary greatly between companies and individuals. However, both parties assume "the other side shares the same understanding."

An organizational problem on the client side occurs when the contact person differs from the actual user. The sales department serves as the contact for ordering, but the actual design users are in the production department with completely different quality and format requirements. The contact person might think "anything that takes shape is fine," while the actual user department expects "pixel-perfect design considering implementation."

Contractors also have problems. The attitude of "flexibly responding to customer requests" actually makes definitions more ambiguous. Phrases like "we'll adjust according to your requests" or "we'll respond within our capabilities" may seem customer-oriented but actually make responsibility unclear.

Gaps in technical expertise also have an impact. When clients don't understand technical details, contractors sometimes skip important confirmations, judging that "explaining this won't help them understand." Conversely, contractors sometimes define deliverables for their own convenience without understanding the client's business processes.

Formal descriptions in contracts and specifications also contribute to the problem. Using vague expressions like "◯◯ package" or "standard quality" to avoid legal risks actually creates practical confusion. The importance of documenting specific definitions hasn't become established as a contractual practice.

This section shows specific procedures and checkpoints for creating deliverable definitions that can be used in actual projects.

Deliverable definitions should be organized along four axes: "items," "format," "quality," and "deadline." Start by identifying "items." For design projects, specifically list what you'll deliver: "top page design mockup," "three sub-page templates," "logo data," "complete icon assets," "color palette definition document." Avoid vague expressions like "package" or "etc."

"Format" clarifies how each item will be provided. For example, for "top page design mockup": "Adobe XD file (editable) + PNG exports (1200px, 768px, 375px width) + PDF (for presentation)." Include not just file formats but resolution, size, and naming conventions.

"Quality" definition is the most important yet often overlooked element. Clarify whether it's "pixel-precise specification needed for implementation" or "rough quality for image confirmation." For web design, set quality standards like "no layout breaks at each device width," "font and color specifications documented in implementable form," "image assets with commercial-use licensing processed."

"Deadline" includes not just simple delivery dates but revision response periods. Make mutual workloads predictable with terms like "revision requests within 3 business days of initial delivery will be addressed within 2 business days" and "up to 3 revisions anticipated, beyond that requires separate consultation."

As a practical deliverable definition document format, the following table format is useful:

【Deliverable Definition Document】
Item Name: Top Page Design Mockup
Format: Adobe XD (source file), PNG (1200px/768px/375px width)
Quality: Detailed specifications for implementation, font/color specifications documented
Deadline: 2024/X/X 17:00
Notes: Includes hamburger menu open/closed states for smartphone display

In this definition creation process, it's efficient for the contractor to create a draft and review it together with the client. Use the contractor's expertise to identify necessary items, then adjust by checking against the client's business requirements.

Particularly important is clearly stating "what's not included." Specify exclusions like "The following are not included in this project: coding work, CMS setup, domain/server configuration, photography, writing services" to prevent later "I thought this was included."

Creating industry-specific templates is also effective. Prepare "standard deliverable lists" for business fields like web design, graphic design, system development, and video production. For new projects, use these templates as a base for individual adjustments to improve efficiency.

Linking with quotations is important. Clearly show the work hours and costs corresponding to each deliverable item, making the relationship "this work creates this deliverable" clear. This makes it easier to calculate impact scope and additional costs when specifications change mid-project.

This section explains methods for forming agreements on defined deliverables that satisfy both clients and contractors, and properly documenting them.

The first step in agreement formation is identifying stakeholders. On the client side, identify not just the contact person but also departments that will actually use the deliverables, managers with approval authority, and budget controllers. On the contractor side, clarify actual work staff, quality checkers, and schedule managers. Without confirming "who gives final approval" at this stage, situations arise near completion where "supervisor confirmation is needed."

Hold agreement formation meetings (including online) rather than email exchanges. Text-only communication doesn't reveal nuance differences or understanding gaps. In actual meetings, share the deliverable definition document on screen while confirming "what does this mean" and "how will this actually be used" for each item.

During this process, contractors should carefully explain technical terms. Confirm whether clients accurately understand words like "responsive design," "wireframe," and "revision." Conversely, clients should explain their business workflows and constraints to contractors, such as "internal approval processes require one week" or "brand guideline-compliant colors are essential."

For documenting agreed content, use "confirmation document" format rather than meeting minutes format. Instead of recording facts like "the following was agreed upon in the X/X meeting," use present-tense documents stating "deliverables are defined as follows, with mutual agreement." This reduces room for interpretation when reviewing later.

Documents must include "change processes." Cases requiring deliverable definition changes as projects progress are common. Define procedures like "changes are proposed in writing (email acceptable) and implemented when mutually agreed" and "when changes generate additional work, estimates are provided and approval obtained in advance."

Using electronic signature tools ensures reliable agreement records. Beyond just signing PDFs, IP addresses and timestamps at signing are recorded, preventing later claims of "we never agreed to that."

Particularly important is setting "confirmation deadlines." Specify within how many days confirmation and approval must be obtained after sending the deliverable definition document, with a rule that no response within the deadline means agreement. This prevents schedule impact from client confirmation delays.

Store agreed content where all project stakeholders can access it. Clearly specify where the latest version is located (Google Drive, Dropbox, internal systems) and share with all stakeholders. Also document contact points for inquiries when questions arise while proceeding with work based on agreed content.

Internal client agreement is also an important element. Even when contact persons agree, objections may come from actual user departments or higher-level managers. To prevent this, have the client go through internal confirmation and approval processes before final agreement. Set a stage requesting "please provide final agreement after confirming with internal stakeholders."

This section specifically lists deliverable definition pitfalls that even experienced practitioners overlook, and shows countermeasures.

The most frequent issue is undefined "data rights relationships." Whether usage rights for materials used in design (photos, illustrations, fonts) are included in deliverables, or only usable under the contractor's license, becomes ambiguous. Fonts are particularly prone to blind spots, with cases where clients attempt independent use of fonts used under designers' Adobe Creative Cloud licenses, resulting in license violations. As a countermeasure, include a "materials usage list" in deliverables, documenting rights relationships and usage conditions for each material.

"Rights to modify and alter" are also often overlooked. Whether clients can independently modify delivered design data, and how to handle attribution when modified, remain undefined. When PSD files are delivered for web design, conflicts arise over whether clients can change layer structures and whether original designer names should remain.

"Post-delivery support period" definition deficiencies are also serious. How long and to what extent to respond to inquiries like "can't open data" or "don't understand how to use" isn't clear. Especially when delivering complex systems or templates, whether instruction manual creation or initial setup support is included greatly affects workload. As countermeasures, set specific conditions like "30 days post-delivery, weekdays 10-18:00, respond to usage method questions via email/phone."

"Environment-dependent operation guarantee" scope also becomes ambiguous easily. For websites, which browsers to confirm operation for, or for apps, which OS versions to support, when undefined leads to problems discovered later like "doesn't work on iOS 15" or "layout breaks in Internet Explorer." Specify realistic support ranges like "Chrome/Safari/Firefox latest versions, iOS 14 and later, Android 10 and later."

"Completion criteria" are also important pitfalls. When "design completion" meaning is ambiguous, contractors think "completion when design mockups are done" while clients think "completion when actually usable without problems." Set objective criteria like "considered complete when no major revision requests within 48 hours of client confirmation."

"Data backup and storage responsibility" is also easily overlooked. Who stores original data until when after delivery, and who's responsible if lost, when unclear leads to inability to respond to requests like "please provide project data from a year ago." Agreements like "contractor stores original data for 6 months post-delivery, client responsibility thereafter" are necessary.

"Third-party subcontracting and repurposing permissions" are also important. Whether clients can give delivered designs to other production companies for coding, or incorporate system parts into other company systems requires definition. Especially in creative work, restrictions may be desired from work integrity and quality control perspectives.

Technical "compatibility guarantee periods" also need definition. While operating with latest technology at delivery time, risks exist of non-operation due to OS updates, browser specification changes, or related service terminations. Define how long and to what extent compatibility is guaranteed, like "1 year post-delivery, free support for changes affecting operation in major environments."

To prevent these pitfalls, create and habitually use a "deliverable definition checklist" for every confirmation. Include business field-specific items in checklists, accumulating points learned from past trouble cases.

This section presents specific action guidelines readers can actually use starting tomorrow, and continuous improvement methods.

First, readers with ongoing projects should immediately propose implementing "deliverable confirmation meetings." Secure about 30 minutes with clients (or contractors) under the reason "to improve project quality, let us confirm deliverable details." In this meeting, document current understanding and perform mutual confirmation.

For new projects, include deliverable definitions from the quotation stage. Develop the habit of attaching detailed definition documents to quotations as "see attached for deliverable details." This clarifies price-deliverable correspondence and prevents later "unexpected" situations.

From the contractor perspective, create "deliverable definition templates" for your business field. Review past projects' actual deliverables, organizing them along the four axes of item, format, quality, and deadline. Present this template in initial meetings for new projects, using it as explanation foundation by saying "we normally deliver the following content."

From the client perspective, create "requirements organization sheets." Organize in advance how deliverables will be used in-house, which departments are involved, and what formats are needed. When receiving deliverable proposals from contractors, check against this sheet for gaps.

Reviewing contract and order form templates is also important action. Add clauses to currently used formats "requiring deliverable definition document attachment." Also include change management rules like "deliverable changes require written agreement, with advance estimates when work changes occur."

Accumulating and sharing trouble cases leads to continuous improvement. Within companies or industry communities, collect cases of "recognition differences like this occurred" or "this definition deficiency caused trouble," reflecting them in definition templates and checklists. Holding monthly team trouble case sharing meetings is also effective.

Understanding industry standards is essential. Collect information on "typical deliverable lists" in your specialty field from industry organization materials, competitor cases, and client-side information. However, don't settle for "because it's industry standard" – always adjust to individual project requirements.

Establish regular review cycles. About quarterly, review the past three months' projects, verifying whether deliverable definitions were problem-free and identifying improvement points. Particularly analyze "work that took longer than expected" and "items additionally requested by clients," reflecting them in future definitions.

Client education is also an important element. Prepare materials explaining "why detailed definitions are necessary" according to client understanding levels. Use past trouble cases (anonymized) to show that clear definitions benefit both parties.

Finally, utilize deliverable definition creation efficiency tools. Create easily reusable templates in Google Docs, Notion, Confluence, etc., allowing easy item addition and deletion. Also enable searching similar patterns from past definition documents through tagging and categorization.

Continuing these actions will definitely reduce deliverable definition troubles and improve overall project quality and efficiency. The important thing isn't aiming for perfection but gradually improving from the current situation.