Verifying deliverables

Determining when a project is complete is not always easy.

Most project team members would say that a project is finished when all the work is done; however, the measure of completion is when the client accepts the deliverables that were agreed to before the project began.

Rather than being surprised, though, how can we anticipate a client’s acceptance of the deliverables?

The project plan is built on the work breakdown structure, which is a detailed articulation of the project scope. 

Verifying deliverables, therefore, requires a careful review of the WBS to ensure that all tasks have been completed to what you either know or assume is the client’s satisfaction. 

If any task is left unfinished, then the project is not complete.

This verification is usually achieved by conducting a technical audit of the project’s outputs, asking does this deliver on the original promise we made – see the project charter if you are unsure.

Once outputs are verified to what you expect is the client’s satisfaction, you need to obtain your sponsor’s or steering committee’s approval to formally hand them over to the client.

---

Handover

Every task in a good WBS has its own acceptance criteria, but these criteria are written with a specific purpose: to ensure that each task is ready to be delivered to the next step in the delivery plan. 

In other words, they are internally derived, usually without reference to the client.

For that reason, it is a mistake to assume a project is complete just because all WBS tasks have been performed. 

Even in the absence of acceptance criteria, a project is not completed until the client accepts the deliverables and responsibility for the outputs of the project.

In a formal contract with a customer outside the organization, specific acceptance criteria will be included in the contract terms. 

However, even these criteria are rarely a complete statement of the client’s expectations.

A crucial mistake made by inexperienced project managers is not requesting a written agreement of acceptance criteria up-front. 

After all, if these criteria do not exist, the client can forever claim that the deliverable is not exactly what was requested, and the project continues.

Likewise, projects internal to an organization – especially those that involve different organizational groups – will suffer the same consequences if there is not a memorandum of agreement among the groups that explicitly details the acceptance criteria.

Regardless of whether or not project- (as opposed to task-) level customer acceptance criteria are in place, in handing over, you should then walk the client through the deliverable(s), stating why you think the project ouput is fit for purpose. 

At this time, you should also clarify any uncertainty and disclose any risks.

Only then can formal sign-off and delivery be achieved.

In construction contracts, you might also have a defects liability period. 

As with a standard warranty, it typically allows 12 to 24 months from the date of practical completion for the contractor to return to the project and remedy any defects.

Often, a project will also have an option for continuing maintenance and servicing; usually, in these instances, a different corporate group is responsible for this function. 

As part of the handover, you should ensure that all the new stakeholders know who the key contacts and players are. 

Not only is it a good project management practice, but it is also good business!

But wait – your work is not yet done! 

Project completion is not the same as project close. 

Verifying and handing over the deliverables is merely the first step in the process of closing a project.