What "done" means — define it before you start
Half the arguments at the end of a project are really disagreements about what 'done' meant that nobody settled at the beginning.
"Is it done?" sounds like a simple yes-or-no question. It rarely is. One person means the code works; another means it's tested, documented, deployed, and handed over. When 'done' isn't defined up front, the end of a project becomes a negotiation nobody expected.
Undefined done causes rework
If the team never agreed on what finished looks like, you discover the gap at the worst time — when someone thought they were wrapping up and someone else thought there were three steps left. That mismatch is pure rework and frustration, and it was entirely avoidable.
Write the definition first
Before starting, agree on what done includes: works, tested, documented, deployed, whatever applies. It's a quick conversation that prevents a slow argument. A shared definition of done turns 'is it finished?' from an opinion into a checklist.
Most end-of-project arguments are just an undefined 'done' coming due. Settle it before you start.