项目管理PMP输入输出ITTO联想记忆——范围管理
一、收集需求
拿着老板签字找客户收需求，定计划、记跟踪。
首先要找到相关人包括客户来了解需求，通过【干系人登记册】，由于人太多，让相关人了解项目大概是什么，最快方法就是让他们自己看【项目章程】
然后得到他们的需求了，记在重要的【需求文件】里，其他范围管理都要用到它，另外一次性把如何管理需求【需求管理计划】和如何从需求跟踪到客户【需求跟踪矩阵】也做好了。
二、定义范围
在章程上填需求。【项目章程】本来就提了点项目大概要做什么，就对照【需求文档】直接在上面总结，省时省力，一下子就总结成一个文档了【项目范围说明书】。
相对需求文件，范围说明书比较粗略，所以在核实和控制过程还是用需求文件，而没有用范围说明书。
三、创建WBS
在范围说明书分解出WBS。对照【需求文档】拿【项目范围说明书】开刀，你要什么我就给你分什么，最后分解成【WBS】和【WBS词典】
然后把项目范围说明书、WBS和WBS词典一起装订起来又成了一个新重要基准文档【范围基准】，竟然可以这样写文档，真可谓天下文章一大抄啊。
四、核实范围
核实产品是否在范围内。首先要通过【需求跟踪矩阵】去保持客户联系，确定产品范围有没变，确保【需求文档】最新后，用它去核实“确认过质量的产品”【确认的可交付成果】的范围
核实没有问题就可以验收这个产品【验收的可交付成果】，有问题就产生一个【变更请求】。注意在核实和控制过程还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。
五、控制范围
控制工作是否在范围内。首先还是要通过【需求跟踪矩阵】去保持客户联系，确定工作范围有没变，确保【需求文档】更新到最新
既然是控制工作本身，那就要用到每日收集的工作状况【工作绩效信息】，去对照【需求文档】得到工作做出的效果如何【项目绩效测量结果】，有问题就产生一个【变更请求】。
注意在核实和控制过程还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。
从技术工具层面上说
收集需求要面对那么多人，自然少不了方法，人不多可以（访谈），多了点就分（焦点小组），意见不统一可以开（引导研讨会）引导一下，人再多就发挥（群体创新）和（决策）能力，人再再多就（问卷调查），遇到有些人不太爱说就（观察），说不清楚的干脆做个（模型）出来看看。
定义范围就是定义要做的事情，也就是最终产品范围就是这样了，所以好方法应该是找个现在市面上类似的（产品分析）一下，简单高效，分析的时候要多用点（备选方案来识别），保险起见，再开个（引导式研讨会），请客户一起来分析
创建WBS就是分解，一层层（分解）到工作包
核实范围是查东西好不好，就是拿着最终东西翻来覆去的（检查）
控制范围是查过程好不好，进行（偏差分析），来工作绩效信息和需求文档——比较是否有偏差。
