Advertisement

【软考】系统集成项目管理工程师(七)项目范围管理

阅读量:
在这里插入图片描述

本文导读

    • 一、范围管理概述
        • 1. 理解范围管理的本质
        • 2. 区分产品范围与项目范围的本质特征
        • 3. 掌握其重要性并了解实施路径

作为项目范围管理的重要组成部分,在项目生命周期中占据关键地位的是六个核心环节:首先包含制定项目范围规划;随后系统地收集各相关方面的项目需求;接着明确项目的具体边界;之后构建工作分解结构(WBS)模型;继而进行最终成果的确认与界定;最后实施对项目规模与界限的有效管控。
这些环节共同构成了完整的"六西格玛"管理体系中关于"确定与监控"的关键步骤。


一、范围管理概述

1. 认识范围管理

项目的具体范围旨在实现项目的既定目标,并提供特定属性的产品与服务以及必要的作业内容。在实施过程中,必须严格遵循范围管理原则,确保只完成指定任务而不超出或遗漏任何部分.该过程主要包括三个主要方面的工作;

  • 明确项目边界
  • 监控项目工作
  • 防止范围蔓延

2. 产品范围与项目范围的区别

商品范围则涵盖产品的特性以及相关的服务项目和最终成果。
项目工作量则指为了实现交付指定产品的特性及所需的服务项目和最终成果所需进行的具体工作。

作为项目的前提条件,产品的定义构成了制定项目的前提条件;而项目的定义构成了制定项目的前提条件;两者在实际运用中存在显著差异;前者决定了后者的发展方向;同时为前者提供必要的支持;

项目的范围基准包含经过批准的 项目范围说明书WBSWBS词典

3. 范围管理的重要性及管理过程

范围管理有助于明确划分项目团队成员的工作职责。通过加强成本预算、进度安排及资源分配的精确把控来提升整体项目的执行效率。避免影响项目的整体规模或工作范围。

项目范围管理涉及的步骤划分为六个具体环节:规划阶段、需求收集阶段、明确边界阶段、创建工作分解结构阶段、确认边界阶段以及控制边界阶段等。这些步骤分别属于五大核心流程中的不同模块:

在这里插入图片描述

二、项目范围管理六大子过程

1. 规划范围管理

范围管理计划可能在项目管理计划中出现也可能单独设立。根据不同项目的不同需求可以选择以详细方案或概述形式存在同时也可以采用正式文件或非正式记录的形式。

规划范围管理子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

范围管理的输出内容中,范围管理计划包含:

  1. 制定项目范围说明书的方法是什么?
  2. 基于范围说明书构建工作分解结构(WBS)的具体步骤是什么?
  3. 对工作分解结构(WBS)进行维护与批准的标准流程是怎样的?
  4. 确保已实现交付成果的标准程序是什么?
  5. 变更管理措施:变更管理流程与整体变更控制体系之间存在怎样的关联?

需求管理计划包含:

以下是按照要求对原文的同义改写

2. 收集需求

在系统架构师角色中进行系统集成项目的成功实施需要满足多个方面的技术要求和能力条件,在这个过程中需要解决的问题包括:如何将分散于不同系统的资源进行整合;如何协调各方利益;如何制定合理的集成方案等。每个系统集成阶段都需要遵循相应的集成标准,并且在每个阶段都需要进行相应的测试工作以确保系统的稳定性和可靠性。

该方案涵盖以下几个关键维度:

  1. 业务方面的需求(主要涉及商业层面的需求)
  2. 相关方的需求
  3. 解决方案方面的需求(包含具体的功能要求和非功能性要求)
  4. 过渡性需求
  5. 项目层面的需求
  6. 质量标准的要求

收集需求子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

需求追踪 被划分为正向追踪与反向追踪两大类。其中正向追踪指的是审查所有项目的需求文档中的每一个具体要求,并确保它们能够在后续的产品交付物中得到相应的体现。作为逆向追踪的一种方法,在项目执行过程中需要回顾所有完成的产品交付物并确认它们均来源于最初的需求文档。

在这里插入图片描述

需求跟踪矩阵 是一种对应的产品需求与可交付成果之间建立联系的技术表格,并通过系统的方式记录和追踪产品全生命周期中的各项需求。该矩阵主要包含以下内容:

  • 业务的核心要素包括业务机会、方向与目标。
  • 项目的重点在于实现主要目标。
  • 项目的范围定义为基于WBS的可交付成果。
  • 产品的规划阶段涵盖了详细的系统设计。
  • 在软件开发流程中,我们将集中精力实现产品的功能模块。
  • 制定全面的测试方案,并明确各种测试条件下的操作规范。

需求跟踪矩阵通常是这样的形式。

在这里插入图片描述

访谈活动 是一种通过与相关人士直接交流获取信息的正式和非正式的方式,并被视为信息收集中最基础的手段之一。其形式主要分为结构化和非结构化两类。

  • 系统性方法是指在处理事务前预先制定好一系列问题进行针对性处理。
    • 非系统性方法则是仅列出一个大致概念,在具体情境下灵活运用。

该方法将被选中的关键利益相关者与领域专家汇聚到一起,并深入探究他们对项目产品的预期效果与个人立场。经过专业培训的一位主持人将引导参与者的互动交流。此方法通常会比一对一 interviews更加活跃热情。与一对一 interviews相比,焦点小组通常会更加活跃热情。该方法是一种群体式的访谈形式而非一对一 interviews,并且一般可容纳6至10名参与者共同探讨问题并分享见解。在提问后,参与者之间展开互动交流以期获得更有深度的意见。

该研讨会旨在通过组织具有关键影响力的战略合作伙伴参与会议并系统性地梳理并明确项目需求。它不仅是一种高效整合各领域资源的技术手段,更是通过消除利益分歧的方式促进各参与方尽快达成共识的过程。相较于单独召开的会议更具优势,在问题识别和解决方案制定上更加高效。
该方法的优势在于加强各领域专家之间的协同工作能力,并在项目启动阶段就建立清晰的目标框架。这种系统性的方法不仅提升了团队的整体效率,也为后续项目的顺利推进奠定了基础。

群体式创新方法 被定义为通过组织一系列群体互动以识别项目需求与产品功能的一种系统化过程。包括但不限于头脑风暴法、名义小组技术、德尔菲技术以及多标准决策分析等多种工具与技巧的综合运用。

该系统设计旨在通过多维度分析实现目标设定与方案筛选,在企业战略管理中发挥重要作用。
通过系统设计能够有效识别关键成功要素,并建立多层次战略模型框架。
该系统设计的主要创新点体现在其多维度分析能力及动态优化机制上。

基准对照有三类不同的形式内部基准对比外部基准对比以及内外部综合基准比较。

系统功能图 用于直观展示产品功能与各组成部分之间的关系网络图形。该图形主要体现不同功能模块间的交互途径和数据流方向,并能清晰地反映出整个系统的运行逻辑和工作流程。在绘制该图表时需要考虑的因素包括:参与者的角色定位以及他们之间的工作协作关系;同时还需要标注各个节点的具体名称以及连接线所代表的功能调用关系等信息点。

3. 定义范围

定义范围是指完成项目和产品详细规范的过程,其核心功能在于明确哪些已收集的需求应纳入项目范围内,哪些则应予以排除,从而界定产品的成果边界. 在需求收集阶段识别的所有潜在需求中,并非所有都应纳入项目范围. 定义范围过程则需要从这些需求文档中筛选出最终确定的项目所需要素,并据此制定详细的项目规格说明.

定义范围子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

项目范围说明书 是对项目范围、主要可交付成果、假设条件和制约因素进行描述的一种说明文件。它不仅包含项目整体情况的概述,还明确了产品的技术规格要求以及相关的制约条件。这种文档的主要组成部分包括以下六个方面:

  1. 项目的总体目标与期望

  2. 可实现的功能模块划分

  3. 关键技术指标与性能参数

  4. 需要满足的性能保障措施

  5. 产品的开发可行性分析

  6. 风险评估与应对策略

  7. 产品实施范围界定

  8. 产品的质量验收规范

  9. 预期可交付成果清单

  10. 项目的排除责任范围

  11. 关键制约因素分析

  12. 项目成功假设前提条件

确定项目的范围是基于产品的定位,请具体涉及以下内容:产品分解、系统分析与设计、需求收集与确认以及系统的功能划分等。

价值工程&价值分析:v=F/C,v 代表价值,f 代表工程,c 代表成本。

备选方案生成 涉及多种创新性方法的整合运用:头脑风暴法、横向思维与纵向思维、配对比较法等技术手段。该技术旨在为项目工作提供多维度的解决方案选择支持

4. 创建工作分解结构(WBS)

划分 WBS 是将项目可交付成果与项目工作细分成为较小且更便于组织管理的部分的过程。其主要目的是对所需交付的内容形成一套结构化的工作框架。基于可交付成果的工作层级分解涉及的团队职责范围包括为实现目标而制定并执行工作计划。

在这里插入图片描述

WBS 将整个项目或主要可交付成果分解为便于管理与控制的多个子项目或工作包(也称工作项)。其中包含里程碑、工作包、控制账户(也称成本账户)、规划包以及WBS词典。

在这里插入图片描述

创建工作分解结构(WBS)子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

分解要开展的活动需要做到以下几点:

  • 识别并系统分析可交付成果及其相关工作内容。
  • 明确WBS结构框架及组织编排方案。
  • 从顶层至底层逐步细化分解过程。
  • 对WBS各子项制定统一编码规范及标识方案。
  • 验证所划分的可交付成果层次是否合理恰当。

分解原则:功能或技术原则、组织结构、系统或者子系统。

分解方式:按生命周期分解、按可交付物分解、按子项目分分解。

WBS 分解后可采用两种呈现形式:一种是以树状结构(组织结构图式)呈现;另一种是以表格形式(列表式)呈现。其中树状结构的特点是层次分明、逻辑清晰且结构稳固;然而该方法具有一定的固定性,在较大或复杂项目中难以全面展现整体情况。相比之下表格形式虽然其直观性相对较弱;但能够完整体现项目的各项核心任务;根据实际需求可灵活采用不同形式结合使用。

分解过程应注意以下几点:

  • 作为面向可交付成果的工作分解结构(WBS),它必须同时满足项目范围的要求。
  • 作为项目的底部分解单元,在设计时就应明确每个工作项的责任归属。
  • 每个WBS元素都应明确由一人负责;避免多人共同承担同一项工作责任。
  • 在制定管理策略时,请依据指导原则进行管理。
  • 作为项目的知识管理系统的一部分,WBS涵盖项目管理活动以及分包工作安排两大部分.
  • 编制过程需获得主要项目干系人与团队成员的支持与认可.
  • 尽管经过编制阶段的工作确定与确认,但在后续实施过程中仍可能对WBS进行必要的更新与优化.

WBS 的主要作用有:

  • 通过清晰界定项目的具体范围和目标来实现精准管理。
  • 明确划分项目的内外界限以确保资源的有效配置。
  • 合理分配人员资源并详细说明各自职责范围。
  • 对各个独立单元进行需求评估并详细规划所需时间和资源预算。
  • 为项目的整体管理制定标准流程并确保进度目标的一致性和可操作性。
  • 建立财务与工作流程之间的紧密联系机制以实现高效管理。
  • 系统地分解项目任务并明确执行步骤与时间安排。
  • 通过科学的方法减少需求扩散的可能性并确保项目顺利推进。

在该子过程的输出内容中,“范围基准 是获得批准后的 范围说明书工作分解结构(WBS) 和相应的 WBS词典 整合而成。变更必须按照既定的程序进行,并作为比较的标准。范围基准是项目管理计划的重要组成部分。

5. 确认范围

确认清单明确了所有属于正式验收项目的文件,并且这些文件必须达到质量合格标准。其核心功能是确保检验流程的公正性。具体操作如下:

  1. 制定时间安排以完成范围确认工作。
  2. 判定进行范围确认所需的投入项目。
  3. 明确正式接受标准及所需要素。
  4. 规划会议流程以确保有序开展。
  5. 执行会议安排并监督其顺利进行。

确认范围子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

在确认范围的过程中,
需确保可交付成果具有明确的确定性,
判断其是否具备关键里程碑,
评估其是否具有明确的质量标准,
审核与承诺的表述是否清晰,
确保项目范围完整无缺,
不存在遗漏或错误。

确认范围主要是由项目干系人(包括客户、发起人等)认可与接纳项目的具体边界工作。由于各个体在项目的参与中所关注的重点存在差异性。例如管理层特别关注项目范围如何影响项目进度、资金使用以及资源分配等方面;而客户则主要关心最终交付的产品或服务是否符合预期质量标准;此外项目经理则会重点检查可交付成果是否按时完成,并评估时间资源的利用情况以及潜在的风险因素;最后团队成员则更关注自己负责的部分是否完成到位。

在确认范围的过程中,有几个概念需要清晰的区分:

确认范围核实产品

在项目尚未完成阶段(即阶没结束时),通过发起人或客户的验证过程来核实产品的完整性(即确定产品是否完成)。这一过程主要关注产品的完成情况(即完整性)。而确认范围则涉及项目的最终 deliverables(即可交付成果),通常由客户或发起人在项目阶段性结束时进行验收确认的过程(即验收环节)。该环节的重点在于评估已实现成果的质量与接受程度。

确认范围质量控制

确认范围着重在于可交付成果能否获得客户或发起人的认可。
质量控制则关注于可交付成果是否符合既定的质量标准。
通常情况下, 质量控制可在确认范围之前开展工作; 同时, 这种活动也不排斥同步推进的可能性。
至于确认范围, 则通常安排在项目阶段的最后; 而关于质量管理, 则并非必须等到阶段结束才实施。
需要指出的是, 质量控制属于内部流程的一部分; 而确认范围则由外部利益相关者负责对项目 deliverable 进行最终检验和认可。

确认范围项目收尾

在当前阶段内,请确保确认范围及项目收尾工作均已完成。其中:

  • 确认范围的核心在于核实并接受可交付的成果;
  • 与此相对应地,
  • 项目收尾则关注于完成项目的流程性工作。
    两者均包含验收环节:
  • 确认范围特别侧重于对可交付成果的验收;
  • 而项目的最终目标则是通过产品来体现这一过程的质量。

6. 控制范围

控制范围的主要功能是确保在整个项目周期内维持对范围基准的管控。其核心目标在于避免镀金现象以及防止范围蔓延的趋势。

控制范围子过程的输入、输出内容及所需工具与技术:

在这里插入图片描述

如果导致了范围变更,通常有以下几个因素:

  • 政策法规层面存在争议或冲突。
  • 项目的规划安排不够全面细致。
  • 市场上出现了新技术/新手段/新方案,并且设计人员也提出了新的技术思路。
  • 项目执行中的组织架构发生了调整。
  • 客户对项目的功能需求和使用体验要求发生了变动。

主要在于寻找影响导致范围变更的因素,并尽力使这些因素朝着有利于项目发展的方向发展。判定范围变更是否已发生。当范围发生变化时需进行相应的处理。确保所有所请的变更均遵循项目整体变化控制流程。


思考:外包是否属于工作分级结构 WBS?

答案是肯定的,外包也需要在 WBS 中反映出来。

全部评论 (0)

还没有任何评论哟~