风险登记册记录尚未发生的事件。每个条目包含六个要素：事件本身、其潜在原因、可能造成的成本、发生的可能性、责任人以及正在采取的措施。一旦事件发生，它就不再是风险，而会转变为问题，并在其他地方进行跟踪。
这种界限模糊是大多数登记册失效的原因。问题被错误地记录为风险，因为登记册是唯一被审查的文档，导致列表不断膨胀。不出两个月，没人会再阅读它，因为它已变成担忧与事实混杂的记录。真正属于项目文件而非跨团队模块的内容，是那些商业敏感信息：例如供应商名称、合同罚款和内部成本敞口，这些应保留在项目文件中。
本登记册内容分为七个场景：一个场景区分风险与问题；两个场景讲解如何编写具体可操作的条目；一个场景探讨可能性和影响，以及为何沟通比评分更重要；一个场景阐述责任归属，以及为何无人负责的风险形同虚设；一个场景介绍响应类型；最后一个场景说明如何通过审查频率来保持登记册的活力。
每个项目都始于一份完整的风险登记册，但大多数在第二个报告周期后便停止维护。本模块的价值在于直接解决这种衰退现象，因为问题并非出在格式本身。
“如果供应商错过集成日期，测试将延误三周。” 这清晰地呈现了原因、事件和后果。那些充斥着“资源”等单一词汇主题的登记册，因无法采取行动而逐渐被忽视。
由“工程部”负责的风险，实际上无人负责。明确指定个人责任，才能促使更新在审查前完成，而非在审查过程中仓促进行。
关闭不再适用的风险，是保持登记册可信度的关键。一个只增不减的列表，只会表明其中没有任何内容正在被有效管理。
单独的风险会议往往最先被取消。将十分钟的风险审查附加到已有的会议中，是唯一能在繁忙月份中持续进行的节奏。
上传您的PMO指南、团队使用的风险登记册模板，或上次项目的经验教训日志。支持PDF、DOC、DOCX、PPTX和TXT格式，文件大小上限为200 MB。草稿将逐场景编辑，原始文件不会被修改。
内部已发布的PMO指南已包含所需内容；请在下一个项目启动前调整草稿。
