SG
1: 建立估计计划：要建立和维护项目计划参数的估计数据
- SP1.1 估计项目的范围
- SP1.2 建立项目属性的估计
- SP1.3 定义项目生命周期
- SP1.4 确定工作量和成本的估计
项目范围的估计可以通过建立顶层WBS分解，WBS分解一般是面向产品结构，需要分解到工作包这个层次。由于WBS面向产品结构，使我们容易遗忘在WBS分解中包括风险缓解，配置管理，集成，培训，非开发管理等任务。我们仍然强调的是WBS加上工作包的描述是项目范围的一个全集。
规模是许多用于估计工作量、成本和进度的模型的主要输入。SP1.2提到的项目属性估计的重点就是先要有任务或工作产品的规模和复杂度的估计，这个是后续工作量，成本和进度估算的基础。对应软件产品衡量规模的单位常用的有功能点，代码行，需求页数，用例数，需求条目数等。
三级的IPM集成项目管理强调了项目的过程是从组织标准过程定义裁剪出来的，一个重点大的裁剪就是选择项目生命周期模型。SP1.3定义项目生命周期在二级的时候还没有上升到组织级。
项目生命周期模型的定义是确定工作量和成本的基础，不同的生命周期工作量的分布往往是不同的，而且我们的项目历史数据也是在一定的生命周期模型下得到的。在这里把生命周期模型放到SP1.3，是否说明顶层WBS分解更多的是项目产品结构，和采用的生命周期模型关系不大?
工作量和成本的估计一般基于使用模型或历史数据分析规模、活动和其他计划参数的结果。不可预测的工作量是更危险的，需要更多研究来开发合理的估计基础，并需要预留更多的管理工作。在软件工程领域，已经开发许多参数化模型来辅助成本和进度。历史数据包括来自先前已执行项目的成本、工作量和进度的数据，加上考虑不同规模和复杂度的调整数据。
再对SG1进行总结，大致遵循的一个步骤如下:
SOW和用户需求->顶层WBS分解->规模和复杂度估算->生命周期模型确定->估算参数确定->工作量和成本
SG 2: 开发项目计划：要建立和维护项目计划，并作为管理项目的基础
- SP2.1 建立预算和进度
- SP2.2 标识项目风险
- SP2.3 计划数据的管理
- SP2.4 计划项目的资源
- SP2.5 计划所需的知识和技能
- SP2.6 计划项目相关人员的参与
- SP2.7 建立项目计划
在这里我们要注意，CMMI里面的PP过程域和PMBOK里面的制定进度过程有些小的区别。SG1的重点是项目范围管理里面内容，SG2重点是项目时间管理内容，有一个大的不同就是规模和工作量的估算是在WBS一建立后就可以开始的工作，而不是要先进度活动定义和排序后再开始。
从SG2内容可以看到PP项目计划强调的内容仍然是一个项目综合计划的内容，SP2.2涉及到初步的风险管理计划制定，SP2.3涉及到数据管理计划；SP2.4涉及到人力资源计划，SP2.5涉及到培训计划等。到了IPM集成项目管理后更加强调了集成计划，会再增加入质量保证计划、配置管理计划，测试计划等。
SP2.1+SP2.4基本就涵盖了PMBOK中时间管理过程组的所有内容。最终的目的仍然是要有一个进度表出来，这个进度表考虑了活动间的依赖关系，每个活动的复杂度和持续时间，关键路径，资源的分配和平衡等各个方面的内容。在这个过程中我们看到关于活动和任务的所有属性基本上都得到了确定了完善，包括任务的依赖关系，开始和结束时间，分配的资源，输入，产出定义。
SP2.1还有个重要内容就是要确定项目的重要里程碑，里程碑的一个重点是来保证度量的准确性，另外就是在里程碑点的时候我们要及时的检查计划和实际执行的偏差情况，当偏差超出了某一个范围的时候就要考虑是否采取相应的纠正措施。
在三级有专门的RSKM风险管理过程域，三级的风险管理更加强调了组织级的风险管理流程和风险参数的定义，组织级的历史风险库等内容。在二级PP里面的风险管理一般做到能够能够识别风险，优先级排序和文档化排序，并没有对文档的分析方法，风险的应对和跟踪过多的进行要求。
注意SP2.4可能是在项目一开始的时候就确定的，也可能是我们更多强调的进度和质量要求，对于资源的投入没有明确的要求。但是要注意的是能够排进度计划的时候资源和资源的分配都应该是基本确定的了。在SP2.4的子实践中也强调了，项目的人员配置取决于为完成项目需求而将项目需求分解为在WBS工作包内任务、角色、职责的分配。人员配置需求应该考虑每个已标识职位要求的知识和技能(像在计划需要的知识和技能特有实践中定义的)。
在项目计划中要计划项目需要的知识和技能，评估当前项目成员是否具备这些技能，如果没有达到则需要安排相应的培训进行学习或者避免使用一些新技术。这也是一个风险管理的过程。在二级这个工作主要是在项目层面进行的，在项目是可重复的，到了三级后提升到组织层面，有专门的OT过程域进行对应。
我们都知道干系人分析和管理是项目管理的一个重要内容，在项目计划阶段我们需要识别项目干系人，分析项目各个阶段活动和干系人之间的关系，知道项目干系人对项目的影响以平衡干系人的期望。对于SP2.6可行的一个方法是通过标识项目中人员和功能需要代表的类型来标识项目生命周期所有阶段的项目相关人员，并描述他们的相关性和在特定项目活动的交互程度。用两维矩阵来描述，一个轴是项目相关人员，另一个轴是项目活动，这是实现这种标识的方便的格式。
有了以上活动后，最终就是要形成一个整体的项目计划。项目计划的意思就是到了项目执行阶段后所有的活动都是事先有所计划进行的，而不是太多的临时任务。为项目产生的计划确定了所有方面的工作：项目生命周期考虑；技术和管理任务；预算和进度；里程碑；数据管理；风险标识；资源和技能需求；项目相关人员的标识和交互。基础设施的描述包括项目人员、管理和支持组织的职责和授权关系。
SG 3: 获得对计划的承诺：要建立和维护对项目计划的承诺
- SP3.1 评审项目的附属计划
- SP3.2 协调工作和资源
- SP3.3 获得计划的承诺
对应SG3主要说明项目计划指定完成后，必须得到项目识别的所有干系人对计划的承诺。而要获取计划承诺的一个重要方式就是对项目计划进行评审，包括项目的附属计划。当出现了相关干系人利益冲突的时候，需要考虑平衡和对计划进行调整。
相关的通用实践和PP过程域的关系
GP 2.2: 制订活动的计划(做项目计划前要先有计划的计划)
GP
2.3: 提供资源(提供进行项目计划活动的资源，你制定项目计划需要哪些资源参与)
GP
2.4: 明确职责
GP 2.5: 培训员工(员工知道如何做计划，估算的方法和原理，风险识别方法等)
GP 2.6: 管理配置(计划活动的内容是受控的)
GP
2.7: 识别和争取相关干系人的参与(和SP2.6的区别?)
GP
2.8: 对活动进行监控(对计划活动进行监控)
三级对PP项目计划的一些要求
- 根据组织标准过程进行过程定义和裁剪，首先要先选择生命周期模型
- 在项目计划中要有风险管理计划，能定性分析风险，对关键风险有缓解措施的制定
- 项目的估算参数来源于组织级的基线数据，但是项目可以根据需要进行调整
- 项目计划是集成计划，要考虑和质量保证计划，配置管理计划，测试计划等配合和集成
- 项目计划有了组织提供的标准规程和模板形成的最佳实践，制定项目计划时候要遵循
四级对PP项目计划的一些要求
- 通过项目历史数据已经分析了项目自身哪些过程或子过程是稳定的。
- 根据业务和客户的目标在项目计划中要确定项目的哪些子过程要进行量化管理。
- 确定要量化管理的子过程采取的方法，工具和技术。
- 通过组织提供的PPM对项目的目标进行量化的预算，如工作量，周期和缺陷情况等。
- 对风险管理进行了量化，比如引入蒙特卡洛方法对风险分析进行了量化。
- 根据总的质量目标分析和定义了可量化的过程性能指标(目标值，控制上下限)
| 
