项目管理计划模板

版本历史

1 目的 4

2 项目摘要 4

2.1 项目目标和范围 4

2.2 主要干系人 4

2.3 里程碑和可交付成果 4

2.4 约束 6

2.5 假设 6

2.6 项目组织结构 7

3 项目计划 7

3.1 项目生命周期 7

3.1.1 生命周期确认 7

3.1.2 制定项目过程及产物裁剪 7

3.2 工作分解结构 7

3.3 项目评估 8

3.4 开发计划 9

3.5 资源计划 11

3.5.1 知识和所需的技能 11

3.5.2 人员安排及分配 11

3.5.3 角色和职责 11

3.5.4 培训计划 12

3.5.5 软硬件资源计划 13

3.6 相关干系人员计划管理 13

3.7 沟通计划 14

3.7.1 每日沟通 14

3.7.2 每周沟通 14

3.7.3 每月沟通 14

3.7.4 随时沟通 15

3.8 流程质量控制计划 15

3.8.1 PPQA评审机制 15

3.8.2 PPQA检查计划 15

3.9 风险计划 15

3.10 发布计划 16

3.11 上线计划 16

3.12 验收计划 17

3.12.1 项目验收标准: 17

3.12.2 验收项清单 17

3.12.3 验收时间和进度 17

3.13 监督和控制计划 17

3.14 需求管理 18

4 附件 18

1 目的

该项目计划确定适用的政策，需求和软件开发的数据交换的标准，文档为完成开发工作定义了日程安排，组织，资源和必要的软件活动进程。

2 项目摘要

2.1 项目目标和范围

示例：

Movitech 负责Eleven技术所需的所有资源.相关资源部门会和美国团队和全队职工协作来实现Eleven Pepperidge Farm 技术产品的成功交付。国内的资源将会按照Eleven技术而在一个可接受的生产力水平和效率。

该项目涵盖Eleven Pepperidge Farm技术产品的所有新的功能、 bug 修复和修改现有功能和代码的十一项技术产品有关的所有事项。

2.2 主要干系人

示例:

2.3 约束与假设

示例:

2.4 项目组织结构

示例：

3 项目计划

3.1 项目生命周期

3.1.1 生命周期确认

主要按照项目特征、项目类型或客户的需求来确定项目的生命周期（如：迭代，瀑布，Scrum)。去认定我们需要根据项目的生命周期来做项目计划。

3.1.2 制定项目过程及产物裁剪

详细参考附件1：项目裁剪模板

3.2 里程碑和可交付成果

示例（瀑布式）:

示例（敏捷式）:

3.3 工作分解结构

通过WBS把模糊的工作逐层分解和简化，为后续工作打下基础，很好的解决现阶段项目开发中存在的问题。

在信息系统开发项目中创建WBS的基本原则?

①任务原则：一个单位工作任务只能在WBS中出现一次；每一项任务只能有一个人负责；WBS中任意一项任务的内容是其对应下级各项工作之和；?

②实际原则：WBS必须与实际工作任务的执行过程一致，分解后的工作应该是可管理的、可检查的和独立的，要符合项目团队工作的需要；?

③时间原则：在任务的分解过程中，最小级别的任务最好控制在40工时内，可以保证项目问题在两周或更短的时间内解决；?

④文档原则：在任务的分解中，每个WBS项都必须文档化，以确保准确理解已包括和未包括的工作范围；?

⑤灵活原则：WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。

3.4 项目评估

（现阶段暂时还是按项目经理本身的估算方法实现，后期跟进。评估人天大于100人天的需要组织部分有经验员工集体review）

项目评估流程参考附件2: 项目评估流程

项目评估方法及模板参考附件3-6：Project Estimate Template-Normal

项目估算模板- Delphi

项目估算模板-Analogy-Pert

项目估算模板-Pert

四种评估方法和模板任选一种进行评估。

3.5 开发计划

 开发计划的每个任务需要小于等于5人天；

 任务明确，并可验证；

 开发验证的过程需要包括在计划中。

关键里程碑计划可采用图形方式。

将项目的所有里程碑和关键活动标注在下面的时间轴上。注意：如果存在早期功能子集Beta和/或ESP交付件，PDT 需要对交付件进行TR4A/TR5评审，以及对GA层产品交付件进行TR4A和TR5评审。PDT不需要对每一个构件标注TR4，只需要标示第一个TR4的日期。如果需要将所有里程碑和关键活动标注出来，可将时间轴划分成阶段：

3.6 资源计划

3.6.1 知识和所需的技能?

3.6.2 人员安排及分配

3.6.3 角色和职责

3.6.4 培训计划

3.6.5 软硬件资源计划

3.7 相关干系人员计划管理

备注：

3.8 沟通计划

3.8.1 每日沟通

3.8.2 每周沟通

3.8.3 每月沟通

3.8.4 随时沟通

根据项目自身需求，可调整各个沟通频率。

3.9 流程质量控制计划

3.9.1 PPQA评审机制

 实施审计

PPQA根据《PPQA检查计划》，检查项目实际执行过程和相关工作产品是否符合既定的规范。

 记录结果

PPQA将不符合项记录在《PPQA检查计划-偏差明细列表》中。

 协商纠正措施

PPQA工程师与项目经理（或EPG Leader）分析不符合项原因并协商改进措施。

对于项目经理（EPG Leader）不认同的不符合项，PPQA工程师将该不符合项汇报给PMO，由PMO协商解决。

3.9.2 PPQA检查计划

详细参见附件7: PPQA检查计划

3.10 风险计划

详细参见附件8：项目风险跟踪管理模板

1

3.11 发布计划

该计划特质外部发布计划，内部发布计划见测试计划。

3.12 上线计划

3.13 验收计划

3.13.1 项目验收标准:

1) P1 缺陷 = 0

2) P2 缺陷 <2

3) 所有新提出的问题解决.

4) QA 结束了所有测试.

5) Agile接受sp的质量.

3.13.2 验收项清单

3.13.3 验收时间和进度

3.14 监督和控制计划

3.15 需求变更管理

每个客户认可的需求变更都需要通过需求申请单填写需求变更申请，保存在项目内部的SVN中。

《需求申请单 》如附件9。

4 附件

本文来源：https://www.2haoxitong.net/k/doc/3f84268b81d049649b6648d7c1c708a1284a0af5.html