PRESENTATION TITLE 项目管理理论和实践 方莹 Ying.h.fang@alcatel-sbell.com.cn.

Presentation on theme: "PRESENTATION TITLE 项目管理理论和实践 方莹 Ying.h.fang@alcatel-sbell.com.cn."— Presentation transcript:

1 PRESENTATION TITLE 项目管理理论和实践 方莹

2 观念决定了一个人的格局 格局决定了一个人的成就

3 不谋万世者，不足谋一时 不谋全局者，不足谋一域
《寤言二迁都建藩议》陈谵然[清]

4 目录 项目管理概述 项目启动过程 项目计划过程 项目执行和控制过程——进度管理 项目执行和控制过程——质量管理
项目执行和控制过程——变更管理 项目执行和控制过程——成本管理 项目执行和控制过程——风险管理 项目执行和控制过程——跟踪项目 项目执行和控制过程——项目采购管理 项目总结及原因分析 冲突管理 项目成功的关键因素——项目经理 团队管理和团队建设

5 1 项目管理概述 5 | Presentation Title | Month 2006

6 项目定义 术语 定义 项目 项目是为创建独特产品或服务而采取得临时性努力。临时性意味着每个项目都有明确的开始和结束。但实现项目目标时，项目即告结束；或者当明确得知项目目标将不会或无法实现而终止项目时，项目也告结束。 计划 计划是以协调方式进行管理的一组相关项目。 项目管理 项目管理是将知识、技能、工具和技术应用到项目活动中以达到或超越出资人对项目需求和期望的过程。

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

8 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 结束采购

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

10 项目核心团队 项目核心团队结构 项目核心团队 PLM Operations TPM CS&Q M&S 项目管理团队

11 实例：项目化组织 Portfolio Management Committee Project A Project B Project C
Release (N) Project C Project B Project A Project Mgt Support R&D PLM TIS BT&Q ADV PROC SCM manager Project Core Team (PCT) Release Lead Program Lead TPL Release Manager Baseline Team Release Core Team R&D Project Team Project Core Team VERTICAL DOMAIN FUNCTIONAL DEPARTMENTS ENABLING PROJECT & RELEASE DELIVERIES Value-Adding Project Delivering Customer Horizontal Domain Project Teams Into Release Release Teams Delivering Releases to Customers

12 项目管理案例：项目管理部的定位 小A是项目管理部的经理，由于公司部门设置的问题，现在项目管理部需要对项目总监负责，又需要对总经理负责，还需要监控各项目组，但各项目组又直接归属项目总监或总经理管理。这样一来，项目经理只听从项目总监或者总经理的话，根本就不把项目管理部的话当一回事，这样一来项目管理部就形同虚设，以至于让高层领导认为项目管理部是一个多余的机构。   小A为了让公司认为自己的部门是有用途的，就开始写一套项目管理规范，但由于部门内的人员都是以前没有多少项目管理经验的人，所以写出来的东西不是太实用。而且，项目管理规范有很多部分都是需要其他部门协同完成的，由于上段所说的原因，执行起来异常的困难，依然是一个没有用途的规定。 问题：现在小A非常郁闷，不知道在这种配置下，自己应该做些什么？

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

14 Contract Transfer Complete Accountable: Project Manager
实例：工程项目生命周期管理 IN: Contract booked All information transferred OUT: Transfer of full accountability Offer and Quote Management Accountable: Sales Lead (CAM) Pi Lead Creation P0 Opportunity Qualification P1 Offer Strategy Planning P2 Offer Preparation P3 Negotiation P4 Contract Booking, Project Transfer IN: Deliveries delivered and accepted OUT: Close all operational activities PRI Lead Qualified PR0 Opportunity Qualified PR1 Win Strategy Qualified PR2 Offer Qualified PR3 Contract Qualified PR4 Order Qualified IN: Contract preparation necessitates PM involvement (any time) OUT: Nomination of PM Allocation of planning resources RFT* Ready for (contract) Transfer CTC Contract Transfer Complete PL Planning Launch Accountable: Project Manager Contract Implementation PP Contract Planning P6 Contr. Closure P5 Contract Execution RFA** Ready for Acceptance RFS** Service RFV ** Validation RFD ** Develop. PR5 Final Acceptance Qualified PRL Planning Launch Qualified PR6 Contract Closure Qualified PRP Planning Qualified Naming logic PRx – decision gate RFx – milestone Px – phase IN: PMP or contract exec. plan OUT: Agreement to start execution Update of resource allocation IN: All contractual obligations closed OUT: Contract closed and archived * Transfer meeting ** Examples, links to PLC under validation

15 项目管理案例：赔钱的项目与企业业绩 某欧洲企业在内地的分公司在香港签了一个金额很小的系统集成项目。项目经理初步估算毛利只有6％（同类项目通常有20％），而且由于合同额小，五六千块就是一个百分点，相应的境外施工风险很多，故而不想接受这个项目。但销售硬逼着做，说是为了有业绩，所以只好硬着头皮接下项目。 但随着项目进行，由于缺乏相应的与香港客户合作经验，人工比预期大大增加（外企的单位人工成本非常高），项目利润一路下滑至负的百分之十几个点。 这个项目或许会按时保质完成，但该公司是注定要赔钱了。 问题1：请问这种“业绩”项目该如何对待？ 问题2：这个项目的项目经理究竟是成功还是失败？

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

17 项目管理案例 ABC是一家电子测试设备制造商。它的产品以高质量著称，除市场价格外，它还因其良好声誉附加了一定比例的额外费用。
周涛是市场部副总裁，李海是销售经理，朱敏是产品开发经理。李海和朱敏都为周涛工作。朱敏两年前从其竞争对手公司来到ABC；在原公司她没有受到重视，没有被提升。在ABC，她发起了一个开发低成本测试工具的项目，这一工具与市场中较低层次的产品，例如她所在原公司制造的产品相竞争。在将近12个月的开发工作后，产品设计已符合朱敏的期望，不久后新产品的制造开始了，并且在3个月前轰动了整个市场。 李海是一个在ABC工作了25年的老雇员，当朱敏没有让他加入设计，而是自己发起了开发项目时，他感到被轻视了，他认为自己具备精深的市场知识，知道该销售什么，不该销售什么。

18 项目管理案例 一天，李海策划了一个与周涛和朱敏共同召开的会议。他以下面的话开始了会议：“我想让大家聚在一起，是为了告诉你们，我们存在一个大问题。我的销售代表说我们目前有一些客户，他们在购买了朱敏的新型廉价测试工具后提出了不满意的意见。” “问题的具体情况是什么？”朱敏问。 “我也不十分了解，但是我的销售代表告诉我，如果产品并不十分好用，他们不感兴趣于挨户兜售这种产品。”李海回答。 “你怎么能策划召开这样的会议，并且捏造出根本不存在的事情？究意是什么问题？有多严重？”朱敏责问道，“也许你的销售代表不想推销这种产品的原因是，你只给他们很低的佣金。”

19 项目管理案例 李海立刻回答：“如果你是在努力查明我们的客户需要什么，想要什么，而不是凭空认为他们想要什么，那么产品才能更成功。据我所知，你已浪费了许多钱开发出这种垃圾，你花的钱已经减少公司的利润，并且减少了今年我们销售代表的经利。” 周涛插话说：“我们必须弄清实际的状况，确切的问题是什么，获得如何纠正这种状况的资料，我们不能让这样一个问题损坏我们的声誉，并影响到我们其他产品的销售。” 朱敏和李海一起回答：“让我去做吧。” 案例习题 为什么ABC公司会出现问题？ 周涛应做些什么？他应该怎么做？ 问题应如何避免？ 从中获得的对未来项目的经验教训是什么？

20 小组讨论：创新和研发 在开发一个新产品时我们会考虑哪些因素，请罗列10个以上的因素

21 商业论证 产品概念 产品类型和命名 产品说明 产品特性表和成本 市场和竞争力评估 客户需求、市场规模和产品前景预测
市场和竞争分析：竞争环境、价格和成本 分销渠道选择 产品策略战略的吻合度 产品线目标 产品路标 产品发布和目标市场的部署 产品评估（可行性分析）

22 商业论证 知识产权分析 技术评估 生产评估 采购评估 可服务性评估 产品开发计划 项目进度、组织和资源 团队结构 人力资源 市场计划
商业和财务数据 项目预算 效益/成本 产品的商业模式

23 商业论证 风险和敏感度分析 供货能力评估 假设和制约条件 推荐的备用方案 项目跟踪

24 2 项目启动过程 24 | Presentation Title | Month 2006

25 项目可行性研究 有没有必要开展项目？ 项目需要多长时间才能完成？ 需要投入多少人力、物力？ 在财务上是不是有价值？
在技术和经济上是不是合理、可行？ 项目的组织能力如何？ 实施项目有哪些制约因素？ 项目是不是支持公司的战略？ 能不能给企业带来竞争优势，带来多少效益？ 细节是否比较清楚，有没有替代方案，项目有没有存在技术或财务风险？

26 项目干系人 项目阶段 / 活动 确定干系人类型 项目说明阶段 设置项目目标 建立组织结构 设立责任矩阵 发布项目纲要 定义变化管理程序
沟通计划 客户 高层主管, 职能管理部门主管, 项目团队 客户, 高层主管, 职能管理部门主管 项目经理, 高层主管 客户, 高层主管,职能管理部门主管 客户, 高层主管,职能管理部门主管, 项目团队 计划阶段 风险分析与应变计划 详细预算及进度开发 工作量估算 客户, 高层主管,职能管理部门主管,项目团队 客户, 高层主管, 项目团队 职能管理部门主管, 项目团队

27 项目干系人责任 角色 职责 项目经理 项目团队 高层主管 客户 职能管理部门主管 说明、计划、控制和领导项目 完成具体项目任务
授权、指导、多个项目的优先权分配 产品要求、 资金 公司政策、资源

28 练习：干系人分析：

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

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

31 需求的分类 业务需求 项目范围文档 用户需求 质量属性 使用实例文档 系统需求 功能需求 非功能需求 约束条件 需求规格说书

32 3 项目计划过程 32 | Presentation Title | Month 2006

33 目标确定 项目目标是项目预期的结果或最终产品，应明确具体，并尽量定量化，主要涉及： 时间 约束性目标 费用 约束性目标 技术 产品需求说明书
时间 约束性目标 费用 约束性目标 技术 产品需求说明书 产品 满足特定需求、个性化的可交付性成果 目标通常是根据以下因素确定，它要求在一定期限和预算内完成预定任务。 工作范围 进度计划 成本

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

35 计划阶段的活动 最终产品 质量标准 WBS 资源 风险 活动 预算 形成WBS 估算和假设 进度 策略和工作流程 事项和问题 选择团队成员
验证作用范围定义 最终产品 质量标准 资源 活动 建立主计划： 预算 形成WBS 估算和假设 进度 策略和工作流程 事项和问题 确认合理性 获得核准 继续下一阶段 WBS 估算 网络图 进度 风险

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

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

38 确定 WBS是否已分解到足够详细的一层 是否需要改善WBS元素的成本估算和时间进度估算的精确度？ WBS要素的负责人是否超过一人？
某一要素对资源的需求一段时间内会变化吗？ 衡量WBS某一元素进度的明确的目标标准存在吗？ 这些验收标准在WBS的要素全部完成前还适用吗？ WBS中的一些要素是否存在一些风险需要特别的注意？ WBS要素中的某一部分是否可作为单独的单元来做时间进度计划？ 项目经理，项目团队，以及其他干系人包括客户对WBS的要素有清晰和完全的理解吗？ 是否有干系人有兴趣WBS某一要素的现状和业绩？

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

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

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

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

43 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

44 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

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

46 计划编制后工作 计划的批准 要争取各干系人，包括业主、上层管理者、顾客、项目经理、承包商、供应商对计划结果有一个共识。 计划做好后
作为目标的分解，作为各参加单位的工作责任，应落实到各部门或单位，得到他们同意，并形成承诺。 计划下达后 还要使人们了解他们面临的目标和应完成的任务，以及为完成目标和任务应当遵循的指导原则，他们完成计划所拥有必要的权力、手段和信息。

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

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

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

50 WBS与责任矩阵 责任矩阵是一种将所分解的工作任务落实到项目有关部门或个人，并明确表示出他们在组织工作中的关系、责任和地位的一种方法和工具。
预算（万元） 责任者 1000 1100 1110 1120 1200 1210 1220 1300 1310 5000 500 700 300 2000 王新建 设计部门 李岩 张德伦 设备部门 钱江林 宋晓波 基建部门 王海 1320 1321 1322 1323 1330 1400 1410 1420 200 600 400 齐鲁 金镇 乔明 陈志红 赵洪安 生产部门 秦艺美 徐青

51 4 项目执行和控制过程——进度管理 51 | Presentation Title | Month 2006

52 网络图与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 完成

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

54 关键路径 完成 开始 路由器配置 持续时间=3天 持续时间=2天 持续时间=10天 持续时间=2天 验收 持续时间=4天 持续时间=2天 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

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

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

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

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

59 5 项目执行和控制过程——质量管理 59 | Presentation Title | Month 2006

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

61 质量要素 质量要素 考虑事项 测量标准 满足商业需求 项目结果多大程度上满足了客户的商业需求？ 项目结果增加了客户的价值吗？ 增加的经济价值
项目完工所实现目标的数量 对客户实现商业目标能力的改进 实现项目计划 项目在多大程度上密切地按照项目计划（已完成的工作、成本、工期等等）实施？ 变更是否得到了控制？是否进行了客户的评审？ 成本差异 工期差异 已完成作业的百分比 符合规范和需求 安装的系统和产品在多大程度上符合文档中规定的功能要求和技术规范？ 缺陷的数量 已完成结果的功能：为完成项目需求所需成本及其能带来的收益之间的比率 要求测试的性能 客户满意度 客户对最终产品满意吗? 客户对项目活动满意吗？ 客户抱怨的次数 评估表上的客户评价 直接的客户反馈 重复订单或转交订单是增加还是减少

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

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

64 质量控制的方法 质量控制检查——该方法采用测量、检查和测试以完成质量控制并决定是否符合项目需求。质量控制计划和设备验收测试计划可以识别出明确的检查组件。 质量控制图——这些图是设计用来确定某过程是否处于控制之中。该质量控制方法常与重复的任务和延期相关，旨在监测成本和工期差异、范围变更的大小和频率、项目文件中的差错和其他管理问题。 帕累托图——这些直方图对检查不同类型的组件或交付物中错误发生的频率非常关键。该工具与帕累托原理相关，该原理的涵义是小数量的诱因会导致大的缺陷问题。 统计取样——该质量控制方法取样要少于相似产品的全部产出物或总量。使用该方法可以减少质量控制成本。 流程图——该技术能帮助分析在产生对所采用过程中问题是如何发生的。对过程加以流程化的流程图有利于致命问题发生在哪里及确定问题的原因。 趋势分析——该质量控制方法是以历史结果为基础，运用数学方法预测未来结果。

65 因果分析图 日本质量管理学者石川馨首先提出，又称石川图或鱼刺图
它把影响产品质量诸因素之间的关系以树状图的方式表示出来，使人一目了然，便于分析原因并采取相应的措施 最后细分出来的原因应是具体的，便于采取实际措施 在细分原因时，应集思广益，力求分析结果准确而无遗漏

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

67 项目管理中的质量和人员 管理层定义工作的类型和数量 员工仅可承担职责以满足完成工作的要求，员工： 了解期望什么来符合规格
了解如何执行功能以符合规格 具有足够的工具来执行功能 能够度量过程中的执行情况 能够调整过程以与期望结果相匹配 项目质量团队的组成如下： 高级管理层 项目经理 项目人员 客户 供应商和承包人 管理机构

68 6 执行和控制过程——变更管理 68 | Presentation Title | Month 2006

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

70 项目团队必须为同一工作陈述和可交付资料而工作
变更的起源 外部 条件与条款 工作的作用范围 需求 进度 成本 内部 设计 实现 配置 成本 风险事项 变更过程 项目团队必须为同一工作陈述和可交付资料而工作

71 变更管理计划 检查引起变 更的因素 检查项目和 合同基线 建立变更 管理战略 开发变更 管理计划 变更管理因素

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

73 检查项目和合同的基线 为了识别出项目中可能引起变更的潜在因素，必须对所有的项目文件和合同文件（项目和合同的基线）进行深入地检查。
初始风险和机遇评估文件也必须由财务经理、合同经理以及顾问等进行审查检查，并编制出风险和机遇管理计划，该文件描述了所有风险和机遇以及相应的风险和机遇战略。 这个文件还识别出了项目潜在的变更。

74 建立变更管理战略 不管变更是内部的还是外部的，是计划的还是意外的，项目团队都必须运用已经建立的战略去识别、评价和执行变更。
根据项目的规模和复杂程度，战略可以分为详细战略和概要战略。 比如， 有一种方法中所有的变更都可以要求在执行合同之前进行修改。 而另外一种方法则规定小的变更可以由客户书面形式确认，只有积累到一定金额的较大变更才进行正式的修改。

75 变更控制为何重要 变更控制的重要性在于： 管理基线，以控制作用范围中的变更，而不仅是防止它们 使作用范围偏离最小化
减少由于作用范围偏离而失败的项目数 项目规划 规格 进度 成本

76 变更协调 执行情况报告 总体变更控制 辅助变更控制 作用范围变更控制 进度安排变更控制 成本变更控制 质量控制 风险变更控制 合同管理

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

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

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

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

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

82 7 执行和控制过程——成本管理 82 | Presentation Title | Month 2006

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

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

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

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

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

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

89 预测公式 术语 公式 度量 要完成估算 ETC=EAC-AC 要完成所必需的预期劳动力 完成时估算 EAC=BAC/CPI 预算的总项目成本
完成时预算 BAC 项目成本基线 进度偏差 SV=EV-PV 计划和实际已完成工作之间的差额 成本偏差 CV=EV-AC 工作的价值和实际花费金额之间的差额 成本执行情况指数 CPI=EV/AC 效率指数，预算对实际成本的比率 要完成执行情况指数 TCPI=(BAC-EV)/(BAC-AC) 要在预算内完成所必需的效率级别 进度执行情况指数 SPI=EV/PV 已执行工作对预定工作的比率 完成百分比 PC=EV/BAC 已完成工作的实际价值

90 6 执行和控制过程——风险管理 90 | Presentation Title | Month 2006

91 风险管理流程 风险计划 y 风险识别 列入风险清单 该风险管理结束 定性、定量分析 否 S 风险量大小 L y 风险是否可以预防或降低
风险监控 n n 剩余风险是否很大 y y 风险转移 是否灾难性风险 n n 是否具有灾难承担能力险 工程保险 风险自留 其它方式 风险检查 风险管理总结

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

93 项目常见风险 产品定位错误（包括市场定位） 人员流动 项目管理失败 开发目标不明确或摇摆不定 开发计划执行受到严重影响 技术方案有缺陷
项目经费超支或不足 开发环境及过程管理混乱 产品质量低劣 需求发生变化

94 项目风险源 政府的政策 项目组织内部 设计错误 项目环境 合同条款的错误与混乱 物资采购与供货时间 工程价款估算或结算错误
通货膨胀和信贷风险 汇率变更 不可抗力 案例

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

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

97 风险清单举例

98 举例：风险对于项目时间影响评估表 风险描述 发生概率 造成的损失（周） 损失暴发量（周） 进度计划过度乐观 50 % 5 2.5
根据市场需求需要增加的新特性 35 % 8 2.8 客户要求从原系统进行自动更新 5 % 20 1.0 图形格式子系统接口不稳定 25 % 4 设计不充分-需要重新设计 15 % 15 2.25 项目审批时间比预期要长 设施未能及时到位 10 % 2 0.2 管理层要求撰写的进展报告需要更多人力和时间 1 0.1 承包商推迟提供图形格式子系统 10-20% 新的编程工具达不到预期时间节省 30% 1.5 风险总爆发量

99 风险影响评级 评估一个风险对项目主要目标的影响 项目 目标 非常低0.05 低 0.1 中 0.2 高 0.4 非常高0.8 成本
不明显的成本 增加 成本增加小 于5% 成本增加介于 5-10% 10-20% 成本增加大 于20% 进度 不明显的进度 进度拖延小 项目整体进度 拖延缓5-10% 项目整体进度拖 延 10-20% 项目整体进 度拖延20% 范围 范围减少几乎 察觉不到 范围的次要 部分受到影 响 范围的主要部 分受到的影响 范围的减少不被 业主接受 实际上无项 目最终产品 质量 质量等级降低 几乎察觉不到 只有某些非 常苛求的工 作受到影响 质量的降低需 要得到业主批 准 质量降低不被业 主接受 项目最终产 品实际上不 能使用

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

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

102 风险监控 风险监测和控制是这样一个项目管理过程：它通过跟踪已识别的风险，监视残余风险和识别新风险，保证风险计划的执行，并评估这些计划对减低风险的有效性。 风险监测和控制是项目整个生命周期中的一种持续进行的过程。随着项目的成长，风险会不断变化，可能会有新的风险出现，也可能预期的风险会消失。 良好的风险监测和控制过程能为我们提供信息，帮助我们在风险发生前做出有效决策。

103 项目风险应对审计 项目风险应对审计是指风险审计员检查与文字记录有关的规避、转移、或缓解风险等风险应对措施的有效性，以及风险承担人的有效性。
为了控制风险，风险审计在项目整个生命周期内应有规律地定期进行。 项目风险审核应是所有项目进展会议议程中的一项，在项目生命期内，风险值和优先次序可能会发生变化。任何变化可能都需要进行额外的定性和定量分析。

104 附加风险应对计划 如果出现了一种风险，而风险应对计划中又没有预计到这种风险，或者该风险对目标的影响比预期的大，那么原计划的应对措施可能就不是很适当。为了控制风险，有必要编制附加风险应对计划。

105 9 执行和控制过程——跟踪项目 105 | Presentation Title | Month 2006

106 项目跟踪活动 项目跟踪活动包括： 跟踪项目状态 控制变更 修订规划 举行状态会议 跟踪里程碑和质量 产生跟踪报告

107 用于跟踪的信息 用于跟踪的关键信息类别： 时间：诸如里程碑的关键信息 资源：使用的人力、剩余工作量的估算 工作：已完成或进展中
成本：资源和服务 工作产品及其相对于完成的进度 问题、风险和变更

108 报告流程 项目成员 团队领导 项目经理 QA 上层管理 客户 赞助人 低层的执行情况 数据应当向所有 更高层提供 举例

109 10 执行和控制过程——采购管理 109 | Presentation Title | Month 2006

110 采购管理 采购计划 承包商 招标计划 合同管理 招标 合同结束

111 工作陈述(SOW) 合同约束陈述，描述双方对服务执行情况的义务 简介/适用文 档/主要假设 责任、产品和 服务、任务 完成标准 进度
项目完成/ 接受标准 收费/条件和 条款/杂项 合同类型 支付安排 条款和条件 标准 差旅 装运 附录 清晰定义何时工作 已完成并被接受 产品和服务将被交付的日期 责任、产品和服务以及完成标准的描述 简介、列出SOW中引用的所有文档（确切 标题、编号、修订级别和日期）主要假设

112 合同发生过程 合同的发生过程实际上是要确定所要编制的采购文件类型，签订合同的专家要通过调查去查找一些可能的卖主，寻找供应商来提供所需要的物品和服务。在一开始的时候，他可能采用一个单边合同或双边合同。 单边合同即以采购单的形式，列出（例如目录价格）物品清单的标准价格。在这种情况下，卖主通常是自动地接受这种采购单。这样产生的单边合同通常不涉及任何谈判，并且相对来说涉及费用较低。 双边合同是通过请求报价（RFQ）、请求提出建议（RFP），或招标方式（Bid）启动。选用哪种双边方法，视下述因素而定： 请求报价（RFQ）用于大宗商品（物品）的相对较低的金额的采购。 请求建议（RFP）用于货币价值相对来说高的、复杂的或非标准的物品的采购。

113 评价可能的承包者 合同谈判：就合同的结构和要求，双方澄清见解，并达成协议。
有多种方法可用于评价可能的承包商，而且它们不是相互排斥的。这些方法包括： 合同谈判：就合同的结构和要求，双方澄清见解，并达成协议。 加权方法：这是为将人的偏见和随意性的影响降至最低程度，而采取的把定性数据量化的方法。 筛选方法：为一个或多个评价标准确定最低限度履行要求。 独立估算：采购组织自己进行估算，并把估算结果作为与相应承包商或卖方的建议相比较的参考点。

114 采购合同类型 固定总价合同（FFP）或总计金额合同 固定价格加酬金（FPIF）合同 成本加固定费（CPFF）合同 成本加酬金（CPIF）合同
成本报销合同：按规定，卖方要以固定价格提供货物或服务，虽然卖方承担全部风险，但是将被最大的利润潜力所补偿。这是最常用的合同类型，并且最适合于技术要求已经相当确定和成本比较确定的场合。 成本返还合同或成本报销合同建立在成本基础之上，同时加上固定的费用。这一类合同是成本加固定奖金，或者是成本加上一定比例的费用。 FPIF合同规定，向卖方提供固定价格，加上一笔预先确定的费用，作为优质执行的奖金。风险由买卖双方分担。这种合同类型主要被用于执行周期长的高价值项目，例如用于造船和大型系统开发项目。 CPFF合同规定偿还正当成本，加上随着合同执行的进展成比例支付的固定成本。虽然对于卖方的利润有一个上限，但是不存在任何控制成本的机能，因此非常大的风险依然在买方。这种合同类型主要用于所要求的投入在项目被顺利执行之前仍是不确定的情况。 CPIF合同规定偿还正当成本，加上作为优质执行的奖金的一笔预先确定的费用。如果实际成本低于预期成本，则买方和卖方将根据一个预先确定的公式，分享节省金额。这种合同类型主要用于执行时期长、硬件开发与试验要求多的合同。 CPPC合同规定偿还所执行的服务的正当成本，加上作为利润的估算成本，即经过双方商定的一定比例的成本。卖方有责任尽其最大努力，在估算的金额以内完成合同；买方则为所有的超支提供资金。这种合同类型在美国联邦计约中是被禁止的，而且在商业部门很少使用。

115 主要合同支付办法 100% 100% 完成时支付 全部 100% 100% 100% 按等量分 批支付 100% 按协定量分 批支付 t t
完成可交付 资料时支付 协定量 开始时全 部支付 100% 100% 100% 100% 100% 当发生成本 时支付 100% 固定价格 扩展 固定价格 扩展 T&M/LOE t t t

116 合同收尾 合同收尾 产品核实和行政收尾 合同记录 合同文件 合同审计 产品核实（即核实工作已经被完成） 行政收尾（即更新所有的合同记录）。
合同记录。包括合同本身和其它相关文件，例如进展报告、财务报告、发票和支付记录。这些记录往往被保存在一个合同文档中。这个文档应该是完整的项目文档的一个部分。 合同文件。如果一项采购审计被启动，这种审计是对从采购计划编制到合同管理的采购过程的一次系统性审查。 审计的目的是找出成功的经验和失败的教训，以利于本项目其它物项或未来项目的物项采购。

117 11 项目总结及原因分析 117 | Presentation Title | Month 2006

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

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

120 经验教训报告内容举例 主要结果和参考数据 主要分析: 项目的人力 项目的功能特性 项目工期 项目 vs 目标 项目质量 项目规模
每一阶段的详细分析 同行评审 测试活动

121 项目总结报告 关键特性和优点 跟踪度量 总体计划 详细计划 项目估算 项目最新预测 定量分析 缺陷记录数据库 项目评审报告 DRs 纪要
RCAs 实施结果 Prev. 项目总结 项目团队成员面试 定量分析 定性分析

122 造成失败的原因 有些失败是不可避免的，因为它们超出了人力所能预期、避免或者影响的范围。这种类型的失败源于天气或者劳动力问题、难以解决的技术难题以及其它不可预见或者不可控制的外力。 但是，这并非是大量项目失败的原因。相反，失败通常是由于“缺陷”引起的，这些缺陷存在于： 项目和用户组织——态度、实践和结构。 项目最终产品——硬件、软件和组成部件。 这些缺陷通常是相互联系的。 例如，尽管硬件失败是因为部件和程序的缺陷，但这些缺陷通常可以追溯到设计时的失误，接下来又可以追溯到在设计和管理过程上的失误，这些失误使得错误没有纠正就过关了。也就是说，计划和控制项目的系统，即项目管理系统内的缺陷可能允许和导致低劣的设计、糟糕的质量控制、不充分的检查，最后导致最终产品本身的失败

123 12 冲突管理 123 | Presentation Title | Month 2006

124 看待冲突的两种对立的观点 传统的观点 现代的观点 冲突是麻烦制造者引起 的是坏事应被避免必须 被压制 冲突是人和人之间不可避免的事
经常是有益的是变化带来的自然结 果是能够被且应被管理的事情

125 导致组织产生冲突的根源 在管理中，导致组织产生冲突的根源(除了变革的影响)： 权限不明 利益冲突 沟通障碍 依赖一方 组织内的分化 小团体
需要达成共识 行为规范 以前遗留未解决的问题

126 矩阵组织中的冲突 在项目组织中，最容易产生冲突的是矩阵组织形式。原因有： 雇员要服从于两个老板 权限不清，职责重叠
为争抢稀缺资源而产生利益冲突等

127 项目生命周期内的各阶段最易引发冲突的原因
概念阶段：项目的优先次序、行政管理程序、进度计划 计划阶段：项目的优先次序、进度计划、行政管理程序 执行阶段：进度计划、技术问题、人力资源 项目结束阶段：进度计划、个性冲突、人力资源

128 处理冲突的5种办法 解决问题 折衷妥协 缓和 退让 强制

129 13 项目成功的关键因素——项目经理 129 | Presentation Title | Month 2006

130 Harold Kerzner博士有关项目管理的16条至理名言
接受项目管理理论，并持续地运用它 采用促进公司向着成熟的项目管理发展的管理哲学，并将其传达给每个人 在项目开始时，制定有效的计划 在付诸实施时，尽可能小地变更范围 要认识到成本和进度管理是紧密相连的 选择合适的人做项目经理 向高层管理者提供项目发起人的信息，而不是项目经理的信息 加强直线管理层的参与和支持

131 Harold Kerzner博士有关项目管理的16条至理名言
关注可交付成果而不是资源 培育有效的沟通、合作及相互信任，以实现项目管理的快速成熟 与全部的项目团队成员和直线管理层分享项目的成功 消除非生产性会议 尽可能早而快地、低成本高效地识别并解决问题 定期测评项目进展 将项目管理软件作为一种工具，而不是一种计划或人际关系技巧的替代品来使用 制定全员培训计划，让员工学习正规的、定期更新的课程

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

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

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

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

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

137 举例：某跨国公司的项目经理能力模型 Business Perspective Cost Management Customer Focus
Gaining a Competitive Advantage Consultancy PM Competency Model Creativity and Innovation Influencing others Listening interactively Facilitating and managing meeting Problem Identification and analysis Business Awareness Problem Resolving Problem Resolving Showing sensitivity Writing Managing confilict and contention Networking Speaking Communication & Interpersonal Assuring the Quality Standards Key Behavior to different Level Planning and Organization Adaptability Project Management Decision Making and Initiative Leadership and Guidance Organization and Administration , Feedback Bias for Action Motivating Others Delegating Setting objective and direction Coping with pressure Coaching and Development Judgment Building Team Success PM level PM0-1 PM2 PM3 PM4

138 14 团队和团队管理 138 | Presentation Title | Month 2006

139 项目失败的原因 组织和管理 36,2 % 个人关系 49,8 % 目标 19,6 % 计划和监控 15,0 % 资源 10,3 %
组织和管理 36,2 % 个人关系 49,8 % 目标 19,6 % 计划和监控 15,0 % 资源 10,3 % 分包商 4,0 % 技术原因 3,7 % 规程和控制 12,1 % 项目规模 9,8 % 项目环境以及其它原因 11,2 % Why focussing on target setting : this will prevent failure and (with next slide ) will enable success It is the second most important issue for project success Organisation and management means the “team organisation and management” as well as the environment

140 团队的定义 一个清晰的团队定义有助于将这种新的组织形式与更传统的工作组 （group）区分开来
“一个团队由少量的人组织，这些人具有互补的技能，对一个共同目的、绩效目标及方法做出承诺并彼此负责。”

141 领导和管理 管理 维护 模仿 注重系统/结构 依赖控制 以事为本 短期视角 When/When 注重财务数字 接受/保持现状 做事正确
问“你现在可以做什么” 领导 不断创新，提高效率 发展 原创 以人为本 信任 长远视角 What/Why 注重整体素质的提高 挑战现状户 做正确的事 问“你将来可以做什么”

142 团队建设过程需要解决9个方面的问题 明确的目的和一致的目标 公开和正面解决问题 支持和信任 合作和冲突 合理的步骤 适当的领导能力 例行审议
个人发展 正常的集体间的联系

143 胜任工作的项目人员具有的特点 重结果、肯实干 头脑细致 对项目有很强的责任感和献身精神 有全局观念，对组织的目标极为明确 政治娴熟
具有成本意识 了解经营的基本知识 了解职员、顾客及管理层的需求 能够应对情况不清、挫折和令人失望的结果等情况 良好的谈判技巧 称职的技术技能 良好的个人素质：坚韧、公平、公开、诚实、有涵养、果断

144 项目组应具备的项目管理能力 对于一个项目组来说，处在个人能力基础之上，它应该： 有明确且切合实际的目标。
有定义明确的实施方案，这个方案是按照项目目标的要求制定的。 有各项技能的合理组合，也就是说具有不同技能的人员的合理组合。 项目组成员拥有适用的教育水平，具备完成工作所需要的技能，有纪律约束（例如沟通计划、例会、定义明确的文件要求等）。 项目组具有凝聚力，能够迅速达成共识，大胆、有开创力。 拥有合理的结构，有利于项目团队按照需求完成工作。 具有能够集成不同意见的能力。 具有达到预定结果的能力。 具有高效配合客户的能力。 需要项目经理的领导艺术和团队成员的合作。

145 选择一 问题一 你知道一个女人怀孕了，她已经生了8个孩子，其中3个耳聋、2个眼瞎、一个智能有问题，自己又有梅毒，请问，你会建议她堕胎吗？
答案：胎儿是贝多芬

146 选择二 现在要选择一个领袖， 候选人A：跟一些不诚实的政客有来往，会星相占卜术，有婚外情，老烟枪，每天要喝8~10杯马丁尼。
候选人B：他过去有2次被炒鱿鱼的记录，睡觉睡到中午才起来，大学时抽鸦片，每到傍晚要喝一夸脱威士忌。 候选人C:他是因为受过勋的战斗英雄。素食主义者，不抽烟，偶尔喝一点啤酒，从没发生过婚外情。 从公正的角度选，你选哪一个 A:富兰克林. 罗斯福 B:温斯顿.丘吉尔 C:阿道夫.希特勒

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

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

149 MSN