Risk Register, a lighter version?

“You will never understand bureaucracies until you understand that for bureaucrats procedure is everything and outcomes are nothing.”

Risks can be viewed as the bridge between the past and the future. They exist just for some unresolved problems inherited by previous situations, which are confirmed in the choices descripted in the Business Case.

The temptation of cancelling those sources by changing the labels, from risk to opportunities, reduces the organization’s capacity to deal with any factor that can hamper the outcome.

Cost/Benefits (brief) analysis

Like any other projects (by) products, the Risk Registry has its own costs that have to be justified. Once the concept of having a common repository (based on CMS) has been accepted (and there are many reasons for this – some of them are discussed in previous posts), the maintenance of this “branch” consists mainly in the update of the situation either operational or strategical. While a good margin of informality helps for catching all information at any level, the entries need to be consolidated in dedicated meetings, this to avoid the danger of leaning on too specific (sometimes interested) evaluations.

From this viewpoint, the cost of general updating is computed in the scheduled meetings (that can be held using web 2.0 tools like wiki – as described in the Delphi method).

The costs of specific updates, which come from the Impact Analysis, can be charged on the single Change Management process.

The benefit offered by the Risk Registry is implicit in the nature of the risk itself. Without any previous reference (history) it is almost impossible to evaluate neither the next trend (proximity) nor the amount of the impact on the outcome.

The need for a complete Risk Register

In the new version of Prince2, there is a full description of this Register. It will be presented in the next post; however, it is important to discuss the value of collecting and making available all these information.

The advantage of the “full description” is confirmed by the possibility of building different queries that can answer to most of the stakeholders’ needs. They can span from proximity to the required financial coverage. With a small investment of a skilled DBA, profiling the system offers the possibility of more meaningful queries and allows defending a bit of “privacy”.

Are different (lighter) versions possible?

In her post, Terri collects some ideas coming from “Risk Symposium”. There is the suggestion about a “less expensive” version of the Risk Register. This idea can be enticing from some viewpoints; however, the correct profiling could answer all these instances without compromising the efficiency of the whole system.

Conclusion

People without specific experience in project management (see Project Smart post) tend to consider any structure destined to manage the project information as a form of bureaucracy. Something that can be minimized if not avoided for a temporary organization that shall produce a unique outcome. Moreover, the idea of speaking about risks can be perceived as a crime (see post ).

If the costs of missing the targets are untenable for the company, the resources invested in preventing the risks and exploiting opportunities become a fruitful investment.

More readings

http://blog.sealightllc.com/?p=576