5.项目范围管理+信息系统项目管理+野马合集

coniting123

已于 2022-09-15 10:07:40 修改

阅读量146

点赞数

分类专栏：野马合集文章标签：项目管理

于 2022-01-06 22:15:42 首次发布

本文链接：https://blog.csdn.net/coniting123/article/details/122354199

版权

野马合集专栏收录该内容

16 篇文章 2 订阅

订阅专栏

1.范围管理ITO

过程名	输入	工具和技术	输出
规划范围管理	1.项目管理计划 2.项目章程 3.组织过程资产 4.事业环境因素	1.专家判断 2.会议	1.范围管理计划 2.需求管理计划
收集需求	1.范围管理计划 2.需求管理计划 3.干系人管理计划 4.项目章程 5.干系人登记册	1.访谈 2.焦点小组 3.引导式研讨会 4.群体创新技术 5.群体决策技术 6.问卷调查 7.观察 8.原型法 9.标杆对照 10.系统交互图 11.文件分析	1.需求文件 2.需求跟踪矩阵
定义范围	1.范围管理计划 2.项目章程 3.需求文件 4.组织过程资产	1.专家判断 2.产品分析 3.备选方案生成 4.引导式研讨会	1.项目范围说明书 2.项目文件更新
创建wbs	1.范围管理计划 2.项目范围说明书 3.需求文件 4.事业环境因素 5.组织过程资产	1.分解 2.专家判断	1.范围基准 2.项目文件更新
确认范围	1.项目管理计划 2.需求文件 3.需求跟踪矩阵 4.确认的可交付成果 5.工作绩效数据	1.检查 2.群体决策技术	1.验收的可交付成果 2.变更请求 3.工作绩效信息 4.项目文件更新
控制范围	1.项目管理计划 2.需求文件 3.需求跟踪矩阵 4.工作绩效数据 5.组织过程资产	1.偏差分析	1.工作绩效信息 2.变更请求 3.项目管理计划更新 4.项目文件更新 5.组织过程资产更新

2.范围管理过程

1.规划范围管理：写一个文档，范围管理计划，规定如何做好范围管理
2.收集需求：收集需求后才知道，后期项目要做什么
3.定义范围：需要写一个详细的范围说明书
4.创建WBS：把整个的项目分解为较小的，易于管理的组成部分，形成一个自上而下的分解结构
5.确认范围：在项目的制作过程中，需要一些阶段性的验收
6.控制范围：做好监控，看有没有偏差，有偏差进行纠偏

3.五大过程组与范围管理

10大管理	启动过程组	规划过程组	执行过程组	监控过程组	收尾过程组
项目范围管理		1.规划范围管理 2.收集需求 3.定义范围 4.创建WBS		5.确认范围 6.控制范围

4.范围管理的基本概念

1.范围管理概述的内容：
（1）明确项目的边界，哪些在项目内，哪些不在项目内
（2）对项目执行的工作进行监控，做该做的，不做额外的
（3）防止项目范围发生蔓延，范围蔓延：客户提出了新需求，超出了范围基准

2.产品范围与项目范围

	产品范围	项目范围
内容	产品或者服务应该包含的功能，技术层面	为了能够交付产品，项目所必须做的工作，管理层面
范围	产品范围的定义是产品要求的描述	项目范围的定义是产生项目管理计划的基础
特点	产品范围是项目范围的基础，是项目范围说明书的重要组成部分，产品范围变更后，首先受到影响的是项目范围	项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典
完成标准	根据产品是否满足了产品描述来判断	以范围基准来衡量

5.项目范围管理的具体内容

5.1 规划范围管理

过程名	输入	工具和技术	输出
规划范围管理	1.项目管理计划 2.项目章程 3.组织过程资产 4.事业环境因素	1.专家判断 2.会议	1.范围管理计划 2.需求管理计划

5.1.1 规划范围管理输出

1.范围管理计划
（1）定义：规划范围管理就是编制范围管理计划，书面描述将如何定义、确认和控制项目范围的过程，在整个项目中对如何管理范围提供指南和方向。范围管理计划需要项目团队整体全员参与。

（2）内容：
<1>如何制定项目范围说明书（定义范围）
<2>如何根据范围说明书创建WBS（工作分解结构）
<3>如何维护和批准WBS（工作分解结构）
<4>如何确认和正式验收已完成的项目可交付成果（确认范围）
<5>如何处理项目范围说明书的变更，该工作与实施整体变更控制过程直接相连（控制范围）

（3）项目范围管理计划可能在项目管理计划中，也可以作为单独的一项，根据不同的项目，可以是详细的或概括的，也可以使正式的或者非正式的。

2.需求管理计划
（1）定义：需求管理贯穿于整个过程，明确需求，并使项目团队和用户达成共识，建立需求基线。建立需求跟踪能力联系链，确保所有用户需求都被正确地应用，并且在需求发生变更时，能够完全地控制其影响范围，始终保持产品与需求的一致性。
需求管理计划描述在整个项目生命周期内如何分析、记录和管理需求。

（2）内容：
<1>如何规划、跟踪和汇报各种需求活动
<2>需求管理需要使用的资源
<3>培训计划
<4>项目干系人参与需求管理的策略
<5>判断项目范围与需求不一致的准则和纠正规程
<6>需求跟踪结构
<7>配置管理活动

5.2 收集需求

过程名	输入	工具和技术	输出
收集需求	1.范围管理计划 2.需求管理计划 3.干系人管理计划 4.项目章程 5.干系人登记册	1.访谈 2.焦点小组 3.引导式研讨会 4.群体创新技术 5.群体决策技术 6.问卷调查 7.观察 8.原型法 9.标杆对照 10.系统交互图 11.文件分析	1.需求文件 2.需求跟踪矩阵

5.2.1 需求的分类

1.分类
（1）业务需求：整个组织高层次的需求
（2）干系人需求：干系人或干系人群体的需求
（3）解决方案需求：为了满足业务和干系人需求，产品服务或成果必须具备的成果或功能
（4）过渡需求：从当前状态过渡到将来状态所需的临时能力
（5）项目需求：项目需要满足的行动、过程和其他条件
（6）质量需求：用于确认项目可交付成果和成功完成或其他项目需求的实现的任何条件或标准，分为基本需求、期望需求和意外需求。

5.2.2 收集需求的工具和技术

1.访谈
通过与干系人直接交谈来获取信息的正式与非正式的方法。

2.焦点小组
由主持人引导大家进行互动交流，选定干系人和主题专家，然后进行分组进行讨论。

3.引导式讨论会
邀请跨职能部门干系人进行参加会议，更快的发现和解决问题。

4.群体创新技术
（1）头脑风暴：集思广益，各抒己见
（2）名义小组技术：投票排名最有用的创意，以便进一步头脑风暴。
（3）德尔菲技术：匿名或背靠背的方式，使专家意见主见统一。
（4）概念/思维导图：心智图，将头脑风暴的创意，用一张简单的图联系起来。
（5）亲和图：也称KJ法，通过图解的方式进行汇总。
（6）多标准决策分析：借助决策矩阵进行分析。

5.群体决策技术
（1）一致同意：所有人
（2）大多数同意：50%
（3）相对多数同意：所占比例最多
（4）独裁：一个人

6.问卷调查

7.观察

8.原型法

9.标杆对照： 实际或计划的做法或其他类似组织的做法进行比较，形成改进意见，为绩效考核提供依据。

10.系统交互图

11.文件分析： 文档挖掘信息

5.2.3 收集需求的输出

1.需求文件
（1）定义：描述了各种单一的需求将如何满足与项目相关的业务需求。需求文件既可以是一份按干系人和优先级分类列出全部需求的简单文件，也可以是一份包括内容提要，细节描述和附件等的详细文件。
（2）内容：
<1>业务需求
<2>干系人需求
<3>解决方案需求
<4>项目需求
<5>过渡需求
<6>与需求有关的假设条件、依赖关系和制约因素
（3）需求跟踪
<1>重要特征：可跟踪下
<2>特性：可验证性是最基本的特征
<3>定义：需求跟踪是将单个需求和其他元素之间的依赖关系和逻辑关系建立跟踪，这些元素包括各类型的需求、业务规则、系统组件以及帮助文件等。
<4>分类：每个配置项的需求到其涉及的产品（或构件）需求都要具有双向可跟踪性，包括正向跟踪和反向跟踪。
在这里插入图片描述正向跟踪：检查需求文件中的每个需求是否都在后继工作产品（成果）中找到对应点。
反向跟踪：逆向跟踪，检查设计文档、产品构件、测试文档等工作成果是否都能在需求文件中找到出处。
箭头表示需求跟踪能力联系链，它能跟踪需求使用的整个周期，从需求建议到交付全过程。

2.需求跟踪矩阵
（1）定义：表示需求和其他产品元素之间的联系链的最普遍的方式是使用需求跟踪（能力）矩阵，需求跟踪矩阵是将产品需求从其来源连接到能满足需求的可交付成果的一种表格。
（2）内容：唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态(进行中、已取消、已推迟、新增加、已批准、已分配、已完成等） 和状态日期。

5.3 定义范围

过程名	输入	工具和技术	输出
定义范围	1.范围管理计划 2.项目章程 3.需求文件 4.组织过程资产	1.专家判断 2.产品分析 3.备选方案生成 4.引导式研讨会	1.项目范围说明书 2.项目文件更新

5.3.1 定义范围的工具与技术

1.产品分析
（1）定义：针对产品提问并回答，形成对将要开发的产品的用途、特征和其他方面的描述（项目范围说明书中有验收标准所以要做产品分析）产品分析技术包括产品分解，系统分析、需求分析、系统工程、价值工程（产品没做出来之前）和价值分析（作品做出来之后）。

2.备选方案生成：用来指定尽可能多的潜在的可选方案的技术，用于识别执行项目工作的不用方法。

5.3.2 定义范围的输出

1.项目范围说明书
（1）内容：
<1>产品范围描述
<2>验收标准
<3>可交付成果
<4>项目的除外责任
<5>制约因素
<6>假设条件

（2）主要作用
<1>确定范围
<2>沟通基础
<3>规划和控制依据
<4>变更基础
<5>规划基础

5.4 创建工作分解结构WBS

过程名	输入	工具和技术	输出
创建wbs	1.范围管理计划 2.项目范围说明书 3.需求文件 4.事业环境因素 5.组织过程资产	1.分解 2.专家判断	1.范围基准 2.项目文件更新

1.定义：创建wbs是将项目可交付成果和项目工作分解成较小的、更易于管理的组建的过程，主要作用是对所要交付的内容提供一个结构化的视图。
2.名词解释
（1）里程碑：每个分解单元中都存在可交付成果和里程碑。里程碑标志着某个可交付成果或阶段的正式完成。
（2）工作包：是位于WBS每条分支最底层的可交付成果或项目工作组成部分，应便于完整地分派给不同的人或组织单元，要求明确个各工作单元直接的界面，工作包应非常具体，以便承担者明确自己的任务，努力的目标和承担的责任，作为一种经验法则，8/80原则（80小时原则），建议工作包的大小应该至少8小时完成，总完成时间不应该大于80小时。
（3）控制账户：是一种管理控制点，一个控制账户就包括若干工作包，但一个工作包仅属于一个控制账户。
（4）规划包：规划包在控制账户之下，工作包之上的WBS要素。规划包是暂时用来做计划的。
（5）WBS词典：用来描述WBS各组成部分的文件。

5.4.1 创建工作分解结构的工具与技术

1.分解
（1）定义：将项目可交付成果和项目工作分解成较小的，更易与管理的组件的技术
（2）WBS的分解过程
<1>识别和分析可交付成果及相关工作（要分解什么）
<2>确定WBS的结构和编排方法（怎么分解）
<3>自上而下逐层细化分解（开始分解）
<4>为WBS组件制定和分配标识编码（编码）
<5>核实可交付成果分解的程度是恰当的（检查和确认）
（3）分解方法：
<1>项目生命周期的各阶段作为分解的第二层，产品和项目可交付成果放在第三层
<2>主要可交付成果作为分解的第二层
<3>整合可能由项目团队以外的组织来实施的各种组件（例如：外包工作），然后作为外包工作的一部分，卖方需编制相应合同的wbs
（4）wbs不是某个团队或成员的责任，应该由全体团队成员、用户和项目干系人共同完成和一直确认。
（5）注意事项
<1>必须是面向可交付成果
<2>必须符合项目范围
<3>底层应该支持计划和控制
<4>元素必须有人负责，而且只由一个人负责，尽管实际上有多人参与
<5>Wbs 的指导，应该控制在4~6层。一个工作单元只能从属某个上层单元，避免交叉从属。
<6>应包括项目管理工作，也包括分包出去的工作
<7>编制需要所有（主要）项目干系人参与，需要项目团队成员的参与
<8>Wbs并非一成不变的

5.4.2 创建工作分解结构的输出

1.范围基准
（1）项目范围基准是经过批准的项目范围说明书、WBS和WBS词典。

5.5 确认范围

过程名	输入	工具和技术	输出
确认范围	1.项目管理计划 2.需求文件 3.需求跟踪矩阵 4.确认的可交付成果 5.工作绩效数据	1.检查 2.群体决策技术	1.验收的可交付成果 2.变更请求 3.工作绩效信息 4.项目文件更新

1.定义：确认范围是正式验收项目已完成的可交付成果过程，确认范围包括与客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收。

2.确认范围应贯穿项目的始终。

3.步骤
（1）确定范围时间
（2）识别需要的投入
（3）确认正式被接受的标准和要素
（4）确认会议的组织和步骤
（5）组织范围确认会议

4.范围确认与质量控制的区别

	范围确认	质量控制
关注点	可交付成果获得客户或发起人的接收	可交付成果的正确性
时间	一般在阶段末尾进行	先做质量控制再做范围确认，但也可以同时进行。并不一定在阶段末尾进行。
参与者	必须有甲方参与	属于内部检查

5.各干系人关注点
（1）管理层关注项目范围
（2）客户关注产品的范围
（3）项目管理人/项目经理关注可交付成果能否与必须完成
（4）项目团队成员关注自己参与与负责的单元或元素

5.5.1 确认范围的工具与技术

1.检查：也称审查、评审、审计、走查、巡检、测试等，指开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。

5.6 控制范围

过程名	输入	工具和技术	输出
控制范围	1.项目管理计划 2.需求文件 3.需求跟踪矩阵 4.工作绩效数据 5.组织过程资产	1.偏差分析	1.工作绩效信息 2.变更请求 3.项目管理计划更新 4.项目文件更新 5.组织过程资产更新