The Close Project or Phase process also establishes the procedures to investigate and document the reasons for actions taken if a project is terminated before completion. In order to successfully achieve this, the project manager needs to engage all the proper stakeholders in the process. My preferred way to do this is by questionnaire and survey. And “no”, questionnaire and survey don’t mean the same thing. The questionnaire is the question and answer sheet, and a survey is a tool for analyzing the results.
The project charter documents the project success criteria, the approval requirements, and who will sign off on the project. My tip is, specify the “office” rather than the person. For example, “This document to be approved by the area Financial Controller”, rather than, “This document must be approved by Efrem Zimbalist Jr”, because, in a number of months’ time, Efrem may have left, changed position or gone on leave. As I mentioned earlier, the problem with common sense on projects is that it isn’t very common.
People are worried that they may be replaced one day by Artificial Intelligence and Machine learning when the truth of the matter is that a few of them could be replaced by a few lines of code.
The risk report provides information on the risk status and is used to check that there are no open risks at the end of the project
Project documents are used on the project but are not considered part of the Project management plan. They could include:
Assumption log. This records all the assumptions and constraints that guided the technical specifications, estimates, schedule, risks, etc. Assumptions are what you believe to be true for the duration of the project, and constraints are what you believed to be limiting your ability to manage the project. I guess now is the times to find out if you were right. My advice is to maintain a record of the source for you believe in these assumptions and constraints because it the project has gone badly, and the blame-game starts, the blame-game will start with the assumptions and constraints – then the risk register, and move on to the Basis of estimates. These documents will be your first line of defense.
But… of the records indicate you are to blame for the failure – shredding the records is not an option 😀
The basis of estimates. The basis of estimates is used to evaluate how the estimation of duration, cost, resources, and cost control compared to the actual results. The same note as for assumptions and constraints. Keep a careful record of where these came from.
Changelog. This records the status of all change requests throughout click this link now the project or phase. You should have been doing a regular audit of this.
Lessons learned register. The team will have been recording lessons learned throughout the project, and so this is really a final edit to remove all the e problem, recorded by ten different people, or ten versions of the same problem, recorded by the same person, who has some “issues”, to make it suitable for transferring to the lessons learned repository.
Quality control measurements. The quality control measurements document the results of Control Quality activities and demonstrate compliance with the quality requirements.
Quality reports
The information presented in the quality report may include all quality assurance issues managed or escalated by the team, recommendations for improvement, and the summary of findings from the Control Quality process.
Accepted deliverables may include approved product specifications, delivery receipts, and work performance documents. Partial or interim deliverables may also be included for phased or canceled projects.
