4、执行阶段（Execution Stage）
  “执行”就是项目组按照项目计划中的安排积极地工作。PM在这个阶段主要工作是监控工作结果及其质量，并与项目计划进行对照，寻找和纠正偏差。如果一个项目在“规划阶段”工作开展地足够细致，团队成员对于自己的任务和职责比较清楚的话，那么在“执行阶段”PM的工作不会很多，开会的次数也相应地减少。对于PLM项目的执行阶段，PM应该注意抓好以下几件事：

  4.1、加强综合变更控制
  由于这样或那样的原因，“执行过程”中的工作结果与计划进行对比时难免会出现一些偏差。小的偏差可以通过调整工作顺序、适当加班等方式完成；如果偏差比较大，则可能需要对总体进度甚至《系统设计》文档进行更改。对于这些更改，应该遵守的几点原则是：
  (a)尽最大努力保持关键里程碑时间点的相对稳定；
  (b)尽量避免对方案主体部分的更改。随着时间推移，改动越大对整个项目的影响越大；
  (c)更改应该与系统提供的客户化框架、开发逻辑相符合。避免改动系统的底层架构。
  因为这样的改动一方面影响系统的稳定性，另一方面在未来系统版本升级时，这些更改将成为潜在的风险。
   

  特别值得一提的是：PM应设法说服客户处理好整体业务需求和对系统IT特征的追求之间的关系。很多PM会有这样的体会：PLM项目最花费时间的不是那些用于满足主体业务功能而进行的开发、配置工作，而是那些系统本来未提供相关开发框架、但应客户中特别追求IT特征的个别人的要求而要进行的开发工作。这些既费时又容易引起BUG的开发工作往往只是为了满足一些细枝末节的功能，如界面的色彩变化和按钮的特征调整等等。我们不能说这些要求都不合理，但我们必须考虑工作的投入与产出之间的平衡。如果系统的某一项IT特征需求需要大量的投入，并且给后续的维护带来很多额外负担的话，我们应该考虑使用一些替代的办法。信息系统的实施必须以业务目标为导向，不能单纯以IT层面的功能为导向，这是必须遵循的基本原则。企业要的是一个能够满足业务目标需求的可用的系统。这个系统可以是一个高科技的产品，但是并不代表它的菜单、按钮、界面、鼠标点击方式都能够尽善尽美，事实上每个使用者的要求和使用习惯也会有所差异。当然系统在满足业务功能的同时，应该在允许的范围内尽可能将界面做的更加人性化，更加符合大多数用户的要求。但是作为实施方和客户都必须把握一个原则：业务目标第一位，IT特征应在软件框架许可的范围内进行调整；过分追求IT特征需要付出昂贵的代价，并且很容易忽视业务的主体需求。
   

  4.2、外包工作的管理
  很多PLM项目需要将部分工作外包给第三方合作伙伴。这种情况下，PM应该注意管理好与合作伙伴的工作关系，确保他们按时、高质量地交付相应的工作成果。为了达到这一目的，以下几点值得引起我们的重视：
  (a)详细、准确地提供外包工作说明书——SOW。合作伙伴通常是编写代码的高手，但在业务方面他们没有太多的经验。因此一份详细、准确的SOW可以减少很多不必要的沟通和返工； 
  (b)尽可能重用代码。代码重用即可以节省工作量，又可以保证质量，因为能够重用的代码通常已经在其它项目中经过了必要的实践检验；
  (c)尽量避免同一个项目的开发工作过于分散。过于分散的开发工作给代码的合成和综合测试带来很多额外的工作和风险，出现问题时责任方比较难以界定；
  (d)在项目计划中应留有足够的测试、调整时间。开发工作完成后经过单元测试，最终还需要在用户现场进行综合测试，这个环节由于环境的不同（如开发者使用Windows系统，客户使用Unix系统；开发者使用虚构的测试数据，现场使用真实的业务数据；数据量可能增加几十倍等等）会涌现出很多之前没有发现的小问题，需要对系统进行调整和完善。另外，在测试过程中，客户往往还会有一些新的需求。当然，对于大的修改要尽量避免，但是有些小改动在所难免。这不是
   

  开发者的问题，但是作为PM必须面对它，有时需要请开发人员帮忙给予调整。所有这些都需要时间，因此在项目计划中，应充分重视系统测试这一环节，给它留有足够的缓冲。