变基线，提变更，任何干系人都可以提变更

提变更，就算口头提，也要书面记录

WBS 工作 拆解 结构  强调分工，方便管理

拆分的标准：单独小组可以完成，2周内可以做完

4-6层，不要太细

组织并定义了项目总范围--》WBS

最底层--》工作包，小的可交付成果

输入：项目范围说明书

 范围基准=范围说明书+WBS+WBS词典，获得干系人批准，得到基准

CCB

记录（变更日志、变更请求）

评估

提交

更新

通知

问要不要走变更 全部六亲不认选择走流程

没有遵守走流程 就 去补变更流程

CCB如果不同意，就要取消不良变更

定义范围：

工具与技术【......】

 输入：需求文件

 输出：项目范围说明书

 需求跟踪矩阵文档链接需求文档和范围说明书

项目范围说明书中的是验收标准，对于整个项目而言是成功标准

创建工作分解结构：

 工具【......】 

 输入：范围说明书

 输出：范围基准=范围说明书+WBS+WBS词典

实施整体变更控制：

 输入：变更请求

 输出：项目管理计划更新

1、输入必然有需求文件，才能定义范围

多标准决策分析-

引导----达成一致

最终做出项目范围说明书

除外责任---不做的话说清楚，实践中需要注意

项目章程----有需求有可交付成果，宏观概括

需求文件-----细化具体需，

范围说明书---定义范围：得出可交付成果，要跟干系人达成共识，每个可交付成果都有对应的验收标准，不管过程怎样，最终要把交付什么定下来，也就是定义范围。

需求和范围会有对应关系

需求跟踪举证

整个项目会有项目成功标准

创建工作分解结构———WBS。eg：家具拆解再拼装——组织并定义了项目总范围

分解要恰当

范围基准——baseline获得干系人批准，不能随便改，要走流程经审批

实施整体变更控制——只审批变更

乙方项目经理负责

任何干系人都可以提变更，必须书面形式记录

变更控制委员会CCB

考点，变更的顺序，要不要变更，考试100%要走流程

没有遵守流程做变更——补流程

创建一份变更请求——记录

批准变更——考试默认CCB

定义范围

输出：项目范围说明书

项目范围说明书：可交付成果和验收标准和除外责任

项目章程中有成功标准

创建WBS

把可交付成果和项目工作

不同可交付成果分解层次不同

分到可以交给单独的某个小组/个人负责两周之内交付较好

WBS组织并定义了项目总范围，最底层称为工作包(提到组织与定义，必为WBS）

遵循100%原则

责任明确原则

80小时原则（建议）

4-6层原则（建议）

WBS输出：范围基准（WBS，WBS词典，范围说明书）

可交付成果+验收标准（首选范围说明书，次选WBS词典，最后选范围基准）

远期成果当前可能无法分解（规划包）需要滚动式规划

实施整体变更控制贯穿项目始终，项目经理对此负最终责任

任何干系人都可以提出变更请求，必须以书面形式记录

输入变更请求

确认变更需走以下流程：1.记录，2.评估3.提交4.更新5.通知

考要不要变更

必须必须走变更流程，若团队成员没走流程必须补流程（若未审批而变更已做，需取消不良变更）

输出

批准的变更请求

项目文件更新

项目管理计划更新