前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >PMPBOK6之项目管理的33个文件

PMPBOK6之项目管理的33个文件

作者头像
菲宇
发布2019-06-13 10:19:33
9640
发布2019-06-13 10:19:33
举报
文章被收录于专栏:菲宇菲宇

1、活动属性:

活动属性是指每项活动所具有的多重属性,用来扩充对活动的描述,活动属性随时间演进。在项目初始阶段,活动属性包括唯一活动标识 (ID)、WBS 标识和活动标签或名称;在活动属性编制完成时,活动属性可能包括活动描述、紧前活动、紧后活动、逻辑关系、提前量和滞后量(见 6.3.2.3 节)、资源需求、强制日期、制约因素和假设条件。活动属性可用于识别开展工作的地点、编制开展活动的项目日历,以及相关的活动类型。活动属性还可用于编制进度计划。根据活动属性,可在报告中以各种方式对计划进度活动进行选择、排序和分类。

2、活动清单:

活动清单包含项目所需的进度活动。对于使用滚动式规划或敏捷技术的项目,活动清单会在项目进展过程中得到定期更新。活动清单包括每个活动的标识及工作范围详述,使项目团队成员知道需要完成什么工作。

3、假设日志:

通常,在项目启动之前编制商业论证时,识别高层级的战略和运营假设条件与制约因素。这些假设条件与制约因素应纳入项目章程。较低层级的活动和任务假设条件在项目期间随着诸如定义技术规范、估算、进度和风险等活动的开展而生成。假设日志用于记录整个项目生命周期中的所有假设条件和制约因素。

4、估算依据:

持续时间估算所需的支持信息的数量和种类,因应用领域而异。不论其详细程度如何,支持性文件都应该清晰、完整地说明持续时间估算是如何得出的。持续时间估算的支持信息可包括:

■关于估算依据的文件(如估算是如何编制的);

■关于全部假设条件的文件;

■关于各种已知制约因素的文件;

■对估算区间的说明(如“±10%”),以指出预期持续时间的所在区间;

■对最终估算的置信水平的说明;

■有关影响估算的单个项目风险的文件。

5、变更日志:

正式受控的任一项目文件都可在本过程变更,通常在本过程更新的一种项目文件是变更日志。变更日志用于记录项目期间发生的变更。

6、成本估算:

成本估算包括对完成项目工作可能需要的成本、应对已识别风险的应急储备,以及应对计划外工作的管理储备的量化估算。成本估算可以是汇总的或详细分列的。成本估算应覆盖项目所使用的全部资源,包括(但不限于)直接人工、材料、设备、服务、设施、信息技术,以及一些特殊的成本种类,如融资成本(包括利息)、通货膨胀补贴、汇率或成本应急储备。如果间接成本也包含在项目估算中,则可在活动层次或更高层次上计列间接成本。

7、成本预算:

无论是计算得出的 EAC 值,还是自下而上估算的 EAC 值,都需要记录下来,并传达给相关方。

8、持续时间估算:

持续时间估算是对完成某项活动、阶段或项目所需的工作时段数的定量评估,其中并不包括任何滞后量(见 6.3.2.3 节),但可指出一定的变动区间。例如:

■2 周 ± 2 天,表明活动至少需要 8 天,最多不超过 12 天(假定每周工作 5 天);

■超过 3 周的概率为 15%,表明该活动将在 3 周内(含 3 周)完工的概率为 85%。

9、问题日志:

在整个项目生命周期中,项目经理通常会遇到问题、差距、不一致或意外冲突。项目经理需要采取某些行动加以处理,以免影响项目绩效。问题日志是一种记录和跟进所有问题的项目文件,所需记录和跟进的内容可能包括:

■问题类型;

■问题提出者和提出时间;

■问题描述;

■问题优先级;

■由谁负责解决问题;

■目标解决日期;

■问题状态;

■最终解决情况。

问题日志可以帮助项目经理有效跟进和管理问题,确保它们得到调查和解决。作为本过程的输出,问题日志被首次创建,尽管在项目期间任何时候都可能发生问题。在整个项目生命周期应该随同监控活动更新问题日志。

经验教训登记册

10、经验教训登记册:

经验教训登记册可以包含情况的类别和描述,经验教训登记册还可包括与情况相关的影响、建议和行动方案。经验教训登记册可以记录遇到的挑战、问题、意识到的风险和机会,或其他适用的内容。

经验教训登记册在项目早期创建,作为本过程的输出。因此,在整个项目期间,它可以作为很多过程的输入,也可以作为输出而不断更新。参与工作的个人和团队也参与记录经验教训。可以通过视频、图片、音频或其他合适的方式记录知识,确保有效吸取经验教训。

在项目或阶段结束时,把相关信息归入经验教训知识库,成为组织过程资产的一部分。

11、里程碑清单:

里程碑是项目中的重要时点或事件,里程碑清单列出了所有项目里程碑,并指明每个里程碑是强制性的(如合同要求的)还是选择性的(如根据历史信息确定的)。里程碑的持续时间为零,因为它们代表的是一个重要时间点或事件。

12、实物资源分配单:

实物资源分配单记录了项目将使用的材料、设备、用品、地点和其他实物资源。

13、项目日历:

在项目日历中规定可以开展进度活动的可用工作日和工作班次,它把可用于开展进度活动的时间段(按天或更小的时间单位)与不可用的时间段区分开来。在一个进度模型中,可能需要采用不止一个项目日历来编制项目进度计划,因为有些活动需要不同的工作时段。因此,可能需要对项目日历进行更新。

14、项目沟通记录:

项目沟通工件可包括(但不限于):绩效报告、可交付成果的状态、进度进展、产生的成本、演示,以及相关方需要的其他信息。

15、项目进度计划:

项目进度计划是进度模型的输出,为各个相互关联的活动标注了计划日期、持续时间、里程碑和所需资源等星系。项目进度计划中至少要包括每个活动的计划开始日期与计划完成日期。即使在早期阶段就进行了资源规划,但在未确认资源分配和计划开始与完成日期之前,项目进度计划都只是初步的。一般要在项目管理计划(见 4.2.3.1 节)编制完成之前进行这些确认。还可以编制一份目标项目进度模型,规定每个活动的目标开始日期与目标完成日期。项目进度计划可以是概括(有时称为主进度计划或里程碑进度计划)或详细的。虽然项目进度计划可用列表形式,但图形方式更常见。可以采用以下一种或多种图形来呈现:

横道图。横道图也称为“甘特图”,是展示进度信息的一种图表方式。在横道图中,纵向列示活动,横向列示日期,用横条表示活动自开始日期至完成日期的持续时间。横道图相对易读,比较常用。它可能会包括浮动时间,也可能不包括,具体取决于受众。为了便于控制,以及与管理层进行沟通,可在里程碑或横跨多个相关联的工作包之间,列出内容更广、更综合的概括性活动,并在横道图报告中显示。见图 6-21 中的“概括性进度计划”部分,它按 WBS 的结构罗列相关活动。

里程碑图。与横道图类似,但仅标示出主要可交付成果和关键外部接口的计划开始或完成日期,见图 6-21 的“里程碑进度计划”部分。

项目进度网络图。这些图形通常用活动节点法绘制,没有时间刻度,纯粹显示活动及其相互关系,有时也称为“纯逻辑图”,如图 6-11 所示。项目进度网络图也可以是包含时间刻度的进度网络图,有时称为“逻辑横道图”,如图 6-21 中的详细进度计划所示。这些图形中有活动日期,通常会同时展示项目网络逻辑和项目关键路径活动等信息。本例子也显示了如何通过一系列相关活动来对每个工作包进行规划。项目进度网络图的另一种呈现形式是“时标逻辑图”,其中包含时间刻度和表示活动持续时间的横条,以及活动之间的逻辑关系。它们用于优化展现活动之间的关系,许多活动都可以按顺序出现在图的同一行中。图 6-21 是一个正在执行的示例项目的进度计划,工作进展是通过截止日期或状态日期表示的。针对一个简单的项目,图 6-21 给出了进度计划的三种形式:(1)里程碑进度计划,也叫里程碑图;(2)概括性进度计划,也叫横道图;(3)详细进度计划,也叫项目进度关联横道图。图 6-21 还直观地显示出项目进度计划不同详细程度的关系。

16、项目进度网络图:

项目进度网络图是表示项目进度活动之间的逻辑关系(也叫依赖关系)的图形。图 6-11 是项目进度网络图的一个示例。项目进度网络图可手工或借助项目管理软件来绘制,可包括项目的全部细节,也可只列出一项或多项概括性活动。项目进度网络图应附有简要文字描述,说明活动排序所使用的基本方法。在文字描述中,还应该对任何异常的活动序列做详细说明。带有多个紧前活动的活动代表路径汇聚,而带有多个紧后活动的活动则代表路径分支。带汇聚和分支的活动受到多个活动的影响或能够影响多个活动,因此存在更大的风险。I 活动被称为“路径汇聚”,因为它拥有多个紧前活动,而 K 活动被称为“路径分支”,因为它拥有多个紧后活动。

17、项目范围书

项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围,包括项目和产品范围;详细描述了项目的可交付成果;还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望,项目范围说明书可明确指出哪些工作不属于本项目范围。项目范围说明书使项目团队能进行更详细的规划,在执行过程中指导项目团队的工作,并为评价变更请求或额外工作是否超过项目边界提供基准。

项目范围说明书描述要做和不要做的工作的详细程度,决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容(可能直接列出或参引其他文件):

■产品范围描述。逐步细化在项目章程和需求文件中所述的产品、服务或成果的特征。

■可交付成果。为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力,可交付成果也包括各种辅助成果,如项目管理报告和文件。对可交付成果的描述可略可详。

■验收标准。可交付成果通过验收前必须满足的一系列条件。

■项目的除外责任。识别排除在项目之外的内容。明确说明哪些内容不属于项目范围,有助于管理相关方的期望及减少范围蔓延。

虽然项目章程和项目范围说明书的内容存在一定程度的重叠,但它们的详细程度完全不同。项目章程包含高层级的信息,而项目范围说明书则是对范围组成部分的详细描述,这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。

18、项目团队派工单

项目团队派工单记录了团队成员及其在项目中的角色和职责,可包括项目团队名录,还需要把人员姓名插入项目管理计划的其他部分,如项目组织图和进度计划。

19、质量控制测量结果

控制质量的测量结果是对质量控制活动的结果的书面记录,应以质量管理计划所确定的格式加以记录。

20、质量测量指标

质量测量指标专用于描述项目或产品属性,以及控制质量过程将如何验证符合程度。质量测量指标的例子包括按时完成的任务的百分比、以 CPI 测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数,以及测试计划所涵盖的需求的百分比(即测试覆盖度)。

21、质量报告

质量报告可能是图形、数据或定性文件,其中包含的信息可帮助其他过程和部门采取纠正措施,以实现项目质量期望。质量报告的信息可以包含团队上报的质量管理问题,针对过程、项目和产品的改善建议,纠正措施建议(包括返工、缺陷/漏洞补救、100% 检查等),以及在控制质量过程中发现的情况的概述。

22、需求文件

需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要相关方愿意认可的需求,才能作为基准。需求文件的格式多种多样,既可以是一份按相关方和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述

和附件等的详细文件。

23、需求跟踪矩阵

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后,需求跟踪矩阵还为管理产品范围变更提供了框架。

24、资源分解结构

资源分解结构是资源依类别和类型的层级展现(见图 9-7)。资源类别包括(但不限于)人力、材料、设备和用品,资源类型则包括技能水平、要求证书、等级水平或适用于项目的其他类型。在规划资源管理过程中,资源分解结构用于指导项目的分类活动。在这一过程中,资源分解结构是一份完整的文件,用于获取和监督资源。

25、资源日历

资源日历识别了每种具体资源可用时的工作日、班次、正常营业的上下班时间、周末和公共假期。在规划活动期间,潜在的可用资源信息(如团队资源、设备和材料)用于估算资源可用性。资源日历规定了在项目期间确定的团队和实物资源何时可用、可用多久。这些信息可以在活动或项目层面建立,这考虑了诸如资源经验和/或技能水平以及不同地理位置等属性。

26、资源需求

估算活动资源是估算执行项目所需的团队资源,以及材料、设备和用品的类型和数量的过程。本过程的主要作用是,明确完成项目所需的资源种类、数量和特性。本过程应根据需要在整个项目期间定期开展。图 9-5 描述本过程的输入、工具与技术和输出,图 9-6 是本过程的数据流向图。

27、风险登记册

风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展,这些过程的结果也要记进风险登记册。取决于具体的项目变量(如规模和复杂性),风险登记册可能包含有限或广泛的风险信息。当完成识别风险过程时,风险登记册的内容可能包括(但不限于):

■已识别风险的清单。在风险登记册中,每项单个项目风险都被赋予一个独特的标识号。要以所需的详细程度对已识别风险进行描述,确保明确理解。可以使用结构化的风险描述,来把风险本身与风险原因及风险影响区分开来。

■潜在风险责任人。如果已在识别风险过程中识别出潜在的风险责任人,就要把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。

■潜在风险应对措施清单。如果已在识别风险过程中识别出某种潜在的风险应对措施,就要把它记录到风险登记册中。随后将由规划风险应对过程进行确认。

根据风险管理计划规定的风险登记册格式,可能还要记录关于每项已识别风险的其他数据,包括:简短的风险名称、风险类别、当前风险状态、一项或多项原因、一项或多项对目标的影响、风险触发条件(显示风险即将发生的事件或条件)、受影响的 WBS组件,以及时间信息(风险何时识别、可能何时发生、何时可能不再相关,以及采取行动的最后期限)。

28、风险报告

风险报告提供关于整体项目风险的信息,以及关于已识别的单个项目风险的概述信息。在项目风险管理过程中,风险报告的编制是一项渐进式的工作。随着实施定性风险分析、实施定量风险分析、规划风险应对、实施风险应对和监督风险过程的完成,这些过程的结果也需要记录在风险登记册中。在完成识别风险过程时,风险报告的内容可能包括(但不限于):

整体项目风险的来源。说明哪些是整体项目风险敞口的最重要驱动因素。

关于已识别单个项目风险的概述信息。例如,已识别的威胁与机会的数量、风险在风险类别中的分布情况、测量指标和发展趋势。

根据风险管理计划中规定的报告要求,风险报告中可能还包含其他信息。

29、进度数据

项目进度模型中的进度数据是用以描述和控制进度计划的信息集合。进度数据至少包括进度里程碑、进度活动、活动属性,以及已知的全部假设条件与制约因素,而所需的其他数据因应用领域而异。经常可用作支持细节的信息包括(但不限于):

■按时段计列的资源需求,往往以资源直方图表示;

■备选的进度计划,如最好情况或最坏情况下的进度计划、经资源平衡或未经资源平衡的进度计划、有强制日期或无强制日期的进度计划;

■使用的进度储备。进度数据还可包括资源直方图、现金流预测,以及订购与交付进度安排等其他相关信息。

30、进度预测

进度更新即进度预测,指根据已有的信息和知识,对项目未来的情况和事件进行的估算或预计。随着项目执行,应该基于工作绩效信息,更新和重新发布预测。这些信息基于项目的过去绩效,并取决于纠正或预防措施所期望的未来绩效,可能包括挣值绩效指数,以及可能在未来对项目造成影响的进度储备信息。

31、相关方登记册

相关方登记册是识别相关方过程的主要输出。它记录关于已识别相关方的信息,包括(但不限于):

■身份信息。姓名、组织职位、地点、联系方式,以及在项目中扮演的角色。

■评估信息。主要需求、期望、影响项目成果的潜力,以及相关方最能影响或冲击的项目生命周期阶段。

■相关方分类。用内部或外部,作用、影响、权力或利益,上级、下级、外围或横向,或者项目经理选择的其他分类模型,进行分类的结果。

32、团队章程

团队章程是为团队创建团队价值观、共识和工作指南的文件。团队章程可能包括(但不限于):

■团队价值观;

■沟通指南;

■决策标准和过程;

■冲突处理过程;

■会议指南;

■团队共识。

团队章程对项目团队成员的可接受行为确定了明确的期望。尽早认可并遵守明确的规则,有助于减少误解,提高生产力;讨论诸如行为规范、沟通、决策、会议礼仪等领域,团队成员可以了解彼此重要的价值观。由团队制定或参与制定的团队章程可发挥最佳效果。所有项目团队成员都分担责任,确保遵守团队章程中规定的规则。可定期审查和更新团队章程,确保团队始终了解团队基本规则,并指导新成员融入团队。

33、测试与评估文件

可基于行业需求和组织模板创建测试与评估文件。它们是控制质量过程的输入,用于评估质量目标的实现情况。这些文件可能包括专门的核对单和详尽的需求跟踪矩阵。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2018年11月16日,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1、活动属性:
  • 2、活动清单:
  • 3、假设日志:
  • 4、估算依据:
  • 5、变更日志:
  • 6、成本估算:
  • 7、成本预算:
  • 8、持续时间估算:
  • 9、问题日志:
  • 10、经验教训登记册:
  • 11、里程碑清单:
  • 12、实物资源分配单:
  • 13、项目日历:
  • 14、项目沟通记录:
  • 15、项目进度计划:
  • 16、项目进度网络图:
  • 17、项目范围书
  • 18、项目团队派工单
  • 19、质量控制测量结果
  • 20、质量测量指标
  • 21、质量报告
  • 22、需求文件
  • 23、需求跟踪矩阵
  • 24、资源分解结构
  • 25、资源日历
  • 26、资源需求
  • 27、风险登记册
  • 28、风险报告
  • 29、进度数据
  • 30、进度预测
  • 31、相关方登记册
  • 32、团队章程
  • 33、测试与评估文件
相关产品与服务
项目管理
CODING 项目管理(CODING Project Management,CODING-PM)工具包含迭代管理、需求管理、任务管理、缺陷管理、文件/wiki 等功能,适用于研发团队进行项目管理或敏捷开发实践。结合敏捷研发理念,帮助您对产品进行迭代规划,让每个迭代中的需求、任务、缺陷无障碍沟通流转, 让项目开发过程风险可控,达到可持续性快速迭代。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档