Getting Good Enough In software there is a refrain of "good enough" started most likely by Cem Kaner of software testing fame. Projects can be good enough as well. The problem is to be able to define good enough in a way that everyone - solution team, project manager, upper management, and the customers - agree that good enough has been defined and achieved at project's end. This is done in the early stages of the project by the business analyst if there is one or the project manager.

It is a simple process. Once the problem is defined with the business there are three questions to ask the sponsor or problem owner or customer, whoever you are dealing with having the authority to answer the questions:
Is this the problem you want to have solved?
How are you going to know you solved it?
What do you need to see to prove to you that we solved the problem?
The answers to these questions are not difficult and constitute the acceptance criteria for the project. The answers also create an informal contract between the project team and the customer: when you show me that the problem is solved, I will sign off.

The answer to question one confirms that the project is tackling the right problem, the solution of which the customer or sponsor is willing to pay.

The answer to question two establishes the acceptance criteria that proves the problem has been solved to the sponsor's satisfaction.

The answer to question three establishes the acceptance test structure - what we are going to do to show the sponsor that we have successfully accomplished the answer to question two.

Getting the answers up front before development has started keeps all the "how hard would it be to..." and other addenda from sneaking into the acceptance criteria. The acceptance is focused on solving the problem as stated and that is all.

And that is good enough.  ¶ 6:25 AM