Contract Deliverables Versus Project Deliverables

Why is it important to distinguish between contract deliverables and project deliverables?

Not clearly distinguishing between contract and project deliverables in your statement of work may lead to higher costs, liabilities and risks. My experience is this can gave major impact on your contract value. Especially, if you’re working in a complex, high-tech or capital good (aircraft, ships, plants, etc.) project-based environment.

I often see companies trying to save time or for other reasons (including simple ignorance) by using or copying the complete requirements document or project statements of work as discussed with the customer as attachment to the proposal or contract.

Now your question will be whether this is so bad? Well, not always if the SOW writers from the start know that it is going to be used as a contractual document.

However, often in many companies the SOW engineer delivering input for proposals and contracts are not trained in proposal writing or contract drafting. So I have seen contracts where delays of providing minutes of meeting (!) was penalized since such minutes of meeting were also defined as ‘deliverables’ by the project manager and therefor subject to delay penalties. It would have been better to call them ‘milestones’.

In this post I want to describe what the difference is between ‘contract variables’ and ‘project variables’ and by doing so prevent contract leakage. It provides actionable steps to remedy the problems that deliverables cause when they aren’t documented, defined, and agreed by both parties (buyer and seller).

What are project deliverables?

Project deliverables are such outputs as the project plans, project reports, and minutes of meeting.

In project management, the work breakdown structure (WBS) describes the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

A WBS element may be a product, data, service, or any combination thereof.

A WBS as such is (should be) not a contractual document. It provides both the necessary framework for detailed cost estimating and control and guidance for schedule development and control.

Creating a high-level WBS ideally precedes writing a proposal or reply to a tender or drafting a contract. This will help in better defining the contract deliverables and agreed to by the project manager who is going to be responsible for execution.

Your project and program managers executing the contract are the “promise keepers”. They need to deliver the products and services (the promises”) that you and your company’s contracted to the customer. So make sure they are also involved in the proposal and contract negotiation phases when the contract deliverables are defined.

What are contract deliverables?

Contract deliverables are the products and end-results of project phases like aircraft, hardware, software, mobile application, service, or test assessment report for which the customer is actually paying.

Contract deliverables are often those deliverables that need to be formally submitted for review and approval before the customer will accept and pay.

For the project scope that will be contracted (or outsourced if that’s the case) using contracts, the contract deliverables need to be aligned with the project WBS. But they are not necessarily the same.

The contract deliverables are a subset of the project deliverables:

• Contract deliverables are items that you will find in the ‘subject matter of sale’ or service description in the main part of the contract (‘articles of agreement’)
• Contract deliverables are end-results that a product or service provider is obligated to provide to a customer and for which the customer will pay.
• For each contract deliverable, the amount to be paid for each deliverable needs to be identified and defined in the contract (or proposal depending on which phase you are).
• If a contract is properly drafted, contract deliverables will be distinguished from the services that produce those deliverables (software development services will result in delivery of specified software; a repair service of aircraft parts will result in parts being repaired and in a ‘serviceable condition’).

For example, when the customer decides on outsourcing the project design scope of work to your engineering people, the contract should specify what are the deliverables for each stage of the design stage and what will be the value or weight of that deliverable.

The contract deliverables can range in size, complexity and cost. But the focus should be on critical deliverables and milestones with money (penalties or incentives) associated with them.

You and your contract managers who draft, negotiate and sign the contracts are the “promise makers.” So make sure the promises are clear, well-defined, realistic, based on input you get from your project and program managers.

The contract deliverables in build projects

Of course, in many other projects, especially in manufacturing projects, most deliverables completion status will be assessed at the end of each project phase on their percentage complete of work in place.

The completed work will also be subject to the site inspection review and approval processes to ensure that it has been delivered in accordance with the contract and specifications.

In most cases, contract deliverables need to be formally reviewed and approved before they can be accepted as being complete. Therefore, there will be a need for a formal process for reviewing and approving those contract deliverables which might be subject to multiple review processes when contract deliverables are not approved from the first submission.

The review and approval of each deliverable might vary depending on the type of the deliverable.

The impact on contract value

So there are two major issues with contract deliverables that may greatly impact your profit margins during the lifecycle of your contract:

1. The contract deliverables and/or acceptance criteria are not correctly defined, specified or agreed with the customer.
2. They are not defined at all.

You will find out the issues that undefined or incorrectly defined contract deliverables requirements and acceptance criteria can cause especially in the contract execution phase:

• deliverables are rejected,
• payments are delayed
• penalties need to be paid (e.g. liquidated damages) pr prices reduced.

I have seen many design and build contracts for complex products and services, unfortunately, lacking clear definitions of, or distinction between tasks, obligations, or deliverables.

The statements of work were prosaic descriptions of procedures and processes in which I could hardly discern the deliverables actually to be delivered or paid for.

When writing a proposal or drafting contracts and asked the engineers writing the statement of work or service specification what they actually were delivering and how acceptance worked, the answer consistently was: what is in the SOW or specification: just read it!

When I insisted it was unclear he standard answer was: yes, because you don’t understand technology; we engineers understand exactly what is meant.

Of course, to be confronted, during contract execution, with lengthy discussions with the customer on the interpretation of the wording and what exactly needed to be delivered, resulting often in failed deliveries, delays, later payments, penalties, and claims.

Project and program managers perform the services and provide the products (obligations and contract deliverables) often not knowing exactly what is required or acceptable nor which quality the customer actually expects

Example of an issue with a contract deliverable

On a helicopter purchase contract and program, an issue arose that quickly turned into a claim.

The contract defined the deliverable as “the first draft of the Component Maintenance Manual.” It was a contract deliverable for which the customer, subject to acceptance, was going to pay.

The service provider delivered it on time – but it was rejected by the buyer. The customer expected the first draft with all components, including the maintenance policies of the components.

The service provider had interpreted it that only a table of contents listing all of the components was needed, not all of the content related to each one component.

And finally, the service provider had to pay a €150,000 liquidated damages penalty for missing the deliverable due date.

Defining contract deliverables, obligations, project deliverables, task and activities.

Because you will not find commonly accepted definitions, you and your customer will need to agree on what each term means and what the acceptance criteria will be, whether approval is needed, or notification suffices, or even nothing is required.

Here some suggestions and examples of terms and their definitions to help you.

Deliverable: A tangible product, intangible result, or capability required to be produced or provided from one party for the other during the execution of a contract or project.

A Deliverable can be either a Contract Deliverable or a Project Deliverable. A Contract Deliverable always has a corresponding Project Deliverable. Project Deliverables do not always have corresponding Contract Deliverables since Project Deliverables also may include internal Tasks and Activities.

Contract Deliverable: A Deliverable as agreed between parties:

• that you will find in the ‘subject matter of sale’ or ‘scope’ as a product or service description in the main part of the contract (‘articles of agreement’)
• that is an end-result that a product or service provider is obligated to provide to a customer
• that will be identified with an amount to be paid for
• that often will acquire approval in accordance with pre-agreed acceptance criteria.

Example Contract Deliverable tangible product: see the example above: Component Maintenance Manual

Example Contract Deliverable intangible result: a new capability (for aircraft: increased take-off weight)

Project Deliverable: Any Deliverable in the work breakdown structure (WBS) of the project or programme management plan describing the total scope of work to be carried out by the project team to accomplish the project objectives including required deliverables.

Example Project Deliverable: minutes of meeting of project progress review meeting.

Acceptance Criteria: Set of conditions that must be met by the supplier or service provider before contract deliverables can be accepted by the customer.

Obligations: Something that must be performed, completed, or provided from one party to the other as agreed in the contract. It does not always require approval like a Contract Deliverable sometimes does, only notification of its completion and delivery.

Obligations come below the level of Contract Deliverables, and above the level of Project deliverables and Tasks & Activities.

Example: “Supplier will provide the client with a copy of their 3rd part liability insurance certificates.”

Milestone A significant point or event in the execution of a contract, project, program, or portfolio. Often, there is a payment or penalty associated with a milestone in which case it should also be a Contract Deliverable. In all other cases, Milestones are (or should be) Project Deliverables.

Tasks and Activities Tasks fall below the level of Deliverables and Obligations and are internal .

A clearly defined activity or item that has to be completed in order for the party to meet all of their contractual commitments.

Usually internal, short-term activities that don’t require any notification of completion to the other party. an are tracked internally.

Example: “Supplier will maintain appropriate records and archives of parts lost during transportation.”

Best practice actions to take to prevent deliverable issues

1. Define all contract deliverables and acceptance criteria, obligations; projects deliverables and tasks and activities can be left out of the proposal, contract’s statement of work as much as possible
2. Agree with the stakeholders and the customer on definitions for contract deliverables and other categories
3. Review and agree on the list of contract deliverables and assign stakeholders for each of them.
4. Develop and implement a process (including approvals and acceptance criteria when relevant) for managing contract deliverables, obligations, and contractual tasks and activities.
5. Document the agreed contract deliverable requirements and acceptance criteria for each contract deliverable.
6. Communicate the contract deliverables list and process to all stakeholders.
7. Ensure that everyone understands their role and responsibilities.
8. Use a contract repository for storing all information relevant to the contract. This should include contract documents, contract-related correspondence, approvals, project documents, etc.
9. Meet regularly internally and with the customer to review the contract (contract review meeting) and the project deliverables status (program/project review meeting). Use the meetings to detect any potential problems on meeting the due date, and allow time for corrective actions before it’s too late.

Recommendations

Contracts (contract language) can influence the chances for a project’s success, either positively or negatively.

If scope, requirements, and acceptance criteria are well defined, project members know exactly what is required and thus able to provide what the client is expecting.

When these definitions aren’t included in the contract it opens the door to misunderstandings, disagreements, and potentially costly issues and claims. All of which will impact schedule, cost, customer satisfaction, the relationship, and also the chances for a successful contract outcome.

While these activities require a little time, effort, and expense on your part, it greatly reduces the causes of disagreements, issues, and potentially expensive claims and disputes later.

Make sure you distinguish clearly between contract variables and project variables.

To prevent non-compliance and rejection of contract deliverables make sure you have:

• Clear definitions of terms including contract deliverables, obligations, and tasks;
• An agreed list of all contractual deliverables, obligations, and tasks;
• Specified inspection/acceptance criteria for each deliverable; and
• A process for managing submittal for inspection/acceptance) and the approvals of contract deliverables.