内容发布更新时间 : 2024/5/26 20:16:42星期一 下面是文章的全部内容请认真阅读。

项目管理PMP输入输出ITTO联想记忆

首先按照过程组的数量进行编号为：667-4343-644

一、整合管理

整体管理是667-4343-644的6了，也就是有6个过程。为了便于区分输入输出，是【）代表输入，（】代表输出，【】代表过程，（）代表技术工具。 1、输入和输出

【4.1制定项目章程】：找老板签字立项。怎么才能项目批准呢，先说一番项目大概要做什么【项目工作说明书），再找专家说我看行【商业论证），再不行的话，杀手锏-【协议），既然客户都给钱来做，看样子老板想说不行都难，这样项目就批准了，立个文档老板签个字（项目章程】。 工具和技术：专家判断、引导技术（头脑风暴、冲突处理、引导者帮助团队、引导者帮助个人、问题解决、会议管理）

【4.2制定项目计划】：拿着老板签字找人汇总计划。首先我就拿着老板的文件【项目章程）给大家看，大家就知道我是头，就肯听我的了，然后让大家一起来定一个个小计划，例如成本计划，时间进度等（其他领域的计划），完事后一起装订成一个大计划（项目管理计划】， 这个计划非常重要，干活和监督时候都要用到，后面就不再提它。 13个计划文件和3个及基准 工具和技术：专家判断、引导技术

【4.3指导与管理项目执行】：提意见，记考核，做东西的过程，要实施批准的变更，所以还要更新计划、更新文件。 提意见就是发现谁做事方法不对，就提出（变更请求】（包括纠正措施、预防措施、缺陷补救）； 记考核就是每天收集项目工作情况（工作绩效信息】； 做东西就是要做出点东西出来（可交付成果】；

实际过程中会经常发现一些地方有问题，提出修改意见再实施变更控制得到批准后即【批准的变更）； 得到【批准的变更），要先更新相关计划和相关文件，然后继续实施。

工具和技术：专家判断、项目管理信息系统（作为事业环境因素的一部分，提供进度计划工具、工作授权系统、配置管理系统、信息收集和发布系统，可自动收集和报告KPI）、会议

【4.4监控项目工作】：实时监控，贯穿整个项目管理。 监督实施过程中提出的【工作绩效信息)；

收集绩效信息（从【4.3指导与管理项目执行】过程中【工作绩效信息)得到）； 测量绩效信息（实际绩效与【管理计划进行比较) )； 如发现问题，提出（变更请求】。

评估绩效信息，做出预测得到，预测趋势（挣值分析【进度预测)、【成本预测)）），以便推动过程改进得到(工作绩效报告】；

项目计划、实施工作中提出并被确认的变更请求、工作绩效数据，作报告提建议。可以想象这样一个场景，在一个会议室，一群人坐在下面包括老板，项目经理在台上做ppt 讲演(工作绩效报告】，项目经理激情洋溢的说进度提前，成本节省等，现在项目做的很不错，请领导放心，然后老板再提出一些改正建议（变更请求】

工具和技术：专家判断、分析技术（回归分析、预测方法、挣值管理、差异分析、储备分析等）、项目管理信息系统、会议

【4.5实施整体变更控制】：审批变更。提出很多建议【变更请求）是要通过变更控制委员会来审批的，好的才要，不好的建议要去除，如何做呢？通过拿和目前工作状况【工作绩效报告）一比较，就知道了，批准的话就有（批准的变更请求】输出了，这个又可以去指导管理大家干活。 整理变更控制过程贯穿始终，项目经理对此负最终责任；

机制：所有变更都必须以书面形式记录，每项记录变更都有责任人（项目责任人或项目经理），—并纳入变更管理和或配置管理系统中，变更请求应该由变更控制系统和配置控制系统中规定的过程进行处理。 变更机制可由CCB实施整理变更控制过程；

变更请求得到CCB（有时还需要客户或发起人）批准后，可能要更新成本估算、活动排序、进度日期、资源需求和风险应对等。 方法：专家判断、会议、变更控制工具 输出：批准的变更请求、变更日志、更新

【4.6结束项目或阶段】：打包交货。最后就把【验收过的可交付成果）包装一下，成了（最终的产品或服务】交给客户了，然后总结积累经验。

小结：从技术工具上来看，整作管理基本靠大局观，那个大呀，大的无边无际，没有方法可寻，基本都靠问人（专家判断）和开会、用系统（项目管理信息系统）、找委员会（变更控制会）。什么时候用什么呢？专家什么时候都要用到，【指导和管理项目执行、监控项目工作】时用系统（项目管理信息系统），有变的时候【整体变更控制】用变更控制工具，找CCB开会委员会去变。

二、范围管理

范围管理就是管理做哪些事情。范围管理是667-4343-644的6，也就是有6个过程

【5.1规划范围管理】：范围管理指导性指南，规定如何收集、定义、创建、确认和控制范围，用什么方法等

1.无从下手，得从章程入手，章程中有背景信息、高层级的产品描述和特征等，从【项目管理章程)中寻找信息，结合事业环境和组织资产，形成【需求管理计划）、【范围管理计划）。

2.一个项目可能有多个阶段，最好每一个阶段制定各自的需求管理计划和文件，便于规划、跟踪、配置、测量。

【5.2收集需求】：拿着老板签字项目章程找客户收集需求，定计划、记跟踪。首先要找到相关人包括客户，得通过【干系人登记册），找到人之后，得看看管理干系人的原则【干系人管理计划），由于人太多，让相关人了解项目大概是什么最快办法就是让他们自己看【项目章程）。

工具和技术：调研（访谈、问卷调查、观察、原型法）、引导式研讨会（快速定跨职能和协调干系人差异，JAD、QFD）、焦点小组、群体创新技术（头脑风暴、思维导图、亲和图、多标准决策分析）、群体决策技术（包括一致同意（德尔菲技术）、大多数原则（名义小组）、相对多数原则、独裁）、标杆对照、系统交互图、文件分析。

然后得到他们的需求了，记在重要的（需求文件】（客户->需求）里,其他范围管理都要用到它，（需求文件】的技术支持（需求跟踪矩阵】（需求描述-WBS可交付成果）也做好了。

需求文件包括：业务需求、干系人需求、解决方案需求、项目需求、过度需求、假设条件、依赖关系和制约因素

【5.3定义范围】：筛选需求，明确收集到的【需求文件）哪些属于项目范围，得到最终的【需求文件）；根据得到的【需求文件）制定项目及产品的服务、成果描述。翻翻【项目章程），里面提到高层级需求和审批要求。一下子就总结成一个文档了（项目范围说明书】。 相对需求文件，范围说明书比较粗略，所以在确认和控制范围过程还是用需求文件，而没有用范围说明书。

项目范围说明书包括：项目范围、产品范围描述（逐步细化章程和需求文件中产品、服务和成果的特征）、验收标准、可交付成果、项目的除外责任、假设条件和制约因素。

同时记得更新：干系人登记册、需求文件、需求跟踪矩阵。

工具和技术：专家判断、产品分析（需求分析QFD、系统分析、价值工程等） 、备选方案生成、引导式研讨会

【5.4创建WBS】：在范围说明书分解出WBS。对照【需求文件）拿【项目范围说明书）开刀，你要什么我就给你分什么，最后分解成（WBS】和（WBS 词典】，然后把【项目范围说明书）、（WBS】和（WBS 词典】一起装订起来又成了一个新重要基准文档（范围基准】，竟然可以这样写文档，真可谓天下文章一大抄啊。 范围基准：经批准的项目范围说明、WBS和WBS词典。 工具和技术：分解、专家判断

【5.5确认范围】：正式验收已完成的项目可交付成果的过程。

确认产品是否在范围内，首先要通过【需求跟踪矩阵）去保持客户联系，确定产品范围有没变，确保【需求文件）最新后，同时查看【工作绩效数据），用它去核实“确认过质量的产品”【核实的可交付成果）(执行过程组中指导和管理项目工作输出“可交付成果”，经过控制质量后变成“核实的可交付成果”)的范围，核实没有问题就可以验收这个产品（验收的可交付成果】，有问题就产生一个（变更请求】。注意在核实和控制过程还是用需求文件，而没有用范围说明书，因为相对需求文件，范围说明书比较粗略。