When a project wraps up, there's usually a natural inclination to move on. The thing is built, it's working, the client is happy. But we've found that one question, asked honestly at the end, tends to be more useful than any amount of mid-project review.
The question is: what would we do differently?
Not "what went wrong" — that framing tends to produce defensiveness, and it focuses attention on problems rather than on the decisions that led to them. And not "what went well" either, because that framing produces a list of things to feel good about rather than things to actually learn from.
"What would we do differently" is more useful because it assumes that most decisions were reasonable given what we knew at the time, and asks what we'd change with the benefit of hindsight. It applies equally to things that worked out and things that didn't. Sometimes the answer is: we'd do exactly the same thing, because it worked. Sometimes it's: that decision made sense on paper but in practice it caused problems we didn't anticipate.
We have this conversation internally after every project, but we also try to have a version of it with clients. That conversation is harder, because it requires both sides to be honest about things that didn't go as well as they could have. But the projects where we've had it openly have tended to produce the best working relationships — because it signals that both sides are interested in doing better, not just in maintaining a comfortable fiction that everything went perfectly.
The practical output is usually a small list of things — how we structure discovery, how we handle a particular kind of change request, how we communicate delays when they happen. They're often minor adjustments. But they accumulate. Most of the ways we've improved how we work have come from the end-of-project conversation, not from any more formal process.