Reviewing the Risk Register periodically and reassessing the risks as more information is known will help. Some groups may review weekly or every two weeks. The frequency should be set in the risk plan.
Then Risk audits can be performed to review how well the mitigation plan worked when the risk occurred. This will give useful information to be used for future projects.
And finally a lessons learned document at the end of the project will document what went wrong and what went right.
Do not document your risks once and walk away. This needs to be a living document that is active for the entire project. Saving Changes...
R = Responsible (One person is responsible)
A = Accountable (Team can be accountable)
C = Consulted (Leadership/Stakeholders can be consulted)
I = Informed (Customer can be informed)
as per ITIL Process.
also PMI tools like Expert Judgement, Review and Living Documents will be a great help for any post project completion issues.
Capture the Risk in the Risk Register with the complete mitigation plan / action taken to mitigate the risk and this can be maintained in the repository for future reference. Saving Changes...
Decisions are the "D" in a RAID log. While it might not prevent impacts of short-sighted decision making, capturing key decisions with some context and who made the decision can at least provide some history to educate us moving forward...
Dinah is correct. Too many time we find that artifact like risk registers and lessons learned are created and then filed. It is part of the PRB, or steering committee responsibility to ensure accountability. The risk register, irrespective of format, must be reviewed at each PRB or steering committee meeting. Saving Changes...
Ensure that your risk register tracks the actual decision made regarding the risk. Other tools can help as well like an issues/actions log, RACI/RASCI diagrams, meeting minutes that state decisions made, etc. Saving Changes...
I would say setting up team meetings as well as separate meetings with all stake holders involved periodically would be ideal. This will allow open communication, transparency, and clarified expectations to be discussed at certain points of the projects.
This would fall back in to your planning phase which is ok to go back to if need be. Usually project processes tend to bounce between planning, execution, and monitoring phases every so often or on a need be basis.
During your planning have you set milestones? If you know where you're currently at in your project, diagnose what area of the planning the issue falls and re-evaluate a clear stance to discuss for the project to get back on course.
It also seems from what you describe that there's not so much leadership or proper managing which is why the information in process gets lost before it can start. Divide teams with your best to lead the core essentials of the project and others to pickup the slack where extra room lies for talented hands.
Communication is 90% of PM work. When's the last time stakeholders were involved in a conversation or your team had a meeting discussing specific objectives?
Just my opinion.
To be honest, I am very new to the foundation of knowledge with PM work and as I continue to study, I like to share my feedback to also help me get an idea or scope that I am understanding what I learn too. So in my opinion, the above answer is also a learning experience for me in helping me get a better sense of things putting myself in your shoes. Saving Changes...