Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | Spotify | RSS | More
Today we will be talking about the importance of learning in helping improve the success of our future projects.
In most aspects of life, we are constantly learning. We develop new understanding, build experience, discover what works and what doesn’t and constantly strive to be better. This is also the case for project work. Every member of the team will identify things that they would do differently or ensure that they repeat next time around.
Without taking the time to reflect on our experiences we may miss a significant number of other opportunities for learning. Our successes, failures and the challenges that we overcame can really help to bring our awareness to opportunities to learn and highlight areas for our own, our team’s and our organisation’s development.
What do we mean by Lessons learned
It’s not just the bad stuff we want to consider here. The goal is to capture and distil the key pieces of knowledge and understanding that are gained from a teams’ experience whilst undertaking a piece of work on a project.
These lessons can come from elements that went well, and need to be replicated on other projects in the future. Or they can come from things that didn’t go so well. When things don’t go as we’d hoped, we have a greater opportunity for learning. This could be in the form of things we need to look out for in future, the warning signs we missed. Or things we tried that didn’t work, so we don’t waste time replicating these actions or behaviours next time a project hits similar bumps in the road. The learnings could be from the satisfaction we gained as we successfully overcame obstacles and events that jeopardised the project.
So, when should we seek to capture learnings?
Often lessons learned are thought of as something that should be captured at the end of a project as part of a project closure phase. The lessons are then written up and filed away with the rest of the project documentation.
Whether captured at the end of the project, or at the end of a phase, there are still two significant drawbacks. Firstly this isn’t frequent enough to capture all potential learnings and secondly, we need to take action on the learnings not simply document them. We need to use them to drive change so that we have lessons learned and not simply lessons documented. Let’s look at how to address each of these in turn.
We often forget that we all suffer from short-term Amnesia. So we need to capture learnings as close to when they occur as possible, before you forget. This is one of the benefits of agile approaches such as Scrum where retrospectives are conducted at the end of each sprint which is typically every 2 or 3 weeks. This is great for the Scrum teams involved as it gives them an opportunity to identify things that are holding them back and address them as well as highlight the things that are working well and why so that these don’t stop or change in future. By reflecting every 2 to 3 weeks it means there is a better chance people will remember what they learned and the context or situation that lead to the learning.
But what about in projects involving more than one scrum team. Well, each scrum team would be going through a similar process of retrospectives and responding to their learnings every 2 to 3 weeks. That’s great but not as efficient as it could be. This is because each scrum team may be solving the same issue in different ways, some of these will be more effective than others. Such retrospectives don’t automatically facilitate sharing of learning between scrum teams or projects. Sure the learnings could be written up and shared amongst the teams, that’s a possible step forward but it doesn’t in and of itself solve the lessons documented vs lessons learned issue mentioned earlier.
The online music service Spotify introduced the concept of an Agile Guild as a community of interest group where any member of any team could contribute to and this can help in sharing knowledge between teams working on different projects in a timely fashion. Such a model may work well in some organisations where there is a good fit with the organisation’s culture.
The key message is, don’t wait to get feedback. Get feedback as close to the point in time that the learning was identified in order to improve the quality of information available. People’s memories fade.
There is also value in recording feedback for which a solution has not yet been identified as this can serve as a prompt for a later time, to follow up on how the issue or opportunity was addressed and how effective the solution was.
So as an absolute minimum we should be capturing and sharing learnings at the end of each phase of a project as well as at the end of the project. For those using an Agile ensuring, we really do need to take the time to do a good job of capturing feedback from retrospectives and to share the relevant learnings with a wider audience than just the team involved. Ideally, we would also provide a mechanism for learnings to be shared by any member of the team at any point in the project. This ad-hoc, suggestion box type approach can help feed into lessons learned workshops by providing a prompt of topics that need to be discussed further.
How do we elicit learnings from our teams
Lessons learned sessions can be as formal affairs overseen by a project management office or PMO. Or they can be informal where team members are given the opportunity and encouragement to reminisce about their time on the project. These workshops need to be handled well to ensure that it is not just the views of a dominant few that shape the learning being captured.
A key point to remember here is that we want to hear from everyone on the team. The junior and senior people, permanent members of staff, contractors and external suppliers. Not everyone will want to share their points of view, especially publicly. So it’s important to make space and cater to those team members who may not be comfortable sharing in a discussion group or workshop. Asking for their feedback beforehand can help by giving them the opportunity to speak one-to-one or email their input ahead of the discussion with a larger group.
Even the most vocal of team members would appreciate the opportunity to reflect and debrief ahead of the workshop. They can then come to the workshop better prepared to share their views on learning, successes and areas for improvement on future projects.
Whilst we are on the topic of who should be included and ensuring all viewpoints are given the opportunity to be heard it’s worth highlighting that the project manager is not the best person to run these workshops. Especially the end of phase and end of project workshops. The project managers viewpoints should be sought and are certainly valuable however they represent just one perspective and the rest of the team could have differing points of view. It is essential to capture differing views on the learnings and this can be difficult to do effectively if the workshop facilitator is not impartial.
Clearly few of us have access to dedicated workshop facilitators ready to lead such lessons learned review sessions. However, most will have colleagues working on other projects within the same organisation. Asking a fellow project manager, business analyst or member of another team to facilitate the workshop on your project can bring a degree of impartiality into the workshop discussion and improve the changes that people feel more able to contribute and really be listened to.
If you were really looking forward to running the workshop yourself, then don’t worry. The other project team will more likely than not come and ask you to facilitate their workshop in return.
What learnings should we capture
When booking in a lessons learned workshop or even an agile end of sprint retrospective it’s imperative that we help our teams to reflect on their recent experiences within the project. Not everyone finds reflection easy. Especially if they need to reflect on their own contributions and involvement. Give them some guidance on what they should spend some time thinking about ahead of the workshop.
It’s important to remember that we’re not just looking for lists of things that went wrong. This is not an exercise in identifying all the bad stuff in a project. Sure, we need to learn from things that went wrong or didn’t go as well as they could have so that we can improve. It’s equally important that we capture the things that went well and why they went well. This has three benefits:
– It allows these good behaviours, processes and approaches to be replicated on other projects and help shape best practice for future project teams
– It also allows people to be recognised and acknowledged for their contributions, good ideas, creative solutions and work that led to a positive outcome.
– Finally when the team can see that the workshop has a positive focus then it helps them to feel more comfortable and confident contributing to the process. This, in turn, leads to a more useful “lessons learned” workshop.
Whilst we’re on the topic of ensuring a positive focus for the workshop. A key piece of advice which we all implicitly know but don’t always follow is, that we should publicly praise and privately deliver feedback about underperformance.
Keep the workshop session and all documentation focused on events, responses and behaviours and not about individuals. If a team member needs to be talked to about something they did or didn’t do that negatively impacted the project or their colleagues in some way then have this discussion in private and involve their line manager as appropriate. The lessons learned session is not the forum for discussing individual performance issues or assigning blame for things that didn’t go as planned.
Some useful questions to get the team reflecting on their experience on the project are:
– WHAT worked well and WHY
– WHAT DID NOT work well, and WHY
– WHAT could we have done to improve the outcomes
For each of the “what worked well” and what didn’t work well items dig into them deeper within the workshop exploring:
– What happened and when?
– What triggered the event/ issue/opportunity?
– Review initial risk assessments, what wasn’t anticipated or was wrongly rated/responded to?
– What procedures were followed, and were they useful?
– How appropriate and effective were any mandated reviews and control points?
– What tools and techniques were used, and were they useful?
– Were the right people involved, who should have been involved that wasn’t?
– Were stakeholder communications right in terms of quantity, timeliness, method, content, people etc?
– What should we watch for in future projects… in other words what are the early warning signs?
The responses to these questions will point to specific lessons that need to be learned from. These could range from simply making future project teams aware of situations to keep a watchful eye out for in case they appear on the horizon. Through to implementing changes to policies and procedures, project teams are expected to adhere to.
Great, we’ve now got a collection of lessons learned from throughout our various projects. Now, what do we do with them?
Ideally, we should capture as much information about the discussions during the workshop. However this tends to result in a report that gets filed with the project documentation, and then never read. Recipients of the report will often times leave it languishing in their email inbox as a lonely relic of the past as they battle with today’s issues. Even though the content of the report could be helpful to them in solving today’s issues.
In order to address the second issue identified earlier in this episode, we need to move from lessons documented to lessons learned.
Simply minuting the meeting in a document is therefore not sufficient. It needs to be actionable and it needs to be accessible.
Even with the best of intentions, we will never address every issue or a good idea that surfaces during a “lessons learned” workshop and therefore it’s important to triage and prioritise at the end of the session. By focusing on the learnings that will deliver the most benefit to future projects we can incrementally drive real improvements. Even if we achieve just one improvement then the lessons learned process will have been worthwhile. So what is your project team’s “one thing”?
Produce an accessible summary of the lessons learned. This could be in the form of a summary presentation, email or one-page document provided to the rest of the organisation or department. It could be in the form of entries in a lessons learned repository that team members can explore or could be a continually updated FAQ held on the organisation’s intranet. Provide a list of action items to the PMO or appropriate group so that they can be incorporated into future processes, procedures and checklists. The key is that it needs to be accessible and this will differ by organisation culture.
However, you choose to share the lessons learned it’s important to be consistent with the approach used by other project teams. Always ask yourself how would someone find this information in a year’s time?
When writing up summaries of the key learnings ensure that common terminology that would be understood by the wider audience and not just the team involved in the project is used. Think about whether a new employee unfamiliar with the organisation’s project histories would be able to make use of the information.
The summaries should provide a roadmap of potential future impediments that projects could face and should give guidance on how to avoid them or handle them effectively. Focus on the events, the triggers and any warning signs that were identified on reflection. Outline what worked and what didn’t so that others can benefit from this insight. And be sure to indicate the stage in the project that the learning event occurred.
Finally, and this isn’t always easy to do. When documenting the learning be sure to include not just views that match your own opinions and impressions. Capture the differing points of view that different members of the team may have had due to the vantage point they were held.
In summary
As project teams and as individuals we are constantly learning and improving. Through reflection on the past and our actions, we can learn to improve and develop in order to have even more positive outcomes in the future. Through sharing what we learn we can help others to benefit from our experiences, be they positive or not as good as we’d have liked.
Identify the events, the thinking and actions that lead to the successes or difficulties become harder with the passage of time. Therefore lessons need to be captured and recorded for future reference if they are to be remembered. Our memories are not as great as we would like to believe. It is therefore imperative that learnings be captured as close to the point in time in which they occur. This valuable learning from past experiences must be codified and turned into action items that get embodied in the organisation’s PM processes and systems.
The goal of all lessons learned activities is to help future projects and teams be even more successful. We need to encourage proactive reflection throughout the project and not just at the end of a project or phase.
We must also ensure that this does not become simply an exercise in generating lessons documented. Change and improvement must come from making use of these experiences. So that we do indeed benefit from the lessons we, and others, have learned.
0 Comments