Project risks can lead to product risks and vice versa. So the risks for a project should be kept together in one central risk management system, which could be an excel sheet or a more advanced tool. Also a findings registration tool could be used to do this, or a requirements management tool. Then the risks should be assigned to a monitor who is responsible for the management of that particular risk for which of course the final responsibility lies in the hands of the project manager. In this risk management system per risk it could be indicated what kind of risk it is, e.g. project risk, product risk etc.
As we said earlier: risk management starts at the very beginning of the project and only stops after the project has finished. The list of risks is updated continuously and is evaluated continuously together with the stakeholders and product specialists. There are various techniques to do the communication with the stakeholders, like interviews, risk analysis sessions (meetings with all the stakeholders), or just simple emails or phone calls. Most important about risk management is the involvement of the stakeholders, for acceptance of the product and the various parts of the development process.
Beside identification of the various risks it is also important to identify and communicate the measures to be taken to avoid or resolve the risks. So these solutions must also be communicated and discussed with the stakeholders.
The project manager is responsible for the whole project so he must identify who has to do what to address the risks. The risks have to be addressed in all the phases of the project, in all the disciplines involved: analysis, realization and testing. In the risk management system beside the risks also the measure have to be registered plus who must execute the measures.
All disciplines involved can use the models that are created for the project, by analysts (e.g. architects, test analysts). All parties involved should review these models to make sure that everybody speaks the same language, is talking about the same functionality. Especially in off shoring projects this is important. The models are important for communication.
This article is one chapter of the book "Q-Course Quality & Organization", a book for Quality Education. See www.q-course.com.