Critical Technology Project Management Best Practices For Lessons Learned

In my reading and research… this article’s title surely got my attention:

Stop with the Lessons Learned

=> Click Here To Read The Full Article

Correct me if I am wrong but it seems to me that the article is indicating that a lessons learned (post mortem) be conducted “a week before the end of the project…”, and I thought it was positive “…linking lessons learned with project initiation, promoting knowledge management and presenting the lessons learned to the project sponsors was a key takeaway.”

But my concern is a project, small or large, has a lot of processes and activities, especially for a full SDLC development project or program. We know the failure rate of projects is high, so we must learn from documented and used lessons learned. It would seem that waiting until the end defeats the purpose to learn within the current project or program. That learning could change the course of a troubled or failing project or program. Lessons learned can be extensive at the end of a project. In one of my early projects the team members could not recall all the significant lessons learned. Who has that kind of memory to recall? Someone in the meeting said they had forgotten some of the lessons learned. From that point on, teams I have managed had opportunities to document lessons learned before the end of the project. I have not had just one lesson learned session for a project or program, and surely not just one at the end; post mortem. Lessons learned must be documented, and lessons learned sessions must be conducted, throughout the project or program.

A best (and good) practice: (an early career lesson learned)

Document lessons learned after each phase, processes/activities, and major tasks and not just at the end of the project (post mortem). Yes, document lessons learned during each phase/process/activity of a system or software development life cycle (SDLC) (requirements definition/analysis, design, implementation/construction, test, delivery/deployment, and support/maintenance) and after each activity, task, and deliverable. (Note: In one company they had you document lessons learned for the entire engagement process; from discovery (including Sales and Contract activities) to project close out.)

Share and archive also for future projects and programs use. Establish a repository or database to store project and program information, knowledge base and lessons learned. Create a feedback mechanism for lessons learned to be submitted for gathering, organization and periodic review. This also allows empowered team members to submit lessons learned on a continuous and periodic basis. Ensure/enforce the use of lessons learned through PMO, if you have one. And, yes, lessons learned should/must be reviewed before a project’s or program’s initiation, especially for any similar or related projects and programs being initiated.
Ensure customers’ and users’ participation in the beginning, and throughout a project, which would allow them to be part of the knowledge transfer and lessons learned processes and activities.

See related articles about documenting and using lessons learned:

• Documenting Lessons Learned
• Tips on Lessons Learned