浅析项目管理计划及其子计划

项目管理九大知识领域中，几乎每一个领域都涉及到项目管理计划或其子计划的规划过程。然而，一个项目管理计划到底包括哪些子计划，这些子计划需要包括哪些方面的内容，它们的作用分别是什么，在制定这些子计划时有哪些需要注意的事项？作者试图对这些信息作一个系统的梳理，以方便项目经理在制定项目管理计划时参考。

以下详细阐述项目管理计划、范围管理计划、进度管理计划、费用管理计划、质量管理计划、过程改进计划、人员配备管理计划、沟通管理计划、风险管理计划、采购管理计划、合同管理计划、项目验收计划的主要内容、作用及注意事项。

1、项目管理计划

n 主要内容及作用

项目管理计划是项目的主计划或称为总体计划，它确定了执行、监控和结束项目的方式和方法，包括项目需要执行的过程、项目生命周期、里程碑和阶段划分等全局性内容。项目管理计划是其它各子计划制定的依据和基础，它从整体上指导项目工作的有序进行。 n 需要注意的事项

在初次制定项目管理计划时，由于各方面的信息还不十分明朗，因此项目经理只需要从宏观上把握住项目的主体管理思路，切记不能理想化而期望项目管理计划一步到位。

2、范围管理计划

n 主要内容及作用

范围管理计划是项目管理团队确定、记载、核实、管理和控制项目范围的指南，需要包括如何制定详细项目范围说明书、进行范围核实和范围变更等内容。该计划为后续范围定义、制定工作分解结构、范围核实和范围控制等工作提供指导。

n 需要注意的事项

实践经验告诉我们，项目范围管理计划需要尽可能在其它子计划之前制定，因为它为其它子计划的合理制定提供基础信息。

3、进度管理计划

n 主要内容及作用

进度管理计划中需要确定制定项目进度表的格式与控制项目进度的准则。该计划为后续活动定义、活动排序、活动资源估算、活动历时估算、制定进度表和进行进度控制等工作提供指导。

n 需要注意的事项

在制定进度管理计划时，需要根据项目的实际情况，明确定义好进度偏差的阀值，方便后续进度控制和计划的变更。

4、费用管理计划

n 主要内容及作用

费用管理计划中需要选定费用管理的模板，制定费用规划、结构、估算、预算和控制的标准。包括费用估算精确等级、费用测量单位、费用偏差标准和费用报告格式等主要内容。该计划为后续费用估算、费用预算和费用控制等工作提供指导。

n 需要注意的事项

项目的费用管理与范围管理、进度管理、人力资源管理、风险管理等息息相关，因此在制定费用管理计划时，需要综合考虑范围、进度、人力资源、风险等对费用管理及费用偏差阀值可能造成的影响。

5、质量管理计划

n 主要内容及作用

质量管理计划需要说明项目管理团队如何执行实施组织的质量方针。该计划为后续质量保证、质量控制和过程持续改进等工作提供指导。

n 需要注意的事项

质量管理计划贯穿于项目的始终（从启动到收尾），因此质量管理计划需要涵盖项目前期的质量工作，以保证先期决策的正确性和质量标准的前后一致性。

6、过程改进计划

n 主要内容及作用

过程改进计划需要详细分析过程分析的具体步骤，包括过程测量标准、过程改进目标等内容。该计划直接为项目过程改进（通过质量保证）提供指导，间接为组织过程改进（通过经验和教训）提供指导。

n 需要注意的事项

过程持续改进的目标是实现过程质量改进和项目质量改进，因此，项目经理在进行质量规划时需要非常重视过程改进计划的制定。

7、人力资源配备管理计划

n 主要内容及作用

人力资源配备管理计划是规划项目人力资源的获取、使用、遣散安置等的文件。其主要内容是何时通过何种方式满足项目人力资源的要求。该计划为后续项目团队组建、项目团队建设、项目团队管理等工作提供指导。

n 需要注意的事项

项目经理在制定人力资源配备管理计划时，需要认真分析项目的范围、进度等基本要求，结合项目实际情况进行规划，否则很容易导致计划的人力资源不能满足项目的需要或不能充分发挥他们的作用的现象。

8、沟通管理计划

n 主要内容及作用

沟通管理计划需要确定利害关系者的信息与沟通需求，主要内容包括什么人什么时候通过何种方式获得何种项目信息。该计划为后续信息发布、绩效报告和项目利害关系者管理等工作

提供指导。

n 需要注意的事项

项目经理制定沟通管理计划时，不但需要认真分析和记录项目团队外的利害关系者的信息与沟通需求，而且也需要分析和记录项目团队成员的信息和沟通需求。

9、风险管理计划

n 主要内容及作用

风险管理计划需要描述如何规划、安排与实施项目风险管理。该计划为后续风险识别、风险定性分析、风险定量分析、风险应对规划和风险监控等工作提供指导。

n 需要注意的事项

项目经理在制定风险管理计划时，需要充分考虑项目团队的风险管理水平和能力，可以借鉴但不可盲目套用其它项目的风险管理计划，否则将会导致后续风险管理工作很难开展。

10、采购管理计划

n 主要内容及作用

采购管理计划需要描述如何管理从制定采购文件到合同收尾的采购过程，主要内容为采购何物以及何时如何采购。该计划为后续发包规划、询价、卖方选择、合同管理和合同收尾等工作提供指导。

n 需要注意的事项

项目经理需要尽可能在项目的早期确定项目需要采购的内容（即尽早制定采购计划），以便能有足够的时间确定采购的方式和选择供应商。

11、合同管理计划

n 主要内容及作用

合同管理计划是按照买方规定的具体内容，管理供应商供货行为的计划。该计划需要包括供应商遵守的管理办法、交付日期、质量标准等要求。合同管理计划对于如何保证供应商严格按照买方要求实施分包合同管理并提供满足质量要求的产品或服务具有重要作用。 n 需要注意的事项

合同管理的一个关键方面是管理各供应商之间的接口，因此项目经理在编制合同管理计划时，不但需要考虑分包工作的实际特点，而且需要结合供应商的实际管理能力和水平，否则将会“一厢情愿”。

12、项目验收计划

n 主要内容及作用

项目验收计划包括验收的时间、验收的地点、验收的组织、验收的形式等内容，是指导项目验收的文件（验收标准一般在合同中规定）。有了项目验收计划，能让甲乙双方在验收时比较容易达成理解和操作上的一致。

n 需要注意的事项

项目验收活动虽然在项目收尾阶段进行，但项目经理需要尽早制定该计划，以让用户有思想准备并有比较多的时间进行验收前的统筹安排工作。

以上归纳的是项目管理计划及其主要的子计划，不同类型的项目可能还会有其它类型的子计划，如配置管理计划、测试计划、试运行计划、用户培训计划等，这里就不一一列举了。 项目管理计划及其子计划的制定和完善，是一个“滚动式”的过程，需要执行PDCA（计划、执行、检查、修正）循环。现实世界中没有哪个项目的计划制定是“一劳永逸”的。因此，作为项目经理，一定需要养成在项目的推进过程中不断检查、修正和完善项目管理计划及其子计划的习惯，惟有这样，项目管理计划才能真正发挥作用。

第二篇：个人项目管理计划及实施建议

个人项目管理计划及实施建议

一、项目启动（项目开工会）

了解项目干系人及其利害关系。

所有项目组成员是否到位，如到位则拿到项目开发人员的简历，详细了解每个开发人员的情况（可能会组织到客户方面试）。

根据项目需求规格列出项目功能列表，并根据开发人员技术等情况创建WBS。 根据项目时间、资源等情况规划项目初步开发计划（各里程碑时间点的粗略计划，每个时间段投入多少人力等）。

确定各种软硬件需求，如：版本控制服务器、数据库服务器、开发服务器、缺陷管理软件服务器、开发工具等。

参与人员：

项目经理、项目总监、全体项目组成员、用户方领导、用户方参与人员、其它主要项目干系人

项目启动会议的目标：

让整个项目组的成员相互认识

建立项目的工作关系和沟通关系

让大家明确团队的工作目标

让大家了解项目的当前状态

一起审阅项目计划

找出项目的难点或可能出问题的环节

分配小组和个人的角色与责任

获得小组和个人的承诺

实施建议：

对立项管理过程域产生的所有有价值的文档如《立项建议书》、《立项调查报告》、

《立项可行性分析报告》、《立项评审报告》进行配置管理。

做好必要的保密工作。

由于每个项目都要占用机构的资金和资源，立项评审一定要严格。建议对机构高层管理人员进行必要的立项管理培训。

输出文档包括：

项目风险管理计划、工作任务分解结构（WBS）、项目进度计划、配置管理计划、质量保证计划、TimeSheet、开发规范文档、测试计划

二、需求分析

需求调研：与客户就其所需要的功能、流程、操作等需要为基础，而且需求决策者必须是项目经理或部门负责人。

列一个需求管理（包括详细的沟通计划及要求沟通）计划，考虑需求沟通中的人员、资源、时间的要求。

虽然有些因素是客户方造成的，但应该站在其角度上，为其考虑一些存在的客观及主观因素。

注意与项目成员之间的沟通方式及对团队的建设。

把握需求分析的进度及质量是否符合要求。

根据交互设计原型与客户交流需求分析是否达到要求及功能点是否有遗漏。 有哪些文档或数据是由客户提供的，这些数据是否需要在新开发的系统中维护等。

实施建议：

先对项目成员进行培训，让他们掌握必要的需求开发技能。(比如需求开发要做什么，做到什么程度，需要注意哪些问题等)

对需求开发过程域产生的所有有价值的文档进行配置管理。

需求的建模分析有较高的技术难度，项目成员应当根据自身水平进行取舍。

交互设计中应以用户的易用性为前提然后考虑在这样设计的前提下技术上实现是否有难度或者工作量超过前期设计的百分之二十.

（多用TAB形式，尽量让客户的某个角色的任务可以在一个页面中完成，一般用上下文菜单，避免用系统的菜单，一个功能块一般只需要一个入口）

输出文档包括：

产品需求分析说明书、数据流程图、系统应用架构图、交互设计原型、需求分析模型(RQM)

三、概要设计

确定影响系统设计的约束因素：本系统应当遵循的标准或规范、软件、硬件环境

（包括运行环境和开发环境）的约束、接口/协议的约束、软件质量的约束、隐含约束等。

确定设计策略：扩展策略、复用策略、折衷策略。

系统分解与设计：将系统分解为若干子系统，确定每个子系统的功能以及子系统之间的关系；将子系统分解为若干模块，确定每个模块的功能以及模块之间的关系。

数据库概要设计。

输出文档：

产品概要设计说明书、数据概要设计模型(CDM)

四、详细设计

确定功能模块的参与者、数据库表、输入参数说明、前置条件、基本流程、异常流程、日志等信息。

各层次结构的接口定义

数据库设计：逻辑设计—>物理设计－>安全性设计－>优化

实施建议：

先对系统设计人员进行“专题”培训，让他们掌握必要的系统设计技能。 由于国内绝大多数的大学不开设“用户界面设计课程”，这导致大部分软件开发人员不善于设计用户界面。项目开发小组应当设法邀请用户界面设计专家参与（或指导）本软件的

界面设计。

对系统设计过程中产生的所有有价值的文档进行配置管理。

输出文档：

产品详细设计说明书、数据物理设计模型(PDM)、自定义数据类型及BO数据类型文件、数据字典、系统测试用例、对象模型(OOM)

五、Coding

软件编码，各接口的实现。

单元测试。

实施建议：

对开发人员进行“高质量程序设计”培训，让他们掌握编写高质量程序的技能。 对开发人员进行“版本控制、代码审查、测试、改错”等方面的培训，提高他们的工作效率。

开发小组根据项目的资源、时间等限制因素，可以适当地减少测试的工作量。 对实现与测试过程中产生的所有代码和有价值的文档进行配置管理。

输出：

单元测试报告、代码评审报告

六、集成测试

根据系统测试用例测试系统的功能性需求，保证系统的正常功能处理及异常处理是否正确。

用户界面测试，重点是测试软件系统的易用性和视觉效果等。

健壮性测试,测试软件系统在异常情况下能否正常运行的能力。(容错能力和恢复能力)

安全性测试(这种测试一般能通过建行的fortify 软件评测即可)

如果产品需要安装，那么还得经过安装与反安装测试

实施建议：

对系统测试人员进行必要的培训，提高他们的测试效率。

项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。

系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。 对系统测试过程中产生的所有代码和有价值的文档进行配置管理。

为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。

输出：

系统测试报告、缺陷管理报告、操作手册

七、客户验收

成果审查。验收人员审查开发方应当交付的成果，如代码、文档等等。确保这些成果是完整的并且是正确有效的。

验收测试。验收人员对交付的产品进行全面的测试，确保产品功能、质量符合需求。

及时解决客户方发现的问题。

输出：

客户验收计划、验收测试用例、客户验收报告、验收操作手册

实施建议：

在客户验收之前，开发方对验收人员进行必要的产品培训。

开发方可以将系统测试用例给验收人员参考，以减少设计测试用例的时间。 开发方人员应当热情地协助验收人员。对验收人员发现的软件缺陷马上予以纠正；对于复杂的问题应当立即请示有关领导，不可拖延。在验收期间不可与客户争吵，给客户留下很

好的印象。

对验收过程中产生的所有有价值的文档进行配置管理。

八、结项

计划与实际情况对比:产品功能、工作成果、产品质量、投入人员、工作量、成本等

申请结项理由和项目自我评价

对项目进行综合评估，总结经验教训。

有价值的结项管理至少包括三项内容：

一、对项目的有形资产和无形资产进行清算，既要防止资产流失，又要及时地利用这些资产。

二、对项目进行综合评估。例如评估项目完成情况、项目质量、投入产出分析、项目的市场价值、项目对企业的贡献等等。该评估报告可以作为考核项目人员业绩的重要依据。

三、总结经验教训，使整个机构受益。

实施建议:

对结项管理过程域产生的所有有价值的文档进行配置管理。

做好必要的保密工作。

结项评审工作不能简化。

对结项评审委员会进行必要的培训，使他们树立正确的观念，从而严格把关

输出：

结项申请书、结项评审报告

下面是这些核心工具的运用经验：

1.必须建立源代码的版本控制系统，就是cvs，基本的代码提交原则：

1)程序员尽量每天只在下班前提交一次;

2)提交的代码必须是在自己的机器上是正常运行的；

3)每次提交都必须用简短的话说明自己提交代码的功能描述。

2.建立错误追踪系统，用Bugzilla就很好，配置好邮件系统，使Bugzilla成为测试人员与开发人员沟通的桥梁。

3.用BAT和Perl脚本，以cvs中的源代码为核心实现简单的每日编译工具，将这个自己写的自动化工具放到一台专门的编译机器上，在每天的半夜开始自动下载代码，自动编译代码

，自动打包安装程序，自动记录各种编译日志，自动将安装程序放置到一个固定的以日期为目录名的公共区。（用cvs2cl.pl得到程序员上传的代码更新日志，以便测试人员参考）

4.测试人员的第二天，应该到公共区取得头天的最新版本，并根据ChangeLog进行新版本的测试。并将测试中发现的Bug，通过Bugzilla反馈给程序员。程序员可以根据自己的情况

，或公司的规定来决定修改这些Bug的时间。并将这些Bug的修改情况，在代码提交时，写入代码日志。

5.开发人员的第二天，应该到公共区查看编译日志，看看自己的模块是否正常编译，及时更正，看看自己的邮箱有没有Bug报告，及时修改。

6.管理人员的第二天，在综合项目需求与头天版本进度的上，可以判断产品的发展方向，如果有偏航或理解错误或有新需求时，可以根据当前情况及时调整。 这样，通过 cvs => bugzilla => daily-build，就能将程序员与测试员，进行互动，各施其责。减少沟通与人为的麻烦。对于管理层，也能做到心中有数：因为每天都有新版本，

随时掌握产品的走向。。。等等