@henri001
2016-02-03T07:13:05.000000Z
字数 9548
阅读 326
学习笔记
在项目管理过程组的各过程间，经常反复发生联系。
制定项目章程是编写一份
正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。本过程的主要作用是，明确定义项目的开始和项目边界，确立项目的正式地位，以及高级管理层直述他们对项目的支持。
项目章程在项目执行组织和需求组织之间建立起伙伴关系。
经批准的项目章程意味着项目的正式启动。在项目中，应尽早确认并任命项目经理，最好在制定项目章程时就任命，最晚也必须在规划开始之前。项目章程应该由发起项目的实体批准。
项目由项目以外的实体来启动，项目启动者或发起人应该具有一定的职权，能为项目获取资金并提供资源。不要把项目章程看成合同，因为其中未承诺报酬或金钱或用于交换的代价。
项目工作说明书（Statement of Work,SOW）是对项目需交付的产品、服务或者成果的叙述性说明。
对于外部项目，项目工作说明书由客户提供，可以是招标文件（如建议邀请书、信息邀请书、投标邀请书）的一部分，或合同的一部分。
SOW包括内容：业务需要、产品范围描述、战略计划
商业论证或者类似文件能从商业角度提供必要的信息，决定项目是否值得投资。
项目经理负责确保项目有效的满足在商业论证中规定的组织目的和广大干系人的需求。
协议定义了启动项目的初衷。
通常，为外部客户做项目时，用合同。
专家判断可来自具有专业知识或受过专业培训的任何小组和个人，可从许多渠道获取。
头脑风暴、冲突处理、问题解决和会议管理等。
在项目章程中记录业务需要、假设条件、制约因素、对客户需要和高层级需求的理解，以及需要交互的新产品、服务或成果。
例如：
定义、准备和协调所有子计划，并把它们整合为一份综合项目管理计划的过程。
主要作用:生成一份核心文件，作为所有项目工作的依据
本过程将产生一份项目管理计划，该计划需要通过不断更新来渐进明细，这些更新需要由实施整体变更控制过程进行控制和批准。
项目章程至少应该定义项目的高层级边界。
配置管理知识库，包括组织标准、政策、程序和项目文件的各种版本和基准。
根据项目需要而剪裁项目管理过程
项目管理计划是说明项目将如何执行、监督和控制的一份文件。它合并与整合了其它各规划过程所输出的所有自管理计划和基准。
项目基准包括（但不限于）：范围基准、进度基准、成本基准
子管理计划包括（但不限于）：范围管理计划、需求管理计划、进度管理计划、成本管理计划、质量管理计划、过程改进计划、人力资源管理计划、沟通管理计划、风险管理计划、采购管理计划、干系人管理计划。
项目管理计划可以是概括或详细的。项目管理计划一旦被确定为基准，就只有在提出变更请求并经实施整体变更控制过程批准后，才能变更。
是为实现项目目标而领导和执行项目管理计划中所确定的工作，并实施已批准变更的过程。
指导和管理项目工作还须对项目所有的变更的影响进行审查，并实施已批准的变更，包括：
批准的变更请求是
实施整体变更控制过程的输出，包括那些经变更控制委员会审查和批准的变更请求。批准的变更请求可能是纠正措施、预防措施或缺陷补救。
如项目管理信息系统（自动化工具、进度计划软件）
项目管理信息系统提供工具：进度计划工具、工作授权系统、配置管理系统、信息收集与发布系统、或进入其它在线自动化系统的网络界面。
会前，应该做好准备工作，包括确定会议议程、目的、目标和期限；会后，要形成书面的会议纪要和行动方案。
可交付成果是指在某一过程、阶段或者项目完成时，必须产出的任何独特并可核实的产品、成果或服务能力。
可交付成果通常是为实现项目目标而完成的有形的组件。
从每个正在执行的活动中收集到的原始观察结果和测量值。数据是指最底层的细节，将由其它过程中提炼出项目信息。
变更请求是关于修改任何文档、可交付成果或基准的正式提议。
变更请求可以是直接或间接的，可以由外部或者内部提出，可能是自选或由法律/合同所强制的。
监控项目工作是跟踪、审查和报告项目进展，以实现项目管理计划中确定的绩效目标的过程。
监督是贯穿于整个项目的项目管理活动之一。
见6.7.3.2节，基于实际进展与进度基准的比较而计算出进度预测。
见7.4.3.2节，基于实际进展与成本基准的比较而计算出的完工尚需估算（ETC）
见8.3.3.2节，批准的变更是实施整体变更控制过程的结果。
工作绩效数据转化为工作绩效信息
采用分析技术来预测潜在的结果。
包括：根本原因分析、故障树分析、储备分析、挣值管理
会议可以是面对面或虚拟会议，正式或非正式会议。
变更请求可能导致需要搜集和记录新的需求。
工作绩效报告是为制定决策、采取行动或引起关注而汇编工作绩效信息所形成的
实物或电子项目文件。
实施整体变更控制是审查所有变更请求、批准变更，管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更，并对变更处理结果进行沟通的过程。
实施整体变更控制过程贯穿项目始终，项目经理对此负最终责任。
应该通过否决或批准变更，来确保只有经批准的变更才能纳入修改后的基准中。
项目的任何干系人都可以提出变更请求。尽管也可以口头提出，但所有的变更请求都必须以书面形式记录。
变更请求应该由变更控制系统和配置控制系统中规定的过程进行处理。应该评估变更对时间和成本的影响，并向这些过程提供评估结果。
每项记录在案的变更请求都必须由一位责任人批准或否决，这个责任人通常是项目发起人或项目经理。
必要时，应该由变更控制委员会（CCB）来开展实施整体变更控制过程。CCB是一个正式组成的团体，负责审查、评价、批准、推迟或否决项目变更，以及记录和传达变更处理决定。
某些特定的变更请求，在CCB批准之后，还可能需要得到客户或者发起人的批准，除非他们本来就是CCB的成员。
配置控制重点关注可交付成果及各个过程的技术规范。
所有监控过程及很多执行过程都会输出“变更请求”。变更请求可能包括纠正措施、预防措施和缺陷补救。但是，纠正和预防措施通常不会影响项目基准，而只影响相对于基准的项目绩效。
通常是指变更控制会议。
CCB的决定都应记录在案，并向干系人传达，以便其知晓并采取后续措施。
全部变更请求的处理结果，无论批准与否，都要在变更日志中更新。这种更新是项目文件更新的一部分。
变更日志用来记录项目过程中出现的变更。
被否决的变更请求也应该记录在变更日志中。
结束项目或阶段是完结所有项目管理过程组的所有活动，以正式结束项目或阶段的过程。
主要作用：总结经验教训、正式结束项目工作、为开展新工作而释放组织资源。
项目经理需要审查范围基准，确保在项目工作全部完成后才宣布项目结束。如果项目在完工前就提前终止，结束项目或阶段还需要制定程序，来调查和记录提前终止的原因。
项目管理计划相当于项目经理和项目发起人之间的协议，其中规定了项目完工的标准。
验收的可交付成果可能包括标准的产品规范，交货收据和工作绩效文件。
专家判断用于开展行政收尾活动。由相关专家确保项目或阶段收尾符合适用标准。
可用于项目收尾的分析技术有：回归分析、趋势分析
需要更新的组织过程资产包括（但不限于）：
项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。
管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。
“范围”的含义：
经过批准的项目范围说明书、工作分解结构（WBS）和相应的WBS词典构成项目范围基准。
规划范围管理是创建范围管理计划，书面描述将如何定义、确认和控制项目范围的过程。
本过程的主要作用是：在整个项目中对如何管理范围提供指南和方向。
项目章程提供了高层级的项目描述和产品特征。产品特征出自项目工作说明书。
专家判断、会议
范围管理计划是项目或项目集管理计划的组成部分，描述将如何定义、制定、监督、控制和确认项目范围。
需求管理计划是项目管理计划的组成部分，描述将如何分析、记录和管理需求。
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。
需求是指根据特定协议或其他强制性规范，项目必须满足的条件或能力，或者产品、服务或成果必须具备的条件或能力。
需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。
需求将成为工作分解结构（WBS）的基础。需求也是成本、进度和质量规划的基础，有时也是采购工作的基础。
解决方案需求：分为功能需求和非功能需求。功能需求是产品能开展的行为；非功能需求是对功能需求的补充，是产品正常运行所需的环境条件或质量。
范围管理计划、需求管理计划、干系人管理计划、项目章程、干系人登记册
访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。
焦点小组是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的预期和态度。
引导式研讨会把主要的干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。
有利于干系人达成一致意见，此外，研讨会能够比单项会议更早发现问题，更快解决问题。
可以组织一些群体活动来识别项目和产品需求。
常用的群体创新技术：
多种创意的技术群体决策技术就是为达成某种期望结果，而对多个未来行动方案进行评估的过程。
群体决策的方法举例：一致同意、大多数原则、相对多数原则、独裁
观察，也成为“工作跟踪”，通常由观察者从外部来观看业务专家如何执行工作。
原型法是指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。
原型法支持渐进明细的理念，需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环的过程。
故事板是一种原型技术，通过一系列的图像或图示来展示顺序或者导航路径。
识别最佳实践，形成改进意见
系统交互图是范围模型的一个例子，它是对产品范围的可视化描绘。
文件分析就是通过分析现有文档，识别与需求相关的信息，来挖掘需求。
只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
需求文件的主要内容包括（但不限于）：业务需求、干系人需求、解决方案需求、项目需求、过度需求、与需求相关的假设条件、依赖关系和制约因素。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
有助于确保每个需求都有商业价值。
需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法。
定义范围是制定项目和产品详细描述的过程。
定义范围过程就要从需求文件（收集需求过程的输出）中选取最终的项目需求。
范围管理计划、项目章程、需求文件、组织过程资产
对于那些以产品为可交付成果的项目（区别于提供服务或成果的项目），产品分析是一种有效的工具。
产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。
备选方案生成是一种用来制定尽可能多的潜在可选方案的技术。
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。
项目范围说明书也代表项目干系人之间就项目范围所达成的共识。
项目章程包括高层级的信息，而项目范围书说明则是对项目范围的详细描述。项目范围需要在项目过程中渐进明细。
可能需要更新的项目文件包括（但不限于）：干系人登记册、需求文件、需求跟踪矩阵
创建工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。
本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
WBS组织并定义了项目的总范围。
WBS最低层的组件被称为工作包，其中包括计划的工作。
范围管理计划、项目范围说明书、需求文件、事业环境因素、组织过程资产
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。
工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。
分解的程度取决于所需的控制程度，以实现对项目的高效管理。
工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下、工作实施效率降低，同时造成WBS各层级的数据汇总困难。
通过把WBS底层的所有工作逐层向上汇总，来确保既没有遗漏的工作，也没有多余的工作。这有时被称为100%规则。
范围基准是经过批准的范围说明书、工作分解结构（WBS）和相应的WBS词典
范围基准是项目管理计划的组成部分，包括：项目范围说明书、WBS、WBS词典
WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。
控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
一个控制账户可以包含一个或多个规划包。规划包也是WBS的组件，位于控制账户之下，工作内容已知，但详细的进度活动未知。
WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。
确认范围是正式验收已完成的项目可交付成果的过程。
本过程的主要作用是，使验收过程具有客观性；同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。
项目管理计划、需求文件、需求跟踪矩阵、核实的可交付成果、工作绩效数据
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。
符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。
其他输出：变更请求、工作绩效信息、项目文件更新
控制范围是监督项目和产品的范围状态，管理范围基准变更的过程。
本过程的主要作用是，在整个项目期间保持对范围基准的维护。
未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须强制实施某种形式的变更控制。
项目管理计划、需求文件、需求跟踪矩阵、工作绩效数据、组织过程资产
偏差分析是一种确定实际绩效与基准的差异程度及原因的技术。可利用项目绩效测量结果评估偏离范围基准的程度。
本过程产生的工作绩效信息是有关项目范围实施情况（对照范围基准）的、相互关联且与各种背景相结合的信息
变更请求、项目管理计划更新、项目文件更新、组织过程资产更新
项目时间管理包括为管理项目按时完成所需的各个过程。