项目范围计划讲义.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 工作包编码举例： 编码不仅把不同的项目单元区别开，而且要保留它所有特征，如所属的子项目，所属区域、专业功能、要素等。在项目实施过程中的网络分析，成本管理、数据的储存、分析、统计都靠编码识别。 层 逻辑流(功能) 生命周期 组织 管理层 项目干系人指定 向管理层做状态报告 大型项目 项目 任务 子任务 工作包 活动层次 大型项目 系统 子系统 人 人 人 大型项目 生命周期 系统 子系统 人 人 大型项目 事业部 部门 组 人 人 技术层 承包商为内部控制而设计 建立WBS的常用分解方式 一个单位工作任务只能在WBS中出现一次 一个WBS项的工作内容是其下一级各项工作之和 每项工作由一个人负责 WBS必须与工作任务的实际执行过程相一致 项目组成员参与WBS 的制定过程 每一个WBS项必须有准确描述 工作包的80小时原则 WBS具有一定的灵活性，以适应变更的需要 建立WBS的指导原则 1）遵循指导方针 DOD 的项目范围说明中明确指出项目的WBS 2）类比法 选取相似项目的WBS作为参考，比如，美国麦克唐那飞机制造公司 3）从上至下或从下至上方法 建立WBS的方法 利用工作分解结构模板(类比) .1 工作分解结构模板—WBS templates 以前项目的工作分解结构（ work breakdown structure，简称WBS）常常被用作新项目的模板： 相同或类似的项目生命周期 每个阶段有相同或类似的可移交项 .2 分解 确定项目的主 要可交付成果 确定每个可付成果的详细 程度是否已经达到了足以编制出 恰当的成本和历时估算 确定可交付成 果的组成元素 核实分解的正确性 YES NO 分解技术 第一步：确定项目的主要可交付成果，包括项目管理。主要可交付成果总是依据项目的实际管理方式进行定义的，例如： 项目生命周期的各个阶段可能作为分解的第一层次，而项目可交付成果可能作为分解的第二层次。 WBS各个分支中的组织原则可能会不同 YES NO 第二步：确定每个可付成果的详细程度是否已经达到了足以编制出恰当的成本和历时估算。 Yes！?第四步 No! ?第三步 分解技术 YES NO 第三步：识别可交付成果的组成元素 可以是服务或产品 在每个组成元素上重复步骤2 能以切实的、可校验的语言加 以描述，以方便进行绩效测量 能对该项目工作实际上将如何 被完成进行描述 分解技术 YES NO 第四步：对分解的正确性进行校验 下一层的元素是否对于完成上一层工作是必须的且足够的？ No ? 增减或重新定义 是否每一项元素都已被清楚且完整地定义？ No ? 对说明进行修改 是否对每一项元素都能进行成本和进度估算，并且将此项工作分配给某个组织单元（如：部门、团队、个人等），以使其承担完成该项工作的责任，以及实施足够的管理控制？ No ? 需要进行修改 分解技术 YES NO 几种不同的分解结构 合同工作分解结构 (CWBS)：用于界定销售者提供给购买者的产品报告级别。内容比WBS的少，用于卖方管理买方的工作。 组织分解结构（OBS）：用以展示工作要素已经分配给了具体的组织单位 资源分析结构 (RBS)：是OBS的一个变种，常 在将工作元素分配给个人时使用 工料清单 (BOM)：制造业中对生产某种产品的原材料的结构化表述 风险分解结构 (RBS)：Risk Breakdown Structure 项目的管理工作 作为项目的领导，业务性的工作也与你有关。在软件项目中，项目领导在做技术工作之余，也要承担项目的管理工作，根据我们提出的拇指法则（rule of thumb），你应当有6％－8％的精力用于项目管理：对于小项目，比如，6人或6人以下的项目，6％就可以了，而对于大项目，比如说，超过12个人，就需要8％的精力了。 尽管在这里考虑了项目团队成员承担的工作，但事实上，大部分工作（75％－80％，或者更多）是由项目经理或团队领导承担的。 项目的计划活动，包括进度安排、估计和基于计算机的工具文件的更新。 记录进程或者设定目标的项目会议。 项目报告。 日常工作安排。 所有项目团队成员的人员问题，包括人员鉴定和评审。 日常问题的解决。 与供应商的沟通，包括内部和外部。 与管理层的沟通。 与客户的沟通。 与相关／依赖项目的联络。 正常工作过程中的人员招募。 质量。 质量计划／配置管理计划。 软件开发项目WBS范例 1. 产品需求阶段 1.1 产品需求文档 研究 编写 分发 个人评估 评审会议 更新/修改文档 重新分发 第二次评审 签署 1.2 结束产品需求阶