大家好,又见面了,我是你们的朋友全栈君。
一、范围管理的基本理解
(1)包括确保项目做且只做所需的全部工作,已成功完成项目的各个过程。
(2)项目范围管理需要做的工作
》明确项目边界。
》对项目执行工作进行监控。
》防止项目范围发生蔓延。指对时间、成本和资源做相应调整,未经控制的产品或项目范围的扩大。
(3)产品范围和项目范围
》产品范围:产品、服务或结果的特性和功能。
》项目范围:是否完成以项目管理计划、项目范围说明书、WBS、以及WBS字典作为衡量标准。产品范围是否完成以产品需求说明书作为衡量标准。
二、规划范围管理
1、项目范围管理计划的内容
(1)如何制定项目范围说明书。
(2)如何根据范围说明书创建WBS。
(3)如何维护和批准WBS。
(4)如何确认和正式验收已完成的项目可交付成果。
(5)如何处理项目范围说明书的变更,该工作与实施整体变更控制过程直接相联。
2、需求管理计划的内容
(1)如何规划、跟踪和汇报各种需求活动。
(2)需求管理需要使用的资源。
(3)培训计划。
(4)项目干系人参与需求管理的策略。
(5)判断项目范围与需求不一致的准则和纠正规程。
(6)需求跟踪结构,即哪些需求属性将列入跟踪矩阵,并可在其他哪些项目文件中追踪到这些需求。
(7)配置管理活动。
三、收集需求
1、需求的分类
(1)业务需求:整个组织的高层级需要。
(2)干系人需求:是指干系人或干系人群体的需要。
(3)解决方案需求:是为满足业务需求和干系人需求、分为功能需求和非功能需求。
(4)过渡需求:例:数据转换和培训需求。
(5)项目需求。
(6)质量需求:QFD对质量需求进行了细分、分为基本需求、期望需求和意外需求。
2、焦点小组:选定干系人和主题专家集中,了解产品、服务或成果的期望和态度。
3、引导式研讨会:邀请主要的跨职能干系人一起参加会议,对产品需求集中讨论与定义。
4、群体创新技术:组织群体活动识别项目和产品需求,创新技术包括:头脑风暴、名义小组技术、德尔菲技术、概念/思维导图、亲和图和多标准决策分析 标杆对照、群体决策技术、系统交互图(DFD)、文件分析等。
5、需求文件内容
(1)业务需求。
(2)干系人需求。
(3)解决方案需求,包括功能和非功能需求、技术和标准合规性需求、支持和培训的需求、质量需求和报告需求。
(4)项目需求,包括服务水平、绩效、安全和合规性等,以及验收标准。
(5)过渡需求。
(6)与需求有关的假设条件、依赖关系和制约因素。
6、需求跟踪
(1)具有双向可跟踪性。正向跟踪和反向跟踪。正向跟踪:从需求文件中检查每个需求是否能在后继工作产品成果中找到对应点。反向跟踪也称逆向跟踪,是指从设计文档、产品构件、测试文档等工作成果中找到出处。
(2)正向跟踪:用户原始需求追踪到后继工作产品成果;反向跟踪:后继工作产品追踪到原始需求;需求文件之间的跟踪:处理各种需求之间的逻辑相关性,检查需求分解中可能出现的错误或遗漏。
7、需求跟踪矩阵
(1)主要用于需求和其他产品元素之间的联系链。
(2)将产品需求从其来源连接到能满足需求的可交付成果的一种表格。有助于确保需求文件中被批准的每项需求在项目结束是都能交付。
三、定义范围
(1)详细描述项目和产品的过程,输出详细的项目范围说明书。范围定义是一个反复的过程。
(2)作用:明确所收集的需求哪些将包含在项目范围内,哪些排除在项目范围外,从而明确产品、服务或成果的边界。
1、需求文件
(1)业务需求。
(2)干系人需求。
(3)解决方案需求。
(4)项目需求。
(5)过渡需求。
2、产品分析:
(1)产品分解。
(2)系统分析。
(3)需求分析。
(4)系统工程。
(5)价值工程和价值分析。
3、备选方案生成:用来识别执行项目工作的不同方法。例:头脑风暴、横向思维、备选方案分析等。
4、项目范围说明书
(1)描述:项目范围、主要交付成果、假设条件和制约因素。详细描述了项目的可交付物和产生这些可交付物所必须做的工作。
(2)作用:1、确定范围;2、沟通基础;3、规划和控制依据;4、变更基础;5、规划基础。
(3)内容:1、产品范围描述;2、验收标准;3、可交付成果;4、项目的除外责任;5、制约因素;6、假设条件。
四、创建工作分解结构
(1)逐步分层分解为更小的、更易于管理的项目单元。
(2)WBS是以结果为导向的分析方法,用于分析项目所涉及的工作。WBS的最底层的工作单元被称为工作包
1、WBS的作用和意义
(1)使相关人员对项目一目了然,使项目的概况和组成、明确、清晰、透明和具体。
(2)保证了项目结构的系统性和完整性。
(3)可以建立完整的项目保证体系。
(4)能够明确相关各方的工作界面,便于责任划分和落实。
(5)作为进度计划和控制的工具。
(6)为建立沟通管理提供依据。
(7)项目各分计划和控制措施制定的基础和依据。
(8)防止需求和范围蔓延。
2、WBS表现形式
(1)树形:层次清晰、直观、结构性强、不容易被修改、应用于中小型项目中。
(2)表格:反应项目所有的工作要素、直观性差,应用于大型、复杂的项目。
3、WBS的分解:将项目可交付物分成更小的、更易管理的单元,直至可交付物细分到足以支持未来的、清晰定义项目活动的工作包。
4、WBS的工作包:位于WBS每条分支最底层的可交付成果或项目工作组成部分,它是定义工作范围、定义项目组织、设定项目产品的质量和规格、估算和控制费用、估算时间周期和安排进度的基础。
5、里程碑:标志着某个可交付成果或阶段的正式完成。
6、滚动式计划:近期的工作计划得细一些,远期的工作计划相对粗一些。依据:项目的规模、复杂度及项目生命周期的长短。
7、分解步骤
(1)识别和分析可交付成果及相关工作。
(2)确定WBS的结构和编排方法。
(3)自上而下逐层细化分解。
(4)为WBS组件制定和分配标识编码。
(5)核实可交付成果分解的程度是否恰当。
8、分解原则
(1)功能或者技术原则(将不同人员的工作分开)。
(2)组织结构(要适应组织结构形式)。
(3)系统或者子系统(总系统划分为子系统,子系统再进行分解)。
9、控制账户:简称CA,是一种管理控制点,是工作包的规划基础。为工作包建立控制账户,并根据“账户编码”分配标志号,是创建工作分解结构的最后步骤。
10、规划包:是指在控制账户之下,工作内容已知但尚缺详细进度活动的WBS组成部分。也就是说,规划包是在控制账户之下、工作包之上的WBS要素。
11、创建WBS过程:WBS不是某个项目团队成员的责任,应该由全体项目团队成员、用户和项目干系人共同完成和一致确认。1、编制高层工作分解结构;2、分配管理层职责;3、分解工作分解结构;4、分配职责;5、编写项目范围说明书;6、审批工作分解结构;7、批准的工作分解结构。
12、分解WBS注意事项
(1)必须面向可交付成果。
(2)必须符合项目的范围。
(3)底层应该支持计划和基础。
(4)中的元素必须有人负责,而且只由一个人负责,尽管实际上可能需要多个人参与。
(5)作为指导而不是原则,应该控制4~6层。同一级的元素大小应该相似。一个工作单元只能从属于某个上层单元,避免交叉从属。
(6)包括项目管理工作(因为管理是项目具体工作的一部分),也要包括分包出去的工作。
(7)编制需要所有主要项目干系人的参与,需要项目团队成员的参与。
(8)WBS并非一成不变的。
13、WBS词典:详细的可交付成果、活动和进度信息的文件。内容至少包括:账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息。
14、范围基准(范围基线):被批准的详细的项目范围说明书、WBS、WBS词典是项目的范围基准。
五、确认范围
(1)客户等项目干系人正式验收并接受已完成的项目可交付物的过程。贯穿于项目始终。作用:使验收过程具有客观性;同时通过验收每个可交付成果,提高最终产品、服务或成果获得验收的可能性。
(2)确认项目范围时,项目管理团队必须向客户方出示能够明确说明项目(或项目阶段)成果的文件。
1、确认范围的一般步骤
(1)确定需要进行确认范围的时间。
(2)识别确认范围需要哪些投入。
(3)确定范围正式被接受的标准和要素。
(4)确定确认范围会议的组织步骤。
(5)组织确认范围会议。
2、确认范围和项目收尾
(1)确认范围:强调的是核实与接受可交付成果,项目收尾:强调结束项目(或阶段)所做的流程性工作。确认范围:强调验收的可交付成果,项目收尾:强调验收产品。
3、确认范围和核实产品
(1)核实产品:针对产品是否完成,确认范围:针对项目可交付成果。
4、确认范围和质量控制
(1)确认范围:强调可交付成果获得客户或发起人的接受;质量控制:强调可交付物的正确性,并符合为其制定的具体质量要求(质量标准)。
(2)质量标准:在确认范围前进行,也可同时进行;确认范围:在阶段末尾进行。
(3)质量控制:内部检查;确认范围:外部干系人(客户或发起人)对项目可交付成果进行过检查验收。
5、群体决策技术:为达成某种期望的结果,而对多个未来行动方案进行评估的过程。本技术用于生产产品需求,并对产品需求进行归类和优先级排序。方法:一致同意(德尔菲技术)、大多数原则(超过50%人员的支持)、相对多数原则(根据群体中相对多数者的意见做出决策、候选项超过两个时使用)、独裁。
六、控制范围
1、控制范围
(1)监控项目和产品的范围状态、管理范围基准变更的过程,也是控制变更的过程。
(2)控制项目范围以确保所有的请求变更和推荐的纠正行动,都要通过整体变更控制过程处理。
(3)当变更发生并且集成到其他控制过程时,项目范围控制也被用来管理实际的变更。经常把未经控制的产品或项目范围的扩大作为项目“范围蔓延”。
2、范围控制涉及的内容:影响引起范围变更的因素,确保所有被请求的变更按照项目整体变更控制处理,范围变更发生是管理实际的变更。
3、项目范围变更的主要原因
(1)政府政策问题。
(2)项目范围的计划编制不周密详细,有一定的错误或遗漏。
(3)市场上出现了或是设计人员提出了新技术、新手段或新方案。
(4)项目实施方本身发生变化。
(5)客户对项目、项目产品或服务的要求发生变化。
4、范围变更控制的工作
(1)影响导致范围变更的因素,并尽量使这些因素向有利的方面发展。
(2)判断范围变更是否已经发生。
(3)范围变更发生时管理实际的变更,确保所有被请求的变更按照项目整体变更控制过程处理。
5、变更控制系统
(1)管理变更的一套系统,是一套用于对项目范围做出变更的程序,包括文书工作,跟踪系统以及授权变更所需的认可。
(2)包含变更流程、变更文件、纠正行动、由变更控制委员会CCB批准或者拒绝变更请求。
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/125295.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...