Although scope creep often comes from stakeholders, it can also come from project team members in the form of Gold Plating ("when technologists augment the original requirements because of a bias toward "technical perfectionism" or because the initial requirements were insufficiently clear or detailed."). I've been one of those technical perfectionists myself.
Are there any effective strategies for drawing a "good enough" line in the sand in order to bring a project to a close?
I find two techniques to be very helpful in this respect:
Gold Plating is the effect of problems with Human Resource Plan, especially its "Motivation Plan" part. People do Gold Plating when they don't know how exactly the project wants them to behave. In most cases they think that "to work hard" is what the project needs from them, which is absolutely wrong.
To solve the problem you need to explain them (in writing!) that the project wants them "to deliver scope".
All the above answers give the standard reasons for Gold Plating. But, there is another reason. It comes from the fact that developers are highly creative people, and the very often get stuck in an "OMG!!! This is so cool!" trap. Google's policy of allowing developers to work on their own projects has as a side benefit, the mitigation of this trap.
But, if a developer ends up in the trap, the best way to deal with it is to defer the coolness to the next release. See if you can get Sales involved, and get the client to pay for the gold plating on the next version.
I think Gold Plating occurs when there isn't a clear scope and proper communication of priorities. Some of the agile techniques can help reduce this tendency. When you have work to deliver daily or weekly, it tends to limit the ability to Gold Plate the solution.
I have seen a developer spend a month coding a screen to turn off the save button when the edits resulted in the data returning to the original values. The screen had a clear button which could be used to do the same. I was not aware of any other screens with the same functionality.
Being somewhat a perfectionist myself, I will often try to exceed the good enough criteria. I certainly advocate for inclusion of features which will increase security such as automatically disabling unused administration user-ids. I would likely capture the data to enable the functionality, even if the functionality were out of scope.
Drawing a "good enough" line in the sand implies something around quality whereas gold plating is going above and beyond scope. These are two different things. Good strategies to avoid gold plating is ensuring your scope is well defined in that the characteristics of the product are defined, documented, and understood by all of the principles. Your quality control reviews during development can help identify where gold plating may be taking place with the idea of stopping it before it becomes out of control. And of course conducting ongoing training with your team and periodic inspections of their work.
However, your original question used the words perfectionist and good enough. Quality is simply different than gold plating so I am not sure what you were really after.
When you're working on the specifications, the client is usually involved in those meetings to make sure that the project scope is properly defined. Both parties go back and forth discussing the goals of the project until the specification contains enough details to satisfy both parties.
In order to help keep technical resources from increasing the scope, involve the technical leads in the discussions as well. If the technical leads feel involved in deciding what goes in the specification document, they will be more likely to adhere to its scope.
The act of having a contract helps resolve disputes, hold all parties accountable, and also help answer questions about scope, not just for the client but also for the technical team.
