见 4.3.3.4 节。监督沟通过程往往会导致需要对沟通管理计划所定义的沟通活动进行调整、采取行动和进行干预。变更请求需要通过实施整体变更控制过程(见 4.6 节)进行处理。
此类变更请求可能导致:
项目集管理指在项目集中应用知识、技能与原则来实现项目集的目标,获得分别管理项目集组成部分所无法实现的利益和控制。项目集组成部分指项目集中的项目和其他项目集。项目管理注重项目本身的相互依赖关系,以确定管理项目的最佳方法。项目集管理注重作为组成部分的项目与项目集之间的依赖关系,以确定管理这些项目的最佳方法。项目集和项目间依赖关系的具体管理措施可能包括:
建立一个新的通信卫星系统就是项目集的一个实例,其所辖项目包括卫星与地面站的设计和建造、卫星发射以及系统整合。
关于项目集管理的更多信息,请参见《项目集管理标准》[3]。
整个项目生命周期需要收集、分析和转化大量的数据。从各个过程收集项目数据,并在项目团队内共享。在各个过程中所收集的数据经过结合相关背景的分析、汇总,并加工成项目信息。信息通过口头形式进行传达,或以各种格式的报告存储和分发。关于这一主题的更多信息,请参见 4.3 节。
在整个项目生命周期中需要定期收集和分析项目数据。关于项目数据和信息的主要术语定义如下:
图 1-7 展示了项目管理各个过程中的项目信息流。
图 1-7项目数据、信息和报告流向
项目管理可被看作为实现项目目标而采取的一系列过程和活动。有些过程可能只发生一次(例如项目章程的初始创建),但很多过程在整个项目期间会相互重叠并重复发生多次。这种重叠和多次出现的过程,比如需求变更,它会影响范围、进度或预算,并需要提出变更请求。控制范围过程和实施整体变更控制等若干项目管理过程可包括变更请求。在整个项目期间实施整体变更控制过程是为了整合变更请求。
虽然对项目过程的整合方式没有明确的定义,但如果项目经理无法整合相互作用的项目过程,那么实现项目目标的机会将会很小。
项目整合管理包括对隶属于项目管理过程组的各种过程和项目管理活动进行识别、定义、组合、统一和协调的各个过程。在项目管理中,整合兼具统一、合并、沟通和建立联系的性质,这些行动应该贯穿项目始终。项目整合管理包括进行以下选择:
项目整合管理过程包括:
4.1 制定项目章程 — 编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。
4.2 制定项目管理计划 — 定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合项目管理计划的过程。
4.3 指导与管理项目工作 — 为实现项目目标而领导和执行项目管理计划中所确定的工作,并实施已批准变更的过程。
4.4 管理项目知识 — 使用现有知识并生成新知识,以实现项目目标,并且帮助组织学习的过程。
4.5 监控项目工作 — 跟踪、审查和报告整体项目进展,以实现项目管理计划中确定的绩效目标的过程。
4.6 实施整体变更控制 — 审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。
4.7 结束项目或阶段 — 终结项目、阶段或合同的所有活动的过程。
图 4-1 概述了项目整合管理的各个过程。虽然在本《PMBOK® 指南》中,各项目整合管理过程
以界限分明和相互独立的形式出现,但在实践中它们会以本指南无法全面详述的方式相互交叠和相互作用。
图 4-1项目整合管理概述
项目整合管理的核心概念项目整合管理由项目经理负责。虽然其他知识领域可以由相关专家(如成本分析专家、进度规划专家、风险管理专家)管理,但是项目整合管理的责任不能被授权或转移。只能由项目经理负责整合所有其他知识领域的成果,并掌握项目总体情况。项目经理必须对整个项目承担最终责任。
项目与项目管理本质上具有整合性质,例如,为应急计划制定成本估算时,就需要整合项目成本管理、项目进度管理和项目风险管理知识领域中的相关过程。在识别出与各种人员配备方案有关的额外风险时,可能需要再次进行上述某个或某几个过程。
项目管理过程组的各个过程之间经常反复发生联系。例如,在项目早期,规划过程组为执行过程组提供书面的项目管理计划;然后,随着项目的进展,规划过程组还将根据变更情况,更新项目管理计划。
项目整合管理指的是:
项目越复杂,相关方的期望越多样化,就需要越全面的整合方法。
项目整合管理的发展趋势和新兴实践项目整合管理知识领域要求整合所有其他知识领域的成果。与整合管理过程相关的发展趋势包括(但不限于):
裁剪时需要考虑的因素因为每个项目都是独特的,所以项目经理可能需要裁剪项目整合管理过程。裁剪时应考虑的因素包括(但不限于):
在敏捷或适应型环境中需要考虑的因素迭代和敏捷方法能够促进团队成员以相关领域专家的身份参与整合管理。团队成员自行决定计划及其组件的整合方式。
在适应型环境下,《整合管理的核心概念》中所述的对项目经理的期望保持不变,但把对具体产品的规划和交付授权给团队来控制。项目经理的关注点在于营造一个合作型的决策氛围,并确保团队有能力应对变更。如果团队成员具备广泛的技能基础而不局限于某个狭窄的专业领域,那么这种合作型方法就会更加有效。
制定项目管理计划是定义、准备和协调项目计划的所有组成部分,并把它们整合为一份综合项目管理计划的过程。本过程的主要作用是,生成一份综合文件,用于确定所有项目工作的基础及其执行方式,它仅开展一次或仅在项目的预定义点开展。图 4-4 描述本过程的输入、工具与技术和输出。
图 4-5 是本过程的数据流向图。
图 4-4制定项目管理计划:输入、工具与技术和输出
图 4-5制定项目管理计划:数据流向图
• Projectcharter项目管理计划确定项目的执行、监控和收尾方式,其内容会因项目所在的应用领域和复杂程度而异。
项目管理计划可以是概括或详细的,而每个组成部分的详细程度取决于具体项目的要求。项目管理计划应足够强大,可以应对不断变化的项目环境。这种敏捷性有利于随项目进展产出更准确的信息。
项目管理计划应基准化,即,至少应规定项目的范围、时间和成本方面的基准,以便据此考核项目执行情况和管理项目绩效。在确定基准之前,可能要对项目管理计划进行多次更新,且这些更新无需遵循正式流程。但是,一旦确定了基准,就只能通过实施整体变更控制过程进行更新。在这种情况下,如果需要进行变更,应提出变更请求以待决定。这一过程将形成一份项目管理计划。在项目收尾之前,该计划需要通过不断更新来渐进明细,并且这些更新需要得到控制和批准。
对隶属于项目集或项目组合的项目,则应该制定与项目集或项目组合管理计划相一致的项目管理计划。例如,项目集管理计划中要求超过某一特定成本的所有变更都需要上报变更控制委员会(CCB)审查,在项目管理计划中就应该对审查流程和成本临界值做出相应规定。
项目管理计划是说明项目执行、监控和收尾方式的一份文件,它整合并综合了所有子管理计划和基准,以及管理项目所需的其他信息。究竟需要哪些项目管理计划组件,取决于具体项目的需求。
项目管理计划组件包括(但不限于):
虽然在本过程生成的组件会因项目而异,但是通常包括(但不限于):
项目管理计划是用于管理项目的主要文件之一。管理项目时还会使用其他项目文件。这些其他文件不属于项目管理计划,但它们也是实现高效管理所必需的文件。表 4-1 列出了主要的项目管理计划组件和项目文件。
表 4-1项目管理计划和项目文件
可作为本过程输入的项目文件包括(但不限于):
见 4.6.3.1 节。批准的变更请求是实施整体变更控制过程的输出,包括经项目经理审查和批准的变更请求,必要时可经变更控制委员会 (CCB) 审查和批准。批准的变更请求可能是纠正措施、预防措施或缺陷补救,并由项目团队纳入项目进度计划付诸实施,可能对项目或项目管理计划的任一领域产生影响,还可能导致修改正式受控的项目管理计划组件或项目文件。
工作绩效数据是在执行项目工作的过程中,从每个正在执行的活动中收集到的原始观察结果和测量值。数据通常是最低层次的细节,将交由其他过程从中提炼出信息。在工作执行过程中收集数据,再交由控制过程做进一步分析。
例如,工作绩效数据包括已完成的工作、关键绩效指标 (KPI)、技术绩效测量结果、进度活动的实际开始日期和完成日期、已完成的故事点、可交付成果状态、进度进展情况、变更请求的数量、缺陷的数量、实际发生的成本、实际持续时间等。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中通过变更请求加以更新。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任一组成部分都可在本过程中更新。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。在监控项目工作过程中提出的变更可能会影响整体项目管理计划。
实施整体变更控制是审查所有变更请求、批准变更,管理对可交付成果、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。本过程的主要作用是确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 4-12 描述本过程的输入、工具与技术和输出。图 4-13 是本过程的数据流向图。
图 4-12实施整体变更控制:输入、工具与技术和输出
图 4-13实施整体变更控制:数据流向图
实施整体变更控制过程贯穿项目始终,项目经理对此承担最终责任。变更请求可能影响项目范围、产品范围以及任一项目管理计划组件或任一项目文件。在整个项目生命周期的任何时间,参与项目的任何相关方都可以提出变更请求。变更控制的实施程度,取决于项目所在应用领域、项目复杂程度、合同要求,以及项目所处的背景与环境。
在基准确定之前,变更无需正式受控于实施整体变更控制过程。一旦确定了项目基准,就必须通过本过程来处理变更请求。依照常规,每个项目的配置管理计划应规定哪些项目工件受控于配置控制程序。对配置要素的任何变更都应该提出变更请求,并经过正式控制。
尽管也可以口头提出,但所有变更请求都必须以书面形式记录,并纳入变更管理和(或)配置管理系统中。在批准变更之前,可能需要了解变更对进度的影响和对成本的影响。在变更请求可能影响任一项目基准的情况下,都需要开展正式的整体变更控制过程。每项记录在案的变更请求都必须由一位责任人批准、推迟或否决,这个责任人通常是项目发起人或项目经理。应该在项目管理计划或组织程序中指定这位责任人,必要时,应该由变更控制委员会(CCB)来开展实施整体变更控制过程。CCB 是一个正式组成的团体,负责审查、评价、批准、推迟或否决项目变更,以及记录和传达变更处理决定。
变更请求得到批准后,可能需要新编(或修订)成本估算、活动排序、进度日期、资源需求和(或)风险应对方案分析,这些变更可能要求调整项目管理计划和其他项目文件。某些特定的变更请求,在 CCB 批准之后,可能还需要得到客户或发起人的批准,除非他们本身就是 CCB 的成员。
可用于本过程输入的项目文件包括(但不限于):
为了便于开展配置和变更管理,可以使用一些手动或自动化的工具。配置控制重点关注可交付成果及各个过程的技术规范,而变更控制则着眼于识别、记录、批准或否决对项目文件、可交付成果或基准的变更。
工具的选择应基于项目相关方的需要,包括考虑组织和环境情况和(或)制约因素。工具应支持以下配置管理活动:
工具还应支持以下变更管理活动:
也可以使用工具来管理变更请求和后续的决策,同时还要格外关注沟通,以帮助变更控制委员会的成员履行职责,以及向相关方传达决定。
可用于本过程的数据分析技术包括(但不限于):
可用于本过程的决策技术包括(但不限于):
与变更控制委员会(CCB)一起召开变更控制会。变更控制委员会负责审查变更请求,并做出批准、否决或推迟的决定。大部分变更会对时间、成本、资源或风险产生一定的影响,因此,评估变更的影响也是会议的基本工作。此外,会议上可能还要讨论并提议所请求变更的备选方案。最后,将会议决定传达给提出变更请求的责任人或小组。
CCB 也可以审查配置管理活动。应该明确规定变更控制委员会的角色和职责,并经相关方一致同意后,记录在变更管理计划中。CCB 的决定都应记录在案,并向相关方传达,以便其知晓并采取后续行动。
由项目经理、CCB或指定的团队成员,根据变更管理计划处理变更请求(见 4.3.3.4 节),做出批准、推迟或否决的决定。批准的变更请求应通过指导与管理项目工作过程加以实施。对于推迟或否决的变更请求,应通知提出变更请求的个人或小组。
以项目文件更新的形式,在变更日志中记录所有变更请求的处理情况。
可用于本过程输入的项目文件包括(但不限于):
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围,包括项目和产品范围;详细描述了项目的可交付成果;还代表项目相关方之间就项目范围所达成的共识。为便于管理相关方的期望,项目范围说明书可明确指出哪些工作不属于本项目范围。
项目范围说明书使项目团队能进行更详细的规划,在执行过程中指导项目团队的工作,并为评价变更请求或额外工作是否超过项目边界提供基准。
项目范围说明书描述要做和不要做的工作的详细程度,决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括以下内容(可能直接列出或参引其他文件):
虽然项目章程和项目范围说明书的内容存在一定程度的重叠,但它们的详细程度完全不同。项目章程包含高层级的信息,而项目范围说明书则是对范围组成部分的详细描述,这些组成部分需要在项目过程中渐进明细。表 5-1 显示了这两个文件的一些关键内容。
表 5-1项目章程与项目范围说明书的内容
控制范围是监督项目和产品的范围状态,管理范围基准变更的过程。本过程的主要作用是,在整个项目期间保持对范围基准的维护,且需要在整个项目期间开展。图 5-17 描述本过程的输入、工具与技术和输出。图 5-18 是本过程的数据流向图。
图 5-17控制范围:输入、工具与技术和输出
图 5-18控制范围:数据流向图
控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程(见 4.6 节)进行处理。在变更实际发生时,也要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。变更不可避免,因此在每个项目上,都必须强制实施某种形式的变更控制。
.
工作绩效数据可能包括收到的变更请求的数量、接受的变更请求的数量,或者核实、确认和完成的可交付成果的数量。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
控制成本是监督项目状态,以更新项目成本和管理成本基准变更的过程。本过程的主要作用是,在整个项目期间保持对成本基准的维护。本过程需要在整个项目期间开展。图 7-10 描述本过程的输入、工具与技术和输出,图 7-11 是本过程的数据流向图。
图 7-10控制成本:输入、工具与技术和输出
图 7-11控制成本的数据流向图
要更新预算,就需要了解截至目前的实际成本。只有经过实施整体变更控制过程(见 4.6 节)的批准,才可以增加预算。只监督资金的支出,而不考虑由这些支出所完成的工作的价值,对项目没有什么意义,最多只能跟踪资金流。所以在成本控制中,应重点分析项目资金支出与相应完成的工作之间的关系。有效成本控制的关键在于管理经批准的成本基准。
项目成本控制包括:
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
WBS 词典记录的质量要求可能需要更新。
审计是用于确定项目活动是否遵循了组织和项目的政策、过程与程序的一种结构化且独立的过程。质量审计通常由项目外部的团队开展,如组织内部审计部门、项目管理办公室 (PMO) 或组织外部的审计师。质量审计目标可能包括(但不限于):
采取后续措施纠正问题,可以降低质量成本,并提高发起人或客户对项目产品的接受度。质量审计可事先安排,也可随机进行;可由内部或外部审计师进行。
质量审计还可确认已批准的变更请求(包括更新、纠正措施、缺陷补救和预防措施)的实施情况。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于):
见 4.6.3.1 节。在实施整体变更控制过程中,通过更新变更日志,显示哪些变更已经得到批准,哪些变更没有得到批准。批准的变更请求可包括各种修正,如缺陷补救、修订的工作方法和修订的进度计划。完成局部变更时,如果步骤不完整或不正确,可能会导致不一致和延迟。批准的变更请求的实施需要核实,并需要确认完整性、正确性,以及是否重新测试。
以下会议可作为控制质量过程的一部分:
控制质量过程的一个目的就是确定可交付成果的正确性。开展控制质量过程的结果是核实的可交付成果,后者又是确认范围过程的一项输入(见 5.5 节),以便正式验收。如果存在任何与可交付成果有关的变更请求或改进事项,可能会执行变更、开展检查并重新核实。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括(但不限于)质量管理计划,见 8.1.3.1 节。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。
开展本过程可能导致项目管理计划更新的内容包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于)资源管理计划,见 9.1.3.1 节。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组成部分包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于)相关方参与计划(见 13.2.3.1 节)。需要更新相关方参与计划,反映会影响相关方参与项目决策和执行的任何过程、程序、工具或技术。
可作为本过程输入的项目文件包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可在本过程更新的项目管理计划包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
见 12.3.1.4 节。如果需要从外部采购项目资源,就应该审查初始采购文档,因为从组织外部采购商品和服务可能提高或降低整体项目风险,并可能引发更多的单个项目风险。随着采购文档在项目期间的不断更新,还应该审查最新的文档,例如,卖方绩效报告、核准的变更请求和与检查相关的信息。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。项目管理计划的任何组件都可能受本过程的影响。
合同是对双方都有约束力的协议。它强制卖方提供规定的产品、服务或成果,强制买方向卖方支付相应的报酬。合同建立了受法律保护的买卖双方的关系。协议文本的主要内容会有所不同,可包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
见 4.6.3.1 节。批准的变更请求可能包括对合同条款和条件的修改,例如,修改采购工作说明书、定价,以及对产品、服务或成果的描述。与采购相关的任何变更,在通过控制采购过程实施之前,都需要以书面形式正式记录,并取得正式批准。在复杂的项目和项目集中,变更请求可能由参与项目的卖方提出,并对参与项目的其他卖方造成影响。项目团队应该有能力去识别、沟通和解决会影响多个卖方的工作的变更。
采购文档更新可包括用于支持合同的全部进度计划、已提出但未批准的合同变更,以及已批准的变更请求。采购文档还包括由卖方编制的技术文件,以及其他工作绩效信息,例如,可交付成果的状况、卖方绩效报告和担保、财务文件(包括发票和支付记录),以及与合同相关的检查结果。
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
在项目初始时识别相关方,不会导致项目管理计划更新。但随着项目进展,项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
可用作本过程输入的项目文件(尤其在初始规划之后)包括(但不限于):
可作为本过程输入的项目文件包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
可在本过程更新的项目文件包括(但不限于):
项目管理计划的任何变更都以变更请求的形式提出,且通过组织的变更控制过程进行处理。可能需要变更的项目管理计划组件包括(但不限于):
执行过程组包括完成项目管理计划中确定的工作,以满足项目要求的一组过程。本过程组需要按照项目管理计划来协调资源,管理相关方参与,以及整合并实施项目活动。本过程组的主要作用是,根据计划执行为满足项目要求、实现项目目标所需的项目工作。相当多的项目预算、资源和时间将用于开展执行过程组的过程。开展执行过程组的过程,可能导致变更请求。一旦变更请求获得批准,则可能触发一个或多个规划过程,来修改管理计划、完善项目文件,甚至建立新的基准。
执行过程组(图 4-1)包括第 4.1 节至 4.10 节所列的项目管理过程。
图 4-1执行过程组
监控过程组包括跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更的一组过程。监督是收集项目绩效数据,计算绩效指标,并报告和发布绩效信息。控制是比较实际绩效与计划绩效,分析偏差,评估趋势以改进过程,评价可选方案,并建议必要的纠正措施。本过程组的主要作用是,按既定时间间隔、在特定事件发生时或在异常情况出现时,对项目绩效进行测量和分析,以识别和纠正与项目管理计划的偏差。监控过程组还涉及:
持续的监督使项目团队和其他相关方得以洞察项目的健康状况,并识别需要格外注意的方面。
在监控过程组,需要监督和控制在每个知识领域、每个过程组、每个生命周期阶段以及整个项目中正在进行的工作。监控过程组(图 5-1)包括 5.1 节至 5.12 节所列的项目管理过程。
图 5-1监控过程组
实施整体变更控制是指审查所有变更请求,批准变更,管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更,并对变更处理结果进行沟通的过程。本过程审查对项目文件、可交付成果或项目管理计划的所有变更请求,并决定对变更请求的处置方案。本过程的主要作用是,确保对项目中已记录在案的变更做综合评审。如果不考虑变更对整体项目目标或计划的影响就开展变更,往往会加剧整体项目风险。本过程需要在整个项目期间开展。图 5-3 描述了本过程的输入和输出。
图 5-3实施整体变更控制:输入和输出
究竟需要哪些项目管理计划组件和项目文件,取决于具体项目的需求。
监控过程组指的是跟踪、审查和调整项目进展与绩效,识别必要的计划变更并启动相应变更所需的一组过程。
在迭代型、敏捷型和适应型方法中,通过维护未完项清单,对进展和绩效进行跟踪、审查和调整。在项目团队的协助(分析并提供有关技术依赖关系的信息)下,业务代表对未完项进行优先级排序。基于业务优先级和团队能力,提取未完项清单最前面的任务,供下一个迭代期完成。业务代表在听取项目团队的技术意见之后,评审变更请求和缺陷报告,排列所需变更或补救的优先级,并列入工作未完项清单。
这种把工作和变更列入同一张清单的做法,起源于充满变更的项目环境。在这种项目环境中,无法把变更从原先计划的工作中分离出来。把变更和原先的工作整合到一张未完项清单中,就便于对全部工作进行重新排序,也能够为相关方管理和控制项目工作、实施变更控制和确认范围提供单一的平台。
随着排定了优先级的任务和变更从未完项清单中提取出来,并通过迭代加以完成,就可以测算已完成工作的趋势和指标,以及变更工作量和缺陷率。通过在短期迭代中频繁抽样,计算变更影响的数量和缺陷补救工作量,就可以对照原来的范围来考察团队能力和工作进展。这样一来,就能基于实际的进展速度和变更影响来估算项目成本、进度和范围。
应该借助趋势图表(信息扩散器)与项目相关方分享这些指标和预测,以便沟通进展情况、共同面对问题、推动持续改进,以及管理相关方期望。