项目管理文档<模板>

文档的目的

项目管理计划定义了项目目标和范围,以及在交付阶段如何执行、监控和控制项目目标和范围。

本文档撰写者

指定的项目经理与项目小组成员合作,并与参与本文所述管理和技术过程的职能组织协商,制定项目管理计划。

如何使用模板

从这个模板创建一个项目管理计划,简单地说:

  1. 将标题替换为项目名称和组织信息。
  2. 用项目名称和信息替换文档标题中的<斜体文本>。
  3. 用与当前文档命名标准一致的文件名保存文档。
  4. 完成整个模板。每个部分包含简短的内容说明,以斜体显示,一旦文档完成,可以删除这些。表格还提供了一些所需信息的建议布局。
  5. 通过右键单击并选择Update Field来更新内容表,然后更新整个表。
  6. 注意:将小于/大于符号“<…>”之间的所有文本替换为项目你所需要的项目上的特定语句。
  7.  (...)内的内容是根据一些经验性的结论或者例子,可以供你借鉴思考,提供一个思路。

 

1、执行概要

<描述驱动项目的关键问题。在满足投资计划、业务、技术或法律/政治/监管目标的同时,清楚地展示问题/机会,以及如何解决问题/机会提供最佳价值。总结项目确定阶段的结果(如可行性评估和商业案例)。定义项目的目标和预期的结果。定义量化的和可测量的目标,这些目标可以作为关键涉众判断项目成功的标准。其中一些信息可以从项目章程中提取出来>。

(业务价值才是项目驱动力

任何一个触网的项目,技术、产品、运营,作为项目的三个支撑方,承担着不同的作用,不可或缺,很难去确定3(技术、产品、运营)方中哪一方才是驱动项目进度的主要那个。

在满足投资计划、业务、技术或法律/政治/监管目标的同时,清楚地展示问题/机会,以及如何解决问题/机会提供最佳价值。

总结项目确定阶段的结果(如可行性评估和商业案例)。定义项目的目标和预期的结果。

定义量化的和可测量的目标,这些目标可以作为关键涉众判断项目成功的标准。其中一些信息可以从项目章程中提取出来。)

2、集成管理

<集成管理包括统一、协调和管理所有项目元素到完成所需的所有过程。集成管理跨越项目的所有阶段,包括变更管理、执行、控制和结束。请简要描述这将如何完成>

(集成管理包括统一、协调和管理所有项目元素到完成所需的所有过程。集成管理跨越项目的所有阶段,包括变更管理、执行、控制和结束。)

2.1、项目团队结构

<描述项目和外部实体之间的组织边界。定义和描述与高级管理人员、客户、分包商、采购、销售、市场、法律、财务、采购、安装和支持组织、标准或认证机构、审计师、制造等的沟通。

在第2.2节中,使用图表说明可能涉及审批过程的公司治理机构,并描述它们的角色和职责。以适合项目规模和复杂性的方式说明项目团队的结构和关系(例如,对于小型项目,可以包括团队成员的名字;对于较大的项目,组织结构图应该命名组成项目团队的组或实体)。>

下面的图表展示了一个示例

 2.2、角色和职责

<列出项目团队结构图中确定的主要角色,以及不是项目团队具体成员的内部和外部项目涉众。描述它们与项目的相关性以及它们与特定项目活动的相互作用程度>

项目位置

 的名字

责任

外部资源

2.3、变更管理

<描述在项目的整个交付阶段如何管理变更。这应该包括变更管理过程、角色和职责、工具和技术以及报告>

(项目变更管理的目的是以一种对于项目影响最小的方式改变现状。它包括以下主要内容:(1)了解变化。在项目实施过程中,项目组织要经常关注与项目相关的主客观因素,及时发现和把握变化,认真分析变化的性质,确定变化的影响,适时进行变化描述。(2)进行变更处理。当变化了的各种因素影响到了项目的顺利实施时,项目组织必须及时进行计划变更,以确保项目目标的实现。项目计划的变更应征得项目主体的同意,项目组织还应及时向其反馈变更及变更执行情况。(3)监控变更合理性。变更处理总是根据项目实施的客观需要进行的,但并不是每次变更都是合理的。

当提出一个变更申请时,以下一些要点应予以考虑:(1)变更是否会影响工作范围、成本、工作质量和时间进度?(2)是否会对工种设备和工具产生影响?(3)会对零部件和成品库存产生什么样的影响?(4)在产品开发项目中,变更会不会影响开发产品的形式、通用性和功能?(5)变更会使产品在市场中更受欢迎还是被抵制?(6)变更是否会影响投资回报率和净现值?如果答案肯定,那么项目在这一投资回报率和净现值水平上是否可行?(7)如何证明变更是合理的?是竞争优势所需求的?是某些规定的强制要求?其商业必要性是什么?(8)变更是为使项目回归原来的轨道所需要的?还是项目已偏离原定目标过远,这一变更不过仅用来记录我们当前所处的位置,同时用做一条跟踪未来进展的基准线)

2.3.1、变更控制

<描述将要使用的变更控制过程,包括:

  • 改变治理
  • 变更识别和请求管理
  • 影响分析
  • 变更审批流程
  • 更改跟踪>

(描述将要使用的变更控制过程,包括:-改变治理-变更识别和请求管理-影响分析-变更审批流程-更改跟踪)

需求变更的原因分析:(1)、范围没有圈定就开始细化。(2)、没有指定需求的基线。需求的基线是指是否容许需求变更的分界线。(3)、没有良好的软件结构适应变化。

注意点:项目启动阶段做好变更预防,对一个需求分析做得很好的项目来说,基准文件定义的范围越详细清晰,用户跟项目经理扯皮的幌子就越少。如果需求没做好,基准文件里的范围含糊不清,被客户抓住空子,往往要付出许多无谓的牺牲。如果需求做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候千万不能手软,这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。相对于需求来说,什么WBS、风险管理、计划进度都是次要的,只要需求做好了就会一帆风顺)

2.4、项目结束

<包括必要的计划,以确保有序地结束项目。结束计划中的项目应包括工作人员调动计划、项目材料存档计划、项目人员事后汇报计划,以及编写一份最后报告,包括所吸取的经验教训和对实现的项目目标的分析。>

3、范围管理

<描述在整个项目交付阶段如何管理项目范围。这可能包括关于特定范围管理过程的信息,如范围验证和控制、工作分解结构的开发、角色和职责、工具和技术以及报告>

3.1、规范说明

<提供一个范围声明,包括什么在范围内,什么不在范围内;也就是说,满足既定目标所需的项目范围。重要的是要记住,范围包括产品范围(产品或服务的特性和功能)和项目范围(交付产品所需的工作)的需求。>

活动范围

范围外活动

3.2、需求管理

<需求将提供项目和产品范围的细节。描述将如何收集、详细、验证、控制和管理需求。还包括将要使用的工具和过程,例如需求映射>

(需求是整个软件项目当中最重要一项输入。软件开发和传统生产行业最大的区别在于,需求总是模糊的、主观的和随时变化的。但是需求又是整个项目能否成功的决定性因素,所以我们必须对需求进行管理,从而使需求成为整个软件工程的基线。使得所有产品、设计、研发、测试、运维工作能围绕着统一的需求开展。保证项目能顺利进行,完成目标。

需求管理的难点:1、需求描述的问题。(需求文档)2、需求变化的问题(这就需要团队在迭代进行前,尽量保证需求清晰明确。)。3、需求的优先级及排期问题(管理工具)。)

3.3、项目可交付成果

<列出要交付给客户、分包商、集成商或其他方的主要项目。根据需要,列出交付物、收件人、中期和最终交付日期以及交付方法。下面这样的表格是显示这些信息的好方法。

清单应区分项目管理可交付成果(如项目进度、沟通计划、进度报告等)与项目可交付成果(如系统、数据库、电信设备、系统和用户文档等>

(可交付成果指的是在某一过程、阶段或项目完成时,必须产出的任何独特并可核实的产 品、成果或服务能力。可交付成果可能是有形的,也可能是无形的。

具体成果应包括中间结果(项目计划、工作分解结构、进度计划、状态报告等)和项目成果(产品、服务、用户手册等),其在完成后必须提交出来以满足合同的要求。

交付给客户、分包商、集成商或其他方的主要项目。根据需要,交付物、收件人、中期和最终交付日期以及交付方法。下面这样的表格是显示这些信息的好方法。

清单应区分项目管理可交付成果(如项目进度、沟通计划、进度报告等)与项目可交付成果(如系统、数据库、电信设备、系统和用户文档等)

一般来说,一个IT项目的可交付成果可以是文档、端口、一个系统架构、一个完整的系统等等。)

可交付成果

收件人

交货日期

交货方法

 3.3.1、工作活动

<指定项目中要执行的各种工作活动。工作分解结构应该用来描述工作活动以及工作活动之间的关系>

 3.3.2、约束

<约束或限制对项目施加限制或条件,特别是那些与项目范围相关的条件(例如,硬期限、预定预算、设定的里程碑、合同条款、隐私或安全考虑等)>

 3.3.3、假设

<假设是指在规划中被认为是正确的、真实的或确定的因素。这些假设将在交付阶段的计划过程中得到验证>

 3.3.4、利益相关者

<识别积极参与项目的个人或组织(如客户、赞助商、表演组织或公众),或其利益可能因项目的执行或完成而受到积极或消极影响的个人或组织。这是一个初步的估计>

4、进度管理

<描述在整个项目交付阶段如何管理时间。这应该包括用于开发进度计划、角色和职责、工具和技术以及报告、PDM、CPM的过程>

(一、 做好项目进度表,确定人员分工。二、优化作业流程,确定工作标准。三、定期检查项目节点/里程碑。四、项目成员的沟通。五、项目团队的激励。)

4.1、里程碑

<确定项目中的重要里程碑(阶段、阶段、决策门、可交付成果的批准等)。这也可以表示一个高级的项目时间表>

描述

预估日期

门/批准

4.2、进度控制

<指定用于在里程碑处测量完成工作的进度的控制机制。指定用于比较实际计划性能和计划性能的方法和工具,并在实际性能偏离计划或需要的性能时实施纠正措施。应该创建甘特图形式的项目进度表,最好是在项目跟踪工具中创建。描述如何以及何时修改进度表,以及如何达成对修改后进度表的协议和承诺。>

5、成本管理

<描述在整个项目交付阶段如何管理成本。这应该包括用于开发预算、角色和职责、工具和技术以及报告的过程。>

(如何做好项目的成本控制工作?这其实就是项目成本的规划问题。

成本是项目的三要素之一(时间,成本,质量)

成本管控首先需要有管控目标,毕竟不是说每个项目都需要盈利很大就是管控有效,主要在于达到我预期的目标即为管理有效!定好成本管控目标。不过,你说你们实施承包制,那公司应该会给你定责任成本,你完成这个目标也是管控有效!)

5.1、评估

<描述如何准备项目评估,包括:

  • 用于估计项目规模、工作量、成本、进度和关键计算机资源需求的方法、工具和技术。
  • 评估的时间。
  • 谁将参与评估过程。
  • 如何记录、审查和报告估算。

您可以在此部分中包含实际的估算值,也可以将它们存储在其他地方。对于所做的每一个估计,记录所使用的估计方法、所做的假设和估计的置信水平。描述将应急缓冲区纳入估计的理由。指定要定期使用的方法,以重新估计完成项目所需的成本、时间和资源>

5.2、预算分配

<在工作分解结构中,为每个主要工作活动提供必要资源预算的详细分解。活动预算应包括活动人员的估计费用,并可酌情包括诸如旅费、会议、计算资源、工具、特别测试和模拟设施以及行政支助等因素的费用。应为每项活动预算中的每一种资源提供单独的项目。工作活动预算可以使用电子表格编制,并以表格形式表示>

5.3、预算控制

<指定用于衡量已完成工作成本的控制机制,将计划成本与预算成本进行比较,并在实际成本与预算成本不一致时实施纠正措施。预算控制计划应规定成本报告的时间间隔,以及用于管理预算的方法和工具。预算计划应该包括可以使用客观指标评估在这些里程碑上完成的工作产品的范围和质量的频繁的里程碑。>

6、质量管理

<质量管理包括质量计划、质量保证、质量控制和持续改进。描述如何在整个项目交付阶段对质量进行管理,以确保交付成果的质量。这应该包括在质量计划中使用的过程,质量标准的定义,管理,角色和职责,工具和技术,持续改进和报告。>

6.1、质量保证

<质量保证活动监控和验证用于管理和创建可交付成果的过程的有效性。描述如何管理质量保证,包括治理、角色和职责、工具和技术以及报告。>

6.2、质量控制

<指定用于度量和控制工作产品质量的机制。质量控制机制可能包括验证和确认、同行评审、设计评审、产品测试等。>

7、人力资源管理

<描述在整个项目交付阶段如何管理人力资源。这应该包括如何确定资源需求、如何获得资源、如何开发和管理资源、角色和职责、工具和技术以及报告。人力资源管理还包括团队建设和奖励与认可。>

7.1、人力资源获取

<指定技能领域或项目角色所需的人力资源数量,以及所需的技能级别,以及每个资源所需的持续时间。描述预期的资源概要(项目中不同时期所需的技能和努力水平的组合),何时将有人加入或离开项目,以及如何面向新的团队成员。指定资源的来源,例如您的分支机构的内部资源、组织中另一个分支机构的内部资源、雇佣新员工的资源或雇佣承包商的资源。请将以下信息记录在本节中:

  • 可用的内部候选人,他们的技能组合,以及可用的日期
  • 对外部候选人的要求,包括职位分类和说明
  • 候选人的选择和任务的分配

所有候选人的可用性和任务持续时间>

7.2、人力资源开发

<描述如何开发人力资源,以确保他们具备完成项目交付所需的技能和知识。发展通常包括特定项目的培训,但也可能包括知识分享、工作观察和指导>

8、通信管理

<描述在这个项目的整个交付阶段如何管理沟通。这应该包括用于计划沟通、识别和管理涉众、确定沟通需求、角色和职责、工具和技术的过程。>

8.1利益相关者分析

<描述用于识别涉众的过程,他们将如何影响项目以及如何受到项目的影响。涉众分析将被输入到涉众管理计划中>

利益相关者的名字

他们将如何影响项目

他们将如何受到项目的影响

通信需求

8.2项目汇报与沟通

<确定项目预期的定期报告和沟通,如每周状态报告,定期回顾和必要的沟通。沟通的确切类型在不同的组之间是不同的,但是在项目开始时确定计划的方式是有用的。指定报告机制、报告内容,以及用于在项目内部和外部涉众之间沟通需求、进度、预算、质量、风险和其他状态指示器的信息流。下面的表格是描述通信期望的一种方便的方式。>

类型的交流

沟通计划

通信机制

引发剂

收件人

<状态报告>

每星期五< >

< >团队会议

<项目经理>

<项目团队>

9、风险管理

<为识别、分析和确定项目风险的优先级制定计划。它应描述应急计划的程序和用于跟踪风险、评估个人风险暴露的变化以及对这些变化作出反应的方法。在项目的整个生命周期中包括一个持续的风险识别计划。在单独的风险登记册中记录风险。一个大型项目应该创建一个单独的风险管理计划。确定要执行的风险管理任务、风险OPI(主要利益办公室),以及完成每项任务的目标日期。估计项目工作的百分比或计划用于风险管理活动的小时数。将风险管理任务纳入项目进度和预算。>

10、参考文献

附录

文档名称

E-DRM # /版本

日期

一个

B

C

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码

)">
< <上一篇
下一篇>>