Project Management - Writing down the issues as they come to you ..

One of the most difficult items that would come up during my experience as a project manager was about collating issues for later use. For example, there could be an issue with a team member in terms of their productivity, or issues with a vendor about their quality standard, or even responsiveness to an email sent for a query, and so on. There are numerous items that pop up like this during the course of a project, and the project manager has to resolve then on an ongoing basis. This is the typical life of a project manager.
However, I found that even though these items were resolved on a regular basis, the lack of capturing them in a detailed way made things difficult later. One of the prime examples of this was about interaction with an external team. We went through a post-mortem with the team, after a cycle where the external team had caused us some amount of grief. There were deliveries that were not on schedule, the quality level of one of the deliveries was bad enough that the delivery was rejected (although to get to the point of rejection took a couple of testers a period of around 2 days, and we did not really want to spend this kind of time period for this delivery of an external component).
Similarly, at the end of the cycle (and sometimes during the period of the cycle) there would be the need for feedback on team members, typically other managers, based on the cycle and the quality of their work. However, in all these cases, there were problems. When you are going through a busy cycle, how often do you really remember what happened in specific instances; and there is a lot of feedback that you should not look too much in the past but look towards the future.
So what would you do ? I would typically keep a specific file that would list issues where I thought some later feedback is required or where I felt that the person to whom I was corresponding could have dealt with issues better and I kept the same file in a special folder, and also kept copies of the relevant emails on this subject in the same folder detail.
Not only did this help in driving specific issues through later post-mortem, but even for my study, where I was discussing these sort of issues to drive process changes or improvements, it would really help that I could recall specific issues, the conclusions, my feedback on whether there were specific improvements that could be made, and also had email to even correct people if they pointed out something that was different from what had actually happened (and you would not believe how many times something like this had actually happened).

Working on items in your status report that are critical and moving them to a green status

For a good Project manager or Program Manager, maintaining the status of the project is one of the most critical items that they need to do. The status of the project is a dashboard that reflects on the status of the various risks and issues that may be faced by the project, and which can cause delay or otherwise imperil the schedule of the project.
For any project, there are a large number of items that can cause problems to the schedule of the project, but not all of them are problematic at the same time. A risk or issue may be small or minimal at some point in the project and be much more significant at another stage of the project, and it is upto the project manager to have the current status of the project in hand at all stages of the project.
So, you have a situation where the project manager already has a listing of all the major items or issues that can cause a risk to the project and is also on the lookout for more such issues that could cause risk, and it is very important that the project manager highlights the risks that are significant at this point of time and brings them up to the attention of the management team of the product.
But it is not just the highlighting of the risks that is a primary job of the project manager. The project manager is not just somebody who reports the issues and risks of the project, but also takes the lead in trying to solve the risks / issues. For this purpose, the project manager needs to have a good understanding of the risks / issues and work with the relevant people for understanding how the risk needs to be mitigated. This needs to be followed by actually working out the mitigation plan (and if these are known risks or issues that were known even before they were actually a risk, then the mitigation plan would already be known) and ensuring that the mitigation plan is as per the actual risk, since even for a known issue, the actual mitigation plan depends on the exact scenario in which the problem occurred.
In some cases, the mitigation plan does not depend on only the team but may need help from outside the team. For example, there may be a situation where the team is behind in the schedule and needs more people helping out the team, and this cannot be solved by the team; the similar is the case when there is a dependency which needs a resolution from outside the team. In such cases, the project manager should bring this plan to the management team of the product where it can even be escalated to outside the team and to senior management if required. It is the responsibility of the project manager to drive this process and reach a point where the plan has helped in reducing the critical status items of the project to less than critical where they can then be managed to become a normal problem.