Two lessons I would repeat
If I had to reduce what I have learned on delivery projects to two sentences, they would be these. Get the client's sign-off on the specifications, and do not imagine or speculate on our side. And stay as close to the client as possible, so that we add value and do not only deliver tickets.
Sign-off instead of imagination
When a requirement is unclear, the temptation is to fill the gap with what seems sensible. The team is capable and the deadline is close, so a guess feels efficient. It is efficient only until the client sees the result and it is not what they meant.
A written specification that the client has signed turns a guess into an agreement. If work has to start before the sign-off arrives, I write the assumption down and ask for confirmation, so that nobody is relying on memory. The sign-off itself does not need to be heavy: a short, dated confirmation from the right person is enough, as long as it exists.
A typical case: the specification says that users can export a report, and the team builds an Excel export. The client expected a PDF sent every week to managers. Both sides read the sentence honestly. A signed specification with a short example of the expected output would have caught it in the first week.
Closeness is not the same as agreement
Being close to the client does not mean saying yes to everything. It means understanding the business problem behind a request, so that we can suggest a better option, warn early and raise a risk before it becomes a surprise. A vendor that only executes can be replaced. A partner that helps the client decide is harder to replace.
In practice closeness is a set of small habits: asking to see the process people actually work in, joining a demo instead of sending notes, and calling when something looks wrong instead of writing a long email.
A workshop at the end of every project
Lessons stay in people's heads unless they are collected. At the end of a project I like to run a lessons-learned workshop and write a report. The next project does not start from a blank page: it starts from that report. A few rules keep the workshop useful:
- Everyone who worked on it is there, and the client is invited where the relationship allows.
- It is about the way we worked, not about who was at fault.
- Each lesson ends in a change that someone owns, not in a general wish.
- The report is read when the next project starts.
This sits alongside the shorter reviews during delivery. The end-of-project workshop looks at the whole arc, from estimation and requirements to handover and support, and it catches patterns that no single iteration shows.
A lesson that nobody reads again was only a conversation. One that changes how the next kick-off is run was worth the time.