项目执行计划书

项目执行计划书

项目基本信息 纪录项目目标、范畴、项目经理、项目发起人(委制单位)、项目期间、项目预期成本、假设与限制等，大致上就是Project Charter中所记载内容的80%。

主要工作项目

项目执行过程中，会包含项目管理类工作(主要是PM的工作)、项目支持类工作(包含建构管理、QA、QC、教育训练、重工等)、需求发展(取得需求列表、获取内部承诺、外部承诺等)、系统分析与设计(SA、SD相关工作)、撰写程序等主要工作项目的计划，这部分可以参考项目的WBS。

专案里程碑

项目主要的里程碑，一般来说最少会有两个里程碑，及启动会议(Kick-off meeting)与验收结案，这部分加上项目基本信息，大致上就是Charter的内容了。

需求访谈规划

纪录项目中主系统、各模块的需求访谈对象、时程、负责人员、进行方式(面谈、问卷等)、访谈要点(要获得的结果)，这部分的重点在找谁谈，以及要获得什么结论，通常需求的来源者很多，这份数据应该是要持续被维护的，因为需求提供人员可能会随着项目的进行逐渐增加。

变更管理

记录项目如何进行Change Manangement，针对项目管理需求(变更时程、成本、范畴)、客户需求、内部需求(让设计更灵活、更美观等)我们如何处理这些变更，必须要记载由谁发起，由谁核可等相关程序。

项目组织与组织结构

记载项目的组织，记载了利害关系人、项目经理、项目成员扮演的角色与主要工作范围，对PM来说，项目团队最好是项目型团队，PM可以管理到所有的人，大家只有一个共同的头头，那就是PM；如果是矩阵型的团队，那Kick-off时的团队成员承诺就变得异常重要，绝对要成员承诺在项目进行的时候必须要全力配合，否则将形成风险。

人力资源

从项目组之中做衍生，记录每个人的称呼、联络方式、因项目所需欠缺的技能以及补强方式，例如今天我缺乏了OOAD的技能，那就必须要注明如何补强OOAD的技能，是由老手带领、开教育训练课程还是到外头上课等。

人员责任矩阵(ARCI)

记录项目中每项主要工作的A(Accountable)、R(Response)、C(Consult)、I(Informed)人员名称，这边要注意的是R、C、I可能都有多个，但A一般来说只有一个。

项目监控与质量活动

记录如何做项目监控？何时、何人来进行？要监控的项目？例如在第二个里程碑之前，为了让项目走的更顺，可能会定每周一次进度审查，有问题的话就进行矫正；进入项目中期，可能会改成每两周进行一次；末期在改成每周进行一次，也就是说让项目的监控更具有规范性，不会漫无章法的乱开会，而质量活动也相同，必须要定义何时、何人来进行质量活动，以确保项目的质量符合一开始定义的范围。

验证与确认(V&V)

注记每一项工作流程(可能会对应到工作产品)的.验证方式、负责人，例如软件架构设计由系统架构师来进行验证。

建构管理

定义项目各项基准中应该包含哪些内容，例如开发基准可能需要包含系统设计规格、原始码；产品基准可能包还原始码、产品文件等，除此之外还要注明建构管理员如何进行建构管理以及建构管理区的R/W权限表。

数据管理

记载项目开发过程中文件、原始码、规格等数据的放置位置，作为项目开发时的依归，也避免大家将数据摆放在不同的位置或者随意放置，到时候要找寻相关文件时会变得非常麻烦。

资源需求

包含项目管理、需求管理、议题追踪、开发管理、原始码管制、建构管理等相关工作衍生出来的资源需求，包含软硬件。

项目工作环境 成员的工作环境，例如使用Windows 20xx/SQL Server 20xx/Office 20xx/VS 20xx等，一般来说项目成员必须要使用相同的开发环境才不会出现大家执行出来的结果不相同。

部署计划

说明项目部署方式、部署负责人等，例如部署时应该使用特定工具、经由特定步骤来执行，且Production环境应只有部署负责人有权限进行操作，不应交由每个人来进行，会上到Production环境的通常是经过测试环境验证过的程序，而非部署负责人本机或者开发人员提供的程序。

风险管理计划

定义风险来源、说明风险参数定义(包含影响性、机率与可侦测性，而什么叫『高』影响性、『低』机率，这些定义应该被记载)、风险响应人员、风险响应计划与策略、项目风险清单、风险监控方式与频率等等。

一份项目计划应该包含以上内容，而因项目特性不同，每个项目都会再增加或者修改一些内容，以我们手上这个项目来说，大约有28个不同项目要规划，对项目团队来说，一份清楚的项目执行计划非常有助于项目团队沟通。