Activity:
|
Purpose
|
|
Role: Project Manager | |
Frequency: As required, typically once per phase starting as early as Inception. | |
Steps | |
Input Artifacts: | Resulting Artifacts: |
Tool Mentors: |
Workflow Details: |
The final acceptance of a project's deliverables by the customer is often the source of some friction in software projects. This is usually the result of a mismatch between the customers view of how the product is supposed to function, and the methods used to assess the products compliance with the stated requirements.
By jointly writing a Product Acceptance Plan during the Inception Phase, the customer and the project team can avoid this situation, by agreeing on a pre-defined process and set of criteria by which the product will be assessed for acceptance. This helps the project team build a product the customer can accept, and helps set the customer's expectations for how the product should perform. The Product Acceptance Plan also specifies how problems identified by the customer during product acceptance will be addressed.
The first step is to explicitly identify which parts of product acceptance process will be the responsibility of the customer and which will be the responsibility of the project team. You should also explicitly identify the individual or group who will make the final acceptance decision. Responsibilities can include such things as:
The product acceptance criteria are defined and agreed during the Activity: Initiate Project during the Inception Phase and should be captured in the Product Acceptance Plan at that time. During the Elaboration Phase, the criteria can be expended in greater detail when specific tests reviews can be identified.
These criteria should be developed jointly by the customer organization and the project team, and may include the following:
Next, identify which project artifacts are to be delivered to the customer for acceptance. For each of these you need to identify the evaluation method(s) that will be used to ensure the artifact meets the specified acceptance criteria. Later in the project, detailed review checklists and test cases will be developed to provide step-by-step instructions on how these evaluations will be carried out.
Once the numbers and types of artifact evaluations have been identified, identify in the plan all the necessary resources that will be required to conduct the product acceptance activity. You should include in your list of resources:
Another common problem with the product acceptance process is where the customer places insufficient priority on the acceptance activity, with the result that the process drags out over a long period of time. It is a good idea to include in you Product Acceptance Plan a schedule detailing when the various acceptance evaluation activities are to occur. This schedule will become "rolled up" into the master project schedule in the Software Development Plan.
This final step is also very important. Should problems arise during the acceptance evaluations, it is a very good idea to have an agreed process to follow. Typically this would simply follow the projects problem resolution process as defined in the Problem Resolution Plan. However is is also helpful to cover off issues such how to reach agreement that a problem is real, the provision of funding for additional work by the project team, or contractual penalties. By agreeing all these things up front with the customer, you will greatly smooth out the end of your project.
Rational Unified Process |