Difference between revisions of "Final Product Acceptance"
m (→Why: Link to next) |
(→Why) |
||
(5 intermediate revisions by 2 users not shown) | |||
Line 2: | Line 2: | ||
== What == | == What == | ||
− | The event where the system-to-be has met the | + | The event where the system-to-be has met the Product Acceptance Specifications and the customer accepts the delivery of the system according to the contract. |
== How == | == How == | ||
Line 8: | Line 8: | ||
'''The dish''' | '''The dish''' | ||
− | Product | + | Final Product Acceptance |
'''Ingredients''' | '''Ingredients''' | ||
− | * Product | + | * Product Acceptance Specification |
* Development Plan | * Development Plan | ||
* Deployment Plan | * Deployment Plan | ||
Line 20: | Line 20: | ||
'''Process''' | '''Process''' | ||
− | The system-to-be is being deployed according to the deployment plan, and the | + | The system-to-be is being deployed according to the deployment plan, and the Product Acceptance Specifications are tested and verified. If the deployed system fails to meet the acceptance specifications, you need to make a list of the deficiencies specifying the problem and then decide whether the problem will stop further deployment or if the problem can be fixed later. |
− | When the entire system is deployed and has been tested according to | + | When the entire system is deployed and has been tested according to the acceptance specifications, when the list of deficiencies is empty and verification completed, the Final Product Acceptance is due to take place. |
− | The product is accepted when the customer | + | The product is accepted when the customer has signed a product acceptance form and accepts the product according to the Quotation and the Final Contract. |
== Why == | == Why == | ||
− | Just as the initial customer contact is very important for the success of the project, so is the | + | Just as the initial customer contact is very important for the success of the project, so is the Final Product Acceptance. Here you actually feel the success rate. If both the developer and the customer are satisfied, the task is carried out well. If not satisfied, you have the scene for a lot of frustration! |
− | The customer will not accept the product because his or her wishes and expectations have not been met. Consequently, the customer will not pay the bill and the developer | + | The customer will not accept the product because his or her wishes and expectations have not been met. Consequently, the customer will not pay the bill and the developer will have to hire lawyers. Another scenario is that the developer has to make many corrections if the Quotation and Product Acceptance Specifications are incorrect. This means additional costs in terms of time and money. |
− | + | To prevent frustration, loss of confidence, loss of reputation, time and money, you have to follow the four phases of the Embedded Unified Development Process carefully and at all times during the project, remember to involve the customer. | |
− | To prevent frustration, loss of confidence, loss of reputation, time and money, you have to follow the four phases of the | + | |
From here [[Product Evaluation]] is the next step to take. | From here [[Product Evaluation]] is the next step to take. |
Latest revision as of 11:38, 8 May 2015
What
The event where the system-to-be has met the Product Acceptance Specifications and the customer accepts the delivery of the system according to the contract.
How
The dish
Final Product Acceptance
Ingredients
- Product Acceptance Specification
- Development Plan
- Deployment Plan
- Quotation
- Final Contract
Process
The system-to-be is being deployed according to the deployment plan, and the Product Acceptance Specifications are tested and verified. If the deployed system fails to meet the acceptance specifications, you need to make a list of the deficiencies specifying the problem and then decide whether the problem will stop further deployment or if the problem can be fixed later.
When the entire system is deployed and has been tested according to the acceptance specifications, when the list of deficiencies is empty and verification completed, the Final Product Acceptance is due to take place.
The product is accepted when the customer has signed a product acceptance form and accepts the product according to the Quotation and the Final Contract.
Why
Just as the initial customer contact is very important for the success of the project, so is the Final Product Acceptance. Here you actually feel the success rate. If both the developer and the customer are satisfied, the task is carried out well. If not satisfied, you have the scene for a lot of frustration!
The customer will not accept the product because his or her wishes and expectations have not been met. Consequently, the customer will not pay the bill and the developer will have to hire lawyers. Another scenario is that the developer has to make many corrections if the Quotation and Product Acceptance Specifications are incorrect. This means additional costs in terms of time and money.
To prevent frustration, loss of confidence, loss of reputation, time and money, you have to follow the four phases of the Embedded Unified Development Process carefully and at all times during the project, remember to involve the customer.
From here Product Evaluation is the next step to take.