A project / program manager (from this point on, I will use the term Project Manager only for ease of writing, with the roles being similar in some respects) has many responsibilities as part of a software project, with a full detailing of such responsibilities being much beyond the scope of a single article. This article focuses more on the responsibilities of the project manager being the repository of a lot of experience related to risks ongoing in a project, and the advantages that come from being able to quickly recognize a risk and figuring out how best to alleviate it.
If you are a project manager, you would know this situation to happen often enough. There is a problem that starts to appear in a project, and you are able to draw upon your experience in this project or in similar projects, and as a result, you are able to take on the required actions that would ensure that the risk is contained (or quickly highlighted, if that be the need). Not all risk histories or course of action can be carried in a risk index, and the action that is taken by a project manager is based on his/her own set of thoughts and principles, so there is no one size fits all kind of next steps.
Typically, once you see a situation developing in a project, you will have some idea about whether the situation developing can quickly reach critical size, or is a small enough contained risk that does not need too much attention at this point. For example, I remember a recent case where a component vendor reported some issues in terms of test reports from their end of the component, and there was history already there in the mind of senior team members about a similar case from 2 years back. At that time, a reading of the situation seemed that there was not a problem, and it quickly caught fire until we spent the better part of week dousing the flames, repairing our burnt behinds, and learning from such an experience.
Once we saw the trend of such a situation, we quickly arranged a quick call with the vendor, figured out the problem area, and learnt that the vendor was under-stating the problem. If we had included this new version of the component with our product during the development phase, around 5% of our testing base (including external vendors) would have lost their data. The last time this happened, we had senior management being called in by some of the more irate external testers, and the inclination to minimize the recurrence of this issue was quickly minimized, and we got the situation in control within a short period of time.
Now, this was a problem. Out of the senior members of the team, we had lost 2 out of the 5 members due to attrition, and the new members did not have the history of this situation, and this was not an easy matter to capture in the database that we used to capture risks. We were lucky that we were involved with the same project, and hence knew the history of this problem and were able to quickly devise a solution that would prevent the worst impact of such a problem. This was why I wrote about how having a history of the project can enable quick and correct reactions to problems (there are some problems of course when you have the same person in the same project for a long time). With attrition, some valuable experience can be lost, and can lead to situations where the team has to spend more time reacting to problems that would be clearer with historical backgrounds.
If you are a project manager, you would know this situation to happen often enough. There is a problem that starts to appear in a project, and you are able to draw upon your experience in this project or in similar projects, and as a result, you are able to take on the required actions that would ensure that the risk is contained (or quickly highlighted, if that be the need). Not all risk histories or course of action can be carried in a risk index, and the action that is taken by a project manager is based on his/her own set of thoughts and principles, so there is no one size fits all kind of next steps.
Typically, once you see a situation developing in a project, you will have some idea about whether the situation developing can quickly reach critical size, or is a small enough contained risk that does not need too much attention at this point. For example, I remember a recent case where a component vendor reported some issues in terms of test reports from their end of the component, and there was history already there in the mind of senior team members about a similar case from 2 years back. At that time, a reading of the situation seemed that there was not a problem, and it quickly caught fire until we spent the better part of week dousing the flames, repairing our burnt behinds, and learning from such an experience.
Once we saw the trend of such a situation, we quickly arranged a quick call with the vendor, figured out the problem area, and learnt that the vendor was under-stating the problem. If we had included this new version of the component with our product during the development phase, around 5% of our testing base (including external vendors) would have lost their data. The last time this happened, we had senior management being called in by some of the more irate external testers, and the inclination to minimize the recurrence of this issue was quickly minimized, and we got the situation in control within a short period of time.
Now, this was a problem. Out of the senior members of the team, we had lost 2 out of the 5 members due to attrition, and the new members did not have the history of this situation, and this was not an easy matter to capture in the database that we used to capture risks. We were lucky that we were involved with the same project, and hence knew the history of this problem and were able to quickly devise a solution that would prevent the worst impact of such a problem. This was why I wrote about how having a history of the project can enable quick and correct reactions to problems (there are some problems of course when you have the same person in the same project for a long time). With attrition, some valuable experience can be lost, and can lead to situations where the team has to spend more time reacting to problems that would be clearer with historical backgrounds.
