Taking the Fuzziness Out of Risk Management

How frequently does your project identify risks that are generalized across the project or program? I see this all the time. I work to mitigate an avoid these generalized risks, and I don't really know if there is any benefit to actually performing this work. For example, I have the following risk:

Closing Requirements
It is important that the requirements are closed on time according to the project plan. Otherwise, the Development Team does not have enough time to implement all the requirements. During the development of Release 2.1, the Role Flexibility requirement discussions extended over a month beyond the closure of the other requirements.

This is a generic, or general risk, not localized to any specific element. In fact, it is a process risk that is telling us that we must be more vigilant about guarding the process.

I use my SharePoint site as the primary mechanism for identifying and monitoring risks. And I have several of these general risks that are not as specific about what needs to be done. To fix this aspect, I am changing my Risk Identification Form to include a section that will allow for references to specific Work Packages in the Project Plan. In this approach I am more closely modeling my Risk ID form from the USDA Risk ID form.

I think that identifying specific work packages impacted by the risk and estimating the best, worst and most likely cases will provide the best opportunity to get out of this fuzzy, 'We have a risk' situation and into a more meaningful discussion that will have real results for my projects. I'll let you know how it goes.