Everything You Need to Know about Project and Process Deliverables

By Marcelo Barbosa

Difference between Deliverables and Delivery
Understand the Process or Project
Applying the 4W1H Method
Comprehending Deliverables: From Essentials to Intricacies
Deliverable Requisites
Writing a deliverable title
How to Distinguish Tasks and Routines from Deliverables
Projects vs Processes Deliverables
Service and Product Deliverables
Internal vs Interdependent Deliverables
Can a Deliverable Be a Part of Something Bigger?
Conclusion

Whether in project management or ongoing operational processes, the clear definition and effective management of deliverables are indispensable. Deliverables are tangible goods or services produced as a result of a project or process.

The key difference between goals and deliverables is that goals are about the "what" to achieve. They are strategic, broad, and long-term. Deliverables, on the other hand, are about the "how" – they represent the concrete steps or outputs that lead to the achievement of the goals.

Deliverables are more tactical and are usually short-term or medium-term in nature. They are specific, concrete items or outcomes that can be checked off a list once they've been completed. Deliverables serve as proof that the work is being done and are the measurable components or milestones that indicate progress toward the goals.

To avoid misalignment, each deliverable should be carefully linked to a broader project, goal, or objective, leading to cohesion with the strategic vision. Additionally, it's vital to maintain a balance between output and quality. Regular quality checks and evaluations must be implemented to ensure that the quality of work isn't compromised.

In summary, identifying quantifiable deliverables is about defining the tangible outputs or products that result from the work being done. The capability to precisely identify and define these deliverables can significantly enhance the planning and execution phases, leading to higher efficiency and better results. However, defining the deliverables of a project or process can often be a challenging task.

This guide seeks to alleviate this challenge by presenting a systematic approach to identifying and defining deliverables in both project and process contexts. It contains a systematic approach based on the 4W1H method (What, How Much/Many, When, Who, Whom). By asking and answering these five key questions, a team can systematically define and describe its deliverables. Each stage of the 4W1H method facilitates an open dialogue within the team, providing everyone with a chance to share their insights, opinions, and ideas.

The 4W1Q method is designed to aid in the identification and management of deliverables, promoting improved efficiency and success in the achievement of objectives. It is intended to support teams handling projects as well as continuous processes. Let's embark on this journey towards more effective management of deliverables.

DIFFERENCE BETWEEN DELIVERABLES AND DELIVERY

Let's start with the basics and put everyone on the same page. Deliverables and delivery are both common concepts in project management, but they carry different meanings:

Deliverables: These refer to the tangible products or services produced as a result of a project or a process that are intended to be delivered to a customer (internal or external). A deliverable could be a report, a document, a software product, a server upgrade or any other building block of an overall project.

Delivery: This refers to the act of turning over the deliverable to the client or stakeholder. It involves ensuring that the agreed-upon deliverables are handed over to the client in the expected condition and at the agreed time.

For example, in a software development company, the deliverable might be the new app developed for a client, whereas the delivery is the process of providing to them, perhaps including installation, integration into their systems, or training their staff on how to use it.

In the context of this article, it will be referring primarily to the "deliverables," the outcomes of the work, which are the basis of what will eventually be delivered. The distinction can be subtle, as the act of delivery often immediately follows the production of the deliverable, but it is an important one.

So, when we're talking about identifying WHAT the outcome is, HOW MUCH will be produced, WHEN it will be ready, WHO requested it, and to WHOM it will be delivered, we're primarily talking about the deliverable itself – the product or service resulting of the work.

UNDERSTAND THE PROCESS OR PROJECT

Before diving into the identification of deliverables, it's essential to thoroughly understand the process or project at hand. This initial step provides a crucial foundation for effective deliverable management.

Begin by having the team articulate a comprehensive overview of the process or project they're engaged with. Encourage them to elaborate on its purpose, overall objectives it aims to achieve, and structure. If it is a project, identify the milestones and the final deliverable. If it is a process, have an overview of its workflow, recurring frequency, and how it is triggered.

In this stage, it's necessary to differentiate between tasks and potential deliverables. While tasks are actions undertaken to achieve an outcome, deliverables are the outcomes themselves. A task might be 'conduct market research,' while the deliverable is the 'market research report.' Highlight this distinction to the team, ensuring they can differentiate between actions and results.

Often, team members may be engaged in tasks that are key for the functioning of the process or project but do not directly result in a deliverable. It is important to differentiate between these routine tasks and tasks that lead directly to a deliverable. For example, in a software development project, daily team meetings might be a routine task. While these meetings are relevant for communication and coordination, they do not produce a deliverable in and of themselves. On the other hand, coding a new feature for the software is a task that directly contributes to a deliverable - the new software feature.

After you have a clear understanding of the tasks and steps involved in the process or project, you should be able to identify the end result or outcome. This is the deliverable. Keep in mind that a process or project might have more than one deliverable, especially for more complex ones.

Understanding processes and projects is the foundation for the deliverable identification and description. It provides the context and the big picture view, which will guide the team in defining the deliverables, setting goals, and tracking progress.

APPLYING THE 4W1H METHOD

The 4W1H is a method based on asking the right questions in a structured format to guide teams in defining and describing their deliverables.

The order in which the 4W1H is applied can impact the flow and efficiency of the discussion, but it's not strictly necessary to follow a specific sequence. However, it might be helpful to start with "What" because it frames the rest of the discussion. After all, knowing what the deliverable is, is fundamental before you can discuss when it's due, who requested it, to whom it will be delivered, and how many/much of it is needed.

In practice, the discussion might not follow this exact order, and that's okay. The goal is to ensure all these elements are defined by the end of the discussion. The sequence can be adjusted based on the needs of the team and the nature of the project or process.

The key to this method's success is consistency and communication. Encourage the team to use the 4W1H Method for every project or process. This way, over time, they will internalize the method and become more effective at identifying and registering the deliverables.

Remember to document all the responses for later review and as a future reference. The method can also be tweaked or expanded upon based on the team's experiences and the nature of the work.

By systematically answering the 4W1H questions, it is possible effectively define and describe the deliverables of projects or processes. Remember, each deliverable should have clear answers to all five questions, providing a complete picture of what the deliverable is, how many will be produced, when it will be ready, who requested it, and to whom it will be delivered.

WHAT - Define the Deliverable

This question lays the foundation. Knowing what the deliverable is, is the most basic and indispensable information needed. This stage focuses on understanding the nature of the deliverable. The answer should clearly define the deliverables of the project or process.

Ask the team:

What are the tangible deliverables that result from the process or project? What is being created? This could be a physical product, a report, a data set, etc. If the process or project is complex, it could have multiple deliverables.

Can you describe the key components/features of the deliverable?

How does this deliverable add value to the recipient?

What are the expectations associated with this deliverable?

WHO - Identify the Requester

Every deliverable has a requester - the person, team or organization who asked for it. This could be an internal stakeholder, such as a manager or a department within the organization, or an external client. Understanding who requested the deliverable can provide context for its importance, priority, and potential specifications.

Who has requested this deliverable?

What are their main expectations and acceptance criteria?

How often and through what means should we communicate with them about progress?

WHOM - Identify the Recipient

Knowing to whom it will be delivered can help in tailoring the deliverable to the recipient's needs. In many cases, this will be the same as the requester, but not always. The deliverable could be for a customer, an internal department, an organization, a target group, or any other entity. This stage identifies the recipient(s).

Who will receive the deliverable? Make sure to identify who will actually use or benefit from the deliverable.

Is the recipient the same as the requester? If not, how do their expectations differ?

How should the deliverable be presented to them for the best impact?

HOW MUCH/MANY - Quantify the Deliverable

Once you know what you're delivering and to whom, it's logical to determine the quantity needed. This stage is about quantifying the deliverable. What is the amount of the deliverable that will be produced? The answer could be in terms of the number of units or percentual of a metric.

How many of the deliverable is expected?

Is the quantity of the deliverable fixed, or can vary?

What are the metrics that we can use to measure the quantity of the deliverable?

If the quantity can change, under what circumstances would that happen?

WHEN - Schedule the Delivery

Time is a critical factor in any project or process. Therefore, it's fundamental to define when the deliverable will be ready. This should be a specific date rather than a vague or indefinite period. If it's a repeated process, you should define when each iteration or bulk of the deliverable will be available.

When will the deliverable be ready for the recipient?

If it's a repeated process, when will each iteration or bulk of deliverables be available?

What are the potential factors that could delay the delivery?

What are the consequences if the deadline cannot be met?

Once defined that the deadline cannot be met, what should be the action?

By defining deliverables and specifying their requisites through the 4W1H method, you create a clear benchmark for success and a way to measure progress over time. It also makes it easier to communicate progress to stakeholders, as they can see tangible evidence of what has been developed and achieved.

In the lifecycle of a project or a process, regular review and refinement of its deliverables is key to ensuring its ongoing success. This not only allows for adjustments in line with performance and resource changes, but also accommodates any strategic shifts in priorities or goals.

The purpose of creating quantifiable deliverables is not just to track progress, but also to motivate the team, align efforts, and ensure everyone is working towards the same objectives. By keeping deliverables clear, measurable, and visible to all, you can increase productivity, enhance teamwork, and improve project or process outcomes.

COMPREHENDING DELIVERABLES: FROM ESSENTIALS TO INTRICATES

In this section, we will explore the essentials and intricacies related to deliverables. We start with the basics: what they are and how to write a good title for them. We'll then go a step further to learn how to tell them apart from everyday tasks and routines. We'll discuss the role of deliverables in both projects and processes. Then, we'll look at different types of deliverables - those that come from services and products. Finally, we'll consider if a deliverable can be part of something bigger. By the end of this section, you'll have a deeper understanding of deliverables.

Deliverable Requisites

Identifying what qualifies as a deliverable can sometimes be a challenging task, especially in complex projects or processes. Here are a few guidelines to help you distinguish deliverables from other elements of your project or process:

Tangible Outcome: A deliverable is a tangible outcome. If the outcome is not evident and cannot be observed or measured in some way, it might not be a deliverable. For example, "conducting a meeting" is a task, not a deliverable, whereas a "deal" resulting from that meeting could be a deliverable.

Value to the Requester and/or Recipient: A deliverable must provide value to the requester and/or recipient. It must contribute to the overall goal or objectives of the project or process. If something doesn't add value or move the project or process forward, it likely isn't a deliverable.

Measurable and Quantifiable: A deliverable should be measurable and quantifiable in some way. It should be possible to determine whether or not the deliverable has been completed successfully. If you can't measure or quantify it, it might not be a deliverable.

Specific and Defined: Deliverables should be clearly defined and specific. They should leave no room for ambiguity. If it's vague or undefined, it's likely not a deliverable.

Requested or Required: A deliverable is often something that has been specifically requested or is required to meet the project or process objectives. If it's not required or requested, it might not be a deliverable.

If something doesn't qualify as a deliverable, it might be a task, a step in the process, a responsibility, or even an objective. Tasks are activities required to produce the deliverable. Responsibilities are the roles or duties of team members. Objectives are the broader outcomes that the project or process aims to achieve, and they are typically achieved through the successful delivery of the defined deliverables.

Writing a deliverable title

Writing a deliverable title effectively is essential for clarity and understanding among team members and stakeholders. When writing deliverable titles, the following tips can be helpful:

Be Specific and Clear: The title should accurately represent what the deliverable is. Try to avoid using technical jargon and ensure the language is easily understandable.

Keep It Concise: Lengthy titles can be challenging to comprehend and remember. Try to write the titles succinctly without losing the meaning of the deliverable.

Take the Details to the Description: Details and explanations should be included in the "deliverable description" field. Stay aware, and don't insert them in the title.

Use Past Participle: This means the focus is on the outcome of an action rather than the action itself.

Deliverable Title Formula

Following the "Direct Object + Past Participle" formula, the deliverable titles might look like these:

Marketing Plan Developed.

Client Research Conducted.

Software Prototype Created.

Project Report Available.

Website Layout Designed.

This title format emphasizes the final product or service, providing a clear view of what will be achieved upon completion. Just ensure to maintain consistency throughout your project or process to prevent confusion.

How to Distinguish Tasks and Routines from Deliverables

Distinguishing tasks and routines from deliverables is crucial to understanding what actually constitutes an outcome that the requester and/or recipient values. While tasks and routines are the components of work that lead to the outcome, the deliverable is the product or service the recipient receives.

Here are some questions and tips to help the team differentiate tasks and routines from deliverables:

Define the Value Proposition:

Ask: What is the value that the recipient is receiving?

Tip: "Value" refers to the importance, usefulness or merit of a product or service in meeting the needs and expectations of the requester and/or recipient.

Understand the Workflow:

Ask: What are the steps to create this value?

Tip: List down the main actions, tasks, and routines involved in the project. This can include meetings, gathering information, documenting etc. These represent the process or work, not the deliverable.

Differentiate Between Process and Product:

Ask: Which of these steps results in a tangible or measurable product or service that the recipient cares about?

Tip: From your workflow, identify which actions actually produce a deliverable. The rest is tasks and routines that contribute to that deliverable.

Align with Requester Expectations:

Ask: What are the requester's expectations? What have they explicitly asked for?

Tip: The answer will help identify the deliverables, as the requester usually demands products or services.

Use the 4W1Q Method:

Ask: Can we apply the 4W1Q Method (What, How Much, When, Who, Whom)?

Tip: If the answer is yes, it is likely a deliverable. If not, it's probably a task or routine.

Remember, tasks and routines are the necessary activities that lead to a deliverable, but they aren't the deliverable itself. The deliverable is the product or service that the requester and recipient value and expect as an outcome of the work.

Consistent application of these questions will help the team distinguish tasks and routines from deliverables, making it easier to fulfill expectations and ultimately ensuring the requester and recipient's satisfaction.

Projects vs Processes Deliverables

While both projects and processes produce deliverables, the nature of these deliverables and how they're managed can vary significantly due to their distinct characteristics.

Projects

Projects are temporary and unique initiatives undertaken to achieve specific objectives within a defined time frame. Their deliverables are often tangible outcomes such as a constructed building, a new software, or a completed report. Given the temporary and unique nature of projects, their deliverables are also often unique, non-repeatable products or services.

Identifying deliverables in a project involves specifying which tangible items or outcomes will be produced by the project. These are outlined in the project scope and aligned with its objective. The timeline, quantity, and specifications of these deliverables are usually set based on the project plan, in the waterfall methodologies, or in the roadmap and sprint plans, in the agile methodologies. Additionally, they are tracked and managed until the project's completion.

Processes

On the other hand, processes are ongoing, repetitive operations that happen consistently within an organization. Processes are often aimed at maintaining or improving day-to-day operations. The deliverables in a process are the outputs of the recurring tasks or routines, such as processed orders in a procurement sector, resolved users’ complaints in a customer service department, or completed payroll in a human resources department.

Identifying deliverables in a process involves understanding the output at each stage of the process and what the end product or service is. Unlike projects, where deliverables are unique and defined upfront, deliverables in a process are recurring and may need to be reviewed and updated regularly to align with operational changes or improvements. Finally, the number of deliverables can be stipulated in bulk over a period instead of one by one.

In Summary

While the principles of defining and managing deliverables apply to projects and processes, the key difference lies in the nature of the deliverables. Project deliverables are unique, non-repeatable outcomes aligned with a specific project goal, while process deliverables are recurring outputs of routine operations. Understanding this distinction is important to effectively identifying and managing deliverables in either context.

Service and Product Deliverables

In this section, we will explore Service Deliverables and Product Deliverables. Each type has its peculiarities and can manifest in various ways, depending on the context and nature of the work. Whether we're talking about consulting, IT, marketing, healthcare, logistics, or product development, understanding what deliverables are and how they apply to each case is fundamental for the success of any project or process. Let's then deepen our understanding of these two types of deliverables.

Service Deliverables

Service deliverables are the tangible outcomes that result from providing a service. They can take various forms depending on the nature of the service. Here are a few examples:

Consulting Services: The deliverables from consulting services could include a detailed report outlining the consultant's findings and recommendations, a strategic plan, process documentation, or training materials.

IT Support Services: Service deliverables may include resolved support tickets, a system setup or installation, software updates, or a system performance report.

Marketing Agency Services: The deliverables might include a marketing strategy, content creation (blog posts, social media posts), SEO configuration, analytics reports, or a branding guide.

Financial Advisory Services: The deliverables could be a personal financial plan, tax filing, or a financial health assessment report.

Healthcare Services: In a healthcare setting, service deliverables could be a medical examination, a diagnostic report, a medical procedure, a treatment plan, or preventative care guidance.

Training Services: For training services, the deliverables might be a course, training materials (manuals, online content, videos), or certification upon course completion.

Logistics Services: Deliverables in this context could be the timely delivery of goods, a shipment tracking report, or inventory management reports.

The specifics of service deliverables can vary greatly depending on the service's specifics, and they often require setting clear expectations and open communication with the requester to ensure the deliverables meet their needs and expectations.

Product Deliverables

Product deliverables are tangible outcomes resulting from a project or process. Here are some examples of product deliverables:

Construction Projects: In construction projects, the deliverables could be the finished building, infrastructure, or any other physical structure that the project was aimed at constructing.

Software Development: In this case, the deliverable might be a mobile app, a web application, a system, or a software update.

Manufacturing Processes: For a manufacturing process, the deliverables would be the finished goods or products that are produced, such as cars, electronics, furniture, or clothing.

Research Projects: A deliverable in a research project might be a final report or research paper detailing the project's findings, or it could also be a database, a model, or a prototype developed during the project.

Design Projects: For a design project, deliverables might include graphic designs, prototypes, finished artwork, branding materials, or website designs.

Engineering Projects: Deliverables from engineering projects could be prototypes, finished devices or machinery, test results, or technical drawings and specifications.

Product Development: In a product development project, the deliverables could include the final product, product designs, prototypes, or product testing results.

Each o f these deliverables is created as a result of the project or process. Identifying and d efining these deliverables upfront is vital for better planning and execution of the project or process.

Internal vs Interdependent Deliverables

The deliverables can indeed be classified into two broad categories based on their dependency:

Internal Deliverables

These are outputs produced solely by a single team, with no dependency on any other team or external entity. The completion and quality of these deliverables lie entirely within the team's control.

Despite being produced by a single team independently, they still contribute to a larger organizational goal. Therefore, while their production might be independent, they are usually not isolated in terms of their purpose or impact.

The main advantage of internal deliverables is that they can usually be planned and managed more predictably because they don't involve coordination with other teams. This means that deadlines can be set and managed within the team itself. However, because the team has full responsibility for these deliverables, they also bear all the pressure and challenges related to producing them on time and to the necessary quality standards.

Interdependent Deliverables

These are outputs that require collaboration or coordination with other teams or external entities. The completion of these deliverables is dependent not just on one team's work, but also on the work of others.

Managing interdependent deliverables can be more complex, as it requires efficient communication and coordination among different teams. This may require regular meetings or updates, the use of collaboration tools, and sometimes negotiation to address problems or delays.

Deadlines for these types of deliverables must take into account the schedules and dependencies of all teams involved. This might mean that deadlines are harder to predict and manage due to potential delays from other teams. Therefore, interdependent deliverables require more robust management processes and effective collaboration mechanisms.

Can a Deliverable Be a Part of Something Bigger?

Absolutely, a deliverable can be part of something larger. In project management, it's common to break down a large project into smaller, manageable parts or phases, each with its own set of deliverables. These are often referred to as "milestones" within the larger project.

For example, consider a project to build a new so ftware system. This could be broken down into several deliverables:

Requirements specification document;

Design and architecture blueprint;

Prototype of the system;

A beta version of the system for testing;

Final, fully-functional software system;

User manual and training materials.

Each of these is a deliverable within the larger project. They each offer value and represent a significant step towards the completion of the project.

When a deliverable is part of a larger project, it's important to consider how it fits into the broader project timeline, how it contributes to the project goals, and how changes to it might impact other parts of the project.

The 4W1H Method can be used at both the project level and the individual deliverable level, helping to clarify what each deliverable is, when it's due, who requested it, to whom it will be delivered, and how much of it is needed.

Examples: Breaking Down a Public Policy and a Public Service into Deliverables

Public Policy - Implementing a New Environmental Policy

The larger project is implementing a comprehensive environmental policy aiming at reducing carbon emissions over a decade. It could be broken down into the following deliverables:

Policy Document: Detailed policy guidelines, including goals, strategies, and actions for different sectors.

Stakeholder Engagement Plan: A plan outlining how different stakeholders (businesses, citizens, government departments) will be involved and informed throughout the implementation process.

Emissions Tracking System: A new software system to accurately track carbon emissions from different sources.

Education and Awareness Programs: Launch of various programs to educate and raise awareness among citizens and businesses about reducing carbon emissions.

Regulation and Compliance Framework: Detailed regulations for businesses and enforcement mechanisms.

Yearly Progress Report: A detailed report summarizing progress made each year towards the policy's goals.

Public Service - Setting up a New Public Library

The larger project is setting up a new public library in a community. This project could be broken down into several key deliverables:

Project Plan: A detailed project plan outlining steps to set up the library.

Building: Procure a suitable building or space for the library, and prepare it for use (installing shelves, setting up computers, arranging furniture, etc.).

Book and Resource Collection: Procure a wide variety of books, e-books, audiobooks, magazines, newspapers, and other resources that the library will offer.

Online Catalog System: Set up an online catalogue system for users to search for available resources.

Staff Recruitment and Training: Hire and train staff to operate the library.

Opening Ceremony: Organize a launching ceremony to officially open the library to the public.

Community Engagement Programs: Plan and execute various programs like reading clubs, author visits, and other community events to engage the community.

In both examples, the 4W1H Method can be applied to each deliverable to specify what it is, when it's due, who requested it, to whom it will be delivered, and how much is needed. This helps manage each part of the larger public policy or service effectively.

Conclusion

Effectively managing deliverables, be it in projects or ongoing processes, is a cornerstone of successful operations and performance. Deliverables are the tangible results of the work that stakeholders see and measure, making their identification and management a vital process.

This guide offers a systematic approach to demystifying this process, applying the 4W1H framework to clearly identify and define deliverables. By asking 'What,’ 'How Much/Many,’ 'When,’ 'Who,’ and 'Whom,’ we've learned to determine the specifics of each deliverable.

But remember, project management and process operation are dynamic and ever-changing. Regular review and refinement are crucial to adapt the deliverables to these changes and maintain alignment with objectives. The communication lines with the team should always remain open, with feedback being an invaluable resource for constant improvement.

In essence, the method shared in this guide is not an endpoint. It is a starting point in your journey towards enhanced performance. As you apply it and gain experience, you'll get the confidence to refine and adapt it to unique situations, leading to greater efficiency, better outcomes, and success in your projects or processes.