项目管理案例（知识点V1.4）.docVIP

项目整体管理 项目计划应包括的内容 项目总计划 包括范围计划、工作范围定义、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划及费用计划 项目辅助计划 质量计划、沟通计划、人力资源计划、风险计划和采购计划 如何制定有效的计划： 制定切实可行的计划，由项目组人员根据整体项目计划来制定个人项目工作计划。将项目计划与项目组人员、公司领导、客户进行沟通，并及时修正，必要时可以展开讨论。在项目组中建立起变更控制系统。 注意事项：项目计划的精细粒度， 项目执行时存在的问题： 识别项目干系人。信息技术部门的支持。项目计划注意沟通。责任任务的平衡。 干系人负责影响处理 绩效报告：绩效报告的制定及发布： 变更：如何变更更加有效： 项目如何收尾：合同收尾、管理收尾 项目计划制定时常见问题 粒度大小、干系人的沟通、是否切合实际 项目启动主要活动 识别项目需求 解决方案的确定 对项目进行可行性分析 项目立项 确定项目章程 提前完工的对策 在进度管理上，可以采用加班等方式 投入更多的人力、物力 把握关键路径上的任务 其它整体管理问题 项目缺少整体管理计划（应建立整体管理机制，制订项目的整体管理计划，并重新进行资源平衡）。 缺少整体的报告和监控机制，各小组各自为政（建立和加强项目的沟通、报告、监控机制，理清各子项目组的工作状态）。 项目缺少整体变更控制流程和机制，不允许修改是不切合实际的（加强项目的整体变更控制）。 项目缺乏有效的质量管理，没有对项目进行及时的监控，进度监控的周期过长。 项目管理计划没有把握好层次性（重新制订切实可行的整体项目管理计划，成员根据此来制订个人的项目工作计划）。 制订项目管理计划时没有与客户、领导、项目组人员进行及时沟通（与他们进行沟通，并及时修正，必要时可开会讨论）。 制订的项目管理计划不切合实际（重新制订切实可行的计划，并在项目组中建立起变更控制系统）。 项目中没有仔细分析项目干系人（应全面分析和识别项目干系人，确定重点沟通对象，尽可能地与其沟通）。 过于关注各阶段的具体技术工作，忽视了项目整体管理和协调（加强整体管理和协调，减少具体技术工作）。 系统定义不够充分。 项目技术工作的生命周期未按时间顺序与管理工作的生命周期统一协调起来。 项目变更没有明确的授权。 项目变更没有进行必要的审核。 项目变更没有对变更的影响进行评估。 项目变更没有让客户确认是否接受变更的代价。 项目范围管理 项目范围是有效管理需求变更的唯一方法。 项目范围的管理就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。功能需求并不是客户或用户提供，是项目组成员在理解目前的人工作业后分析出来的结果。建立功能需求是软件开发人员的责任，不是客户或用户能够提供的内容。 项目范围不是由客户或用户提供，是依据要开发的项目目标（如何达到）和项目的最终交付而制订出来的结果。 范围管理的基本内容 确定项目的需求 定义规划项目的范围 范围管理的实施 范围的变更控制管理 范围核实 项目范围管理包括5个过程： 范围计划编制 范围定义 创建工作分解结构 范围确认 范围控制 如何定义范围 定义和规划项目目标，可交付成果的性能指标、约束条件、工作原则以及管理策略等。确定项目范围时，应该根据需求的定义，将项目范围分解为成面向产品或服务的层次结构，即PBS。 WBS WBS的最底层为工作包，最终的工作包都必须有明确可验证的交付成果。 “项目管理”工作是WBS中所必须的，注意不要遗漏。 WBS总是处于计划过程的中心，也是制订进度计划、资源需求、成本预算、风险管理计划和采购计划的重要基础。 WBS同时也是控制项目变更的重要基础。项目范围是由WBS定义的，所以WBS也是一个项目的综合工具。 创建WBS的方法 使用指导方针 类比方法 自上而下的方法 自下而上的方法 创建WBS的基本要求 某项任务应该在WBS中的一个地方且只应在WBS中的一个地方出现 WBS中某项只能有一个责任人，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。 WBS必须与实际工作中执行方式一致。 应让项目团队成员积极参与创建WBS，以确保WBS的一致性。 每个WBS项都必须文档化，以确保准确地理解已包括的和未包括的工作范围。 WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。 WBS的作用 防止应该做的工作被遗漏掉防止镀金 方便项目团队沟通 防止不必要变更 提供一个基本的资源估算依据 帮助获取团队认同和创建团队。 需求开发、需求管理和范围管理的联系和区别 通过需求开发来获取项目的需求，在此基础上确定项目的范围、进行项目范围管理 需求管理是对已批准的项目需求进行全生命周期的管理，其过程包括需求管理定义、需求管理流程、制定需求管理计划、管理需求和实施建议等。 对于项