Successful completion – OPEN

Add your own custom notes.

You need to login before you can record your own custom course notes.

Registration is easy, and completely free.

Topic 12.1: Successful completion

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,706 people have passed the quiz

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.

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 organisation, specific acceptance criteria will be included in the contract terms.

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

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

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 organisation – especially those that involve different organisational groups – will suffer the same consequences if there is not a memorandum of agreement among the groups that specifically 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 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 handover you should ensure that all the new stakeholders are aware of who the key contacts and players are.

Not only is it good project management practice, 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.

Cookies. They're how the internet works.