1. 选择最终实现的需求

2. 定义范围前提是有需求文件 

3.定义范围时做数据分析的时候需要有备选方案

4. 难度/可靠性/成本（多标准决策分析）

5. 项目范围承认书，需求，是否可达成需求

6.除外责任：是指比较模糊/可能项目进行中会产生争议的事，所以在项目范围说明书发行时一定要向客户明确，哪部分我么能做，哪部分不能做

7.项目章程里面的范围是很广的，但是具体。需求文件是细化工作，且可量化，范围说明书等同于验收标准，范围说明书跟需求文件是对应关系，且他们在需求跟踪文件里面

8. 需求文件，我们需要引导客户的需求

9.WBS= Work break out structure，分解需求,当需求比较复杂情况，细化让事情好管理(其中包含项目管理）

10. JIM建议由一个小组负责细化后的需求，便于管理

11. 细分化的需求是工作包，工作包只能由唯一的小组负责，如果由多个小组负责，容易扯皮

12. WBS用层级来划分，组织且定义了不同组（需求）的范围，从上而下，逐层分解，可把可交付成果放在第二层

13， 每个可交付的需求都需要有计划&有预算&有描述。包含在（WBS词典---详细说明文件）

14. 需求信息不充分时，有待进一步考察（渐进明细）

15. WBS 遵循100%原则，责任要明确

16 WBS输出后，形成了范围基准，由相关的干系人负责批准

1、考试重点：变更流程。1、记录；2、评估；3、提交；4、更新；5、通知。

2、变更请求批准人：变更控制委员会（CCB）。

项目范围

1、定义范围：选取最终的项目需求，然后指定出关于项目及产品、服务或成果的详细描述。

工具与技术：
1、数据分析-备选方案分析

2、决策-多标准决策分析

3、人际关系与团队技能-引导技能

4、产品分析

项目范围说明书：

1、产品范围描述

2、可交付成果

3、验收标准

4、除外责任

项目章程：宏观需求

需求文件：单一需求罗列

范围说明书：可交付成果/验收标准

创建工作分解结构

1、创建WBS：把项目可交付成果和项目工作分解成较小的，易于组件的过程。

WBS组织并定义了项目的总范围，最底层的组成部分称为工作包，工作分解结构，“工作”是指作为活动结果的工作产品或可交付成果，而不是或者本身。

分解5个步骤：
1、识别和分析

2、确定结构和编排方案

3、自上而下逐层细分

4、为WBS组件指定和分配表示编码

5、核实可交付成果分解的程度是否恰当

创建WBS4个注意

1、采用敏捷方案，化繁为简

@复习！！！

启动--规划--执行--监控--收尾

WHAT     WHY     HOW

2.2 项目规划（启动--规划--执行--监控--收尾）

需求（客户需要）和范围（可交付成果）的区别

2.2.1 规划范围

2.2.2 收集需求----输出：需求文件&需求跟踪矩阵

2.2.3 定义范围---输出：项目范围说明书（可交付成果、验收标准）

WHAT：

• 从需求文件中选取最终的项目需求
• 然后制定处关于项目机器产品、服务或成果的详细描述

WHY：

• 描述产品、服务或成果的边界和验收标准

输入

I*UT1：项目章程

I*UT2：项目文件---需求文件

工具与技术

TT1：数据分析

• 备选方案分析

TT2：决策

• 多标准决策分析（男女朋友？）

TT3：人际关系与团队技能

• 引导（跨职能的干系人达成共识）

TT4：产品分析

输出

OUTPUT：项目范围说明书

1、记录了项目的整个范围

2、与干系人之间就项目达成的共识

3、管理干系人期望

• 产品范围描述（细化项目章程）
• 可交付成果
• 验收标准
• 除外责任（不做的，减少期望蔓延）

2.2.4 创建WBS---输出：范围基准（项目范围说明书可交付成果、验收标准、WBS可交付成果、验收标准）

WHAT：

WBS--（work breakdown structure）

WHY：

WBS：对所要交付的内容提供架构

输入

I*UT:  项目范围说明书（菜谱）--得到WBS

工具与技术

WBS--（work breakdown structure）

• 把可交付成果和项目工作-分解成较小、易于管理的组件
• WBS--组织并定义了项目的总范围（供应商的也要纳入）
• 最底层的组成部分--工作包--是可交付的成果！！

WBS词典：WBS的详细说明

创建WBS的4个原则：

• 无遗漏100%（做且只做）
• 工作包80h
• 4-6个分层
• 责任明确--工作包只能由唯一的小组负责

输出：

OUTPUT：范围基准--主要干系人批准baseline

• 项目范围说明书（产品范围描述、可交付成果、验收标准、除外责任）
• WBS（工作包、规划包、控制账户）
• WBS词典（可交付成果、验收标准等）

？控制账户

项目文件可以改

项目管理计划最好不改---改走正式流程

2.4.10 整体变更----输出：批准变更请求\项目文件更新--变更日志\项目管理计划更新

WHAT：

审查所有变更请求、批准变更、管理变更

WHY：

只审批、管理变更

不会提出变更请求

注意点：

• 项目经理对此最终负责
• 任何干系人可以提出变更请求、必须书面形式记录
• 评估变更影响和成本
• 由变更控制委员会CCB实施变更-----注意更新变更日志

输入

！！I*UT：变更请求

1. 记录--项目经理/变更提出者（提交书面请求）--记到变更日志
2. 评估--变更影响
3. 提交--项目经理把变更请求和评估结果给CCB
4. 更新---无论是否通过
5. 通知---受影响的干系人

！！常见考法！！

1. 变更顺序（偶尔：有选前期了解原因）
2. 要不要变更（都要走流程）

！！常见关键词！！

• 处理/实施变更请求——1~5步

输出

OUTPUT1：批准变更请求

CCB！！！（PMO\发起人\项目经理等）

OUTPUT2：项目文件更新--变更日志

OUTPUT3：项目管理计划更新

书面记录，可以项目经理也可以提的人填表。

自己或者相关干系人评估下。

项目经理乙方把合理评估结果提交给ccb审批。

不管是否通过都是更新CR

结果通知受影响的干系人！

考试重点！！20题目！！比对。 

2.2.3定义范围

1.输入：项目章程（高层级需求和可交付成果）、需求文件（单一需求）

2.工具与技术：备选方案分析、多标准决策分析、引导技能、产品分析

3.输出：项目范围说明书*（产品范围描述、可交付成果、验收标准、除外责任）

2.2.4创建工作分解结构（WBS）

定义：可交付成果和项目管理分解为组件，最底层组件称为工作包（本质也是可交付成果）

1.输入：范围说明书

2.工具与技术：分解（100%、80小时、4-6 层、责任明确）

3.输出：WBS、WBS词典、范围基准（范围说明书、WBS、WBS词典）

2.4.10实施整体变更控制（处理变更请求）

1.输入：变更请求（了解变更内容和原因）

2.变更管理计划（流程）：记录（干系人-PM，书面：变更日志、变更申请）、评估（PM）、提交（PM-CCB/PMO）、更新（变更日志）、通知

3.输出：批准的变更请求、项目文件更新（变更日志）、项目管理计划更新

附：未通过批准也要更新和通知

需求跟踪矩阵

WBS：work breakdown structure

可交付成果和项目工作

组织并定义

WBS词典

主要交付成果：范围说明书

借鉴：文件夹的命名

分几层标准：由一个唯一的小组负责==》容易管理

最底层的本质：工作包（成果）-还是可交付成果，颗粒度更小

定义范围：从需求文件中选取最终的项目需求，然后制定出关于项目及其产品、服务或成果的详细描述。

项目范围说明书（输出）：项目范围说明书详细描述了项目的可交付成果，还代表项目干系人之间就项目范围所达成的共识。

范围基准：范围说明书、WBS、WBS词典

交付成果和验收标准：首选范围说明书，次选wbs词典，再次选范围基准。

变更流程：1记录、2评估、3提交、4更新、5通知

变更很重要

变更流程

1. 记录

2. 评估

3. 提交

4. 更新

5. 通知