结案前还是结案后的风险都必须事先做好风险识别、分析、制订风险管理计划和对风险加以处置等工作。而如果向前追溯的话，许多应对与规划工作必须在项目启动与计划阶段就加以完成。
1. 项目结案前：
2. 项目结案后：
以往项目执行过程中，一个常见的误区在于：项目结案会一开，所有的事情就万事大吉了。其实项目的结案只能标记着项目执行的结束，而不能说PLM项目就一定能平稳地投入到后续运行中了。系统的维护和技术支持工作是一个持续不断的过程。对一些成熟的客户，自己的队伍在项目结束时，就已经可以承担起系统正常运维的工作了，而在项目结束后，通过正常渠道延展客户方与顾问方的支持服务关系也不失为一种可行的做法。此时需要重点考虑如下问题：
1) 客户是否具备独立支持系统正常运作的能力和做系统改进调整的能力，如果没有(倘如此，一定是在前期的风险管理中已经出现问题了)，如何在短期具备这样的能力;
2) 基于已有的运行维护与支持能力，是否建立了一套行之有效的运行维护的管理过程，避免因系统未及时备份而带来的严重损失(知易行难，很多企业在这方面都有过惨痛的教训);
3) 如何保证在客户遇到涉及产品本身问题，而不是开发订制问题时，能够从原厂商处得到必要的技术支持(一个典型案例：系统在正常运行1年半后，基于成本的考虑客户没有再购买必要的技术支持服务，当他们遇到系统问题时，所需的花费要比及早购买技术支持的花费大了许多，因为它包括了系统宕机带来的实际损失)
这里有一条重要的现象需要指出：系统维护的早期正常投入，其代价通常会远比问题发生后再加以解决所带来的成本低得多。因此在项目结案后，客户的系统运维支持部门需要时刻提醒自己：未来有一天当系统发生问题时，我们的对策是什么以及如何才能把对最终用户的影响降到最低?这其实仍然是风险管理手段在项目结束后的继续应用。
结语
回到本文开头那句英文“We don’t go mountain climbing with a rope because we plan to fall, but we’d be all too grateful for the rope if we did.”。这里尝试翻译如下“我们不是因为我们打算坠入深渊而在登山时准备绳索，但在我们有过坠入深渊的体验时，会感念登山绳索对我们的莫大救助”。其实PLM项目的风险管理何尝不是我们登顶企业信息化巅峰时的救命绳索呢?