February 2, 2007 – Managing the Thing: Acceptance Management

The third leg in our attempt to manage The Thing is Acceptance Management. The purpose of Acceptance Management is to gain approval of the project one piece at a time. The concept is that the successful completion of each of the deliverables adds up to a successfully completed project. The process actually began back in the Project Definition Document. The deliverables defined there are the building blocks for the overall project.

In the PDD you defined each deliverable with acceptance criteria and approval authority so you would know when that piece of the project is complete and who is to verify and accept it. When a deliverable is completed, it is presented to the approver(s) for review and a Deliverable Acceptance form is issued to formally accept it. If it meets the criteria listed in the PDD it should pass. If it doesn’t it should be rejected with a list of specific reasons and returned to the team to fix. In the event that the deliverable meets the specified criteria but not the expectations of the approver, then you need to understand what changed and potentially issue a Change Request to bring it back into alignment.

The Deliverable Acceptance form should contain the following fields.

Project Number and Name states which of the multiple projects you are managing and the approvers are reviewing.

Deliverable Number and Name identifies which part of the project is under review. These should match exactly back to the PDD to avoid any confusion. At the end of the project you are going to go through the PDD and demonstrate that you delivered everything you said you would.
Approvers, as stated in the PDD. Give both the name and the role. If you remember, in the PDD you listed the role that was expected to approve the deliverable. That is because the people fulfilling roles may change during the course of the project but the role should remain constant. NOTE: the changing of resources on the project should be communicated with a Change Request to align the PDD back with reality.

Date Submitted and Date Reply Due represent the date you review the deliverable with the approver(s) and the date 3 to 5 days beyond that. In the Acceptance Management section of the PDD you need agreement on the exact number of days to review and approve deliverables. Since deliverables tend to build on each other the work you perform for the next part is at risk until the current deliverable is approved. As an example, if the Data Base Architecture document isn’t approved any work done to create the data base may change drastically.
Requestor is usually the project manager.

Description of Deliverable should be a cut and paste from the PDD. Keep that in mind when you are writing the statement in the PDD. It may make it easier to determine what to write.
Acceptance Criteria is also cut and paste from the PDD.

Finally, a statement such as “If this Deliverable has met the Acceptance Criteria as specified above, please respond to this email stating that you approve. If for some reason this Deliverable does not meet your expectations, please respond stating that you Disapprove and give the specific reasons for your dissatisfaction.”

As with Change Management, approval can be sought electronically or with hard copy signatures. Email seems to work best, but don’t use Outlook’s response buttons. They only return approved or disapproved and don’t include the original email with the response. For both project clarity and SOX purposes you will want the response to clearly state what was approved.

The Thing doesn’t stand a chance of getting delivered successfully if it isn’t:

• Defined,
• Allowed to change with the business needs, and
• Approved upon completion.

While I was fixing virus infected PCs I realized that the urgent details of the project were keep me from clearly communicating what was to be delivered. If you do the same you may end up delivering the coffee and donuts for UAT.