Lessons Learned is one of the most important parts of a project and is finalized in the closing process. Well, it's one of the things that I think is the most important part of a project (after the deliverables), and something that many people don't want to do since it feels like "wasting time rehashing what didn't work and what did work".
If you look it up in different project management books and sites there will be something about "closing the project allows the organization to record, maintain and reuse lessons learned for future projects". This might be especially helpful if your organization has repetetive projects, say running a same production of compound X in various batches, or performing preclinical PKs with different drugs but the same models.
In my experience this specifics of "lessons learned" is more about "How" you go about capturing the learnt part rather than the "What did you learn". Maybe this is more due to the fast paced environment I move in, with several different teams and the feeling that we are doing "one of a kind experiments that wouldn't benefit from this formal step". Side note, a lot of the processes are the same, just that the people involved in them often think of themselves and the work product as unique and therefore not benefitting of a lessons learned.
There is also a similar connotation of "lessons learned" feeling more like a sit down and repeat what didn't work and let us capture who failed on what. Of course, this is similar to the feeling of people who don't like evaluations or critiques or feedback since the emphasis tends to be on "what didn't work". However, dealing with processes, it's always helpful and important to sort out which processes that did work well, and why. Side note 2, most often these processes get repeated and most people tend to view them as the "norm" since they work, when in fact these processes more often than not are not the norm and can give a huge insight to strengths and built in flows in the organization. It also gives an opportunity to review the successes of the team retrospectively, something that might not happen as often in an academic environment where we have forgotten the project the moment the paper is sent in and accepted rather than when it is actually published.
For the point of this blog post though, I had something specific in mind when contemplating the latests of Lessons Learned I am facing to do and capture. One of these closings is my annual review where I will go through a few of the projects I've worked on this year and I see that some of the bullet points from Lessons Learned will fit well into the review format. Why? Well mainly because of the point I made above in regards to a set of experiments that the people viewed as unique and one in a time, whereas I see them as the same process being slightly tweaked with details specific for the project in questions. And I'm involved in these projects on a regular basis.
Interestingly enough (but not surprising), it's a similar Lessons Learned for another project with a different set of people but similar deliverables and time lines. It goes something like this; Communication plan was decided and in the beginning of the project everything worked fine. Emails to the team was sent, in a timely manner before and after meetings, and updates were clear. Everyone got the work done on time. Once the project started lagging behind the time line, the communication plan broke down. This was in hindsight more clear since the person responsible for the communication decided to not be transparent with the delays in production, and at the same time stopped producing meeting minutes and tasks to the team. The team started meeting in smaller groups, which didn't have follow up or minutes, thus making it impossible to gauge where the project was. Finally there was a large group meeting where the project sponsor and the biggest stakeholder were present, this meeting generated a clear list of expectations, deliverables and time line with mile stones. For future projects, clear meeting minutes need to be delivered to the project sponsor and stakeholder for accountability. Communication should not be considered an afterthought. And even an email stating "no news in the project" is an important email if there has been no update meetings in over four weeks since communication indicates "keeping everyone in the project up to date and on the same page".
All of this is obviously easier said than done when working on concurrent projects with several team members in different projects, however - it's even more important for efficient work and avoiding rework and break downs.
There is a lead in from Lessons Learned into more private sphere and how this can be helpful in a career setting (lessons learned from your PhD project for example) but that's another blogpost.
No comments:
Post a Comment