Nothing is perfect. Even when you think you’ve done a perfect job, there is always something you can improve. Chasing the ideal outcome leads you to spend time and resources to improve things beyond necessity. This is true about any project in any domain, from renovating a house to getting a car to deprecating a software service.

There is always an objective goal where the project can be considered good enough. Back to the previous examples, in the case of renovating a house, good enough can be when your house doesn’t need any general repairs in the next ten years. In the case of getting a car, good enough can be a car that can operate well in snow, costs less than $40K, and can fit four passengers. In the case of deprecating a software service, good enough can be that no new service calls the deprecated service.

Without an explicit good enough goal, the project can either be under-engineered or over-engineered. Under-engineered work is not meeting the original needs, while over-engineered work drains resources, such as money and time, to get to an imaginary better state.

Who should set the good enough goal? The owner of the project. It can be a product manager, an engineering manager, or a client. Only one person should be responsible for setting this goal, and that is their responsibility to get alignment from all stakeholders. Setting the goal should never be left to other than the owner.

What should be the good enough goal? It depends on why we are doing the project in the first place. Making it simpler: there is a problem, there is a target state, and the project is a mean to solve the problem by bringing the target state into reality. This target state needs to be translated to an objective goal, and that goal is good enough.

There is usually a temptation to go a step further when the goal seems to be within reach, either by stretching the goal or piggybacking on the accomplished work of other goals which are not a priority. Whenever a goal is about to change in the middle of the execution, the owner should do a cost-benefit analysis. 

A cost-benefit analysis shows how much gain (or loss) can come with the new goal with regard to new cost constraints in the short, medium, and long term. The cost in this analysis should consider the new risks that come with the new goal. Sticking to a goal dogmatically without considering changing attributes will lead to failure.