PLM项目执行与控制阶段 非知之艰,行之维艰

 

在项目启动阶段，对项目风险进行了识别分析;以此为基础，项目规划阶段制订了项目风险管理计划，从理论上讲，项目在执行与控制阶段，只要严格按照项目风险管理计划来开展工作就应该取得令人满意的结果。但在项目实际运作过程中，这恰恰是最容易出问题的阶段。究其原因可以总结如下：

1) 项目执行是一个动态的过程，一些原本存在的风险可能会随着其存在基础的消失而湮灭;一些原本低优先级别的风险会因其发生的可能性或带来影响的变化而变成高优先级别的风险;一些原本不存在的风险也会随之而产生。这无疑加大了风险管理的难度;

2) 项目管理组在项目执行过程中通常会陷入到项目日常管理的琐碎工作中。项目执行过程已经把项目经理折磨得苦不堪言，项目经理纵有控制未来风险的强烈愿望，无奈项目执行自身的压力导致其必须先着手眼前的项目布局，至于未来项目中潜在的风险，权且不闻/不问才好。当然项目经理还是会经常想想未来潜在的风险的，但应对策略是且等风险变成问题找上门再说;

3) 在风险处置过程中，由于原来风险管理计划中具体风险应对策略的欠缺，导致风险处置不力。而此时如果项目组得不到有力的支持与协助，则给项目管理层带来风险管理的严重挫折感。故此项目管理层难以再投时间和精力在项目风险的管理上。

凡此种种，无不是执行层面风险管理“知易行难”的具体体现，其造成的结果自然是项目管理计划束之高阁。事前风险管理又变化为事后亡羊补牢式的管理。而这又导致客户和实施顾问团队双方都不得不投入更多的时间、人力、物力和财力去化解危机，最终导致事倍功半的消极结果。

解决“知易行难”问题的最好办法其实也是最简单的办法，其实就是采用RISK LOG的方式(也叫RISK REGISTER)对所有已确认的风险进行记录，并定期给出分析从而确定各风险的优先级别，然后对每个风险条目给出建议的处置计划、负责人员、希望解决的完成时间。同时对识别出的新的风险及时记录在案，而对可以关闭的风险，则标记其为“已关闭”、同时给出关闭的确切时间和风险关闭的确认人。

需要指出的是：任何项目成员包括项目经理，在多项任务缠身，必须在任务之间进行取舍时，往往主要精力会关注已经火烧眉毛需要迫切解决的问题，而对于未来才可能发生的风险，会倾向于采用绕过去走捷径的做法。而这势必造成未来有更多紧迫的问题需要解决。

其实这种关注眼前任务的做法是人们在压力面前采取的非常自然的一种应对策略。尽管不是项目风险管理中期待看到的做法，但却是大多数人的天性。这一天性尽管无可后非，但在项目风险管理过程中，项目管理层应该予以充分的认识，并在此基础上对其进行有效的规避。为此，从项目组织的角度建立日常规范的项目风险管理机制(定期会议/沟通/通报等方式)就成了极为重要的工作了。这样可以通过组织的行为去避免个人行为中的薄弱环节，实现组织优势与个人优势的恰当结合，并以组织行为去督促项目管理层能持续不断地对项目各种风险进行有效的管理。

PLM项目结案-“行百里者半九十”

项目结案通常会带来一种错觉，似乎只要能把结案会一开，客户方和项目实施顾问方一切就都万事大吉了。但真正做过项目的项目经理都知道，项目结案其实是项目最危险的阶段：此时所有的系统内容都已经展示给最终用户，而此阶段产生的问题更需要以尽可能快的速度予以响应或解决。但此时无论在时间上还是经费上留给项目组的空间已经非常有限。

围绕项目结案的工作需要考虑结案前系统上线过程的风险，还需要考虑项目结案后系统运行维护期间可能遇到的风险。但无论是结案前还是结案后的风险都必须事先做好风险识别、分析、制订风险管理计划和对风险加以处置等工作。而如果向前追溯的话，许多应对与规划工作必须在项目启动与计划阶段就加以完成。

1. 项目结案前：

项目结案前的系统上线工作是项目能否成功的重点：处置不当，会导致项目发生严重的拖期乃至于项目的失败。此时需要重点考虑：

1) 对应既定方案的系统是否与企业的实际业务过程关联在一起，如果没有，项目组应对的策略是什么;

2) 相关的历史数据准备工作是否完成以及所准备数据的正确性是否通过恰当的评估;

3) 正式生产服务器是否已经准备就绪，并经过必要的性能调优;

4) 是否建立起系统切换的领导机构和问题处理处理机制并经过项目高层管理机构的批准;

5) 如何安排对最终用户进行必要的培训，如何对培训效果进行必要的考核;

6) 如何对用户验证测试过程中发现的问题制订必须的处置策略;

7) 正式系统上线是否经过反复的预演，并根据预演的结果拟订最终确认无误、切实可行的上线切换计划;

8) 预留的系统切换时间是否足够(对涉及需向ERP系统发数据的情况，此条尤为重要);

9) 在发生不可预见的问题时，项目组的备份方案是什么

　2. 项目结案后：

以往项目执行过程中，一个常见的误区在于：项目结案会一开，所有的事情就万事大吉了。其实项目的结案只能标记着项目执行的结束，而不能说PLM项目就一定能平稳地投入到后续运行中了。系统的维护和技术支持工作是一个持续不断的过程。对一些成熟的客户，自己的队伍在项目结束时，就已经可以承担起系统正常运维的工作了，而在项目结束后，通过正常渠道延展客户方与顾问方的支持服务关系也不失为一种可行的做法。此时需要重点考虑如下问题：

1) 客户是否具备独立支持系统正常运作的能力和做系统改进调整的能力，如果没有(倘如此，一定是在前期的风险管理中已经出现问题了)，如何在短期具备这样的能力;

2) 基于已有的运行维护与支持能力，是否建立了一套行之有效的运行维护的管理过程，避免因系统未及时备份而带来的严重损失(知易行难，很多企业在这方面都有过惨痛的教训);

3) 如何保证在客户遇到涉及产品本身问题，而不是开发订制问题时，能够从原厂商处得到必要的技术支持(一个典型案例：系统在正常运行1年半后，基于成本的考虑客户没有再购买必要的技术支持服务，当他们遇到系统问题时，所需的花费要比及早购买技术支持的花费大了许多，因为它包括了系统宕机带来的实际损失)

这里有一条重要的现象需要指出：系统维护的早期正常投入，其代价通常会远比问题发生后再加以解决所带来的成本低得多。因此在项目结案后，客户的系统运维支持部门需要时刻提醒自己：未来有一天当系统发生问题时，我们的对策是什么以及如何才能把对最终用户的影响降到最低?这其实仍然是风险管理手段在项目结束后的继续应用。