Project closure is often ignored as focus and resources tend to quickly switch to another project. However, I believe that closure is a crucial part of the project life cycle. In this article, we will talk about “Lessons learned” which is one of the many aspects of project closure.
In lessons learned, you take a step back and analyze things that didn’t go so well with the project. The goal is to document the lessons learned from this project which can be used as reference for future projects.
It can be anything from lack of communication from your side to evolving customer’s needs. Once you’ve identified those issues, you should suggest actionable steps to address those.
Getting clients or stakeholders to give honest feedback can be like pulling teeth. This is why during the closure meeting, you should ask the hard questions. It’s the constructive criticism that helps build better relationships, and help businesses grow.
By acknowledging things that went wrong during the project and offering solutions, you will build a trust relationship with your clients (or stakeholders). They will respect you more for being transparent and soliciting honest feedback.
By offering suggestions on how to improve how the project was handled, it gives clients a sense that you are serious about helping them meet their objectives in the long run. It suggests that you’re ready for the next project and that future engagements will be even more successful.
Here are some common examples of things that go wrong with web / software projects. For each, answer the following: how can we improve our project methodologies?
| Issue | Potential solution |
|---|---|
| Under or overestimate development estimates | Organize weekly meeting with developers to re-evaluation time estimates. Alternatively, if resources is not an issue get requirements estimated by multiple developers. |
| Project was delayed because client was’t clear about his needs | Run more effective scoping meetings in which you present the high level solution with the help of supporting material (ex: user flow charts, mindmaps, UML diagrams, sequence diagrams, etc). |
| Vocabulary misunderstanding | Provide glossary of technical terms that are only known to tech savvy users (example for web project: what's header / footer / collapsible element / modal window / etc) |
| Feedback on the UI was provided after the project was delivered | Detailed mockups with limited amount of iterations and strict signoff process. |