Risk planning is a critical part of any project / program manager's job. Anytime during the course of a development cycle, the project may be exposed to a number of risks. If the team has not done as well a job of risk planning as it should have, they can land in a very unpleasant condition; and even if they do got help, the first question that anybody would fire at the manager would be about not properly anticipating these kind of problems and being ready for such problems as they occur.
So what can you do in terms of risk planning even before a project has started, and then continue doing through the course of a project ? There will be always be new risks or problems that will arise during the course of a project that have not happened previously or did not have the same gravity earlier, but there will always be risks that could have been anticipated in advance. And this is where a good project / program manager can excel, in terms of doing a good job at risk planning.
So what does this mean ? Well, the simplest case is if you are working on a new version of a product where there have been earlier versions. In such cases, if you have been around for previous versions, you typically have a good idea of what the risks are like and also know some ways of handling such risks. For example, you know the time period in which defects tend to peak, you know the time periods in which resourcing can become an issue, you know about components that you integrate which can cause the maximum damage to your schedule because they are either late or of bad quality. With all these, you can start to prepare such a list of problem areas.
Typically, risk planning is not something that comes of age in one version. What is required is to ensure that all problems and issues that you face in the previous version of the product have been recorded in some way, along with a note about the critical nature of the issue and the time period in which such an issue came out. With these as an input, an experience project / program manager can figure out which of these issues can become risks in the current versions of the product, and plan accordingly. If issues are not recorded, then you lose out some part of doing an effective risk planning for future versions of the product or project.
It is also necessary to find out more areas of risks that you would not know. There are risks that come to other people in the team, typically to the development or quality teams, which are known by their managers. For example, once we ran into a huge problem due to a different version of Visual Studio that we needed to upgrade to, and one of our components had a consistency problem with that version. This was something that our development managers knew would happen every other version, but we did not know from the project/program management side. It turned out to be a huge risk for the project, with the potential to need cutting out an important feature or add some more weeks to the schedule, and that did cause problems since it was not there in the list of risks, and yet was an old risk.
So what can you do in terms of risk planning even before a project has started, and then continue doing through the course of a project ? There will be always be new risks or problems that will arise during the course of a project that have not happened previously or did not have the same gravity earlier, but there will always be risks that could have been anticipated in advance. And this is where a good project / program manager can excel, in terms of doing a good job at risk planning.
So what does this mean ? Well, the simplest case is if you are working on a new version of a product where there have been earlier versions. In such cases, if you have been around for previous versions, you typically have a good idea of what the risks are like and also know some ways of handling such risks. For example, you know the time period in which defects tend to peak, you know the time periods in which resourcing can become an issue, you know about components that you integrate which can cause the maximum damage to your schedule because they are either late or of bad quality. With all these, you can start to prepare such a list of problem areas.
Typically, risk planning is not something that comes of age in one version. What is required is to ensure that all problems and issues that you face in the previous version of the product have been recorded in some way, along with a note about the critical nature of the issue and the time period in which such an issue came out. With these as an input, an experience project / program manager can figure out which of these issues can become risks in the current versions of the product, and plan accordingly. If issues are not recorded, then you lose out some part of doing an effective risk planning for future versions of the product or project.
It is also necessary to find out more areas of risks that you would not know. There are risks that come to other people in the team, typically to the development or quality teams, which are known by their managers. For example, once we ran into a huge problem due to a different version of Visual Studio that we needed to upgrade to, and one of our components had a consistency problem with that version. This was something that our development managers knew would happen every other version, but we did not know from the project/program management side. It turned out to be a huge risk for the project, with the potential to need cutting out an important feature or add some more weeks to the schedule, and that did cause problems since it was not there in the list of risks, and yet was an old risk.
No comments:
Post a Comment