定期会议/沟通/通报等方式)就成了极为重要的工作了。这样可以通过组织的行为去避免个人行为中的薄弱环节，实现组织优势与个人优势的恰当结合，并以组织行为去督促项目管理层能持续不断地对项目各种风险进行有效的管理。
PLM项目结案：
项目结案通常会带来一种错觉，似乎只要能把结案会一开，客户方和项目实施顾问方一切就都万事大吉了。但真正做过项目的项目经理都知道，项目结案其实是项目最危险的阶段：此时所有的系统内容都已经展示给最终用户，而此阶段产生的问题更需要以尽可能快的速度予以响应或解决。但此时无论在时间上还是经费上留给项目组的空间已经非常有限。
围绕项目结案的工作需要考虑结案前系统上线过程的风险，还需要考虑项目结案后系统运行维护期间可能遇到的风险。但无论是结案前还是结案后的风险都必须事先做好风险识别、分析、制订风险管理计划和对风险加以处置等工作。而如果向前追溯的话，许多应对与规划工作必须在项目启动与计划阶段就加以完成。
1. 项目结案前：
项目结案前的系统上线工作是项目能否成功的重点：处置不当，会导致项目发生严重的拖期乃至于项目的失败。此时需要重点考虑：
1) 对应既定方案的系统是否与企业的实际业务过程关联在一起，如果没有，项目组应对的策略是什么？
2) 相关的历史数据准备工作是否完成以及所准备数据的正确性是否通过恰当的评估; 3) 正式生产服务器是否已经准备就绪，并经过必要的性能调优;
4) 是否建立起系统切换的领导机构和问题处理处理机制并经过项目高层管理机构的批准;
5) 如何安排对最终用户进行必要的培训，如何对培训效果进行必要的考核;
6) 如何对用户验证测试过程中发现的问题制订必须的处置策略;
7) 正式系统上线是否经过反复的预演，并根据预演的结果拟订最终确认无误、切实可行的上线切换计划;
8) 预留的系统切换时间是否足够(对涉及需向ERP系统发数据的情况，此条尤为重要);
9) 在发生不可预见的问题时，项目组的备份方案是什么。
2. 项目结案后：
以往项目执行过程中，一个常见的误区在于：项目结案会一开，所有的事情就万事大吉了。其实项目的结案只能标记着项目执行的结束，而不能说PLM项目就一定能平稳地投入到后续运行中了。系统的维护和技术支持工作是一个持续不断的过程。对一些成熟的客户，自己的队伍在项目结束时，就已经可以承担起系统正常运维的工作了，而在项目结束后，通过正常渠道延展客户方与顾问方的支持服务关系也不失为一种可行的做法。此时需要重点考虑如下问题：
1) 客户是否具备独立支持系统正常运作的能力和做系统改进调整的能力，如果没有(倘如此，一定是在前期的风险管理中已经出现问题了)，如何在短期具备这样的能力;
2) 基于已有的运行维护与支持能力，是否建立了一套行之有效的运行维护的管理过程，避免因系统未及时备份而带来的严重损失(知易行难，很多企业在这方面都有过惨痛的教训);
3) 如何保证在客户遇到涉及产品本身问题，而不是开发订制问题时，能够从原厂商处得到必要的技术支持(一个典型案例：系统在正常运行1年半后，基于成本的考虑客户没有再购买必要的技术支持服务，当他们遇到系统问题时，所需的花费要比及早购买技术支持的花费大了许多，因为它包括了系统宕机带来的实际损失)
这里有一条重要的现象需要指出：系统维护的早期正常投入，其代价通常会远比问题发生后再加以解决所带来的成本低得多。因此在项目结案后，客户的系统运维支持部门需要时刻提醒自己：未来有一天当系统发生问题时，我们的对策是什么以及如何才能把对最终用户的影响降到最低?这其实仍然是风险管理手段在项目结束后的继续应用。
项目实施的过程是一个逐步完善的过程。这样的事实注定PM在项目实施过程中将面临一个充满未知因素的环境，因此，PLM项目的项目经理尤其应该重视沟通与协调对于项目成败的意义。每个实施PLM的企业因其所在的行业和产品不同，其系统实施策略和侧重点也各不相同，这决定了每个PLM项目都具有各自独特的特点。