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).

Define the tracking progress for an object oriented project?

For a object oriented project, tracking becomes really difficult and establishing some meaningful milestones is also a difficult task as there are many things that are happening at once. For tracking an object oriented project, following milestones are considered to be completed when the below mentioned criteria are met:

Milestone for Object Oriented Analysis is considered completed when the following conditions are satisfied :
- Every class is defined and reviewed.
- Every class hierarchy are defined and reviewed.
- Class attributes are defined and reviewed.
- Class operations are defined and reviewed.
- Classes that are reused are noted.
- The relationships among classes are defined and reviewed.
- Behavioral model is created and reviewed.

Milestone for Object Oriented Design is considered completed when the following conditions are satisfied :
- Subsystems are defined and reviewed.
- Classes are allocated to sub systems.
- Classes allocated are reviewed.
- Tasks are allocated.
- Task allocated are reviewed.
- Design classes are created.
- These design classes are reviewed.
- Responsibilities are identified.
- Collaborations are identified.

Milestone for Object Oriented Programming is considered completed when the following conditions are satisfied :
- Classes from design model are implemented in code.
- Extracted classes are implemented.
- A prototype is built.

Milestone for Object Oriented Testing is considered completed when the following conditions are satisfied :
Debugging and testing occur in concert with one another. The status of debugging is often assessed by considering the type and number of bugs.
- The correctness of object oriented analysis and design model is reviewed.
- The completeness of object oriented analysis and design model is reviewed.
- Collaboration between class and responsibility is developed and reviewed.
- Test cases designed are conducted for each class.
- Class level tests are conducted for each class.
- Cluster testing is completed and classes are integrated.
- Tests related to system testing are established and completed.

Each of the milestone is revisited as object oriented process model is iterative in nature.

How important is the job of issue tracking for a Project / Program Manager ?

In the course of work, I have had several interviews, and also interviewed a number of people, mainly for the post of project manager or program manager. One of the most significant questions that is posed is about the SDLC, and whether people understand what the Software Development Life Cycle is all about.
For me, the life blood of a project (and the issue that can cause the most harm to a project) is about effectively tracking the open issues that happen in a project. You know them, right ? You have a project where there are a lot of open ends, a lot of design and architectural meetings where questions are posed and answered, and then these are not captured in some sort of minutes. Or you have an important new concept, and there are a lot of questions, and then a few months later, you find that that the same questions are again being asked, and people have to scramble to answer these questions. Further, if it turns out that some people in the group have changed, then new people have to answer these questions, and there may be changes that may happen in the specs or design because of these questions. Consider an example, where a design is done in a specific manner (and not in the blatantly obvious way) because of some limitations. Later, when a design review is done, you can be sure that the same question would be asked (and this could happen months later), and then, there are no easy answers to these questions.
Now consider the case where you presented a design concept, there were some important queries that were raised, and then, in the excitement, nobody captured these queries (or there were queries regarding some part of the schedule, or about some follow up with a vendor or even the customer), and nobody followed up to get these queries answered; it is only later that it is realized that these were important questions, and the lack of follow up meant that some problems that were detected via the queries were never really caught.
So, how do you solve this ? For a Project Manager or a Program Manager, it is critical that the tracking of open issues and queries be set as an ongoing process, and that there are no failures in this area. For this purpose, whatever tool, whatever process, all these need to be decided and set in stone. For example, I know people who have bought issue tracking tools, other use Excel or even a notebook to capture important issues, still others use flagging inside Outlook to track open items. And people set aside dedicated time to look at their issues and follow these up.