Real Lessons

Many years ago, in fact last century (if its OK to write that) I worked with an individual who was responsible for collating the lessons learned from the projects that had been run across the IT department.

In order to ensure that no one got the blame for any projects that didn’t go as well as a expected he decided to sanitise the lessons.

This meant that he would remove the details of the project manager for the project, which would then protect that person from further blame

He would remove the project name and replace this with information about the business area that the project delivered into, which would stop people picking on that particular project

He would take out all details where individuals were named and replace them with some generic like IT developer, project manager, business representative, again to prevent the people from getting blamed

This led to some very bland statements being recorded in the lessons log such as project managers should engage with the stakeholders more, which I have seen in countless project management books and blogs.

As the names had been taken out you weren’t able to talk to anyone about the lesson

As the context had been taken out you didn’t know the best way of doing that engagement. Did they prefer emails, face-to-face, meetings or one-to-ones? How frequent should that engagement be

And they wondered why they weren’t getting the benefit of the lessons learned

One thought to “Real Lessons”

  1. Very interesting post and a wholeheartedly agree. Too often have I seen generic lessons recorded (e.g. “communication was good”) that are meaningless to anyone but the person who wrote them.
    What would be your suggestion of how best to capture lessons? What tools are best in your experience? And is there even a need for Lessons Learnt in a more and more agile project world with regular retrospectives? I’d be interested in your view on these points.

Comments are closed.