Acceptance Management

“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:

1. Based 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 presentation.
2. As change requests are submitted, they should be added to the Deliverables Acceptance Log in chronological order between the predefined deliverables and milestones.
3. The 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.
4. If 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.
5. These 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.
6. At 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 requests).
7. The Deliverables Acceptance Log and all completed deliverables acceptance forms should be kept in the project notebook in the section labeled ‘Acceptance’.
8. When 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.
9. All deliverables should be approved by the project manager and the project sponsor or executive sponsor.
10. Deliverables that have been submitted for approval should be tracked on the Deliverables Acceptance Log, which is maintained in the project notebook.
11. The 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.
12. Deliverables 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.
13. If a 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.
14. One 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.
15. Negotiations 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.”