I have two principles for running projects. The first tends to make people wonder whether I moonlight as a notary. The second has three rules, and keeps the first from turning into a cult of paperwork.
If a decision isn't written down, it doesn't exist
Of course people can agree on something verbally. They can even leave the conversation with exactly the same understanding. This rare and beautiful state usually lasts until the next meeting.
Then someone remembers a caveat, someone else remembers an exception, and the person who has to do the work learns about the decision from circumstantial evidence. It is rather like reconstructing an ancient civilization, except archaeologists usually have more time.
Yes, asking people to record an agreement can make me seem difficult. I don't need a seven-volume treatise. A few lines will do: what we decided, why, who confirmed it, and where it applies. That's cheaper than holding a séance with an old message thread six months later.
The second principle is to avoid unnecessary complexity. It has three rules.
First: if it solves the business problem and works for the team, stop
Not every rough edge needs polishing to a mirror finish. Especially when the only person visible in the mirror is the one who rather enjoys polishing their own solution.
At the same time, 'good for the business' doesn't always mean 'cheapest right now'. Sometimes the economical option is a door behind which sits a person with Excel and a lifetime of manual work. Count not only the cost of implementation, but also what the solution will cost people later.
Second: we sell a product, not code
Users don't award medals for the number of new conditions, screens, and integrations. They want to do what they came to do. If that takes code, great. If it doesn't, even better.
Third: the best code is the code we never had to write
A new feature rarely arrives alone. It brings a procession: discussions, tests, release work, maintenance, and a future developer opening the ticket with the expression of someone who has discovered a secret room in their own flat.
Once, we had a question about legal text for particular products on a website. At first the answer looked obvious: add logic to show the right text for the right product. The task could have followed the familiar route through discussion, development, and testing. We might even have given it a number and wished it a safe journey.
But we spoke to the legal team first. In the end, we updated the site's policy and added a disclaimer. That solved the original problem without development.
I like this example precisely because nobody performed a technical feat. We worked out what users needed to be told, found a solution that worked for both the business and the team, and stopped. The technical specification never got the chance to become a life form of its own.
To me, a good process helps us ask the right question in time, find someone authorized to answer it, and record the result before it becomes legend. It also helps us notice when the problem is already solved. That isn't the most dramatic part of project management. It does leave the team more time to build the product and fewer reasons to excavate its own past.