系统学习项目管理知识，系统性的完善项目管理方法论
项目范围管理概念
- 项目范围管理的含义及作用
项目范围管理就是做项目范围内的事，而且只做范围内的事，既不多做也不少做。
项目范围管理的主要过程
编制范围管理计划过程。对如何定义、确认和控制项目范围的过程进行描述。收集需求。为实现项目目标，明确并记录项目干系人的相关需求的过程。定义范围。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。创建工作分解结构。把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。确认范围。正式验收已完成的可交付成果。范围控制。监督项目和产品的范围状态、管理范围基准变更。
项目范围管理概念
编制范围管理计划是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。编制范围管理计划有助于降低项目范围蔓延的风险。
- 编制范围管理计划过程所用的工具和技术
- 会议
- 专家判断
- 编制范围管理计划过程的输入
- 项目管理计划
- 项目章程
- 组织过程资产
- 事业环境因素
-
编制范围管理计划过程的输出
1.范围管理计划
范围管理计划是项目或项目集管理计划的组成部分，描述了如何定义、制定、监督、控制和确认项目范围。范围管理计划是制定项目管理计划过程和其他范围管理过程的主要依据。范围管理计划要对将用于下列工作的管理过程做出规定:
(1) 制定详细项目范围说明书。
(2) 根据详细项目范围说明书创建WBS。
(3) 维护和批准工作分解结构（WBS)。
(4) 正式验收已完成的项目可交付成果。
(5) 处理对详细项目范围说明书或WBS的变更。该工作与实施整体变更控制过程直接相联。
根据项目需要，范围管理计划可以是正式或非正式的，非常详细或高度概括的。2.需求管理计划
需求管理计划是项目管理计划的组成部分，描述了如何分析、记录和管理需求，以及阶段与阶段间的关系对管理需求的影响。
需求管理计划主要内容包括：
（1）如何规划、跟踪和报告各种需求活动。
（2）配置管理活动，例如，如何启动产品变更，如何分析其影响，如何进行追溯、跟踪和报告，以及变更审批权限。
（3）需求优先级排序过程。
（4）产品测量指标及使用这些指标的理由。
（5）用来反映哪些需求属性将被列入跟踪矩阵的跟踪结构。
（6）收集需求过程。
收集需求
收集需求是为实现项目目标而确定、记录并管理干系人的需要和需求的过程。本过程的主要作用是 为定义和管理项目范围(包括产品范围)奠定基础。
- 收集需求过程的工具和技术
- 访谈 通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈经常是一个访谈者和一个被访者之间的“一对一”谈话，但也可以包括多个访谈者或多个被访者。
- 焦点小组 召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。
- 引导式研讨会 把主要干系人召集在一起，通过集中讨论来定义产品需求。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见。此外，研讨会能够比单项会议更早发现问题，更快解决问题。
- 群体创新技术 组织一些群体活动来识别项目和产品需求。如：头脑风暴法、名义小组技术、名义小组技术等等。
- 群体决策技术 为达成某种期望结果，而对多个未来行动方案进行评估的过程。本技术用于生成产品需求，并对产品需求进行归类和优先级排序。如：一致同意、大多数原则、相对多数原则、独裁。
- 问卷调查 指设计一系列书面问题，向众多受访者快速收集信息。问卷调查方法非常适用于以下情况:受众多样化，需要快速完成调查，受访者地理位置分散，并且适合开展统计分析。
- 观察 观察是指直接察看个人在各自的环境中如何执行工作（或任务〉和实施流程。
- 原型法 指在实际制造预期产品之前，先造出该产品的实用模型，并据此征求对需求的早期反馈。在经过足够的反馈循环之后，就可以通过原型获得足够的需求信息，从而进入设计或制造阶段。
- 标杆对照 将实际或计划的做法（如流程和操作过程〉与其他可比组织的做法进行比较，以便识别最佳实践，形成改进意见，并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的，也可以是外部的。
- 系统交互图 对产品范围的可视化描绘，显示业务系统(过程、设备、计算机系统等〉及其与人和其他系统(行动者)之间的交互方式。系统交互图显示了业务系统的输入、输入提供者、业务系统的输出和输出接收者。
- 文件分析 通过分析现有文档，识别与需求相关的信息，来挖掘需求。
- 收集需求过程输入
- 范围管理计划
- 需求管理计划
- 干系人管理计划
- 项目章程
- 干系人登记册
- 收集需求过程输出
需求文件:描述各种单一需求将如何满足与项目相关的业务需求。需求文件的格式多种多样，既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求文件的主要内容包括:- 业务需求。
- 干系人需求。
- 解决方案需求（质量需求）。
- 项目需求。
- 过渡需求。
- 与需求相关的假设条件、依赖关系和制约因素。
- 需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵，可以把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。需求跟踪矩阵还为管理产品范围变更提供了框架。
需求跟踪包括跟踪以下内容:- 业务需要、机会、目的和目标;
- 项目目标;
- 项目范围/WBS可交付成果;
- 产品设计;
- 产品开发;
- 测试策略和测试场景;
- 高层级需求到详细需求。
范围定义
- 范围定义
定义范围是制定项目和产品详细描述的过程。本过程的主要作用是，明确所收集的需求哪些将包含在项目范围内，哪些将排除在项目范围外，从而明确项目、服务或输出的边界。
范围定义的内容和作用： 定义范围最重要的任务就是详细定义项目的范围边界，范围边界是应该做的工作和不需要进行的工作分界线。定义范围可以增加项目时间、成本和资源估算的准确度，定义项目控制的依据，明确相关责任人在项目中的责任，明确项目的范围、合理性和目标，以及主要可交付成果。 范围定义的输入：- 范围管理计划
- 项目章程
- 需求文件
- 组织过程资产
范围定义的输出： - 项目范围说明书
- 项目文件更新
范围定义的技术和工具： - 产品分析
产品分析旨在弄清产品范围，并把对产品的要求转化成项目的要求。产品分析技术包括产品分解、系统分析、需求分析、系统工程、价值工程和价值分析等。 - 专家判断
- 备选方案生成
备选方案生成是一种用来制定尽可能多的潜在可选方案的技术，用于识别执行项目工作的不同方法。许多通用的管理技术都可用于生成备选方案,如头脑风暴、横向思维、备选方案分析等。 - 引导式研讨会
范围说明书：
项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。项目范围说明书记录了整个范围，包括项目和产品范围。项目范围说明书详细描述项目的可交付成果，以及为创建这些可交付成果而必须开展的工作。包括内容： 项目目标：项目目标包括衡量项目成功的可量化标准。产品范围描述：产品范围描述了项目承诺交付的产品、服务或结果的特征。项目需求：项目需求描述了项目承诺交付物要满足合同、标准、规范或其他强制性文档所必须具备的条件或能力。项目边界：项目边界严格地定义了项目内包括什么和不包括什么，以防有的项目干系人假定某些产品或服务是项目中的一部分。项目的可交付成果：在某一过程、阶段或项目完成时，产出的任何独特并可核实的产品、成果或服务。项目的制约因素：指具体的与项目范图有关的约束条件，它会对项目团队的选择造成限制。假设条件：与范围相关的假设条件，以及当这些条件不成立时对项目造成的影响。
虽然项目章程和项目范围说明书的内容存在一定程度的重叠，但它们的详细程度完全不同。项目章程包括高层级的信息，而项目范围书说明则是对项目范围的详细描述。项目范围需要在项目过程中渐进明细。
创建工作分解结构
创建工作分解结构是把项目可交付成果和项目工作分解成较小的、更易于管理的组件的过程。本过程的主要作用是，对所要交付的内容提供一个结构化的视图。
- WBS的作用和意义
- 通过工作结构分解，把项目范围分解开来，使项目相关人员对项目一目了然，能够使项目的概况和组成明确、清晰、透明和具体。使项目管理者和项目干系人如投资人或客户，都能通过WBS 把握项目、了解和控制项目过程。
- 保证了项目结构的系统性和完整性。因为分解的过程要求包含项目的所有工作，这样才可能在规划和实施项目中保证不会存在遗漏，进而保证了项目的完整性。
- 通过工作结构分解，可以建立完整的项目保证体系，因为这个分解过程将项目的总目标关注的重点，如进度、成本和质量等分解到可控制的各项目单元，便于执行和实现目标要求。
- 项目工作结构分解能够明确项目相关各方的工作界面，便于责任划分和落实。
- 最终工作分解结构，可以直接作为进度计划和控制的工具。
- 为建立项目沟通管理提供依据，便于把握信息重点。
- 是项目各分计划和控制措施制定的基础和主要依据。
- 有助于防止需求和范圉蔓延。
- WBS包含的内容
WBS最低层的工作单元被称为工作包，是我们进行进度安排、成本估算和监控的基础。工作包对相关活动进行归类。- 工作分解结构是用来确定项目范围的，项目的全部工作都必须包含在工作分解结构当中，而且不包含在工作分解结构中的任何工作都不是项目的组成部分，都不能做，否则就是“镀金”。这是工作分解结构百分百规则的要求，即工作分解结构必须且只能包括100%的工作。
- 工作分解结构的编制需要所有项目干系人的参与，需要项目团队成员的参与。
- 工作分解结构是逐层向下分解的。工作分解结构最高层的要素总是整个项目或分项目的最终成果。每下一个层次都是上一层次相应要素的细分，
上一层次是下一层次各要素之和。一般情况下，工作分解结构应控制在3~6层为宜。如果项目比较大，以至于工作分解结构要超过6层，我们可以把大项目分解成子项目，然后针对子项目来做工作分解结构。
工作分解结构中的各要素应该是相对独立的，要尽量减少相互之间的交叉。
当前较常用的工作分解结构表示形式主要有以下两种:
1. 分级的树型结构
类似于组织结构图:树型结构图的WBS层次清晰，非常直观，结构性强，但是不容易修改，对于大型的、复杂的项目也很难表示出项目的全景。
由于其直观性，一般在一些小的、适中的应用项目中用得较多。
2. 表格形式
类似于分级的图书目录:能够反映出项目所有的工作要素，可是直观性较差。但在一些大型的、复杂的项目中使用还是较多的,因为有些项目分解后，
内容分类较多、容量较大，用缩进图表的形式表示比较方便，也可装订为手册。
**里程碑** 里程碑标志着某个可交付成果或者阶段的正式完成。里程碑和可交付成果紧密联系在一起，但并不是一个概念。可交付成果可能包括报告、原型、成果和最终产品，而“里程碑=具体时间+在这个时间应完成的事件”。
**工作包** 工作包是位于工作分解结构每条分支最低层的可交付成果或项目工作组成部分。作为一种经验法则，8/80规则（80小时原则）建议工作包的大小应该至少需要8个小时来完成， 而总完成时间也不应该大于80小时。
**WBS编码设计** 编码设计对于WBS来说是个关键技术。
在制作分解结构的过程中，把每个工作包分配到一个控制账户，并根据账户编码为工作包建立唯一标识，这些标识为进行成本、进度与资源信息的层级汇总提供了层级结构。
控制账户是一个管理控制点。在该控制点上，把范围、预算、实际成本和进度加以整合，并与挣值相比较，以测量绩效。
控制账户设置在WBS中选定的管理节点上。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。
需要生成一些配套的文件，这些文件需要和工作分解结构配合使用，称为工作分解结构词典，
它包括工作分解结构组成部分的详细内容、账户编码、工作说明、负责人、进度里程碑清单等，
还可能包括合同信息、质量要求、技术文献、计划活动、资源和成本估计等。
某个可交付成果，如果具有下列特征之一，就可能被当作为工作包:
1. 规模较小，可以在短时间(80小时）完成。
2. 从逻辑上讲，不能再分了。
3. 所需资源、时间、成本等已经可以比较准确地估算，已经可以对其进行有效的时间、成本、质量、范围和风险控制。
- 创建工作分解结构的工具和技术
- 分解
分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的单元，直到可交付物细分到足以用来支持未来的项目活动定义的工作包。
要把整个项目工作分解为工作包，通常需要开展以下活动:
（1）识别和分析可交付成果及相关工作。
（2）确定WBS的结构和编排方法。
（3）自上而下逐层细化分解。
（4）为WBS组件制定和分配标识编码。
（5）核实可交付成果分解的程度是否恰当。
工作结构分解应把握如下原则:
(1）在层次上保持项目的完整性，避免遗漏必要的组成部分。
(2) 一个工作单元只能从属于某个上层单元，避免交叉从属。
(3）相同层次的工作单元应用相同性质。
(4）工作单元应能分开不同的责任者和不同的工作内容。
(5) 便于项目管理计划和项目控制的需要。
(6）最底层工作应该具有可比性，是可管理的，可定量检查的。
(7）应包括项目管理工作，包括分包出去的工作。
- 分解
- 专家判断
- 创建工作分解结构的输入、输出
- 创建工作分解结构的输入
(1) 项目范围管理计划
(2) 项目范围说明书
(3) 需求文件
(4) 事业环境因素
(5) 组织过程资产 - 创建工作分解结构的输出
范围基准
经过批准的范出说明书、工作分解结构（WBS）和相应的 WBS 词典组成了范围基准，只有通过正式的变更控制程序才能进行变更这个基准，它被用作比较的基础。范围基准是项目管理计划的组成部分，包括:项目范围说明书
WBS
WBS词典
WBS词典是针对每个WBS组件，详细描述可交付成果、活动和进度信息的文件。WBS词典对WBS提供支持。WBS词典中的内容可能至少包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。
- 创建工作分解结构的输入
项目范围确认
确认范围是正式验收已完成的项目可交付成果的过程。确认范围需要审查可交付物和工作成果，以保证项目中所有工作都能准确地、满意地完成。 确认范围应该贯穿项目的始终，从 WBS的确认或合同中具体分工界面的确认，到项目验收时范围的检验。确认范围过程应该以书面文件的形式把它完成情况记录下来。 本过程的主要作用是，使验收过程具有客观性;同时通过验收每个可交付成果，提高最终产品、服务或成果获得验收的可能性。
- 项目范围确认的工作要点
1.制定并执行确认程序
确认范围过程与控制质量过程的不同之处在于，前者关注可交付成果的验收，而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程，但二者也可同时进行。 确认范围的一般步骤:
(1) 确定需要进行确认范围的时间。
(2) 识别确认范围需要哪些投入。
(3) 确定范围正式被接受的标准和要素。
(4) 确定确认范围会议的组织步骤。
(5) 组织确认范围会议。
- 项目干系人对项目范围的正式承认
项目干系人进行确认范围时，一般需要检查以下6个方面的问题:
(1) 可交付成果是否确实的、可确认的或者说可核实的。
(2) 每个交付成果是否有明确的里程碑，里程碑是否明确可辨别的。
(3) 是否有明确的质量标准。
(4) 审核或承诺是否表达清晰。
(5) 项目范围是否覆盖了需要完成的产品或服务进行的所有活动。
(6) 项目范围的风险发生概率，管理层是否能够降低可预见性的风险对项目的影响。
- 项目确认范围的技术和工具
- 检查
检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准， 是否满足项目干系人的要求和期望。 检查有时也被称为审查、产品审查、审计和巡检等。在某些应用领域，这些术语具有独特和具体的含义。
项目范围确认时，项目管理组织必须向客户出示能够明确说明项目或阶段成果的文件，如项目管理文件(计划、控制、沟通等)、技术需求确认书、技术文件、施工图纸等。 当然，提交的验收文件应该是客户已经认可了这个项目产品或某个阶段的文件，他们必须为完成这项工作准备条件。 确认范围完成时，应当对确认中调整的WBS 及WBS词典进行更新。
- 检查
2.群体决策技术
- 项目确认范围的输入、输出
- 确认范围的输入
（1）项目管理计划
（2）需求文件
（3）需求跟踪矩阵
（4）核实的可交付成果：核实的可交付成果是指已经完成，并经质量过程检查为正确的可交付成果。
（5）工作绩效数据 - 确认范围的输出
（1）验收的可交付成果
（2）变更请求
（3）工作绩效信息
（4）项目文件更新
- 确认范围的输入
项目范围控制
-
项目范围控制涉及的主要内容
范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。范围控制过程应该与其他控制过程协调开展。 未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）被称为范围蔓延。变更不可避免，因此在每个项目上，都必须以书面的形式记录并实施某种形式的变更控制管理。本过程的主要作用是，在整个项目期间保持对范围基准的维护。 - 项目范围控制与项目整体变更管理的体系
项目的范围变更控制、管理是对项目中存在的或潜在的变化采用正确的策略和方法来降低项目的风险。
范围变更管理过程中经常遇见的问题包括:项目范围蔓延
很多项目经理都能够意识到大的范围变化，但是对小的范围变化就不那么细心了。因此，在实际工作当中就往往有这样一种趋势， 很多项目经理没有经过认真的思考就把新的工作增加到了项目当中。当这些小的变化都聚合到一起的时候，项目小组才意识到他们承担了太多的超额任务， 已经无法按照原有的时间和预算框架来完成项目了。得不到投资人的批准
客户通常只能提出范围变化的要求，但却没有批准的权力。即使是项目经理也没有批准的权力。 真正拥有这种权力的只有一个人，那就是这个项目的投资人（除非该资助人已经授权给了他人)。项目小组未尽责任
整个项目小组都必须理解范围变化管理的重要性。所有小组成员都必须及时发现项日范围的变化并将其报告给项目经理。 如果他们把所有的额外工作都自己承担,就很可能造成无法按时完成任务的结果,从而危害到整个项目。
-
项目范围控制与用户需求变更的体系
需求基线定义了项目的范围。随着项目的进展，用户的需求可能会发生变化，从而导致需求基线变化以及项目范围的变化。 每次需求变更并经过需求评审后，都要重新确定新的需求基线。项目组需要维护需求基线文档，保存好各个版本的需求基线，以备不时之需。 随着项目的进展,需求基线将越定越高，容许的需求变更将越来越少。 -
项目范围控制涉及所用的技术和工具
偏差分析 - 项目范围控制的输入、输出
- 项目范围控制的输入
(1)项目管理计划
(2)需求文件
(3)需求跟踪矩阵
(4)工作绩效数据
(5)组织过程资产 - 项目范围控制的输出
(1)工作绩效信息
(2)变更请求
(3)项目管理计划更新
(4)项目文件更新
(5)组织过程资产更新
- 项目范围控制的输入
