适合任何项目的-项目管理计划标准模板.docVIP

【适合任何工程的工程管理方案标准模板】

工程管理方案

制定：

日期：

文档创立信息

工程名称

X

工程编号

X

工程经理

X

文档作者

X

创立日期

X

批准人

X

文件编号

X

总页数

X

正文页数

X

附录页数

X

文档修订记录

版本号

修改日期

修改原因

修改位置

修改人

审核人

X

X

X

X

X

X

X

X

X

目录

TOC\o1-3\h\z\u1. 引言 5

1.1. 本文目的 5

1.2. 术语、定义和缩略语 5

1.3. 参考资料 5

1.4. 本文档的管理要求 5

2. 工程组织管理 6

2.1. 组织结构 6

2.2. 角色、职责和人员 6

3. 工程范围 7

3.1. 工程目标 7

3.2. 工程工作产品 7

3.3. 验收标准 8

3.4. 假设和依赖 8

4. 工程工作分解、进度 9

4.1. 过程定义和里程碑点说明 9

4.2. 工程工作分解 10

4.3. 工程估计记录 10

4.4. 工程任务网络图 11

4.5. 工程进度安排 11

5. 工程本钱方案 11

5.1. 工程的人力资源方案 11

5.2. 工程人力资源费用预算 12

5.3. 设备、工具和环境需求 12

5.4. 工程阶段预算 13

5.5. 工程本钱控制方案 13

6. 工程沟通管理方案 13

6.1. 工程报告 13

6.2. 工程会议 14

6.3. 同行评审方案 14

7. 配置管理方案〔如果内容比拟多，可用附件形式〕 15

7.1. 人员及职责 15

7.2. 用于配置管理的软硬件资源 15

7.3. 配置项方案 15

7.4. 基线方案 16

7.5. 配置库备份方案 16

8. 专题方案 16

8.1. 技术专题 16

8.2. 培训方案 16

8.3. 外包方案 16

8.3.1. 外包方说明 16

8.3.2. 外包任务跟踪方案 17

8.4. 其它方案 17

9. 风险管理方案 17

9.1. 风险管理方案〔包括主要的阈值风险〕 17

9.2. 进度控制阈值及超出阈值采取措施 17

10. 其它特殊说明 18

引言

本文目的

本文是工程方案环节最重要的工作成果之一。本文评审后，将形成方案基线，作为工程跟踪和评价的根底。

本文的评审对象是：

本文的预期读者包括：

术语、定义和缩略语

列出文档中用到的专门术语的定义和缩略语的原文。

参考资料

列出本文的参考资料。一般包括：

●经评审的《产品可行性分析报告》、《产品版本规划》；

●与工程有关的已发表的资料，或前期工作成果；

●文档中所引用的资料，所采用的软件标准或标准等。

序号

资料名称

作者

发表日期

出版单位或资料来源

备注

1

《产品可行性分析报告》

2

《产品版本规划》

3

本文档的管理要求

本文档的模版中，斜体字代表说明或例如，在正式方案中应予删除或替换成工程相关内容；

本文档由工程经理建立并维护；

产品研发工程立项前，完本钱方案并组织评审。评审通过后，方可立项；

在每一阶段开始前，应进一步细化、完善本文档，特别是详细进度、任务分配、工作量估计和风险规划局部，如对原方案里程碑时间点有改动，那么需再进行评审。

工程组织管理

组织结构

[描述工程组内部、工程组与其他部门或工程组之间的接口关系。可参考下列图。]

产品委员会

产品委员会

技术委员会

需求分析组

工程经理

UI设计

组

工程QA

技术架构组

产品经理

开发组

测试组

系统配置组

角色、职责和人员

[根据工程的组织结构，参考下文，定义不同角色所具有的职责。]

角色

姓名

邮箱

工程投入度

进入时间

释放时间

变更控制委员会

产品经理

工程经理

外部专家

需求分析工程师

UI设计工程师

技术架构师

开发工程师

测试工程师

系统配置工程师

QA人员

……

工程范围

工程目标

1、完成《产品版本规划》中所定义的产品；

2、按规定流程实行标准过程管理，积累公司软件工程管理过程资产，供工程改良参考；

工程工作产品

工程过程

具体任务

工作产品清单

提交负责人

拟定提交时间

验收标准

涉及需求的标准

由产品经理提出。通常，优先级为1的需求，必须实现。

系统测试通过标准

由测试部提出。

Alpha测试、Beta测试通过标准

由产品经理提出。

涉及文档的标准

说明哪些文档，使用标准模版。哪些文档，使用工程组内部模版，及其原