PRESENTATION TITLE 项目管理最佳实践 方莹.

Presentation on theme: "PRESENTATION TITLE 项目管理最佳实践 方莹."— Presentation transcript:

1 PRESENTATION TITLE 项目管理最佳实践 方莹

2 1 项目管理导论 2 | Presentation Title | Month 2006

3 创新是企业的发展之道 Innovation = Invention + Commercialization

4 战略愿景（Strategic Vision)
组合管理和项目集管理 战略愿景（Strategic Vision) 动员 战略目标 战略选择 项目组合 项目集（Program） 项目集前期准备 项目集准备 建立管理及技术框架 增量效益交付 结束项目集 效益转移 常规运营 相关项目 项目A 项目B 项目C 项目n 其它项目

5 项目管理管什么？ 项目管理就是通过一系列的步骤,对项目的时间、成本、质量以及范围进行管理 范围
改变范围将会对进度和时间产生影响，需要对时间或其它约束条件进行调整 同理，改变其中一个或几个约束条件也需要对范围作出调整，或对项目的期望值作出修改 范围 质量 成本 时间 平衡

6 什么是项目? 什么是项目管理? 项目：是为提供某项独特的产品或服务所作的临时性努力. 临时性:每个项目有明确的开始和完成日期 .
独特性: 产品/服务在一些现有的方式有所不同 项目管理: 就是把各种知识、技能、工具和技术应用到项目中去以其达到项目干系人的需求和期望，同时要平衡以下的各种相互冲突的要求： 范围、进度、成本、质量和风险. 项目干系人的不同需求和期望 . 识别需求和未识别的期望的要求. 项目干系人是指那些积极参与该项目工作的个体和组织，或者是那些由于项目的实施或项目的成功其利益会受到积极或消极影响的个体和组织。项目管理工作组必须识别哪些个体和组织是项目的干系人，确定他们的需求和期望，然后设法满足和影响这些需求、期望以确保项目能够成功。

7 PMBOK（第4版）项目管理过程组和知识领域表
启动过程组 规划过程组 执行过程组 监控过程组 收尾过程组 4. 项目整合管理 4.1 制定项目章程 4.2 制定项目管理计划 4.3 指导与管理项目执行 4.4 监控项目工作 4.5 实施整体变更控制 4.6 结束项目或阶段 5. 项目范围管理 5.1 收集需求 5.2 定义范围 5.3 创建工作分解结构 5.4 核实范围 5.5 控制范围 6. 项目时间管理 6.1 定义活动 6.2 排列活动顺序 6.3 估算活动资源 6.4 估算活动持续时间 6.5 制定进度计划 6.6 控制进度 7. 项目成本管理 7.1 估算成本 7.2 制定预算 7.3 控制成本 8. 项目质量管理 8.1 规划质量 8.2 实施质量保证 8.3 实施质量控制 9. 项目人力资源管理 9.1 制定人力资源计划 9.2 组建项目团队 9.3 建设项目团队 9.4 管理项目团队 10. 项目沟通管理 10.1 识别干系人 10.2 规划沟通 10.3 发布信息 10.4 管理干系人期望 10.5 报告绩效 11. 项目风险管理 11.1 规划风险管理 11.2 识别风险 11.3 实施定性风险分析 11.4 实施定量风险分析 11.5 规划风险应对 11.6 监控风险 12. 项目采购管理 12.1 规划采购 12.2 实施采购 12.3 管理采购 12.4 结束采购

8 项目管理理论和应用模型 …… 行业应用 知识体系 任务视角 领导力视角 系统视角 项目干系人视角 商务视角 合同视角 军事、国防工业
建筑行业 软件开发 制造业 服务业 …… 研究视角 项目采购管理 项目风险管理 项目沟通管理 项目质量管理 项目成本管理 项目范围管理 项目整体管理 项目时间管理 项目人力资源管理

9 组织结构的类型 项目型 职能型 矩阵型 三种组织结构的类型是： President President Project VP
Support Team member 职能型 President VP Purchasing Marketing Production R&D 矩阵型 President VP Purchasing Marketing Production R&D Project

10 项目组织 项目组织 项目的核心团队基本规则 项目核心团队 项目管理团队 (R&D) 核心小组在DR0+组建 核心团队由产品经理领导
CS&Q PM M&S Operations PLM 项目的核心团队基本规则 核心小组在DR0+组建 核心团队由产品经理领导 核心团队每周举行例会议题包括 项目进展情况, 问题以及所要关心的问题 特性的遗漏/重复或增加 核心小组的所有成员出席所有这些这些会议 (1) 项目范围的变化向项目管理办公室和项目总监报告 核心团队的概念在可以是BU和研发之间是透明的，BU在项目中可以在更高的管理层面上干预项目。

11 PDT — Product Development Team
实例：产品开发项目典型项目团队结构图 产品线总经理 产品线市场部 产品线项目管理部 产品经理 项目经理 系统级工程师 计划经理 质量经理 市场经理 研发经理 生产经理 采购经理 技术支援经理 销售经理 成本经理 需求人员 售前人员 客户人员 软件开发组1 软件开发组2 硬件开发组 测试组 结构开发组 工艺组 生产组 试制组 装备组 国内销售人员 国际销售人员 维护组 工程设计组 工程安装组 各产品线 例行组织 PCT PCT项目组织 PCT扩展组 PDT — Product Development Team

12 典型的产品生命周期 开发活动中采用并行工程 市场准备就绪评审 (启动计划) 立项 指定和任命项目核心团队 (BU内)
用于详细估算的最初的产品特性表 技术评估 投放市场前评估 (开始促销和销售) 发布产品目录 商业信息散发 相关的应用项目启动 DR3 可能在DR2之前或之后 量产准备就绪评审 (启动部署和维护) 项目移交 策略准备就绪评审 (启动商业机会定义) DR0 DR0+ DR1 产品原形准备 商业机会 定义 计划 DR2 DR3 DR3P DR4 DR5 销售和技术开发 确认 Ltd 部署 DR6 DR6+ 商务准备就绪评审 启动开发 商务部门和R&D签署开发协议或合同 承诺项目的范围、时间和预算 承诺至DR5项目所需要的资源 修改目标成本 兼容策略 项目组织 部署&维护 退出阶段 启动产品认证 HW, SW, OEM, … 进行系统测试 内部里程碑 认证活动 客户准备就绪 (验收开始） 批准提交客户/验收测试为市场测试作准备 退出评审 (退出市场) 产品生命周期终止评审 (停止支持） 停止各种支持活动（维护、库存、维修、售后服务等） 开发活动中采用并行工程 note: DR0+, DR1, DR3, DR4, DR6, and DR6+ are mandatory for all ABC products

13 结构化的开发流程 产品管理 及市场 营销 核心小组组 VI. 产品运营与维护 V. 客户验收 IV. 验证 III. 设计开发 II. 规划
0. Pre-DR 阶段功能 概念小组 5.1 产品 维护计划 3.1综合计划更新 2.1产品与项目综合计划 1.1 概念描述 与商业策划 0.1 启动商业计划 核心小组 1.2 市场 需求定义 2.3 产品 2.2 外部资源利用与协作管理） 项目团队 产品维护组 3.2 产品市场准备 4.1 产品市场启动与推广 3.3客户文档准备 3.5硬件开发 3.6 软件开发 3.7产业化开发 3.4 系统设计 3.8 集成与 测试 4.2 系统 5.3 现场 6.1 产品 维护与支持 5.2 客户验收 4.3内部 确认测试 4.4 产品认证与入网 4.5小批量试生产 6.2 批量生产 3.9 生产设备与工艺开发 3.10 原材料与零部件采购

14 讨论 在您的项目哪些是你想改进的地方？启动一个新产品开发项目要考虑的要素(10个以上)有哪些？

15 项目管理过程组 启动过程 计划过程 控制过程 执行过程 结束过程 确认项目或项目的某个阶段可以开始或获得可以启动的承诺
制定和修改切实可行方案和来完成项目的需求 执行过程 控制过程 组织协调相关人员以及各种资源执行项目计划 监控和纠正确保项目目标的达成 结束过程 过程组在项目各个可以重复进行 通过正式验收并移交项目

16 2 启动过程 16 | Presentation Title | Month 2006

17 制定项目章程 输入 专家判断 工具与技术 项目章程 输出 项目工作说明书 商业论证 合同 事业环境因素 组织过程资产

18 项目启动的标志：项目章程 项目章程的主要包括： 项目的背景说明。包括机会与机遇的说明。 这一问题究竟是什么样的问题？ 为什么要做这个项目？
这个项目的范围如何界定？ 列一个产品清单，说明项目的产品，包括最终产品、中间产品。 目标是什么？项目的产品是什么？有什么要求，完成标准是什么？ 说明项目经理的权力、范围。必须在项目章程上体现项目经理的权力范围，并有一个专门的证书正式确认项目经理的权利。 项目章程

19 3 需求管理 19 | Presentation Title | Month 2006

20 收集需求 输入 访谈 焦点小组会议 引导式研讨会 群体创新技术 群体决策技术 问卷调查 观察 原型法 工具与技术 需求文件 需求管理计划
需求跟踪矩阵 输出 项目章程 干系人登记册

21 需求管理流程 ... RCR： Requirement change request 项目 需求控制 委员会 DR0 DR1 需求 更新
否决/ 等待 产品线管理 项目 项目 销售, 市场 项目 DR0 需求控制 委员会 DR1 需求 招标 更新 初步分析 项目 DR0 更新 演进策略 产品开发 These were the objectives we established earlier this year We chose to keep scope flexibility to 30% to allow primarily market driven changes to the feature-set We chose to limit schedule and cost deviation to within 10% And target fault capture is 95% We have been tracking our performance against these targets 平台研究/ 策略工作组 ... RCRs RCR： Requirement change request 确定市场需求

22 需求分析类型 初步分析 为 DR0准备 精度 -75/+300% 详细分析 为DR1准备 精度 +-20%

23 实例：需求管理团队 初步分析是有一个涵盖所有相关领域的多职能的团队来实施的 主要输出: RCR人工量估算
(= RCReffort =具体到这个RCR人工量) 产品生命 周期管理 项目 RCB 系统 软件 初步分析 团队 硬件 SIT 需求控制 委员会

24 需求分析步骤 需求分析研究 搞清需求是否正确/ 冲突/ 冗余的 检查商业论证 可行性分析研究 这是可行的吗? 底层设计分析研究 顶层设计
受影响的文档 人工量分析 工作分解 人工量 影响分析研究 工作分解的结果对其他项目的计划、预算以及开发计划的影响 对于初步分析通常不需要做

25 PM -> System Project Leader
DR1 准备 需求控制委员会 DR0 DR0+ DR1 前端任务: PM -> System Project Leader PM 主要活动: 初步分析 工时分析研究* 计划 现有信息: 发布 可测试性 工作分解 相关性 需要的材料 标号 这一阶段的详细分析是不准确 需求分析研究 可行性分析研究 顶层设计研究 团队重新估算 项目人工量 计划 测试设备 项目组织 RCR-人工量 版本的工作内容在DR0+被冻结. *正式被称为可行性研究 风险评估 开发计划 项目人工量估算 产品需求规格

26 需求分析工具：产品差异化模型 $APPEALS
$-产品价格(Price) A-可获得性(Availability) P-包装(Packaging) P-性能(Performance) E-易用性(Easy to use) A-保证程度(Assurances) L-生命周期成本(Life cycle of cost) S-社会接受程度(Social acceptance)

27 需求分析工具：产品差异化模型 $APPEALS
Price 价格 A vailability 可获得性 P ackaging 包装 erformance 性能 E ase of use 易用性 ssurances 保用性 L ife cycle cost 生命周期成本 S ocial influences 社会影响 P包装 P性能 E易用 A保证 L生命周期成本 S社会接受程度 $价格 A可获得性

28 实例：$APPEALS产品差异化模型 P包装 A可获得性 P性能 E易用性 ＄价格 A保证 S社会接受程度 L生命周期成本 P包装
视觉评估 销售界面 布局 尺寸 风格 颜色 结构 等… P性能 购买过程 分销 销售 分配 渠道 交货期 广告 订购 等… 规格比较 速度 功能 规格 容量 精确度 多功能性 多产性 等… E易用性 ＄价格 P包装 感觉的比较 安装 可用性 升级 图形化 显示 人类工程学 文档 等… A可获得性 P性能 价格比较 技术 原材料 生产 人力成本 管理成本 库存 废料 等… ＄价格 E易用性 A保证 S社会接受程度 S社会接受程度 A保证 L生命周期成本 其它方面的影响 顾问 团体 环境的影响 法律关系 安全 保密 责任 等… 顾虑和响应 可靠性 可用性 可（维）修性 保证 质量 安全性 稳定性 完整性 等… L生命周期成本 真实成本比较 寿命 正常运作／停工时间 磨损 服务 备件 能源 操作成本 等…

29 练习：联通114和XX的12580的差异化

30 练习：需求分析（号码百事通） 客户需求：列举出项目客户所关注的因素。
相对重要性：指对项目客户而言，这些需求的重要程度，相对重要性等级从9到1，9代表对客户最重要，1表示重要程度最低。 需求支持度：每项满足需末的要素(措施)对每项客户需求的支持度分为9个等级，9代表该措施对某项需求支持或影响最大，1 代表支持或影响最微弱。 加权总分：接列将每个需求相对重要性值与每项措施的需求支持度值相乘后相加，得出该措施的加权总分。得分从高到低表明应该关注的次序。 难度等级：将实施该措施的难度分为5个等级，1为最难，5为最容易。 权衡原则：在加权总分排序和难度等级排序中进行权衡，选择具有突破口的因素。

31 项目目标设立 目标：电信“号码百事通”业务全年完成1000万元人民币销售
措施：A．广告宣传吸引前向客户；B各分局、营销渠道、代理公司拓展后向客户；C．成立“号码百事通”中心专职负责业务开展。 时间：今年度全年。 标准：全年完成1000万元人民币业务收入。 资源：A.投资200万元建设技术支撑平台；B投入300万元广告宣传费；C.500人营销队伍；D.5家代理公司拓展行业客户。 权重比例：100%。 责任人：“号码百事通”中心经理。

32 练习：（号码百事通）项目伙伴分析 前向客户 市场部 后向客户 专业支撑公司 大客户部 公众客户部 多区域分局 代理公司 号码百事通 中心
产品政策 指标授权 渠道管理 特大客户 拓展 号码百事通 中心 广告公司 宣传推广 信息提供方 自我品牌宣传 直接 最终客户 技术支撑 行业性 普通客户

33 练习：（号码百事通）消费者需求与措施因素分析
客户 需求 相对 重要性 满足需求的要素 使用114作为接入号 支持模糊查询 与网络搜索引擎合作 建设全国统一号码百事通品牌 加强话务员培训工作 设计各种 分类客户 拓展信息服务范围 提供各种接入手段 查询方便 9 7 5 1 信息准确 3 覆盖面大 宣传效果好 4 资费便宜 加权总数 146 106 126 84 80 158 改进难度等级 2 说明：对消赍者而言，查询方便与信息准确最重要； 对促销活动而言：·提供各种接入手段、拓展信息范围、使用“114”作为接入号最重要； 对改进绩效而言：使用“114”作为接入号最容易，话务员的素质提升最困难。

34 练习：根据上述案例，完成贵公司的产品的需求分析
客户 需求 相对 重要性 满足需求的要素 加权总数 改进难度等级

35 4 项目估算 35 | Presentation Title | Month 2006

36 项目成本和预算类型 项目的相关人工量成本 （约占整个项目成本的~70% ) 人工量成本 = # [PY] * 成本等级
成本等级是整个人工量的平均值 (= R&D 预算除以人数) 由PM直接负责 项目的直接成本 (约占整个项目的30%) 差旅, 分包, 咨询 (除非直接从项目组织出的部分),.. 模型, 软件包, .. 超出PM预见 预算种类 运营计划 最终预算 预测 (为年度剩下的各个季度做预算预测) 给出每个产品开发线概况 (业务单位– 产品线 – 项目)

37 实例：某公司的人工量估算流程 主要在DR0前到DR1进行 在项目生命周期中对照实际和估算持续不断地进行评审。 初步分析
初步分析在DR0之前进行以确定每个RCR的人工量. 这个人工量计算研发项目的所需的总的人工量的基本人工量 可行性分析 估算的人工量用来开发被分配到项目里所有的RCR，它是以DR0中每个RCR为基础的 研发所需的人工量是总的RCR的人工量和项目相关人工量的总和。 研发所需的人工量必须在DR1承诺并批准 结束架构的定义 重新估算出来的人工量承诺要在DR1 完成. 以后的需求在DR1后按照同样的流程执行

38 实例：某公司的人工量估算基本原则 (I) (用于初步分析和详细分析)
人工量的估算必须提供相关的： RCR (Requirement change request): 所有的人工量都可以归结到RCR中. 范围: DR0-DR4.在DR0+之前提供详细的范围信息 项目: 所有的在RCR中不明确的人工量 (项目管理团队人工量、FRs归并等). 要在确定RCR人工量之后才能确定，更详细的要在DR0+之后才能明确。 根据假定的平均熟练程度进行估算 在DR0+和 DR1之间考虑 工作分解通常要在DR0+之后. 在 DR0+后, 由团队领导重新估算并承诺 各个RCR 单独估算 估算时要考虑RCR之间相互的关联，并假定已经具有相应的文档 每个RCR的WBS由各个专业更新维护 系统 : 受影响的文件清单 (可行性研究) 软件 : 收集到的 KLOC 和 每个受影响的部分的人工量 系统集成测试 : # 测试用例 每一个专业要求要在检查表上体现出来 (硬件除外: 常规操作)

39 实例：某公司的人工量估算基本原则 (II) (用于初步分析和详细分析)
RCR 相关的人工量 包含每个RCR 人工量估算模板 (DDTS 工件)。 每个专业的人工量估算 (SE, SW, HW, SIT) 澄清对其对其它项目的影响(Y/N) 接入事业部其它产品 (AWS, …) 负责人工量的分析 (可行性研究): DDTS中的工程师 提供顶层设计(TLD)分析并由所有相关专业人员提供估算 将数据输入到RCR中. 在DDTS中涉及的每个相关专业进行详细的估算 项目相关的人工量 在人工量估算模板中的每个项目 (Excel) PM指派项目管理团队成员提供他们的估算 注意: 在DR1后CRs也包含了一些估算的人工量用于发布。这些版本还没达到DR1和在到达DR1一周前的路线图中已经有的。但这并不保证这些版本会发布。

40 实例：某公司的人工量估算基本原则 (III) (用于初步分析和详细分析)
不列入估算的人工量 (不在 PLF Project Latest Forecast 中) 流程改进, 工具支持 (除了RCR明确的要求以外) 实验室支持 节假日, 员工大会, 病假, 中断打扰, ... 即意味着是净人工量 ( 1人年（毛人工量） = 41 人周（净人工量）)， 在PLF中给出的是毛人工量, 因此其中包括了节假日等. 维护版本的发布 FR-调查时占DR4-DR5工时的一部分 DR0-准备

41 实例：某公司的人工量估算基本原则 (III) (用于初步分析和详细分析)
工时的估算不包括 流程改进, 工具支持 (除了RCR明确的要求以外) 实验室支持 假日, 员工大会, 病假, 中断, ... 这意味这所给出的工时是净工时 ( 1人年 = 42 净人周). 在PLF中, 给出的不是净工时, 包含了假期等. 除了集成测试以外 软件模型 维护发布 FR-调查时占DR4-DR5工时的一部分 DR0-准备

42 实例: 详细系统 RCR 相关的人工量 从编写文档到顶层设计完工（TLDC Top level design completeness）的总的人工量 对别的专业进行评审 / 支持 项目相关的人工量 SPL 人工量 ( x% * (DR0-TLDC) + y% (TLDC-DR4) ) 客户文档 (SPL负责的 R5.1，组织变动后重新评估) 由于在DR1后的加入的CR而进行的文件更新

43 人工量估算模板 Following effort are in PW. 估算 : 初步分析, 详细分析, DR1 系统: 1, 1, 1
在被忽略的数字之间是空格/制表符 0-价值 (如 没有人工数) 必须明确填上 未知的人工数用 “?”表示 可行性分析FS (Feasibility Study) 人工数估算 总计 = 系统+硬件+软件+SIT “估算”: 各个里程碑的估算: 初步分析 (DR0), 详细分析 (DR0+), DR1: DR1 承诺的数量 SW_KLOC = 千行新/变更的代码 只需从DR0+ 算起 NA: Not Applicable EMS的影响, … : only Y or N required 没有人工数估算 详细指南: see link in new RCRs. Following effort are in PW. 估算 : 初步分析, 详细分析, DR1 系统: 1, 1, 1 硬件: 0, 0, 0 软件: 9, 8, 10 SIT: 7, 7, 8 总计: 17, 16, 19 FS_SYS: 5, NA,NA FS_HW: 2,NA,NA FS_SW: 5,NA,NA FS_SIT: 3,NA,NA Total_FS: 15,NA,NA SW_KLOC: NA,11,12 Efforts outside R&D project : EMS: Y/N Other: Y/N Per RCR:

44 练习: 人工量估算 根据前面练习中的RCR估算人工量 pw LA FA DR1 SYS: HW: SW: SIT： Total：
FS_SYS： NA FS_HW： FS_SW： FS_SIT： Total_FS： SW_KLOC：

45 5 计划流程 45 | Presentation Title | Month 2006

46 项目过程组定义 计划过程 为解决和实现业务需要而提出的项目而制定和维护一个可行的方案。 建立该项目的范围或界限。作为项目的基础和期望的基线
未来提出的变更要以这个基线来进行评估 PM 定义和计划项目并的到有关专家和工具的支持如 PEF, WBS, PLF, project schedule

47 项目目标SMART 明确性（Specific） 最终目标是否明确了应该做到哪一步以及何时完成 可度量性（Measurable）
你能在多大程度上测量最终目标的完成情况 可完成性（Achievable） 在规定的时间内，最终目标是否合理，能够实现？ 相关性（Relevant） 最终目标是否很重要、很有价值、是否值得进行下去？ 可跟踪性（Time-Bound） 你能够对整个项目的时间进程进行跟踪检查吗？

48 项目计划流程图实例 项目章程 & 规程 feedback 计划过程 项目计划 确定任务的次序和项目进度 估算所需的人员编制
项目章程 & 规程 计划过程 项目计划 确定任务的次序和项目进度 估算所需的人员编制 识别风险和制定计划 确定项目的质量基准 完成项目的所需的 培训需求 定义量化的项目基线 识别需要完成的项目任务 制定项目开发策略 项目WBS 项目总体计划 项目最新预测 风险清册 项目质量计划 项目培训计划 项目目标 硬件、软件开发计划、项目配置管理计划… feedback 定量分析 沟通计划 说明采购需求 (第三方) 拟定沟通策略 采购计划

49 案例分析：联通的CDMA 在CDMA推出后的最初一段时间，联通的战术性安排与执行力存在较大的问题。在联通C网3个月试运行期过后，贝恩国际顾问公司(BN&CO)得出的调查结论是：联通前期推广中出现的问题多数是操作性问题，如果能够理顺所有环节，在推广力度上不落后于中国移动的GPRS，CDMA有望取得成功。贝恩认为，CDMA在营销的4个P(产品、价格、促销、渠道)上都出现了纰漏。C网的初期不利，营销操作的失败难辞其咎。

50 案例分析：联通的CDMA 联通原本希望，到02年元旦，市场能够提供约400万台手机，因为一期开通的城市达330个，平均每个城市仅1万多台。但让联通意想不到的是，2002年新年，制造商连4万台手机都拿不出来。联通对手机短缺的解释是： CDMA一期工程仅花7个月即开通，规模达到1500万户的容量并覆盖330个城市，多数手机厂家对联通建设C网的高速度估计不足。 国内手机厂商很多通过与国外企业合作生产CDMA手机，合作过程需要一定时间，部分企业合资报批手续启动较晚，还未完全批复下来。 联通是全球第一家提供机卡分离CDMA手机的运营商，对手机生产商技术要求更高，而本土手机生产商研发及生产能力有限，在机卡分离CDMA上投入过大，风险太高。

51 案例分析：联通的CDMA 实质上，联通的解释仅仅揭开了冰山一角，手机短缺还有其他更深层次的原因。
在国内GSM市场利润稳定可观、潜在用户近亿的背景下，多数国内手机厂商(如科健、波导、TCL)等GSM手机生产既得利益者对前途未明的CDMA采取了观望的态度，虽然政府对CDMA的支持显而易见，但这部分生产商更关注现实的收益，不愿贸然进入一个尚不成熟的领域，因而其重心仍放在GSM／GPRS手机的生产上。对CDMA手机充满坚定信心的是中兴、海信、摩托罗拉等另一阵营，他们是GSM手机市场上的迟到者，并对CDMA持乐观预期。但总体上，在C网开通前，19家企业并未准备好相应的手机。

52 案例分析：联通的CDMA 受联通高端定位的影响，CDMA手机定价高，但本土手机缺乏诸如诺基亚、爱立信那样的品牌效应，消费者认同度较差。由于核心技术掌握在高通公司手里，手机生产商必须支付不菲的苍片费用，增加了生产成本，这也是手机生产商对联通责难最多的地方。他们指责联通在2000年与高通的知识产权谈判中没有维护终端制造商的利益。 手机生产商都愿意在CDMA被先行者(主要是联通)炒热并传递出明确的市场需求信号后才大规模生产，并企望在CDMA发展初期实现高额利润。

53 案例分析：联通的CDMA 此外，联通在CDMA网络建设以及市场运作上的失误在一定程度上动摇了手机生产商的信心。
小组讨论： 通常我们怎样做项目计划 从计划的角度来讨论联通在执行中为什么会出现这样的问题

54 成功的计划的条件 明确定义项目目标和工作包 明确定义项目相关的能力、角色和相关的负责人 建立需求分配和估算流程
训练有素的计划制定人员(流程、方法以及工具) 计划流程的工具支持 严格遵守已定义的流程和规程

55 PAC（Project Approval Committee） PCT（Project Core Team）
实例：结构化的开发流程 职责 活动 跟踪 阶段 步骤 任务 活动 (<7) (20–25) (200–400) (1000+) PAC（Project Approval Committee） 流程图总貌 PCT（Project Core Team） 流程指导方针 项目 详细计划 项目团队 研发人员 规程和工作指导

56 实例：企业的产品研发流程的层次结构图 流程概览 阶段流程 支持流程或制度 文档模板 指导产品开发团队对项目 对全流程提供快速浏览，
体现阶段和主要任务 指导产品开发团队对项目 进行计划和管理，体现所 有任务，描述任务之间的 依赖关系，建立流程和子 流程、模板等之间的关系 指导各职能部门的具体 开发工作的支持性流程： 项目管理流程 配置管理流程 需求管理流程 决策评审流程 集成产品和项目计划流程 系统设计流程 详细设计流程 硬件开发流程 软件开发流程 技术评审流程 系统测试流程 产品认证流程 产业化开发流程 试生产流程 。。。。 概念阶段流程 计划阶段流程 开发阶段流程 验证阶段流程 发布阶段流程 产品生命周期管理流程

57 三级分层结构计划 递交物 目的 使用对象 Level 1 – 阶段计划 Level 2 – 步骤计划 Level 3 – 任务计划 PAC
4 5 PAC Project Core Team 决策评审 里程碑 管理状态报告 显示阶段所有的步骤 过程/项目总的流程图 Level 2 – 步骤计划 Step 3 X PCT Leader PCT 显示项目总体计划 以及控制过程 (“What and When”) 将步骤分解成任务 项目计划 流程图以及步骤的描述 Level 3 – 任务计划 Date Task X Activity Resp. PCT Project Team 任务计划以及各个职能组织 的执行内容 将任务分解成活动 子项目计划 或 活动列表

58 实例：计划流程 扩建项目组 团队培训 开工会 开发 阶段 验证 制定计划阶段WBS（3/4） 计划阶段WBS模板 开工会培训 过程相关培训
技术培训 软件开发计划细化 软件估算 优化/制定软件项目过程手册 优化/制定软件项目开发计划 制定/优化软件质量目标 SQA计划 SCM计划 测试与验证计划概要 系统规格结束处理 文档更新（估算、过程手册、开发计划） 配置管理相关工作 数据收集和项目数据库更新 开发质量目标控制 风险总结与评估 过程审计和交付物审计计划 结束报告、会议和解决措施 需求分解与分配 SE：需求分解与分配 系统设计与规格 系统规格基线化 测试：参与软件需求分析 技术评审2 分解与分配模板 软件开发计划模板 设计规格模板 配制管理模板 测试与验证计划 项目过程手册 软件架构模板

59 计划流程图方法 制作WBS 分解计划 说明流程的先后次序 操作计划 及其相互关系 确定持续时间并 时间进度 计算完工日期 确定和计算人力
和其他资源 资源分配计划 成本计划 确定和计算成本

60 项目产品范围和项目工作范围 一般由项目团队自己界定，客户不一定关注 项目工作范围： 为交付具有规定特征或功能的产品或服务所 必须完成的工作
项目范围的完成通过时照项目计划来衡量 产品范围和项目范围结合起来以确保项目 所做的工作能够取得规定的产品 产品范围 产品或服务所包含的 特征或功能 产品范用的完成 通过对照产品 要求来衡量 一般由合同加以规定，客户高度关注

61 工作分解结构(WBS) 工作结构分解(WBS)是可交付资料为导向的对项目要素的分组，它组织和定义项目的总体作用范围 WBS是：
以工作、资源和成本表达的对项目作用范围的详细表示 对生产系统所需要的工作（任务）的层次结构式分解 注：WBS (Work breakdown structure)是项目经理的计划数据库的中心

62 时间估算方法 类比法 专家法 参数模型法 在具体估算时还需考虑相应因素的影响，包括员工的技能水平、工作效率，一些突发事件的影响，有效的工作时间，有返工，这些因素都会影响项目工作所消耗的时间的长短。 通过相同类别的项目比较，确定不同的项目工作所需要的时间 依靠专家过去的知识、经验进行估算 是通过依据历史数据，用计算机回归分析来确定一种数学模型的方法

63 常用的计划开发工具 工作分解结构（Work Breakdown Structure，简称WBS）和工作包（Work package）。
职责矩阵（Responsibility Matrix）：用来定义项目组织、个别关键人员及其职责。 事件（Event）和里程碑（milestone）：用来确定项目进度中的关键点和主要的发生事件。 甘特图（Gantt Chart）。

64 显示项目信息的典型方式 任务1 甘特图 任务2 任务3 里程碑表 开始 A B C D E F 完成 前驱图 完成的生产计划 交付第一单元
测试子系统 复查设计 定案的规格 签署的子合同 8月 7月 6月 5月 4月 3月 2月 1月 事件 里程碑表

65 WBS格式 缩进列表 1.1xxxxxxx 1.1.1xxxxxx 树形结构 1.1.2xxxxxx 1.1.3xxxxxx
项目 WBS举例

66 进行工作分解的三种方法 级次 流程法 生命周期法 组织法 项目集合体 大型项目 超大型项目 中小型项目 项目 系统 生命周期 分部 任务
子系统 部门 子任务 个人 基层 工作包 工作单元 流程法适合项目周期短于两年的项目，更长期的项目适用于生命周期法，重复性的项目和较少部门整合的项目可采用组织法分解。

67 WBS案例 5个月的开发时间，预留20天作为抵御风险以及突发任务的时间
对工作任务作一个初步分解，将整个软件模块的开发按照系统的分析和设计、实现、测试三个步骤来完成。根据以前的统计结果给出各个阶段经验的最后期限。 与相关的资源经理沟通讨论，确定详细的任务时间及调整各阶段的完成时间如下图： ABC软件开发 需求分析 总体设计 A模块设计 B模块设计 C模块设计 集成测试 风险预留时间 20天 35天 50天 45天 7.1—8.3 8.4—9.24 9.25—11.10 11.11—11.30

68 WBS案例 ABC软件开发 需求分析 总体设计 A模块设计 B模块设计 C模块设计 集成测试 A概要设计 A详细设计 A编码 A单元测试
10天 07/01 07/10 21天 07/11 07/31 27天 08/01 08/27 34天 09/03 41天 09/10 40天 09/11 10/20 风险预 留时间 20天 10/21 11/10 A概要设计 A详细设计 A编码 A单元测试 B概要设计 B详细设计 B编码 B单元测试 C概要设计 C详细设计 C编码 C单元测试 测试计划 方案拟定 集成测试 测试报告 08/01 08/07 08/08 08/15 08/16 08/22 08/23 08/27 08/09 08/18 08/19 08/28 09/03 08/11 08/12 08/20 08/21 08/31 09/01 09/10 09/11 09/15 09/16 09/26 09/27 10/15 10/20

69 实例：一个通信系统的WBS WBS 信息处理器3000 项目管理4000 系统工程设计5000 系统设计6000 接收2000
处理器测试3400 集成的通信系统（0000） 发射1000 开发说明5100 接口控制5200 审核验证5300 系统测试6100 天线11000 终端放大器1200 发射测试1300 信号处理器2100 天线2200 降低噪声放大器2400 接受测试2300 处理器3100 语音处理器3200 转换器3300 项目管理4100 项目概况4200 配置管理4300 质量保证4400 设计1110 材料1120 光纤1130 检查1140 测试1150 设计1210 材料1220 光纤1230 检查1240 测试1250 设计2110 材料2120 光纤2130 检查2140 测试2150 设计3210 材料3220 光纤3230 检查3240 测试3250 ...... WBS

70 WBS关系 供应商管理计划 组织 （make/buy决策） 集成战略 一致性 基础 变更管理 系统解决方案 （系统结构、产品 、支持）
项目进度 计划、复查、记载 集成战略 供应商管理计划 （make/buy决策） 系统解决方案 （系统结构、产品 、支持） 状态报告 形成成本估算 基础 一致性

71 6 资源计划 71 | Presentation Title | Month 2006

72 资源管理 来自项 目团队 组建项目 团队 开发 获取资源 控制资源 组织 资源 项目资 源需求 跟踪 管理 获取资 项目 使用 源许诺
准备资源计划 项目资 源需求 获取资 源许诺 把资源分 配到任务 来自项 目团队 组建项目 团队 组织 资源 获取资源 开发 控制资源 管理 项目 跟踪 使用

73 编制资源计划 在资源计划编制时，它所有的组成部分被集中在一起作为有用的参考文档。计划应该有利于管理所有分配到和安排到项目中的资源。使用项目资源计划适用表来协助项目经理来确定和编制计划的内容。 项目资源计划包括 ： 项目人员计划工作表 项目团队花名册 项目材料明细表

74 项目责任矩阵 WBS 代号 钢结构平台设计 计算机系统设计 电气仪表设计 通风环保设计 工艺设备设计 机械设备设计 工艺设计 设计 现场管理
1270 计算机系统设计 1260 电气仪表设计 1250 通风环保设计 1240 工艺设备设计 1230 机械设备设计 1220 工艺设计 1210 设计 1200 现场管理 1130 项目计划 1120 项目总体规划 1110 项目管理 1100 施工 分包 设备供应商 下属部、公司 安全环境经理 财务经理 控制经理 开车 经理 采购经理 项目经理 WBS 代号

75 实例：软件开发任务及其任务分配 任务 责任人 说明 1 软件详细开发 项目经理, 软件工程师 测试工程师
软件模块的设计以及相应的测试用例、特性集成测 试和检查、编码和各个模块的测试 软件的详细设计 详细设计的同行评审 软件编码 代码阅读和检查 单元测试 2 特性集成测试 行为和文档特性集成测试，测试模块一起工作的功能特性 3 建立软件基线和测试用例 产业化团队成员 建立软件基线以及以后要用的测试用例和改进

76 实例：软件开发任务及其任务分配 任务 责任人 说明 4 产业化数据设计以及生成 产业化团队成员 产业化数据设计和生成，这个任务是可选的 5
软件改进 项目经理, 软件工程师、测试工程师 根据本任务中发现的问题，如技术评审以及问题报告以及从后面的步骤中的缺陷报告，变更软件设计，编码，并做必要的相应单元测试和功能集成测试。 6 TR2 项目经理 TR2 – 集成准备评审 参照技术评审流程指南

77 承诺的资源对项目的影响 不能及时提供资源 PM 无法及时释放资源 CCM不遵守在DR1对资源的承诺影响在曲线的前半部分
计划 资源 实际 DR1 DR4 DR1 DR4 实际 资源 计划资源 CCM不遵守在DR1对资源的承诺影响在曲线的前半部分 PM不遵守在DR1约定影响在曲线的后半部分

78 实例：某公司开发项目干系人介入点以避免情况恶化
关注在DR1所承诺的资源的大致情况例如： DR1 由于缺少能力中心经理（CCM）承诺的资源而没批准 包括最初2个月的所有人员的配备 在已经商定的时间释放资源 （即关注资源的情况） 如果某些产品的特性不能由于缺乏资源在规定的时间里递交, 暂时去掉另外项目的一些特性以便及时地释放资源 (由项目核心团队来做决定) 项目有关的一些基础资源的使用的授权在DR1未被批准，项目延期直到得到承诺为止 一旦承诺，项目就立即启动并且相关的资源必须到位 一旦在DR1签署批准开发合同他的资源就必须释放到位 同意批准项目各个特性的优先级以便: 及时地释放资源以免影响其它项目 至少要及时递交的特性 PD / PM CCM BU

79 7 进度计划制定和时间控制 79 | Presentation Title | Month 2006

80 网络图与WBS的关系 WBS 1.0 2.0 3.0 1.1 1.2 2.1 2.2 3.1 3.2 1.1 1.2 2.2 开始 2.1 3.2 完成

81 应用关键路径法(CPM) 关键路径法(CPM)是用于通过分析活动的何种顺序（哪条路径）具有最小的进度灵活性（最小的浮动量）来预测项目持续时间的网络图分析技术 名称 WBS号 持续时间 最早开始 最晚开始 最早完成 最晚完成 ES LF EF LS

82 关键路径 向关键路径要工期，向非关键路径要资源 完成 开始 路由器配置 持续时间=3天 持续时间=2天 持续时间=10天 持续时间=2天
设备安装、 路由器配置 持续时间=3天 ES EF 5 9 12 LS LF 场地准备 持续时间=2天 ES EF 2 2 应用软件安装调试 持续时间=10天 ES EF 12 12 软硬件联调 持续时间=2天 ES EF 14 系统调试开通、 验收 持续时间=4天 14 ES EF 18 完成 开始 2 2 12 12 14 14 18 LS LF LS LF LS LF LS LF 2 铺设电缆、布线 持续时间=2天 ES EF 4 10 12 LS LF 向关键路径要工期，向非关键路径要资源

83 依赖关系 强制 也叫硬逻辑，硬依赖关系。 任意 最佳实践 软逻辑 优先

84 添加管理任务 管理任务通常是工作量级别的任务，包括： 项目管理 变更控制管理 风险管理 沟通管理 绩效管理 合同管理
所包含的大于仅为项目经理预留的时间，这些任务消耗的资源且必须被跟踪。

85 工期压缩 赶工 : 成本与进度的平衡/折衷。 确定如何用最小的成本获得最大的工期压缩。 通常成本增加。 快速跟进 将前后顺序变为平行
通常风险增加。

86 验证进度 任务必需 的角色 人员的 可用性 人员技能 任务估算 匹配 网络图 项目进度

87 三点时间估计（PERT） 特点：工作时间不确定
如果对一项工作估计缺乏足够的信息，或者说考虑到未来环境的变化，它的时间不能一次进行，这时可以采用三点估计法。 用三种时间估计办法： MD=(OD+4HD+PD)/6

88 造成项目工期拖延的人的因素 学生综合症 帕肯森定律（Parkinson’s Law）
工作总是拖延到它所能够允许最迟完成的那一天也就是说如果工作允许它拖延、推迟完成的话，往往这个工作总是推迟到它能够最迟完成的那一天，很少有提前完成的。大多数情况下，都是项目延期、工作延期，或者是勉强按期完成任务。

89 8 项目成本管理 89 | Presentation Title | Month 2006

90 成本管理实际上做什么 成本控制： 监控成本执行情况 确保纪录了所有适当的变更 防止将错误的变更包含在成本基线中 与出资人交流有关已核准的变更
允许就正偏差和负偏差的原因进行调查研究

91 管理指标 为了便于回答项目执行中的绩效报告的问题，会采用下列的管理指标：
投资回报率 (ROI: Return on Investment ) 储蓄率的估计或测量在给定的努力来实现这一目标的努力所产生的费用 通过估算和测量人工量来确定完工时的人工量 投资回报率(ROI)通常用作一个项目的成功综合指标 投资回报率依赖于对于挣值的连续跟踪来保证 挣值 (EV: Earned Value ) 挣值分析整合项目范围，成本（或资源）和计划的度量，以帮助项目管理团队评估项目的绩效. 定期用挣值比较比较给定的成本计划来判定项目是否超前或落后进度。 用挣值比较项目执行期间所消耗的成本来确定该项目是否是在给定的成本基线下或超越其预算

92 ROI 实例: 早期缺陷检测介绍 抱怨 后果: 决策: 不能验证 项目里程碑延期 下一个项目延期
计划 “我们跟上了里程碑” “我们已经延期了” 资源 “没有足够的资源” “技能不够熟练 态度: “我们宁可在实验室做测试" 决策: 不能验证 后果: 资源不能释放给 下一个项目 项目成本超支 项目里程碑延期 下一个项目延期 有利于： 降低非质量的成本 (由于返工所耗费的时间) 减少现场由于缺陷花费的工作量 释放资源用于其它项目 缩短 ROI的时间 方法: 在设计中避免重大缺陷 尽早发现缺陷 尽量在可以在最低成本可以解决的检测出缺陷 有效地进入和退出的评审标准 临界性的检查和测试

93 挣值管理在项目状态复查中，问题是“位于何处”
挣值管理(EVM)分析是执行情况度量的首选方法EV基于三个基本要素： 计划价值（PV） 挣值（EV） 实际成本（AC） EV回答了以下问题： 项目的进度位于何处？ 已完成了多少？ 工作已花费了多少？ 要完成将再花费多少？ 最后的成本将是多少？ 项目的基线成本是什么？

94 术语 PV 预定工作的预算成本=基线、预定成本或计划成本 使PM能够知道项目是否有困难 给定时间中的计划花费是多少？ EV
已执行的工作预算成本（已执行工作的预算金额）=挣值 代表已执行的工作价值 已完成了什么工作，何种度量用于建立这些项的已完成的价值？ AC 已执行工作的实际成本=实际成本 代表执行工作的实际成本 已完成了什么，这些项的估算价值是什么？ BAC 完成时预算=总预算成本 项目的基线成本 项目的预算是多少？ EAC 完成时估算（完成时的估算成本） 总项目预算成本是多少？项目完成时的成本是多少？ ETC 要完成估算（对要完成项目所需的附加资金的估算） 对要完成项目所需的附加资金的估算是多少？

95 挣值偏差和执行情况指数分析 CV 成本偏差，已完成和完成它所花费之间的差额 实际化费在项目上的金额与完成的预定成本之间的偏离是多少 CPI
成本执行情况指数（成本执行情况因子），将实际成本与预算成本做比较 从财务的观点来看，任务完成的效率是多少？ SV 进度偏差，已完成和计划或预定完成之间的差别 从财务的观点来看，项目与进度之间的距离是多少？ SPI 进度执行情况指数（进度执行情况因子），将执行的工作与预定的工作做比较 相对于期望其执行的好坏程度，项目执行得有多好？

96 挣值偏差和执行情况指数分析 PC 完成百分比（已完成的实际价值），使PM知道项目已完成多少？ PS
已花费百分比，使PM知道目前已使用了多少BAC目前已使用了完成时预算的多少？ TCPI 要完成执行情况指数（验证因子），使PM知道团队必须以何种效率级别工作，项目团队必须有怎样的效率才能在预算内完成剩下的工作？

97 项目进度控制过程（续）—— 挣值在项目进度控制中的应用
已完工作的预算费用（挣值） 已完工作的实耗费用 %完成百分数（人工时或费用） 当前时间 EAC ACV BAC 计划工作的预算费用 AC PV EV SV CV 日历时间 ？

98 成本绩效指数和进度绩效指数 CPI or SPI CPI or SPI time 1.0 Jan Feb Mar Apr May 中性曲线
有利的趋势 1.0 Jan Feb Mar Apr May CPI or SPI 不利的趋势

99 挣值分析 对成本和进度偏差负数表明在这部分有问题（该项目是耗资超过计划或所花时间比原计划长）
如果是一个特定的任务显示为一个需要引起注意的红色信号旗，结果并没有发现该问题的原因，要做挣值分析 CPI 和 SPI 小于 100% 就意味着有问题 最大的困难就是获取和跟踪实际工时数

100 挣值观测 成功因素: 确保项目用一个详细的WBS来描述. 为每一个工作包建立成本账户. 建立一个基线，将进度和预算信息不断和其对比.
用一定的方法来计算挣值。 确定一定的项目报告周期，定时度量PV，EV和AC。 然后用这些参数与计算CV，SV，CPI，SPI等其它参数。 用这些参数跟踪和管理项目的进度。 准则: 假设用于预测的人工量和时间成线性关系 在项目刚开始时可能会产生较大的偏差，最好将可管理的部分（阶段）近似地化成线性关系

101 9 风险管理 101 | Presentation Title | Month 2006

102 产品项目的风险管理流程 至少2次正式的风险评估 (DR1前, DR2) 在每次项目评审前，风险信息应及时通报
在各阶段的Kick Off meeting 风险管理是会议的正式议题部分 阐述先前识别的风险 识别新的风险 风险分析、分级 确定缓解措施并加入项目活动列表，确定负责处理的人员以及成功的标准和完成的日期 根据项目定期的活动来跟踪风险缓解行动 XXX-... 风险管理过程 XXX-... 风险清册

103 项目风险识别方法 客观概率 主观概率 专家预测法 历史资料统计

104 风险识别步骤 运用WBS识别风险和机会 确定有效的 识别技术 整理、合并和 归类风险和机会 风险和机会类别表 *资源风险和机会
*潜在风险和机会事件 *风险和机会征兆 输入 步骤 输出 假设和约束 工作范围 或规范 合同条款 需求 工作分解结构 估算（资源， 进度，成本） 关键路径分析 期望

105 风险管理的利器——风险清册 风险最后一次评估 当风险出现时 缓解后 得分 = 可能性 *影响后果 可能发生的概率 - 已识别 - 开放
得分 = 可能性 *影响后果 可能发生的概率 - 已识别 - 开放 - 作废的 - 缓解的 - 发生的 对于成本/进度/功能/质量影响。1低/2中等/ 3严重

106 风险清册举例

107 举例：项目风险评估

108 风险应对策略 根据不同条件、环境、问题可以选择不同的对策。在风险应对措施中，风险发生概率有高有低，后果损失有大有小。概率高低以及后果损失大小，组成了一个四维空间。 概率大 概率小 A C B D 损失小 损失大

109 风险应对策略 针对四种情况，可以采取不同的应对策略： 概率高，损失比较小，（化减、减轻） 概率比较高，后果损失也较大，（回避）
概率比较低，后果损失较大，（转移） 概率比较低，后果损失也较小，（承担）

110 练习: 风险管理 实施一个项目的风险分析并选出优先级高的的风险表，分析它们的发生的可能性和影响并识别可能的缓解行动 风险 可能性 影响 得分

111 10 项目质量管理 111 | Presentation Title | Month 2006

112 质量管理过程 项目质量管理 质量计划 质量保证 质量控制

113 实例：质量管理体系的责任主体 公司质量管理部 资源线或产品线经理 系统级工程师 测试及验证部 PQA(1-n) 研发体系负责人
过程质量控制 组织产品 质量控制 设计质量保证 技术质量保证 公司质量管理部 资源线或产品线经理 系统级工程师 测试及验证部 PQA(1-n) 研发体系负责人 指导 汇报 指示 制定质量方针 贯彻质量方针 项目组(1-n) 业务指导 汇报反馈

114 实例：质量管理的五种手段 质量管理 任职资格 与活动匹配 规划及 CBB共享 评审 测试和验证 缺陷归零 管理

115 实例：质量管理的六个评审点 概念 生命周期 发布 验证 开发 计划 业务层面 技术层面 CDCP PDCP ADCP LDCP GA TR1
转产 产品发布 生产初始产品 用户验证 TR1：产品需求和概念评审 TR2：需求分解和规格评审 TR3：概要设计评审 TR4：模块/系统评审 TR5：样机评审 TR6：小批量评审

116 产品质量的影响因素 Q = f（h，p，T，m, RS ，t，d） h —— human p —— process
T —— Technology m —— material RS —— Requirement t —— time d —— device

117 实例：项目质量计划模板 模板: XXX-... XXX-... PQP 执行指导方针 XXX-... 总体质量计划指导方针 内容:
介绍/范围/ 授权批准 质量目标 (项目目标) 指导方针, 规程和关键结果 缺陷预防活动 风险管理 阶段详细的规程 (进入和退出标准以及每个阶段的质量管理活动) 项目适用的度量方法 项目基线

118 质量责任（Responsibility for Quality）
项目干系人 质量责任 管理层 对85%的质量费用负直接责任 项目经理 对项目的质量负责 员工 对所执行任务的质量负根本责任 执行组织 负责对产品质量改进的投资，特别是缺陷预防和鉴定需要的投资 质量管理团队 确定和传达质量原则和所要达到的质量等级的标准水平，负责将质量政策告之项目干系人，执行质量方针 项目工程师 对设计和规范负责

119 直接质量成本 合格所需的成本 （为防止缺陷和实施质量评估相关的成本） 计划编制 培训 检查和评估 测试和评价 客户验收步骤 过程控制和生效
成本要素 质量措施 合格所需的成本 （为防止缺陷和实施质量评估相关的成本） 计划编制 培训 检查和评估 测试和评价 客户验收步骤 过程控制和生效 维护 审计 他正式的质量保证活动 不合格所带来的成本 （与纠正缺陷相关的成本） 返工和重置成本 残值 不合格给客户造成的信誉损失 延期增加的费用 超额的被保证人费用

120 间接质量成本 成本要素 质量结果 低质量导致的成本 由客户不满意而进行的重复作业损失 由于不利的名声认可度给新业务带来的损失
经过对上述两项成本的可量化测量所导致的市场份额损失 员工不满意增加了员工的流动，从而导致的招聘和培训新员工的额外成本 股东和投资者缺少信心所导致的公司股价降低

121 鱼刺图应用案例 设备因素 个人因素 输入错误 率增加 文件因素 环境因素 显示器太差 能力不够 键盘失灵 硬件故障 情绪低落 身体不适
软件不好使 精神不集中 输入错误 率增加 期限太急 环境嘈杂 逻辑混乱 座位不适 特殊字多 空调不足 字迹不清 光线太暗 文件因素 环境因素

122 互动演练——因果分析图

123 11 执行流程 123 | Presentation Title | Month 2006

124 项目过程组定义 执行过程 即那些直接作用于项目的实际工作 包括: 执行项目计划 实施质量保证活动 开发团队和团队成员的能力
和团队成员和项目干系人保持沟通

125 项目执行流程图 执行流程 项目执行 项目计划 提供确保得到执行承诺的信息 Kick-off Meeting 执行项目计划和达成项目目标
产品或目标 项目计划 团队及个人能力的发展 团队建设 团队成员以及干系人的沟通 有效沟通 反馈

126 12 变更控制

127 变更的定义 变更： 是从先前核准的基线的任何偏离 影响项目的三个约束： 进度 成本 规格 可源自作用范围的偏离（如果未全面定义基线）
可与工作内容或项目管理相关

128 检查可能引起变更的因素 意外的变更事件 不良的计划 项目人员变化 公司的业务决策 实施质量 没有实现的期望 技术变化 规章变化 法律要求
供应商或者卖方的表现 客户需求的变化 价格、成本和可获得性的波动 变化的或者不明的环境

129 变更控制 评估好处和 交流变更 代价 复查请求 变更 识别任务影响 识别替代方案 实施变更 转换到执行情 况、成本和进度 安排 接受或拒绝
报告变更 和影响

130 变更请求表的要素 变更请求表包括： 变更请求号 变更请求日期 请求变更人的姓名 变更描述 调查费用的估算 变更对项目的影响
受变更影响的任务和人员列表 变更成本估算 授权代表签名 实施变更请求的时限 调查的时限 要进行的授权 调查 实施 对相关项目的影响

131 影响变更请求的因素 客户同意 变更请求 内部公司同意 供应商同意

132 项目经理在变更管理中的角色 在变更管理中，项目经理： 分析变更请求 评估变更的影响： 风险 基线 管理作用范围 接受或拒绝变更 修订基线

133 变更管理举例 请求号 10 变更规格 IS-41分析器——IS分析器支持CDMA 影响分析
CDMA配置模块和分析器有特殊变化。TDMA编码可以重用，脚本可以重用， Net config和分析器类可以重用。受影响模块如下： cgaapp模块：也需要独立地触发IS-41的分析Cdmaoi模块（a)TRIS41OI 必须复制成TRCDMAIS41ROI;(b)在TRCDMAROI中有个纯虚拟的方法用来设置 ActualCallModuleManager.它需要重新定义silver06guiapp++模块：必须 将IS-41加入资源表 进度影响 没有 工作量影响 5人日 状态 合并如新的CDMA包中

134 13 收尾过程

135 项目管理过程组的定义 收尾过程 正式的阶段或项目验收并使其按步骤结束 该项目准备进入维护阶段同时更新总结报告
在每个阶段结束时（DR评审）项目正式转移到下一个阶段时，检查是否还有任何悬而未决的问题吗？ 包括工作产品例如经验总结报告，并正式移交给维护的PM 在各个阶段重复这几个过程组

136 项目收尾过程 收尾过程 项目收尾 收集项目过程信息和经验教训 项目控制 项目总结 解决存在的问题 正式完成收尾 移交给维护项目

137 14 经验总结和根本原因分析

138 根本原因分析过程概貌 目的: 从我们所犯的错误中学习以避免重新犯错. 支持我们的产品和流程持续改进.
启动根源分析（ RCA Root Cause Analysis）活动的角色和时间: 一旦出现下列问题由PM发起: 已经报告的重大问题 和流程相关的问题 似乎发生了同样的问题但根本原因还不清楚时 任务: 数据/反馈分析 (RCA) 比较严重的问题由相关领域的专家以及团队领导一起参与研讨解决. 搞清问题的根源, 提出改进活动的建议以免再出现同样的问题 ( 过程改进, 应用过程,...) 由过程专家提出分析和改进的建议

139 经验教训总结报告 总结项目的关键问题以说明项目的绩效以及对以后的项目的指导意见. 从这些关键问题中提出防止缺陷的活动和流程改进的建议.
通常在主要阶段结束或项目结束时撰写总结报告 总结报告中必须包括 定量分析 (实际的 vs. 估算和目标) 定性分析 (项目相关的特殊环境来说明定量分析的合理性） 总结报告可以基于正面的和负面的影响. 必须首先和团队成员沟通以获得他们的认可

140 项目总结工作内容实例 主要成果摘要和参考数据 主要分析: 项目人工量 项目实现的功能 项目进度 项目 vs. R&D 目标 项目质量
项目规模 每个主要阶段的详细分析 同行评审 (文档 & 代码) 测试结果

141 15 项目成功的关键因素——项目经理

142 一个参与型经理的个性 可接近的、开放的 诚实的、遵守诺言的 不耍政治手腕的 说到做到 在成员中自由走动式的管理 鼓励开诚布公的讨论
必要时进行磋商 召开场地外的会议 邀请重要人员吃午餐 鼓励专业上的发展

143 项目经理具有5种权力 合法权 惩罚权 奖赏权 专家影响力 上级的影响力

144 思维模式的转变 Crossover 技术人员的思维模式 商务人员的思维模式 真理(Truth) 最优(Optimal) 智商(IQ)
科学(Scientific) 唯物导向(Objective) 研究(Research) 执着(Persist) 特性(Feature) 商务人员的思维模式 最优(Optimal) 情商(EQ) 创意(Creative) 唯人导向(People) 沟通(Communication) 弹性(Flexible) 效益(Benefit) Crossover

145 项目经理的能力 相关的知识 相关的技能 能力 人格和态度 执行和行动

146 项目经理的能力 知识 技能 态度 全球的宏观经济 全球的财务知识 全球的战略眼光 组织结构 竞争分析 决策能力 项目管理
全球的市场和品牌管理 销售和客户管理 技术管理 会计学 人力资源管理 公司治理 跨文化的管理 决策 灵活处理不确定问题的技能 承担责任 绩效管理 将复杂问题简化的技能 表达，呈现的技能 倾听和观察的能力 协同能力 团队建设和团队合作 人才的评估 人际关系 诚信 全球眼光 变化与成长 直觉和判断 高标准的要求 坚韧不拔 处变不惊 充满激情并影响他人 好奇心和富有创意 自我意识 充满自信并影响他人 不遗余力 注意绩效 不断提高学习的欲望和能力 乐于辅导他人

147 以诚待人，以心待事 147 | Presentation Title | Month 2006

148 谢谢大家！ 148 | Presentation Title | Month 2006

149 The end

150 小组演练 “全自动滚筒洗衣机”研制项目

151 分组练习： 45分钟 选一个项目经理 每组选一个负责人

152 项目背景及其要求 1、项目背景 某电器制造厂是一家国有大中型企业，主要的拳头产品是各种类型的洗衣机产品，由于多年来企业一直未能进行有效的技术革新，所生产的洗衣机一直为普通洗衣机，而普通洗衣机市场竞争激烈，加之市场的疲软导致企业效益持续下滑，经过市场人员的初步调查分析，发现消费者对于新款全自动滚筒洗衣机市场需求旺盛。 企业领导人经过研究，决定开发市场前景较好的“全自动滚筒洗衣机产品”，由于滚筒洗衣机的生产面临许多新的技术，特别是电动机的研究与试验、电脑控制系统的研究与试验是滚筒洗衣机成功开发的关键，该项目经过调查研究需投入开发资金600万元，计划研制时间为2002年1月1日至2002年6月30日。

153 项目背景及其要求 2、需要解决的问题 为了保证新款“全自动滚筒洗衣机产品”的开发取得成功，企业领导人决定采用项目管理的方式来进行，为此企业领导人提出需要解决如下几个方面的问题: 根据项目实施背景，对项目实施的总目标进行描述。 为企业实施该新款“全自动滚筒洗衣机研制项目”设计一个合理的组织管理机构，要求采用项目负责制的管理形式，并统筹考虑计划、人力、资源、费用及质量管理方面的管理问题。 针对项目的目标要求，初步拟定该项目的重大里程碑计划，制作该项目实施的反映重大里程碑事件关系的里程碑计划图。

154 项目背景及其要求 (续) 针对项目的实施要求及重大里程碑事件，对该项目实施的过程进行分解，要求分解后的项目工作数目大约15个左右，并用工作分解结构图或工作分解结构表进行表达，在工作分解结构图或表中编制工作编码。 为项目的每项工作指派责任人，并制定项目的责任分配。 针对项目的工作分解结构制定项目的人力与资源使用计划。 针对项目总投资结合工作分解结构及人力资源使用计划进行项目费用的分解，编制项目的费用分解结构。

155 项目背景及其要求 (续) 分析项目各项工作之间的先后关系。
估计项目各工作的执行时间，并编制项目的计划，项目计划以网络图或甘特图的形式表示，确定项目的关键工作。 按照项目的执行周期描述项目的成本曲线和累积成本曲线，并结合项目的执行情况进行项目成本费用的分析，制定项目的进度与费用控制计划。 分析项目实施过程中可能遇到的实施风险，并提出应对计划。 描述项目的进度管理过程，怎样报告项目进展状态。

156 项目管理的应用 1、项目总目标的确定 该项目的实施，主要是为了解决企业面临的普通洗衣机市场疲软，从而导致企业效益持续下滑的问题。企业通过调查分析认为在新款全自动滚筒洗衣机方面有一定的市场机会，而企业自身作为国有大中型家电企业，人才储备较为丰富，技术力量雄厚，为此选择开发新型全自动滚筒洗衣机具有很大的优势。 通过可行性分析企业决定进行“全自动滚筒洗衣机”的开发，其主要的目标如下： 交付成果：新型“全自动滚筒洗衣机”样品。 工期要求：研制开发周期6个月，从2002年1月1日至2002年6月30日。 成本要求：项目总投资限额600万人民币。

157 项目管理的应用 2、项目的组织管理 该企业一直采用职能管理的形式，主要的职能部门有技术研发部、生产制造部、采购部、质量部、经营计划部、市场部、财务部、人力资源部等。由于产品的开发需要企业各部门的通力合作，为此，企业领导决定采用项目管理的模式进行管理，委托一位项目经理全权负责该项目的开发，同时成立新款洗衣机研发项目管理办公室。 对于滚筒洗衣机研制项目的组织管理结构，可能采取的组织形式有职能式、矩阵式、项目式。职能式组织结构比较适用于规模较小、偏重于技术的项目，而不适应于项目的环境变化较大的项目。当一个公司中包括许多项目或项目的规模比较大、技术复杂时，则应选择项目式的组织结构。

158 项目管理的应用 同职能式组织结构相比，在对付不稳定的环境时，项目式组织结构显示出了自己潜在的长处，即来自于项目团队的整体性和各类人才的紧密合作。同前两种组织结构相比，矩阵式组织结构无疑在充分利用企业资源上显示出了巨大的优越性。它融合了前两种组织结构的优点，在进行技术复杂、规模较大的项目管理时呈现出了明显的优势。 基于项目实施的特点，即技术方面的复杂性和组织协调方面的难度，以及原有公司职能型组织的特点，为了保证项目的顺利进行，公司决定采用强矩阵组织结构的形式。如图1所示。

159 项目管理的应用 该组织结构的特点是项目办直接归总经理领导，以保证该项目的开发成功，也说明了公司领导层对该开发项目的重视程度。项目办通过横向的职能机构协调利用公司现有的资源，各职能部门在项目办的协调下相互协作，使得项目的开发中各职能部门的作用井井有条。 由于矩阵式组织结构形式的特点是将按照职能划分的纵向部门与按照项目划分的横向部门结合起来，以构成类似矩阵的管理系统，因此特别适应于多品种、结构工艺复杂、品种变换频繁的场合，这与本项目的特点是相吻合的。

160 图1：组织结构 总经理 人力 资源部 财务部 设计部 计划部 职员 PMO

161 项目管理的应用 3、项目的里程碑计划 项目的里程碑是项目实施过程中，对项目实施进度有重要影响的关键事件。本项目的主要里程碑事件有总体方案结束、筒体研制结束、电动机研制结束、电脑控制系统研制结束、总装结束。该项目的主要事件及其完成时间，如图2所示。

162 图2：里程碑 6-14 2010年6月14日 总装结束 5-24 2010年5月24日 电脑控制系统研制结束 5-10 2010年5月10日
电动机研制结束 4-26 2010年4月26日 筒体研制结束 1-18 2010年1月18日 总体方案结束 6月18日 5月26日 5月 5日 4月14日 3月24日 3月 8日 2月10日 1月20日 12月30日 完成日期 任务名称

163 项目管理的应用 4、项目的工作分解结构 项目的工作分解结构（WBS）包含了项目实施过程中的全部工作。滚筒洗衣机研制项目主要工作，如图3所示。

164 图3：WBS 100新款全自动 滚筒洗衣机研制 120 筒体研制 130 电动机 研制 140 电脑控制 系统研制 150 总装与测试
111 总体 方案 112 技术 服务 121 筒体 研究 132 试制 131 141 系统研究 142 系统试制 151 总装 152 测试 113 外形 设计 123 133 系统测试 160 项目管理 110 总体设计

165 二、项目管理的应用 5、项目的责任分配矩阵 参与项目各方的责任一般通过责任分配矩阵的形式进行表达，这种表达形式的优点是直观地将项目责任方的责任和权利完整地表达出来，便于项目各方进行有效的协调，对项目的成功实施非常关键。根据滚筒洗衣机组织结构确定的项目责任分配矩阵，如表1所示。

166 表1：责任分配矩阵 任务 责任者 任务编码 任务名称 项目办 设计部 生产部 计划部 财务部 质量部 项目经理 111 总体方案 C F J
S 112 技术规格 113 外形设计 121 筒体研究 122 筒体试制 123 筒体测试 131 电动机研究 132 电动机试制 133 电动机测试

167 表1：责任分配矩阵(续) 任务 责任者 任务编码 任务名称 项目办 设计部 生产部 计划部 财务部 质量部 项目经理 141
电脑控制系统研究 C F S 142 电脑控制系统试制 J 143 电脑控制系统测试 151 总装 152 总装测试 160 项目管理 注：F：负责、C：参与、S：审批、J：监督

168 项目管理的应用 6、项目的人力资源计划 人力资源的安排对于项目的实施非常重要。在责任确定下来之后，就必须落实每项工作需要的具体人数以及需要的工作时间。当然最基本的思路是先预计每项工作的工作量。然后结合资源的可利用情况及项目工期的限制进行综合分析，确定每项工作需要的资源数量和工期。最后确定的滚筒洗衣机研制项目的人力资源计划及每项工作的工期安排，如表2所示。

169 表2：人力资源计划 编号 任务名称 资源 工时 数量/人 工期/周 100 新款全自动滚筒洗衣机 110 总体设计 111 总体方案 工程师
2000 50 1 112 技术规格 1600 20 2 113 外形设计 120 筒体研制 121 筒体研究 3000 15 5 122 筒体试制 工人 4800 4 123 筒体测试 8 130 电动机研制 131 电动机研究 4000 132 电动机试制 6000 25 6 133 电动机测试 10

170 表2：人力资源计划(续) 编号 任务名称 资源 工时 数量/人 工期/周 140 电脑控制系统研制 141 电脑控制系统研究 工程师
5000 25 5 142 电脑控制系统试制 工人 8000 8 143 电脑控制系统测试 3000 15 150 总装与测试 151 总装 2400 20 3 152 总体测试 2000 2 160 项目管理 管理人员 3120 26

171 项目管理的应用 7、项目的费用分解 项目的总费用限额为600万元，每项工作到底需要多少费用才能够完成就是项目费用分解所需要确定的内容。项目费用的分解思路有多种方式，其中最基本的一种思路就是分别确定每项工作的人力资源费用及材料等费用，然后进行汇总。根据这一思路确定的项目费用分解如表3所示。 其中，工时费用：工程师为60元/小时，管理人员为50元/小时，工人为30元/小时。

172 表3：项目成本 编号 任务名称 资源名称 工时 数量/人 工期/周 人力费用/元 材料费用/元 总费用/元 100 新款全自动滚筒洗衣机
110 总体设计 111 总体方案 工程师 2000 50 1 120000 10000 130000 112 技术规格 1600 20 2 96000 106000 113 外形设计 15000 111000 120 筒体研制 121 筒体研究 3000 15 5 180000 100000 280000 122 筒体试制 工人 4800 30 4 144000 500000 644000 123 筒体测试 8 300000 396000 130 电动机研制 131 电动机研究 4000 240000 150000 390000 132 电动机试制 6000 25 6 480000 660000 133 电动机测试 10 420000

173 表3：项目成本(续) 编号 任务名称 资源名称 工时 数量/人 工期/周 人力费用/元 材料费用/元 总费用/元 140 电脑控制系统研制
141 电脑控制系统研究 工程师 5000 25 5 300000 200000 500000 142 电脑控制系统试制 工人 8000 8 240000 600000 840000 143 电脑控制系统测试 3000 15 180000 480000 150 总装与测试 151 总装 2400 20 3 72000 198000 270000 152 总体测试 2000 2 120000 100000 220000 160 项目管理 管理人员 3120 26 156000 52000 208000 合计

174 项目管理的应用 8、项目各工作先后关系的确定
项目各工作执行的安排需要遵守工作之间先后制约关系的限制，某些工作的开始与结束之间具有一定的限制，这一限制决定了工作的安排次序。工作先后关系分为逻辑关系和组织关系两种，其确定的原则是先逻辑关系后组织关系。通过分析，滚筒洗衣机研制项目各工作之间的先后关系，如表4所示。

175 表4：任务之间的关系 编号 任务名称 工期/周 紧后作业 100 新款全自动滚筒洗衣机 132 电动机试制 6 133 110 总体设计
112,113 电动机测试 5 151 111 总体方案 1 121,131,141 140 电脑控制系统研制 112 技术规格 2 141 电脑控制系统研究 142 113 外形设计 电脑控制系统试制 8 143 120 筒体研制 电脑控制系统测试 121 筒体研究 122 150 总装与测试 4 123 总装 3 152 筒体测试 总体测试 130 电动机研制 160 项目管理 26 131 电动机研究

176 项目管理的应用 9、项目的进度安排 进度安排是项目按期完成的基本前提条件，良好的进度可以保证项目按照预定的计划得以实施，相反如果项目计划的时间安排不合理可能会导致项目的实施非常被动。 安排计划的一个良好习惯是先不考虑项目工期的限制，根据现有的资源及人力情况进行合理的、客观的估计，然后综合考虑可利用资源情况及工期限制，进行适当的工期及资源优化，保证项目按照预先规定的工期完成。 对于滚筒洗衣机研制项目确定的项目进度安排计划如图5-4和5-5所示。 图4是用单代号网络图形式表示的项目进度计划，图5-5是以横道图的形式表示的项目进度计划。

177 图4：网络图 111 总体方案 1周 1 ES LF EF LS 112 技术规格 2周 3 113 外形设计 121 筒体研究 5周 7
1 ES LF EF LS 112 技术规格 2周 3 113 外形设计 121 筒体研究 5周 7 8 12 122 筒体试制 4周 16 123 筒体测试 17 21 131 电动机研究 5 10 132 电动机试制 6周 14 133 电动机测试 19 141 电脑控制 系统研究 142 系统试制 8周 143 系统测试 151 总装 3周 24 152 总体测试 26