Asking Your Project Team to KISS
Asking Your Project Team to KISS
How to gather and document lessons learned from the team
“Good is identifying a lesson, better is applying it, best is propagating it!” —Kiron Bondale
The TL;DR Key Takeaways:
Identifying and documenting what went well, what didn’t, and what could have been done better is an important aspect of a project’s closeout phase; the gathered information is known collective as a project’s “lessons-learned.”
Identifying lessons-learned will help you and your organization perform better on the next project that you undertake. Additionally, soliciting feedback helps build trust and morale within the project team.
An effective method of gathering lessons-learned is via a “KISS” survey, in which you ask your team for recommendations for the next project, based on four key categories of feedback about the current project: a) What would you Keep; b) What would you Improve; c) What would you Start doing; and d) What would you Stop doing on the next project?
The What’s and Why’s:
A properly conducted Closeout Phase is an essential component to project success, and one of the key elements to the phase is the gathering and documentation of so-called project “lessons-learned.” A lesson-learned document is the collected results of surveys, interviews, and input from team members gathered throughout the lifecycle of a project. Every project has ups and downs along the way, but the best projects try to learn from both the highs and lows, using them as opportunities to learn and improve for the next project.
A well-constructed lessons-learned document provides three key benefits:
Avoid Mistakes. There’s nothing more frustrating than making the same mistakes over and over again. Unless a project manager makes a conscious effort, your team may lose out on valuable insight by not learning and improving from their experiences. Insights gained from a reflective exercise are only useful if you can document and retrieve them for future projects. Remember, it’s hard to address a problem if you are not aware of what the challenge is! Collecting feedback from the team makes it easier to identify common threads and issues that caused project struggles.
Identify Strengths. Conversely, if there are team members or groups that did an excellent job on a project, getting things done on budget or ahead of schedule, then you should learn why. Unlike avoiding past mistakes, these are the things you want to leverage and repeat on future projects.
Make Team Members Feel Heard. Studies have shown that three out of four employees say they’re more effective at their job when they feel heard. Collaborating on a lessons-learned document is an excellent opportunity for your team to vocalize what they struggle with and what makes life easier. Giving your team the space to voice their opinions will make them feel heard and appreciated. This kind of company culture is more likely to boost employee morale and productivity.
The How:
Gathering:
Gathering lessons-learned can be done through various methods, including formal After Action Reviews (AARs), informal project “post-mortem” discussions, and surveys.
AARs can be useful, but often these kinds of group meetings elicit the “iceberg” phenomena, whereby only a small fraction of “vocal” people voice their opinions. (See the Cautions & Caveats section below for more on this issue.)
Informal “post-mortem” discussions can also be helpful. The key issue with them, however, is their informality. It’s hard to ensure everyone on the project participates, and that the questions (and collected” answers cover all important aspects and areas of the project.
Surveys are considered one of the most effective methods as they solicit feedback from all team members, providing a comprehensive view of the project's strengths and weaknesses. There are a variety of ways to collect and categorize survey responses, but I like author and leadership expert, Michael Hyatt’s, “KISS” system, which is an acronym that stands for Keep, Improve, Start, and Stop:
K is for Keep. These are the things that you would definitely keep or continue doing on a future project. For example, imagine that you found an unusual but very effective method of communicating with a key stakeholder. This is something that you would want to keep doing on future project with this type of person.
I is for Improve. These are things that might have worked, but certainly could have been done better. For example, the project’s risk register may have been useful, but could have been even more beneficial if it were formatted different, or made more visible to all team members, or updated more frequently.
S is for Start. These are things that should have been done on the project, but for some reason weren’t. For example, hosting a regular “all-hands” meeting to disseminate information and help build team morale could help overall project effectiveness.
S is for Stop. The fourth category in the KISS system are for those things that you should stop doing. These are things that caused more harm than good, and should not be continued on future projects. For instance, holding weekly progress and status meetings might have wasted too many people’s time, and could have been replaced with simply having the employees send in 1-2 paragraph written updates via email. You could then follow up on any areas that were unclear or needed further discussion.
It’s also helpful to create subcategories, such as technical lessons learned (e.g., we should never again use parts from supplier X), programmatic (e.g., we didn’t have enough time or money to fully complete Y), and miscellaneous (e.g., remote working arrangements require improvement).
Documenting:
It is crucial that the lessons-learned be documented in a clear, concise, and accessible manner. This documentation should include not only the feedback received from the team, but also the actions that will be taken as a result of this feedback. The lessons-learned documentation can then serve as a reference for future projects, providing a roadmap for continuous improvement.
To document the results, you (and perhaps other senior project leadership) will need to review, sort, triage, and ultimately, compile the gathered information into a meaningful and useful document. Said simply, you want to ensure that the information in the final report is (a) beneficial and practical; and, (b) doesn’t include any sensitive or inflammatory statements.
The form of a final lessons-learned document can vary. Some projects simply produce a master spreadsheet of the lessons, sorted via tabs. Others write a detailed, explanatory report. Still others create online, searchable databases. The exact method you use will depend upon things like your industry norms, what your organization needs, and any formal requirements that might be spelled out in project oversight documents.
Presenting Results:
It is (unfortunately) very common for a well-written and otherwise useful lessons-learned document to be stuck in a drawer somewhere, never to be seen again. This defeats the entire purpose of the exercise. To combat this tendency, there are a few things you can do.
First, post the final approved lessons-learned document someplace visible and accessible to the team and future project folks. This can be your company website or, alternatively, create a “wiki” page or searchable database.
It’s also useful to hold an all-hands meeting and present the results to the entire team. This ensures they know that you listened to them, but also gives them another chance to provide further feedback and information.
Example of a Real-World Lessons-Learned Process:
On my last project, we used all the previously mentioned methods. We created a Google Survey form, which was sent out about a year before the end of the project. The survey question simply asked for KISS-type input, and it was also made clear that all advice was welcome, not just in a person’s individual work area. Follow-up emails were then regularly sent out, reminding people that their input was both requested and valued.
We also encouraged people who were uncomfortable with the written survey to schedule an appointment with their supervisor and pass along direct feedback. As the project manager, I held about a dozen of these 1-on-1 discussions. I used the KISS framework to facilitate the meeting, and I also employed The Five Why technique.
During this process, we also made sure not to criticize or push back on the feedback we received. Don’t constrain people on their answers or make them feel afraid of voicing their opinions. Let them tell you what they want to tell you. The message to the team should be that there isn’t “good” or “bad” feedback, and that you’re honestly investigating how to improve the planning and execution of future projects. All feedback is welcome and appreciated, regardless of type.
Following the gathering of information, one of our senior systems engineers was then given the task of sorting and categorizing the gathered information. This person also took the first stab at teasing out actionable actions. They did this by taking each piece of input and turning it into three distinct things: a) What was the issue raised? b) Why is this important? And c) How can this information be used on a future project.
Following this sorting exercise, the information was then turned over to me, the Project Manager, for writing our final Lessons-Learned report. In our case, of the hundreds of individual advice received, there were ten key themes and common categories that arose. These then formed the basis of the lessons-learned report chapters. Each chapter began with a short intro and sample (anonymized) quotes from the team. Then the same What, Why, and How methodology mentions above was employed to write the key takeaways.
Finally, the report was reviewed by our directorship, some minor wording changed, and then the report was published.
Cautions & Caveats:
When gathering and documenting lessons-learned, there are a few important things to keep in mind:
Lessons-Learned Gathering Should Be Continuous. The process of gathering and documenting lessons-learned is not just something done during closeout. In fact, it should be performed throughout the life of the project. Waiting until the end to do it for the first time means that important and useful information may be lost or forgotten. You should strive to gather and assess lessons at regular intervals, both formally and informally, integrated throughout the project lifecycle. This provides the team with ongoing opportunities to reflect and improve, leading to better results on future projects.
Expand the List of Participants. Don’t limit lessons-learned input to just the project team. We found it useful to Las ask some of our key stakeholders for their input, too! For instance, our upper management had thoughts on what did and didn’t work well from their perspective, as did people at our funding agency.
Beware the Iceberg Rule. Group sessions for gathering lessons-learn are often employed on projects. While these can work and generate useful feedback, you should also be cognizant of the so-called “Iceberg” rule. If you get people together and solicit advice, loud and “alpha” people will speak up the most and provide their input. But most people won’t. The quiet ones, who typically have really good input, frequently won’t speak up. While the loud people are like the tip of an iceberg, visible above the water line, the majority of people are like the bottom of the berg, unseen and nervous or reticent to voice their opinions. It’s fine to hold group sessions, but this should be augmented with surveys and one-on-one discussions, too.
The Bottom Line:
Gathering and documenting lessons learned is a crucial part of the Closeout Phase of a project. It provides organizations with an opportunity to evaluate their processes and improve, while also fostering a positive work environment and building trust and morale among the team. The use of surveys is considered one of the most effective methods of gathering lessons learned, and the information gathered should be curated in documented in a clear and accessible manner. By integrating the process of gathering lessons learned throughout the project lifecycle—and communicating the lessons—organizations can achieve continuous improvement and better results on future projects.
Or, as Kiron Bondale said, it’s good to identify a lesson, it’s better to apply it, and best of all is to propagate it to others.