【学习笔记】IT项目管理2:IT项目的范围管理
作者:互联网
项目范围管理概述
- 缺少正确的项目需求、定义和范围核实是导致项目失败的主要原因。
- 目前IT项目的问题是项目需求与范围的不确定性和易动性。
- IT人员缺乏对企业信息化的深刻理解,他们更多地把视角放在技术上面,而忽视了对企业需求获得能力和信息化的感悟能力的造就。
- IT项目的成功从需求开始,优秀的需求分析与设计人员是IT成功之本。
一、项目范围与项目范围管理
1、项目范围的定义
- 项目范围是指产生项目产品所包括的所有工作及产生这些产品经过的所有过程。
- 项目范围的定义包括两个方面的含义:
- 项目产品范围——某项产品、服务或成果所具有的特性和功能。对项目产品范围完成的衡量标准根据客户需求来进行。
- 项目工作范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。对项目工作范围完成的衡量标准根据项目范围管理计划来检验。
2、项目范围管理的定义
- 项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程。项目范围管理主要在于定义和控制哪些工作应包括在项目内,哪些不应包括在项目内。 ——PMBOK 2008
- 确保项目包括且仅包括所要求的工作(交付成果)
- 项目范围管理的主要任务——保证项目利益相关者在项目要产生什么样的可交付成果方面达成共识,也要在如何生产这些可交付成果方面达成共识。
- 应该将项目产品范围与项目工作范围的管理很好地结合,以确保项目工作可以得到项目的最终可交付成果。
3、项目范围管理的作用
-
为项目实施提供任务范围的框架。
- 项目范围及其构成(WBS及其词典)
- 排除对于与完成项目目标无关的工作。
-
对项目的实施提供有效的控制。
-
实时跟踪项目范围绩效水平,计算偏差;
-
根据偏差产生的损益,决定是放弃项目以免造成更大的损失,还是对范围进行调整,确定新的范围目标。
-
为项目最终交付提供依据。
-
-
原则:清楚理解项目的范围,是项目取得成功的基石!
4、项目范围原理
5、项目范围管理的步骤
- 把客户的需求转变为对项目产品的定义。
- 根据项目目标与产品分解结构,把项目产品的定义转化为对项目工作范围的说明。
- 通过工作分解结构,定义项目工作范围。
- 项目干系人认可并接受项目范围(范围核实)。
- 授权与执行项目工作,并对项目进展进行控制。
二、项目范围管理的重要性
- 范围不明确的后果是项目的范围蔓延,项目永远也做不到头;
- 对范围的理解不一致的结果是项目组的工作无法得到其他干系人的认可。
- 对于软件项目来说,这两种现象非常突出,它严重阻碍了项目的成功。
- 确定项目的范围对项目管理来说非常重要,它至少能起到如下作用:
- 提高费用、时间和资源估算的准确性。
- 确定进度测量和控制的基准。
- 有助于项目分工。
三、项目范围管理过程
- 范围规划:制定项目范围管理计划,如何确定、核实与控制项目范围,如何制作和定义WBS;
- 范围定义:制定详细的项目范围说明书,作为将来项目决策的根据;
- 制作WBS:将项目大的可交付成果与项目工作划分为较小和更易管理的组成部分;
- 范围核实:审核项目范围界定的工作成果;
- 范围控制:通过对造成项目范围变更的因素施加影响,控制项目范围的变更。
项目范围规划与范围定义
一、项目范围规划
-
范围规划:确定如何定义、验证并控制项目范围以及如何构建WBS,给出项目范围管理的主要方法和程序;其成果是项目范围管理计划。
-
项目范围管理计划包含在项目管理计划之内,项目范围管理计划主要包括:
- 如何确定项目范围
- 如何编制详细的项目范围说明书
- 如何分解WBS
- 如何确认项目产出物和可交付成果
- 如何对项目范围进行控制和变更管理
-
项目范围管理计划是项目范围管理的基础,需要从分析产品、项目章程、项目初步范围说明书以及其他项目管理计划入手。
-
编写范围管理计划应遵守“SMART”原则:
- Specific
- Measurable
- Achievable
- Result driven
- Timing
二、项目范围定义
- 范围定义就是制定详细的项目范围说明书,供将来的项目决策作为依据的过程。——PMBOK
- 范围定义的目的:提高对时间及资源估算的准确性,为绩效测量与控制定义一个基准,便于进行明确的职责分配。
- 项目范围定义的主要依据:
- 项目文件:项目章程、项目初步范围说明书、项目范围管理计划、批准的变更请求。
- 项目范围定义中搜集的信息:环境因素和组织过程资产信息、IT项目专业领域对项目交付成果和项目工作的客观要求方面的信息、项目范围变更请求方面的信息、项目限制条件与假设条件信息 。
三、IT项目范围说明书
- 详细地说明了项目产品或可交付成果及生成这些项目交付成果所要求的工作。
- 是项目相关利益主体对有关项目目标和要求的共同意愿表述。
- 由此制定后续的详细计划和业绩评估基线,并开展各项项目工作。
- 详细的项目范围说明书包括如下内容:
- 项目目标和项目范围指标
- 项目产品范围说明书
- 项目可交付成果的规定
- 项目约束条件和假定条件
- 项目配置关系及其管理要求
- 项目批准的规定
四、软件项目范围说明书
- 在软件项目中,软件系统范围经常表现为软件需求规格说明书(Software Requirements Specifications,SRS)。
- SRS 也称为功能规格说明、产品规格说明、需求文档或系统规格说明;
- SRS 精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件;
- SRS 不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。
- SRS作为产品需求的最终成果必须包括所有的需求。
- 任何未写入SRS中的需求,将不能作为协议的一部分,并且不能在产品中出现。
- 所有的参与者必须根据已通过评审的需求来安排工作,以避免不必要的返工和误解。
- 高质量需求文档必须具有完整性、一致性、可修改性、可跟踪性和可读性的特征。
项目工作分解结构技术
- 工作分解结构( Work Breakdown Structure,WBS)是一种为了便于管理和控制而将项目工作任务分解的技术。
- WBS是一种以可交付成果为分解对象、以结果为导向的分析方法。
- 通过WBS对项目所涉及的工作进行分解,而所有这些工作构成了项目的整体范围。
一、WBS的定义
- WBS是项目团队实现项目目标和创建必须的可交付成果,面向可交付成果的层次分解,定义出项目的整体范围。 ——PMBOK
- 没有在WBS中的工作不属于项目的范围。WBS是有层次的,没有层次的活动列表不是WBS!
二、WBS的用途
- 工作分解结构确定了项目整个范围,并将其有条理地、分层次地组织在一起。
- 属于工作分解结构底层组成部分的计划工作叫做 “工作细目”或“工作包”,可以安排在进度表中,用来估算费用,进行监视和控制。
- 工作分解结构是当前批准的项目范围说明书规定的工作。
- 没有包含在WBS里的工作是不应该做的。
三、WBS示例
- WBS 示例1——树型(图表)
- WBS 示例2——列表型(清单)
四、建立WBS的指导原则
- 第一级通常与项目生命周期相同(如需求分析,设计,采购,施工……)
- 一个工作包任务只能在WBS中出现一次
- 一个WBS项的工作内容是其下级各项工作之和
- WBS中的每一项工作都明确由一个人负责
- WBS必须与工作任务的实际执行过程相一致
- 项目组成员参与WBS的制定过程
- 每一个WBS项必须有准确描述
- 工作包的80小时描述
- WBS具有一定的灵活性,以适应变更的需要
五、创建WBS的方法
-
模板法:PMI标准、业标准咨询公司的商业性模板库、企业标准与惯例(知识经验库)
-
分解法:
- 识别主要的项目要素或项目提交成果
- 项目要素的构成分解,以便项目绩效度量和责任分配
- 确定工作任务(工作包)
- 检查分解结果的正确性。必要和充分性检查、完整和模糊性检查、可计划和控制性检查(分配工期、预算、资源和责任人)
-
由上而下法:从项目最大的单位开始,逐步将它们分解成下一级的多个子项。
-
由下而上法:让项目组人员一开始就尽可能地确定项目有关的各项具体任务,然后再将各项具体任务进行整合,并归总到WBS的上一级内容当中。
六、WBS的编码
- WBS的编码的规则:由高层向下层用多位码编排,要求每项工作有唯一的编码。
七、WBS词典
- 项目WBS字典是对WBS中各个部分的详细文字说明。
- WBS中的各要素与各工作包都需要在WBS字典作为词条进行描述和说明。(包括:预期、工期、人员安排…….)
- WBS字典对每一活动包括的详细内容进行表述,包括:任务编号、名称、如何做、投入资源、结果、完成的标准/质量、由谁做。
八、WBS的创建步骤
步骤一:识别项目的主要组成部分。
- 问题:要实现项目目标需要完成那些主要工作?
- 可以按照项目生命周期阶段、项目的主要提交成果、产品、系统或者专业进行有效识别。
步骤二:判断。
- 在已经分解的基础上,判断能否快速方便地估算各个组成部分各自所需的费用和时间、以及责任分配的可能性与合理性。
- 如果不可以,则进入步骤三;
- 如果可以,则进入步骤四。
步骤三:识别更小的组成部分
- 要完成当前层次上各个部分的工作,需要做哪些更细的工作?
- 这些工作是否可行?可核查?
- 这些工作之间的先后顺序怎样?
- 在WBS上标示出来,第三、四……层;
- 判断:能否快速方便地估算该层的各个组成部分各自所需的费用和时间、以及责任分配的可能性与合理性。
- 如果还是不可以,返回1;
- 如果可以,则进入步骤四。
步骤四:检查工作
- 如果不进行这一层次的工作,上一层的各项工作能否完成?
- 完成了该层的所有工作,上一层次的工作就一定能完成吗?
- 根据检查,对当前层的工作进行增加、删除或者修改,或者对上层工作进行适当的整理;
- 本层各项工作的内容、范围和性质是否都已经明确?如果回答肯定,则需要写出相应的范围说明书,该说明书就是工作包的范围说明书;
- 对“4”的否定,进行必要的修改和补充。
项目范围核实与控制
- 由于IT项目的特点,范围蔓延的现象屡见不鲜,正是诸如范围蔓延等类似的问题,导致了许多项目的失败。因此,对项目范围进行核实,并制定专门的范围变更控制程序尤为重要。
一、项目范围核实
-
范围核实是指利益相关者对范围的正式接受。项目范围核实就是获取干系人对项目范围以及相应的可交付成果的正式承诺。
-
为了能使项目范围得以正式认可,项目团队必须形成明确的正式文件,说明项目产品及其评估程序,以评估是否正确和满意地完成了项目产品。
-
IT项目范围核实的步骤:
- 确定需要进行范围核实的时间
- 识别范围核实需要哪些投入
- 确定范围正式被接受的标准和要素
- 确定范围核实会议的组织步骤
- 组织范围核实会议。
-
范围核实不同于质量控制:
- 范围核实主要关注对可交付成果的验收,而质量控制则主要关注可交付成果是否正确以及是否满足质量要求。质量控制通常先于范围核实进行,但二者也可同时进行。
- 质量控制是对工作结果正确性的核实,依据的是项目的质量标准(如:GB1998—127)
- 范围核实是对工作结果的验收,主要是指边界责任,依据主要是项目执行结果和项目范围计划的输出结果。
二、项目范围控制
-
范围变更的表现形式多种多样,在IT项目中,范围变更可能来自服务商、供应商或者客户,也可能来自项目组织内部。产生变更可能有如下一些原因:
- 需求不明确
- 系统实施时间过长
- 用户业务需求改变
- 系统正常升级。
-
项目范围控制是指控制项目范围变更。其目的是对引起范围变更的因素施加影响,确保变更能依据集成变更控制建立的程序有序进行。
-
项目范围控制是指当项目范围变化时对其采取纠正措施的过程,以及为使项目朝着目标方向发展而对项目范围进行调整的过程。应当全过程地与其他控制过程集成起来,如进度控制、成本控制、质量控制等。
-
项目范围控制的主要工作
- 分析和确认影响变更的主要因素和环境,并管理和控制它们;
- 分析和确认项目干系人提出变更的合理性、可行性;
- 分析和确认范围变动是否已经发生;当范围变更发生时,对实际变更情况进行管理。
-
范围控制——变更的来源
- 外部事件:政府的法规发生了变化,市场变化,技术变革
- 纠正错误或疏忽:
- 当初设计存在错误或者遗漏
- 误用工料清单代替工作分解结构
- 增加价值的变更
- 采用新技术可以帮助节约成本
- 为应对一个风险而实施的一个应急计划
-
范围变更控制系统:定义范围变更控制的程序、方法和管理规范,包括:
- 变更管理流程
- 责任划分、授权及授权变更所需要的批准层次
- 变更的文档管理
- 变更的跟踪监督
-
注意事项:
- 变更控制系统已在项目管理计划中明确给出;
- 与整体变更控制结合起来,保持配置关系的一致性;
- 当项目在合同形式下进行时,范围变更控制系统必须符合有关的合同条款。
- 项目范围控制需要重点考虑以下几个方面:
- 范围控制是必须的,不存在无变化的项目。
- 项目范围变化并不仅仅意味着工作量的增加。
- 项目范围控制的目的不是阻止变更的发生。
- 积极地、主动地进行项目范围管理,使变更朝着有利于项目顺利完成的方向发展。
三、软件项目范围变更控制
- “软件项目唯一不变的就是总是在变”,范围变更控制就是为了消除范围变更造成的不利影响。
- 项目团队必须意识到软件项目范围变更本身并没有什么不对,很多时候这会让系统更健壮、更实用。
- 有效的范围变更流程对项目范围的控制至关重要。
- 变更控制的目的不是控制变更的发生,而是对变更进行管理,确保变更有序进行。
标签:控制,WBS,项目,项目管理,笔记,学习,工作,变更,范围 来源: https://www.cnblogs.com/zhulu506/p/14544310.html