“In every project, the executive sponsor, project sponsor,
or designee documented in the project charter should officially approve and
accept deliverables, change requests or milestones that have been performed
along the way. Acceptance along the way helps to mitigate risks by closing
tasks that can be affected by a risk. By providing the business organization
opportunities to review work performed, any mis-communications can be caught
early and managed. The project manager should meet with the project sponsor and
executive sponsor to review the completed work. The executive sponsor should
then approve the work, confirming that it was completed as agreed upon in the
project charter. There are several different times when a formal acceptance and
approval should be sought and obtained:
When a deliverable is completed
When a change request or a group of change
requests is completed
At the end of every phase or milestone
At project completion”
Project Acceptance Procedure
“Most technical methodologies define a formal acceptance
procedure. Unfortunately, that process is often ignored and default acceptance
of the 'no news is good news' criteria is used, creating conflict,
misunderstanding, and mis-communication between the business group(s) and the
technical group. Make sure acceptance is a deliberate, formal process, to avoid
the inevitable finger-pointing blame game that will ensue by ignoring it.”
“The following process can be used if your organization does
not have a formal acceptance process:
on the project charter and project plan, the project manager should create
a Deliverables Acceptance Log, listing each deliverable and milestone that
requires the project sponsor’s or executive sponsor’s approval upon
completion. This log should be part of the project charter and the
acceptance process should be described during a formal project charter
change requests are submitted, they should be added to the Deliverables
Acceptance Log in chronological order between the predefined deliverables
project manager should complete a deliverables acceptance form for each
deliverable, each milestone, and each change request. The form should
describe in detail the deliverable, milestone, or change request and
should provide space for the project manager and the project sponsor or
executive sponsor to sign off. Any supporting documentation should be
attached, such as testing forms, screen prints, e-mails, or reports.
more than one change request is completed within a given period of time,
they can be grouped on one form if it makes sense to do so.
forms can be completed either at the time each deliverable, milestone, or
change request is added to the Deliverables Acceptance Log or at the point
in time when signoff is required.
the close of the project, a project completion (or final) acceptance form
should be completed, indicating that all expectations were met and
accepted per the project charter (as amended by authorized change
Deliverables Acceptance Log and all completed deliverables acceptance
forms should be kept in the project notebook in the section labeled
work is completed for a deliverable, milestone, or change request, the
project manager should meet with the project sponsor and executive sponsor
to review the performed work. This review session (walkthrough with all
necessary parties) can be incorporated into the planned status meetings or
it can be a specific acceptance meeting. If the work is satisfactory, the
project manager and the project sponsor or executive sponsor should
approve and accept the work.
deliverables should be approved by the project manager and the project
sponsor or executive sponsor.
that have been submitted for approval should be tracked on the
Deliverables Acceptance Log, which is maintained in the project notebook.
deliverables acceptance form should be signed and returned to the project
manager as specified in the project charter. The form should be marked
accepted or rejected. Acceptance means that the deliverable fully meets
expectations. Acceptance or rejection of deliverables by default or by
conditional approval is not allowed.
that are not accepted within the time period specified in the project
charter should be added to the project status report and the project
issues log until they are resolved. Any outstanding deliverables should be
reviewed at weekly status meetings. Late acceptances can result in a
noncompliance change request.
deliverable is rejected, a detailed description of why it was rejected
should be included in the form. If required, a meeting can be held to
discuss the deliverable in detail. All errors and omissions should be
detailed in the rejection.
resubmittal should be permitted to allow the deliverable to be modified
and to address the items that were specifically rejected. If additional
resubmittals are required, the change procedure should be invoked.
between the business organization and the technical organization
management should begin if disagreement arises as to the action to be
taken or the extent of corrections needed to satisfy the executive sponsor
with regard to a rejecteed deliverable. All attempts should be made to
resolve the issue at the lowest management level possible. When necessary,
escalation to the next higher management level should take place.”