Repeated mistakes happen all the time due to associates leaving the company or moving to another position within the company without sharing their previous experience with the rest of their project team or function. Projects are never useless, even if they end up not moving forward or if the business decides that they are not feasible for the time being. There are always lessons learned from any projects. Teams can always learn something new since projects are never similar and there is always something that causes questions and concerns, no matter how much experience the team has. The ideal solution to avoid repeated mistakes is to have a database to store all the lessons learned within the team and also within the function, i.e. R&D, Quality, and Regulatory. A really good initiative would be starting a risk register in order to capture all the risks for the project in order to present a full picture of the project and when it is expected to be completed. The project manager should be able to share previous experience with the rest of the team members and what mistakes have happened in the past in order to be proactive and act fast. Another important aspect of lesson learned is related to FDA feedback. It is good to keep track of what the FDA asked as additional information for the 510(k). Additional information does not have to be because of mistakes in the submission but it really depends on the reviewer and how they want the data to be presented. With that being said, the team would have all the resources needed to have a successful project and avoid past mistakes.
From my experience working on research projects in academia, I believe that ensuring the carryover of lessons learned from prior projects is crucial to increase efficiency and the likelihood of success in ongoing and future projects. The significance of this may be greater in academic research due to the high turnover rate of project members from semester to semester due to factors such as graduations, acceptance of other jobs, etc. As mentioned in a prior response, one important technique to promote the sharing of knowledge and lessons learned is to host group progress report meetings with the project manager. This technique is helpful because as a member is sharing their own progress, roadblocks, and upcoming objectives, another team member can chime in and share their personal experiences or lessons. Another important tool implemented by the project manager in the lab I work in is to require team members to document their progress and lessons learned and upload it on a shared drive. In particular, I have found the creation of shared, detailed documentations for the use of processes or software is helpful in reducing the time another team member may spend using it for the first time. For someone with experience working on projects in both academia and industry, are there distinct similarities or differences in the tools and techniques used by project managers to promote the sharing of knowledge and lessons?
Avoiding repeatable mistakes within project management teams can save time, money, and resources depending on the situation. During an internship experience I had, one measure taken to avoid repeated mistakes was to have team meetings every so often to specifically go over projects and the issues we had. We would then quickly discuss each problem and try to brainstorm potential solutions. This helped to not only resolve current issues but also teach others on the team about potential solutions if they were to have a similar dilemma. More than this, along with most assignments, my team was also required to create detailed documentation. This documentation was then sent to the entire team, as well as uploaded to a document repository. In fact, there were many occasions in which I referred to the document repository and found instructions on how to complete tasks I was struggling with, or even to understand why a particular project was done the way it was. Even from a minor internship experience, I found various project management strategies in place to help prevent repeatable mistakes, and I am curious to learn about some of the other methods in which companies try to avoid repeatable errors.
I think there is no possible way to avoid unintended mistakes, yet sharing experience and good training could minimize the possibility of the mistakes happening. Most importantly, a project manager has to train the team on how to fix common mistakes when they occur. In a lot of cases, people make mistakes because they are too stressed about making the mistake in the first place, and the fear of getting penalized. Learning how to own up to our mistakes and how to fix them is a way to reduce common mistakes. Another important part to avoid making mistakes is to assign a verifier to the task so that two people are reviewing the task to avoid making mistakes.
There is no avoiding initial mistakes in a project team. Its part of the growing pains that occur with newer teams and project managers. That being said, these failures should be incorporated into a growing list of things to watch for in a company. Project manager's should be collaborative with one another as well as the business to ensure that a mistake that has been identified in the past is made public knowledge to the teams to help avoid future mistakes. These learnings can be done in "Lunch and Learns" or explained in staff meetings to broader teams to aid in existing project managers in knowing what may be avoided in the future as well as teach younger engineers, marketers, etc. who may aspire to become product/program managers. The project manager should also know who has led certain types of products where, if they had transitioned from a project based in screws into a project based upon bone plates, would be the subject matter expert and understand their experiences and growing pains initially to evolve the team's performance.
The way I see it is “lessons learned” can only be passed down from one to another by word of mouth if not experienced. Experiencing a lesson is far more impactful on a person than just hearing a story from another. Something my uncle would always say that will stick with me is “we lived through experiences so that you won’t have to”. He is mainly referring to the mistakes that were made when our parents were our age. Every time this comes to mind, I just can’t make sense out of it. There’s no way I could get the same lesson from a life experience as someone else did just by hearing about it. Going back to the forum, I don’t think there’s a way to share your lessons learned that will have a great enough impact on someone that it will cause them to make a different decision down the line. If these lessons are shared, they may help other project managers in some way, but not every project is the same. There will always be mistakes to be made and something new to learn.
Discuss the tools and techniques that project managers can use to ensure knowledge and lessons
learned from previous projects are not lost, and can be shared for the benefit of future projects. Everything learned from previous projects, whether they were successes or failures can teach a project manager important lessons. And individual project managers usually do learn from their own previous experiences, but how can these “lessons learned” be shared with others within the project team or within the same organisation? If they are shared, how do other project managers apply the lessons to their own projects?
I think project review should be conducted; it will involve an internal review of project performance, undertaken primarily by the project team as part of the completion phase. The object will be to identify strengths and weaknesses in respect of future projects. In addition, project members should perhaps be rotated to ensure that the "lessons learned" are understood by other staffs as well and can be applied by anyone in the project team to avoid similar issues in the future.
One of the best things that project managers can do to ensure that mistakes are not repeated in projects in the future is to record everything and make sure that the rest of your team is accurately reporting things. If one has a team with relatively new people to the project management world or even team members that have not to work with one another before, it might be best for the overall project to conduct some quick refreshers to make sure everyone is on the same page. One thing that should be included in said refreshes is the standardization of taking project notes and reconciling reports. These will be crucial when it comes to the end of a project, and it's time to have an overall evaluation. The more detailed the notes and records, the easier it will be to identify shortcomings of the project and highlight the major successes for the project. Good record-keeping skills are part of one of the main skills of project management which is organization. The better organize the project, the more efficient the project will run, and the more efficient similar projects will go in the future.
Every project is a learning the experience. Nothing ever happens exactly the same. That is why it is so important for a debrief at the end of every project. A review of meeting minutes recorded throughout the project, exit interviews, etc., can all contribute to a productive debrief. In that debrief it is important to address what went well, and what did not go well. Finding areas of strength and growth are necessary at this point. This information can lead to the formation of a "playbook" for successful projects. This document can be a working document that can be adjusted and updated as necessary. That will ensure a strong foundation on any future projects, raising the floor for success every time.
After action reports are a good way to asses if the project had any pitfalls or if there are ways to optimize performance in future projects. This allows for an assessment of mistakes made and best practices for future projects. Keeping a regular account of the areas of opportunity are essential to minimize waists, lower overall expenses, delineate the best course of action for remediation for mistakes made, and most importantly allow for improved overall safety. An after action report places the pros and cons of the stages of a project in direct focus, outlining in granular detail any missteps in the planning processes, loss of productivity and provides a map to strategically eliminate any sources of error in your project design. A plethora of useful information can be gleaned from an after action report which can guide a project manager to be more proficient in his/her approach to successful projects. Depending on who performs the audit, internally or externally, may determine how much more information on the mistakes made can be gathered. External approach to an after action report opens the process to outside scrutiny however it gives the most unbiased, objective analysis of the project mistakes with constructive criticisms or feedback to eliminate similar errors on behalf of future projects.
I agree that the primary objective in a business setting or project review should be to identify strengths and weaknesses of the project. However, I believe there has to be successful translation of the strengths and weaknesses identified in a project review before a future project can be successful. A company cannot expect to successfully move forward if the information is not translated successfully to all team members or the organization risks the chance of having a repeat of the same situation or even worse, success in particular areas with a variation of failure that patterns after the first failure. In regards to the statement about rotating project members, I do not necessarily agree with that- what if there is an important project that needs to be tackled. The company has to have the foresight to understand that there is a difference in project manager and project member. specifically in the case of rotating members, I can see where that will be beneficial if it is not an important project so that the "lessons learned" is understood by all members but teaching a lesson should is not conducive when there is a time constraint and a deadline for production. Other then that I agree with the main ideas. Thank you.
This is only my second week in project management. I still feel like I "just don't know" how a project looks. I guess a practical, simple example would be nice to see. Admittedly, I feel a little lost in the forums because I don't always feel I know enough to comment.
Based on the comments I've read in this particular thread, I would like to say that I do think there is always something to be learned. In general, I find that every instance of completion will present an opportunity for reflection. What was successful? What areas are there for improvement? With my limited knowledge of project management, I do think that the projects that are encountered will often be quite varied in nature. Even as a team it might be good for each small group/ person to share their highs and lows of the project during the closing phase.
A few things come to mind that a project manager can use to ensure mistakes are not made. First, taking the time to understand the project's full scope would prevent many mistakes early on. Often, if the project's scope is not fully identified, project managers can run into conflicts and have to change the scope of the project midway. This can open up the doors for miscommunication, project delays, budget breaks, team members' frustrations, and loss of faith from stakeholders. So, taking the extra time to identify the scope and layout specific milestones in the project's initiation phase will help.
Another essential thing to do to avoid mistakes would be to learn from past projects. It's imperative to take detailed project notes during a project not only for reconciliation or auditing purposes but so that when the project reaches the last stage and its time to evaluation, areas of improvement will be more easily identified. The lesson learned at the evaluation phase of a project can help the future project go smoother by providing a base or outline for the project and also bring a team closer together by identifying certain people's strengths and weaknesses.
Mistakes can happen in all the formats of life. Especially in Project management if there is a err in the protocol, it is bound to happen. As discussed earlier, a log created or even a perfect protocol to compare with all the aspects of the project helps. Moreover the discussion of the ideas or even the mistakes help a lot if it is defined. A group meeting should be created at every timepoints such that all can discuss about the mistakes which may have occurred in the field and everyone can pinpoint it such that it does not happen again. A senior in the team or even a veteran can find out and give solutions top the errors which may be recurring again and again.
As a team, it would be self sabotage to continue to make the same mistakes over and over again. And as we have learned from Dr. Simon, a good Project Manager should have a log of what goes wrong. In my opinion, this log should be filled when the mistake or issue arises and talked about during the next meeting. This is to ensure everyone is on the same page as well as to have the team brainstorm how to fix the issue or other ways around it. Having a team means having more brains and experience to pull from. If everyone is able to lend some of their knowledge to issues that arise, the project will become more efficient as time moves on.
This is only my second week in project management. I still feel like I "just don't know" how a project looks. I guess a practical, simple example would be nice to see. Admittedly, I feel a little lost in the forums because I don't always feel I know enough to comment.
Based on the comments I've read in this particular thread, I would like to say that I do think there is always something to be learned. In general, I find that every instance of completion will present an opportunity for reflection. What was successful? What areas are there for improvement? With my limited knowledge of project management, I do think that the projects that are encountered will often be quite varied in nature. Even as a team it might be good for each small group/ person to share their highs and lows of the project during the closing phase.
Hi, @kbentleymsm-edu
If I could offer some insight from a previous class I've taken with Dr. Simon, a project is a task with a goal and a deadline (in not so many words). For context, I'm a teacher. So a project for me that is very common is any new unit that comes up. I get together with my fellow chemistry teacher and we draw up an outline of what the unit should look like. We plan how many days we spend on what as well as when our unit should be done. As a teacher there are always set backs; field trips (even virtual ones), sports, snow days, storm days, or the students are just not getting it. All of these are a part of the process; that's okay. And yes, every unit we learn something new; whether to be applied during the next unit for this particular group of students or next year. I hope this helped.
