信息系统项目管理师-项目范围管理

"精准掌控项目边界，告别范围蔓延！" 项目范围管理是确保目标达成的核心，包含五大关键步骤：1. 规划范围管理（制定规则）；2. 收集需求（明确干系人期望）3. 定义范围（细化项目说明书）；4. 创建WBS（分解可交付成果至工作包）；5. 确认范围（验收成果）与6. 控制范围（监控变更）通过定期检查、基准对比和干系人反馈，动态调整范围，避免偏离目标从需求到交付，每一步都需严谨迭代！

项目范围管理

• 一、管理基础
  • 产品范围和项目范围
    • 产品范围
      • 指某项产品、服务或成果所具有的特征和功能。
      • 产品范围的完成情况是根据产品需求来衡量的。
      • “需求”是指根据特定协议或其他强制性规范， 产品、服务或成果必须具备的条件或能力。
    • 项目范围
      • 包括产品范围，是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。
      • 项目范围的完成情况是根据项目管理计划来衡量的。
  • 管理新实践
    • 随着全球项目环境变得日益复杂，项目范围管理的新趋势和 新兴实践更加注重与商业分析师一起合作，以便： 1.确定问题并识别商业需要； 2.识别并推荐能够满足需要的可行解决方案； 3.收集、记录井管理千系人需求满足商业和项目目标； 4.推动项目集或项目产品、服务或最终成果成功应用。
    • 商业分析师的职责还应包括需求管理相关的活动
    • 项目经理则负责确保这些活动列入项目管理计划， 并且在预算内按时完成，同时能够创造价值。
• 二、项目范围管理过程
  • 过程概述
    • 项目范围管理六大过程
      • ①规划范围管理：为了记录如何定义、确认和控制项目范围及产品范围，创建范围管理计划。
      • ②收集需求：为了实现项目目标，确定、记录并管理干系人的需要和需求。
      • ③定义范围：制定项目和产品详细描述。
      • ④创建WBS：将项目可交付成果和项目工作分解为较小的、更易于管理的组件。
      • ⑤确认范围：正式验收已完成的项目可交付成果。
      • ⑥控制范围：监督项目和产品的范围状态，管理范围基准的变更。在项目实际进展中，以上各过程会相互交叠和相互作用。
    • 项目范围管理的输入、工具与技术、输出
  • 裁剪考虑因素
    • 项目经理可能根据需要裁剪范围管理过程的因素有： •知识和需求管理； •确认和控制； •开发方法； •需求的稳定性； •治理
  • 敏捷与适应方法
    • 对于需求不断变化、风险大或不确定性高的项目，在项目开始时通常无法明确项目的范围，而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间，为后续细化范围、明确范围争取更多的时间。
    • 采用敏捷或适应型生命周期，旨在应对大量变更，需要干系人持续参与项目。
    • 采用多次迭代，重复开展三个过程：①收集需求；②定义范围；③创建WBS。
    • 发起人和客户代表应该持续参与项目，重复开展两个过程：①确认范围；②控制范围。
• 三、规划范围管理
  • 规划范围管理：是为了记录如何定义、确认和控制 项目范围及产品范围，而创建范围管理计划的过程。
  • 主要作用
    • 是在整个项目期间对如何管理范围提供指南和方向。
  • 本过程仅开展一次或仅在项目的预定义点开展。
  • 数据分析-备选方案分析
    • 备选方案分析：是一种对已识别的可选方案进行评估的技术，用来决定选择哪种方案或使用何种方法来执行项目工作。
  • 范围管理计划
    • 范围管理计划是项目管理计划的组成部分，描述将如何定义、制定、监督、 控制和确认项目范围。可以是正式或非正式的，非常详细或高度概括的。
    • 范围管理计划用于指导如下过程和相关工作：
      • ①制定项目范围说明书； ②根据详细项目范围说明书创建WBS; ③确定如何审批和维护范围基准； ④正式验收已完成的项目可交付成果。
  • 需求管理计划
    • 需求管理计划是项目管理计划的组成部分，描述如何分析、记录和管理需求。
    • 需求管理计划的主要内容包括：
      • ①如何规划、跟踪和报告各种需求活动； ②配置管理活动，例如，如何启动变更，如何分析其影响， 如何进行追溯、跟踪和报告，以及变更审批权限； ③需求优先级排序过程； ④测量指标及使用这些指标的理由； ⑤反映哪些需求属性将被列入跟踪矩阵等。
• 四、收集需求
  • 收集需求旨在使需求明确化、具体化和书面化；需求必须是可测量的、文档化的。
  • 收集需求：是为实现目标而确定，记录并管理干系人的需要和需求的过程。
  • 主要作用
    • 是为定义产品范围和项目范围奠定基础。
  • 本过程仅开展一次或仅在项目的预定义点开展。
  • 收集需求的重要内容
    • 1、让干系人积极参与需求的探索和分解工作（分解成项目和产品需求）， 并仔细确定、记录和管理对产品、服务或成果的需求，能直接促进项目成功。
    • 2、需求是指根据特定协议或其他强制性规范，产品、服务或成果必须具备的条件 或能力。它包括发起人、客户和其他干系人的已量化且书面记录的需要和期望。
    • 3、需求将作为后续工作分解结构（WBS）的基础，也将作为成本、进度、质量和采购规划的基础。
  • 数据收集
    • 可用于收集需求过程的数据收集技术主要包括：
      • 头脑风暴
        • 是一种用来产生和收集对项目需求与产品需求的多种创意的技术
      • 访谈
        • 是通过与干系人直接交谈，来获取信息的正式或非正式的方法。
      • 焦点小组
        • 是召集预定的干系人和主题专家，了解他们对所讨论的产品、服务或成 果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。
      • 问卷调查
        • 是指设计一系列书面问题，向众多受访者快速收集信息。适用受众多样化， 需要快速完成调查，受访者地理位置分散井且适合开展统计分析的情况。
      • 标杆对照
        • 将实际或计划的产品、过程和实践，与其他可比组织的实践进行比较， 以便识别最佳实践，形成改进意见，并为绩效考核提供依据。
  • 数据分析-文件分析
    • 文件分析：指审核和评估任何相关的文件信息。在此过程中，文件分析用于通过分析现有文件，识别与需求相关的信息来获取需求，可供分析并有助于获取需求的文件包括：协议；商业计划；业务流程或接口文档； 业务规则库；现行流程；市场文献；问题日志；政策和程序、法规文件， 如法律、准则、法令等；建议邀请书；用例等。
  • 决策
    • 适用于收集需求过程的决策技术主要包括：
      • 投票
        • 是一种为达成某种期望结果，而对未来多个行动方案进行 评估的决策技术和过程。本技术用于生成、归类和排序产品需求。
      • 独裁型决策制定
        • 采用这种方法，将由一个人负责为整个集体制定决策。
      • 多标准决策分析
        • 该技术借助决策矩阵，用系统分析方法建立诸如风险水平、 不确定性和价值收益等多种标准，以对众多创意进行评估和排序。
  • 人际关系与团队技能
    • 可用于收集需求过程的人际关系与团队技能主要包括：
      • 名义小组技术
        • 名义小组技术是用于促进头脑风暴的一种技术，通过投票排列 最有用的创意，以便进一步开展头脑风暴或优先排序。
        • 名义小组技术是一种结构化的头脑风暴形式，由四个步骤组成：
          • ①向集体提出一个问题或难题，每个人在沉思后写出自己的想法；
          • ②主持人在活动挂图上记录所有人的想法；
          • ③集体讨论各个想法，直到全体成员达成一个明确的共识；
          • ④个人私下投票决出各种想法的优先排序，通常采用5分制，1分最低，5分最高。为减少想法数量、集中关注想法，可进行数轮投票。每轮投票后，都将清点选票，得分最高者被选出。
      • 观察和交谈
        • 观察和交谈：是指直接察看个人在各自的环境中如何执行工作（或任务） 和实施流程。适用于产品使用者难以或不愿清晰说明他们的需求。
        • 观察也称为“工作跟随”，通常由旁站观察者观察业务专家如何执行工作，但也可以由 “参与观察者”来观察，通过实际执行一个流程或程序，来体验该流程或程序是如何实施的，以便挖掘隐藏的需求。
      • 引导
        • 引导与主题研讨会结合使用，把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。有助于参与者之间建立信任、改进关系、改善沟通，从而有利于干系人达成一致意见并能够更早发现并解决问题。
  • 系统交互图
    • 系统交互图：是对产品范围的可视化描绘，可以直观显示业务系统（过程、 设备、计算机系统等）及其与人和其他系统（行动者）之间的交互方式。
  • 原型法
    • 原型法：是指在实际制造预期产品之前，先造出 该产品的模型，并据此征求对需求的早期反馈。
  • 故事板
    • 故事板是一种原型技术，通过一系列的图像或图示来展示顺序或导航路径。 在软件开发中，故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。
  • 需求文件
    • 需求文件：描述各种单一需求将如何满足项目相关的业务需求。它是逐步细化。只有明确的（可测量和可测试的）、可跟踪的、完整的、相互协调的，且主要干系人愿意认可的需求，才能作为基准。
    • 需求的类别
      • 业务需求
        • 整个组织的高层级需要
      • 干系人需求
        • 干系人的需要
      • 解决方案需求
        • 为满足业务需求和干系人需求，产品、服务或成果必须具备的特性、功能和特征。
        • 解决方案需求又进一步分为功能需求（描述产品应具备的功能）和非功能 需求（是对功能需求的补充，是产品正常运行所需的环境条件或质量要求）
      • 过渡和就绪需求
        • 描述了从“当前状态”过渡到“将来状态”所需的临时能力。
      • 项目需求
        • 项目需要满足的行动、过程或其他条件
      • 质量需求
        • 用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准
  • 需求跟踪矩阵
    • 需求跟踪矩阵是把产品需求从其来源连接到能满足 需求的可交付成果的一种表格。包括以下内容：
      • （1）业务需要、机会、目的和目标； （2）项目目标； （3）项目范围/WBS可交付成果； （4）产品设计； （5）产品开发; （6）测试策路和测试场景；（7）高层级需求到详细需求。
• 五、定义范围
  • 定义范围：是制定项目和产品详细描述的过程。
  • 主要作用
    • 是描述产品、服务或成果的边界和验收标准。
  • 本过程需要在整个项目期间多次反复开展。
  • 定义范围的工具与技术
    • 1、可用于定义范围过程的数据分析技术是备选方案分析。
    • 2、可用于定义范围过程的决策技术是多标准决策分析。
    • 3、可用于定义范围过程的人际关系与团队技能是引导。
    • 4、产品分析：可用于定义产品和服务，包括针对产品或服务提问并回答，以描述要交付产品的用途、特征及其他方面。产品分析技术主要包括：产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。
  • 项目范围说明书
    • 1、项目范围说明书：是对项目范围、主要可交付成果、假设条件 和制约因素的描述。明确指出哪些工作不属于本项目范围。
    • 2、详细的项目范围说明书包括内容有：
      • •产品范围描述：逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。
      • •可交付成果：为完成某一过程、阶段或项目而心须产出的任何独特井可核实的产品、成果或服务能力，可交付成果也包括各种辅助成果，如项目管理报告和文件。对可交付成果的描述可略可详。
      • •验收标准：可交付成果通过验收前必须满足的一系列条件。
      • •项目的除外责任：识别排除在项目之外的内容。明确说明哪些 内容不属于项目范围，有助于管理干系人的期望及减少范围蔓延。
• 六、创建WBS
  • 创建工作分解结构（WBS）：是把项目可交付成果和 项目工作分解成较小、更易于管理的组件的过程。
  • 主要作用
    • 是为所要交付的内容提供架构。
  • 它仅开展一次或仅在项目的预定义点开展。
  • 分解
    • 分解：是一种把项目范围和项目可交付成果 逐步划分为更小、更便于管理的组成部分的技术。
      • 工作包是WBS最低层的工作，可对其成本和持续时间进行估算和管理。
      • 创建WBS的方法多种多样，常用的方法包括自上而下的方法、使用组织 特定的指南和使用WBS模板。自下而上的方法可用于归并较低层次的组件。
  • 分解活动
    • 要把整个项目工作分解为工作包，通常需要开展以下活动：
      • （1）识别和分析可交付成果及相关工作。（2）确定WBS的结构和编排方法。 （3） 自上而下逐层细化分解。（4）为WBS组成部分制定和分配标识编码。 （5）核实可交付成果分解的程度是否恰当。
  • WBS仅为了说明之用。它无意代表任何特定项目的整体项目范围， 也不意味着这是对此类项目组织工作分解结构的唯一方法
  • WBS结构
    • 1、以项目生命周期的各阶段作为分解的第二层， 把产品和项目可交付成果放在第三层。
    • 2、以主要可交付成果作为分解的第二层
    • 3、纳入由项目团队以外的组织开发的各种较低层次组件（如外包工作）。 随后，作为外包工作的一部分，卖方须制定相应的合同WBS
  • 分解注意事项
    • ①WBS必须是面向可交付成果的。
    • ②WBS必须符合项目的范围：WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则，在WBS中，所有下一级的元素之和必须100%表上一级的元素。
    • ③WBS的底层应该支持计划和控制。
    • ④WBS中的元素必须有人负责，而且只有一个人负责。
    • ⑤WBS应控制在4~6层。一个工作单元只能从属于某个上层单元，避免交叉从属。
    • ⑥WBS应包括项目管理工作（因为管理是项目具体工作的一部分），也要包括分包出去的工作。
    • ⑦WBS的编制需要所有（主要）项目干系人的参与。
    • ⑧ WBS并非是一成不变的。
  • 范围基准
    • 范围基准的组成是经过批准的范围说明书、工作分解结构（WBS）和 相应的WBS词典。只有通过正式的变更控制程序才能进行变更这个基准。
  • 工作包
    • 工作包是WBS的最低层，是带有独特标识号的工作包。这些标识号为成本、 进度和资源信息的逐层汇总提供了层级结构，即账户编码。
  • 控制账户
    • 控制账户是一个管理控制点。在该控制点上，把范围、预算和进度加以整合，并与挣值相比较来测量绩效。每个控制账户可能包括一个或多个工作包，但是一个工作包只能属于一个控制账户。
  • 规划包
    • 规划包是一种低于控制账户而高于工作包的工作分解结构组件，工作内容己知， 但详细的进度活动未知，一个控制账户可以包含一个或多个规划包。
• 七、确认范围
  • 确认范围：是正式验收已完成的项目可交付成果的过程。
  • 主要作用
    • ①使验收过程具有客观性；
    • ②通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。
  • 确认范围过程应根据需要在整个项目期间定期开展。
  • 范围确认的一般步骤
    • 1、确定需要进行确认范围的时间
    • 2、识别确认范围需要哪些投入
    • 3、确定范围正式被接受的标准和要素
    • 4、确定确认范围会议的组织步骤
    • 5、组织确认范围会议
  • 质量控制和范围确认
    • 质量控制：核实的可交付成果
    • 范围确认：验收的可交付成果
    • 范围确认与质量控制不同，范围确认是有关工作结果的接受问题，而质量控制是 有关工作结果正确与否，质量控制一般在范围确认之前完成，当然也可并行进行。
  • 项目干系人进行范围确认的内容
    • （1）可交付成果是否确实的、可确认的。
    • （2）每个交付成果是否有明确的里程碑，里程碑是否有明确的、可辨别的事件。
    • （3）是否有明确的质量标准。
    • （4）审核或承诺是否有清晰的表达。
    • （5）项目范围是否覆盖了需要完成的产品或服务的所有活动，有没有遗漏或错误。
    • （6）项目范围的风险是否太高，管理层是否能够降低可预见性的风险对项目的影响。
  • 干系人关注点的不同
    • 确认范围主要是项目干系人（例如，客户、发起人等）对项目的范围 进行确认和接受的工作，每个人对项目范围所关注的方面是不同的：
      • 管理层主要关注项目范围
        • 是指范围对项目的进度、资金和资源的影响，这些因素 是否超过了组织承受范围，是否在投入产出上具有合理性。
      • 客户主要关注产品范围
        • 关心项目的可交付成果是否足够完成产品或服务。
      • 项目管理人员主要关注项目制约因素
        • 关心项目可交付成果是否足够和必须完成，时间、 资金和资源是否足够，主要的潜在风险和预备解决的方法。
      • 项目团队成员主要关注项目范围中自己参与的元素和负责的元素
        • 通过定义范围中的时间，检查自己的工作时间是否足够，自己 在项目范围中是否有多项工作，而这些工作是否有冲突的地方。
  • 核实的可交付成果VS验收的可交付成果
    • 核实的可交付成果是指已经完成，并被控制质量过程检查为正确的可交付成果。
    • 符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件，证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。
  • 可交付成果的时间线
    • 指导与管理项目执行（可交付成果）
    • 质量控制（核实的可交付成果）
    • 范围确认（验收的可交付成果）
    • 结束项目或阶段（最终产品、服务或成果移交）
  • 检查
    • 检查是指开展测量、审查与确认等活动，来判断工作和可交付成果是否 符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。
• 八、控制范围
  • 控制范围：是监督项目和产品的范围状态，管理范围基准变更的过程。
  • 主要作用
    • 在整个项目期间保持对范围基准的维护。
  • 本过程需要在整个项目期间开展。
  • 范围蔓延
    • 范围蔓延：是指未经控制的产品或项目范围的扩大（未对时间、成本和资源做相应调整）。
  • 数据分析
    • 1、可用于控制范围过程的数据分析技术主要包括：偏差分析和趋势分析。
    • 2、趋势分析：旨在审查项目绩效随时间的变化情况，以判断绩效是正在改善还是正在恶化。