全球项目管理方法论 ——H企业工业自动化和控制项目运作

第一章 概述案例

1 全球项目管理概述 1.1 全球项目管理简介 1.2 项目管理框架 1.3 项目管理生命周期结构 1.4 项目管理生命周期阶段 1 全球项目管理概述 1.1 全球项目管理简介 1.2 项目管理框架 1.3 项目管理生命周期结构 1.4 项目管理生命周期阶段 1.5 项目管理活动概览 1.6 全球项目管理的构成要素 1.7 全球项目管理过程词典 1.8 全球项目管理核心功能 1.9 全球项目管理工具箱 1.10 全球项目管理术语

1.1 全球项目管理简介 H公司的工业自动与控制（IAC）部门（division）已经把项目管理构建成为其核心专长，该部门需要项目管理来实现其战略目标以及在市场上获得竞争优势。IAC认识到这种能力对于实现我们的愿景——通过提供最佳的价值解决方案以及展示我们获得卓越绩效的激情来提高客户的经营成果——将起到极其重要的作用。 新的Global Project Management（GPM）为企业和个人获得项目管理的成功提供了一个有用且便于使用的框架。随着GPM的不断发展，现在的GPM已经包含了H公司在过去的经验和努力中所积累起来的最佳管理过程，将这些过程与先进的项目管理概念以及艺术性的实践相结合将会推动我们的企业成为项目管理领域内的顶级公司。

全球项目管理主要内容 开发和任命专业项目经理人员 为IAC项目经理建立和使用一个项目管 理的一般性过程和通用方法 提供有效的项目管理工具和技术 调整IAC项目管理服务，以便为公司项目管理人员和全球项目管理方法论的维护提供管理服务和持续支持。

1.2 项目管理架构 项目管理被描述为：运用方法、工具和技能以实现项目的时间、成本和绩效目标的艺术。毫无疑问，这个概念包含了在项目的全过程中满足顾客的期望以及合同所规定的各种规范和要求的责任。 作为一种努力，项目具有如下特性： • 以实现特定目标为目的 • 由一系列相关的活动构成 • 有确定的起止时间 • 独特的，不是重复的活动 大项目是与项目管理相关的另一个概念，大项目是一个比项目的范围要大通常包含几个相互关联的项目。

1.3 项目管理生命周期结构 H企业项目管理生命周期结构中包含了一系列连续的逐层细化的层级，将用来指导项目管理的执行。 下图描述的就是H企业Global Project Management Methodology的基本层次分解结构。

1.3.1 项目管理生命周期结构图 阶段 任务 步骤 活动 项目管理生命周期结构

1.3.2 项目管理生命周期结构层次 阶段层次：阶段层是结构中的最高层级，它代表着项目生命周期中的四个阶段，这四个阶段将在下面的部分予以讨论。 活动层次：这个层次是用来确保所有的项目所采用方法的一致性的。它是一个high-level执行陈述，每个活动的执行要求将随着项目的规模和类型的不同而变化。 任务层次：结构的这个层次为确保恰当地完成每一个活动需要做什么提供了详细的指导。对于比较小的项目，任务层次可以作为参考；对于比较大的项目，为了确保项目成功，每一个任务必须完成并要记录。 步骤层次：任务进一步分解为步骤有利于任务的完成。这些步骤形成了项目生命周期结构中最详细的层次。

1.4 项目管理生命周期阶段 H企业项目管理生命周期既可以是迭代的又可以是循环的。在前面的图标中，箭头标明了产出是如何从项目的概念阶段流向计划阶段，从计划阶段流向执行阶段的。这一过程是项目管理努力迭代前进的过程，其中的每一个过程都会对其后续过程形成影响。同时，在获得新的信息后，又可以对以前执行完成的活动造成影响，在概念阶段所做出的成本估计可能会因为计划阶段作详细计划时所获得信息而做出调整，计划阶段的成果也可能会因为执行阶段获得的信息而做出改变。这种重复活动就是项目管理中的循环特性。

1.4.1 项目管理生命周期阶段图 概念 阶段 计划 执行 收尾 项目管理生命周期

1.4.2项目管理生命周期阶段概览 概念阶段：是项目管理的起始阶段，其中的活动包括：描绘和定性分析项目机会，进而建立一个真实的、经过授权的项目。 计划阶段：项目管理的这一阶段是一个广义的计划活动，它生成向客户提供的解决方案所需的时间、成本和资源估计；同时建立一个基线计划文件，项目团队成员将利用这个文件执行和跟踪项目。 执行阶段：执行阶段就是所计划的项目努力的执行，他伴随着一系列的活动，如跟踪、评价和控制项目的过程。 收尾阶段：这是项目管理的最后一个阶段，在这一阶段通过接收到正式移交的接受文件、最后的项目反馈活动、以及最后的接收项目或其他部署的文件来正式地清晰地结束一个项目，这个项目既可以是内部项目也可以是客户项目。

1.5 项目管理活动概览 概念阶段 • 识别项目机会 • 定义项目机会 • 启动项目 计划阶段 • 定义项目范围 • 开发初始项目计划 • 生成项目建议书 • 签订合同或协议 • 获得并分配项目资源 • 开项目开始会议 • 准备项目的执行 实施阶段 • 管理项目绩效 • 控制项目 • 管理客户要求 • 管理采购 • 管理风险和机会 • 管理项目分歧 • 进行项目最终测试和接受 收尾阶段 • 向客户移交 • 项目最后鉴定 • 重新分配项目资源和员工

1.6 全球项目管理的构成要素 良好定义的管理项目的过程，这一过程描述了在项目管理生命周期的各个阶段所要执行的活动和任务。 一系列核心项目管理功能，描述如何完成每一个任务 一系列相关的标准工具，这些工具的运用有助于项目经理和项目团队成员执行项目管理活动。 项目管理术语集合，这些术语为项目管理生命周期内所使用的术语提供了一个可供参考的一般性框架。

1.7 全球项目管理过程词典 一个有效的项目管理方法论必须对项目管理过程做出一个简明的描述。 项目管理全生命周期标准过程的说明书包含在GPM过程词典中。这个过程词典确定了各个阶段需要完成的工作、活动和任务。其中在任务层次，给出了明确的执行步骤，具体参见相应的核心项目管理功能部分，同时给出了与任务相关的工具，以便于项目经理的参考。 GPM过程词典包含在第二章的内容中。

1.8 全球项目管理核心功能 完成H企业的每一个项目都需要执行一系列的核心功能，这些核心功能由项目经理和项目团队负责。 成功完成项目管理的方法包含于GPM核心功能部分。这些核心功能提供了在过程词典中识别的关于如何完成任务步骤的细节。全球项目管理核心功能，共十条如下： • 组织和计划 • 质量管理 • 评估 • 客户关系管理 • 资源管理 • 合同管理 • 项目跟踪和控制 • 沟通和文档管理 • 风险和机会管理 • 变更管理 GPM核心功能包含在第三章到第十二章。

1.9 全球项目管理工具箱 使用标准工具可以使项目经理集中精力于管理新的文档、参考资料和其他必要的辅助性措施来维护数据、监督项目的进程和状态，而不用再去创造这些工具。同时，使用标准工具还可以为所有的项目经理提供一个一般性的方法来记录项目状况、交流相关信息。 已经建立了适合于所有企业项目的GPM工具箱，这个工具箱包含有各种表格、清单以及可以用来完成整个项目生命周期内的所有任务的模版。 在H企业Global Project Management Methodology文档中，每一个核心功能的最后都有一个使用于此功能的GPM工具箱。

1.10 全球项目管理术语 GPM术语表中定义了H企业 特定的工业标准和项目管理一般术语。这个术语表将会使H企业项目管理环境中的交流更加有效。 GPM术语表第十二章后附加。

第二章 项目管理过程案例

2 项目管理过程词典 2.1 概念阶段 • 活动1.1 识别项目机会 • 活动1.2 授权项目机会 • 活动1.3 启动项目 2 项目管理过程词典 2.1 概念阶段 • 活动1.1 识别项目机会 • 活动1.2 授权项目机会 • 活动1.3 启动项目 2.2 计划阶段 • 活动2.1 定义工作范围 • 活动2.2 制定启动项目计划 • 活动2.3 生成项目建议书 • 活动2.4 签订合同或协议 • 活动2.5 获得并分配资源 • 活动2.6 召开项目启动会 • 活动2.7 准备实施项目 2.3 执行阶段 • 活动3.1 管理项目绩效 • 活动3.2 项目控制 • 活动3.3 管理客户要求 • 活动3.4 管理采购 • 活动3.5 管理风险和机会 • 活动3.6 管理项目变更 2.4 收尾阶段 • 活动4.1 向客户移交 • 活动4.2 执行最后的项目评价 • 活动4.3 重新分配项目人员与 资源

过程词典规定了在项目管理生命周期四个阶段中要完成的标准过程。每个阶段的活动和任务用一组流程图和文字说明来表示。每个任务的流程图展示了较好的绩效步骤顺序，并附有对绩效步骤的一个总的说明。 在任务层，绩效步骤也与作为应用核心职能主题的参考。过程词典说明了有效地管理一个项目必须做什么。核心职能主题提供了关于一个任务的绩效步骤怎样做的说明。 流程图 概 念 阶 段 计 划 阶 段 实 施 阶 段 收 尾 阶 段

2.1 概念阶段 活动1.1 识别项目机会 • 任务1.1.1 定义项目机会 • 任务1.1.2 验证项目机会 活动1.2 授权项目机会 2.1 概念阶段 活动1.1 识别项目机会 • 任务1.1.1 定义项目机会 • 任务1.1.2 验证项目机会 活动1.2 授权项目机会 • 任务1.2.1 开发业务专案 • 任务1.2.2 开发概念解决方案 • 任务1.2.3进行启动风险和机会评估 • 任务1.2.4完成业务专案 • 任务1.2.5 授权项目 活动1.3启动项目 • 任务1.3.1 建立项目管理制度 • 任务1.3.2 安排项目初始资金 • 任务1.3.3 建立项目管理信息系统

2.1 概念阶段 概念阶段是项目生命周期的起始阶段。销售经理是这一阶段的主要负责人。在概念阶段，销售经理及其管理组织识别、评价和界定机会，以保证其符合H企业的目标和战略方向。销售经理与其团队开发出一个概念化的解决方案，进行最初的风险评估，并准备一个业务专案。由分支销售机构经理评审后，把此业务专案提交给区域业务团队，他们将作出最后决定是否量化此项目。 开始 项目 1.1 识别 机会 1.2 授权 1.3 启动 2.0

活动 1.1 识别项目机会 此活动的目的是对机会进行定义与验证。销售经理识别出项目发起人和决策制订者并获得投标邀请/报价邀请(RFP/RFQ)及其它项目定义文档。销售经理和H企业咨询师/企划经理评审文档并对机会进行筛选。销售经理准备一份销售计划，提交给分支销售机构经理，由他来决定是否进行下一步。 开始 项目 1.1.1 定义 机会 1.1.2 验证 1.2.1

任务 1.1.1 定义项目机会 此任务的目的是识别客户和定义机会。为了满足客户期望，H企业必须指导客户的组织和关键人物（决策制订者、项目发起人及其它相关利益主体）。还有理解客户的需求和项目的范围与需求也非常重要。 开始 项目 识别 顾客 获得顾 客的项 目定义 文档 评审顾 1.1.2 准备项 目销售 计划

任务1.1.1过程步骤 过程步骤 过程描述 功能参考 识别顾客 业务经理使用环球业务管理软件记录并识别顾客组织中的发起人决策制订者。 1.2.1 获取顾客的项目定义文档 业务经理需获取所有定义顾客要求和需求的文档。这些文档可能包括建议申请书/报价申请书，或由顾客或顾客与H企业联合制定的任何其它定义文档。在某些情况中一份与顾客联合制定的可行性研究需要对项目作出定义。 7.3 评审顾客的项目定义文档 业务经理和咨询/方案经理要对所有定义了顾客要求及项目的范围和需求的文档进行评审。 1.3.1 准备销售计划 由业务经理准备销售计划，此计划包括了象顾客所在地、关键决策制订者和可能干扰项目成功进行的主要竞争者和障碍等这样的信息。销售计划还应给出与对顾客的整体业务战略一致的策略和目标。 2.2.1 2.2.2 2.2.3

任务 1.1.2 验证项目机会 机会的验证是概念阶段最重要的任务之一。此过程必须可以重复（无论谁来做此验证结果都应相同）。此过程也建议为所有相关利益主体提供验证结果。为了完成机会验证的任务，销售经理必须问以下问题：H企业真的想在这个机会上投标吗？它是公司的核心业务之一吗？此机会适合IAC目标吗？它是什么类型的项目？ H企业有竞争优势吗？存在一个高于一切的营销决定支持投标吗？H企业 能满足客户需求吗？H企业能取悦客户吗？ 1.1.1 扫描项 目机会 识别项 目类型 对照 IAC 目标进 行评价 1.2.1 制定继 续进行 的销售 决策

任务1.1.2过程步骤 过程步骤 过程描述 功能参考 扫描项目机会 业务经理和咨询/方案经理要评审此机会：是否可行、是否在IAC的技能和能力范围内、是否是公司的核心业务或目标动机。 1.2.1 1.3.1 7.3 识别项目类型 IAC已经整合了服务指南中介绍的几种类型的项目（在方法论文件的第一部分）。GPM方法的应用将根据项目的要求而决定。 对照IAC目标进行评价 业务经理及其管理团队要对此机会进行评价，以确保其符合IAC的目标和战略方向。 制定继续进行的销售决策 分之机构销售经理与可用的地区管理人员一起，根据以上评价作出一个主要为是否继续追踪此机会的决策。把此决策作为建议给所有干系人。

活动 1.2 授权项目机会 在把资金和资源交给任何业务机会前，H企业必须通过一个正式的限定过程来制定是否批准进行此项目的决策。 此过程评价项目的技术和经济生命力，评价多区域影响和国际应用，并开发业务专案。 1.1.2 1.2.1 开发业 务专案 1.2.2 开发概 念方案 1.2.4 完成业 1.3.1 1.2.5 量化 项目 1.2.3 进行初 步的风 险与机 会评价

任务 1.2.1 开发业务专案 业务专案将包括所有为制定是否限制项目的适当管理决策而收集的商务和技术信息。此业务专案包括一份客户与机会的行政性摘要、一份财务评价（或一份成本/收益分析）、一份概念化的解决方案、一份初始的风险与机会评价和管理计划，和一份按标书进行开发所需的投资。此任务是开发一个业务专案的起始步骤。 1.1.2 识别和 指定业 务专案 开发人 准备 项目 定义 财务 评价 1.2.2 1.2.3 编辑初 始的业

任务 1.2.1过程步骤 过程步骤 过程描述 功能参考 识别和指定业务专案开发人 业务经理要识别、申请开发业务专案所需的人力资源，并为之分配任务。这些人员可能包括咨询/方案经理、一个估算师或财务咨询师以及其他所需专家。 8.3.1 工具8－1 业务专案 准备项目定义 由业务经理和咨询/方案经理准备作为项目高层次概述的项目定义文档。项目定义文档包括项目类型、范围和约束等信息；一份所需组织和资源类型的评价；及一份建议的技术方案。 准备财务评价 此项高层次的成本－收益分析既是与顾客假定的预算（如果知道）相对应的期望成本加期望收益。顾客的真实利润和毛利润应通过次任务识别出来。这也是第一次计算项目的投资汇报（如果有）。 编辑初始的业务专案 此步开始为业务专案开发框架。当收集到额外信息时，要整合到此文档中去。

任务1.2.2 开发概念解决方案 销售经理识找一个或多个技术建造师来开发一个整合到业务专案中去的高水平的概念化解决方案。 1.2.1 识别技师 并为其分 配任务 评审项目 定义文档 准备概念 方案 1.2.4

任务1.2.2过程步骤 过程步骤 过程描述 功能参考 识别技师并为其分配任务 业务经理要识别开发技术方案所需的技师，并为其分配任务。这些技师可能包括咨询/方案经理、一个网络咨询师及其它所需人员。 3.2.1 3.3.3 评审项目文档 业务经理和技师们对项目定义文档进行评审，以确定满足客户要求的最合适和可行的技术方案。 8.3.1 工具8－1 业务专案 准备概念方案 技师们开发一份整合到业务专案中去的高层次的技术方案。此概念方案必须至少陈述以下问题： 要求是什么？ 怎样满足要求？ 谁来满足此要求（包括所需的任何联盟、第三方或分包商）？ 8.3.2

任务 1.2.3 进行启动风险 和机会评估 最初的风险与机会评价是一种对可能影响项目绩效的主要风险、成功概率和潜在的可能减小这些风险的业务机会的高层次检验。此评价考虑了技术和非技术、风险及其相关成本。也考虑了成本节省或额外收入形式的潜在业务机会。 1.2.4 1.2.1 识别初 始风险 和机会 评价初 的影响 制定初始 风险转移 和机会最 优化策略 2.2.6 准备初始 风险和机 会管理计 划

任务 1.2.3过程步骤 过程步骤 过程描述 功能参考 识别初始风险和机会 业务经理和咨询/方案经理对项目定义和概念方案进行评审，以识别出主要的风险和潜在的机会。 8.2.4.2 5.3.1 5.2 工具 5－1 风险与机会管理过程核检表 工具 5－2 风险与机会评价模型（ROAM） 评价初始风险和机会的影响 业务经理和咨询/方案经理对识别出的风险和机会可能对项目产出物造成的影响进行高层次的评价。 5.2 工具 5－3 风险核检表 工具 5－4 机会核检表 制定初始风险转移和机会最优化策略 业务经理和咨询/方案经理准备一份已识别出风险的契丹，并制定一份减小风险影响的转移策略。同时也要制定一个将潜在机会转化为资本的最优化策略。 准备初始风险和机会管理计划 此高层次的计划包括转移风险和最大化机会的策略。此初始计划将整合到业务专案中去以待地区业务团队进行评审。

任务 1.2.4 完成业务专案 销售经理与咨询师/企划经理最终会为业务专案准备一份机会限定总结，其中整合进了最初的业务专案，还有概念化解决方案和最初的风险与机会管理计划。 1.2.5 整合概 念方案 整合风 险与机 会管理 计划 准备附 属的机 会定量 总结 进行预 管理评 审 1.2.2 1.2.3

任务 1.2.4过程步骤 过程步骤 过程描述 功能参考 整合概念方案 业务经理和咨询/方案经理将技师们准备的高层次概念方案整合到初始业务专案中去。 8.3.1 工具8－1 业务专案 整合风险与机会管理计划 业务经理将与咨询/方案经理一起开发的初始高层次风险和机会管理计划整合到初始业务专案中去。 准备附属的机会定量总结 业务经理和咨询/方案经理准备一份机会定量总结。此信息是申请指派建议的计划团队的先决条件。 进行预管理评审 在将业务专案提交到地区业务团队之前，业务经理要与分之机构销售经理对其进行评审。 1.2.1

任务 1.2.5 授权项目 销售经理把业务专案连同所有相关的信息，提交给区域商务团队，他们将决定是否从事此机会。在项目生命周期的早期对机会进行限定，使得H企业可以通过追逐具有高成功率，并且与IAC’s目标和战略方向一致的机会来管理销售成本。 1.2.4 准备提交 地区业务 团队的业 务专案 团队进行 评审 获得继续 进行的批 准 1.3.1 2.1.2

如果作出了抓住此机会的决定，地区业务团队就批准了此项目，并要为继续开发一份建议书指定所需资源。 任务 1.2.5过程步骤 过程步骤 过程描述 功能参考 准备提交到地区业务团队的业务专案 业务经理要准备提交的材料，并将所有相关的技术和财务数据整理进去，以便地区业务团队能作出正确的决策。推荐业务经理在评审会议召开之前就将此业务专案的副本提交到地区业务团队。 8.3.1 工具8－1 业务专案 地区业务团队进行评审 业务经理将业务专案提交给地区业务团队。团队对机会及其成本、风险和收益作出评价。也要保证此机会是H企业的核心业务之一，并且与IAC的目标和战略方向一致。 获得继续进行的批准 如果作出了抓住此机会的决定，地区业务团队就批准了此项目，并要为继续开发一份建议书指定所需资源。

活动1.3 启动项目 项目群经理/区域项目总监任命了负责的项目经理后，项目就启动了。一旦得到任命，项目经理与其管理团队一起取得计划和开发一个正式标书所需的资金。资金的管理以赢得投标和所需资源为基础；还要建立一个风险项目编号或投标与标书 (B&P)项目编号。建立了项目管理信息系统，并输入了初始的项目数据。 1.2.5 1.3.1 建立项目 管理制度 1.3.2 安排初始 的项目资 金 2.1.1 1.3.3 管理信息 系统

任务 1.3.1 建立项目管理制度 要启动项目，需要尽快有项目经理到任。理想情况下，区域业务团队一旦限定了项目就任命项目经理。 1.3.2 1.2.5 识别负责 的项目群 经理、地 区项目总 监 确定项 目管理 需求 任命项 目经理 1.3.2 1.3.3

任务 1.3.1过程步骤 过程步骤 过程描述 功能参考 识别负责的项目群经理、地区项目总监 根据业务经理的资质申请，地区项目总监来为此项目确定项目群经理/地区项目总监。在某些案例中，地区项目总监可以保留此任命。任命将由项目类型和客户意见决定。 1.2.1 确定项目管理需求 项目群经理/地区项目总监和业务经理一起对业务专案的项目类型、规模、复杂程度、工期和其它特殊因素进行评审，并找出最有资格的项目经理。 任命项目经理 一旦选中，立刻通知此项目经理并将其分派到项目中去。 1.2.2

任务1.3.2 安排项目初始资金 项目启动后，项目经理开始寻求计划编制和制定客户建议书的资金。根据中标的可能性，决定商业资质的过程，从运营或销售中获得资金。 1.3.1 2.1.1 获得初始 项目资金 制定并提交 资金授权申请 确定风险或 B&P项目账号

任务 1.3.2过程步骤 过程步骤 过程描述 功能参考 制定并提交资金授权申请 项目经理制定资金授权申请并提交区域项目总监，从风险项目账号中获得资金 1.2.3 工具1-2 资金授权申请办法 获得初始项目资金 区域项目总监告知项目经理，计划和制定客户建议书的初始项目资金可以从风险项目账号或B&P项目账号中获得 确定风险或B&P项目账号 财务部门为项目经理提供项目账号

任务1.3.3 建立项目管理信息系统 项目管理信息系统包括所有硬件、软件和用于跟踪、监控和报告项目数据和运行状态的操作过程，包括用于跟踪成本的ORACLE项目会计系统（ORACLE PA）和用于跟踪时间和资源的标准软件应用程序，它或许还包括一些手工做的日志或者跟踪表格。 1.3.1 2.1.1 识别初 始项目 报告需 求 建立工 作档案 跟踪初 始成本 、进度 和资源 定义项目 管理信息 系统使用 需求

任务 1.3.3过程步骤 过程步骤 过程描述 功能参考 识别初始项目报告需求 项目经理根据明确的项目需求，确定向管理部门和客户报告的内容和频率 1.2.4 4.2.1 建立工作档案 由项目经理决定文件的范围和类型，包括所有的文件归档要求，并且与当地ISO9000标准保持一致 9.6.2 4.2.3 跟踪初始成本、进度和资源 项目经理向系统中输入信息，比如：客户和项目经理的名字，发展计划建议书，项目持续期间，资源以及成本 定义项目管理信息系统使用需求 项目经理根据各部门需求，定义项目管理信息系统使用需求，并指定系统使用的特权和一般权利，项目经理向所有参与各方传达此信息

2.2 计划阶段 活动2.1 定义工作范围 • 任务2.1.1召集建议书计划编制团队 • 任务2.1.2 确定项目方法 2.2 计划阶段 活动2.1 定义工作范围 • 任务2.1.1召集建议书计划编制团队 • 任务2.1.2 确定项目方法 • 任务2.1.3 开发初步工作范围 • 任务2.1.4 制定详细工作范围 活动2.2 制定启动项目计划 • 任务2.2.1 制定工作分解结构 • 任务2.2.2 制定成本估算 • 任务2.2.3 制定项目进度 • 任务2.2.4 制定资源估算 • 任务2.2.5制定项目支持计划 • 任务2.2.6 制定风险和机会管理计划 • 任务2.2.7 评审并编制初始项目计划 活动2.3 生成项目建议书 • 任务2.3.1制定建议书商务元素 • 任务2.3.2 生成建议书 • 任务2.3.3最后确定并提交建议书 活动2.4 签订合同或协议 • 任务2.4.1参与客户建议书评审 • 任务2.4.2合同或协议谈判 • 任务2.4.3准备项目登记 活动2.5 获得并分配项目资源 • 任务2.5.1 更新资源计划

2.2 计划阶段 计划编制阶段是成功的项目实施非常重要的一环。项目计划编制所花费的时间和努力必须与项目的类型，大小，复杂程度和持续时间成比例。为小型的、简单的项目制定广泛的、详细的计划所费的努力或许并不值得。计划完成之前，项目计划流程一定会频繁的反复。 在计划编制阶段，项目经理组织建议书计划编制团队，由他们来定义工作范围，制定初始项目计划，生成建议书并且参加与客户的谈判。如果建议书被接受，可以从客户那里获得书面协议或合同，以及订单。项目经理接下来组织项目团队，获取所需的资源，召开项目起始会议并准备实施项目。

2.2 计划阶段 1.3 3.1 2.1 定义工 作范围 2.2 制定初 始项目 计划 2.3 生成建 议书 2.4 签订合同 或协议 2.2 计划阶段 1.3 3.1 2.1 定义工 作范围 2.2 制定初 始项目 计划 2.3 生成建 议书 2.4 签订合同 或协议 2.5 获得并鉴 定项目资源 2.6 召开项目起始会议 2.7 准备实施项目

活动2.1 定义工作范围 这项活动的目的是：把项目的管理从销售转到运营上来（项目经理起领导作用）并开发一个详细的工作范围。建议书计划编制团队召集后，召开由销售部门和建议书计划编制团队参加的交接会议，考察贸易事件（包括概念上的解决方案和机会限制信息）并使团队熟悉项目范围。建议书计划编制团队考察所有可以获得的项目初步信息，明确项目团队成员的任务和责任，制定开发工作范围的计划和评估计划。建议书计划编制团队开发初步工作范围，制定客户验收标准，并与客户一起考察工作范围以确保满足客户需求。接下来团队制定详细的工作范围。 1.3.2 1.3.3 2.1.1 召集建 议书计 划编制 团队 2.1.2 确定项 目方法 2.1.3 确定初 步工作 范围 2.1.4 制定详 细工作 2.2.1 1.2.5

任务2.1.1 召集建议书计划 编制团队 建议书计划编制团队被授权确定工作范围，估算成本，制定最终的客户建议书，它一般由项目经理、项目工程师、成本估算师、销售团队成员以及其它支持工作范围开发的必需的资源。 1.3.2 1.3.3 识别资 源技能 需求 评估资 源的可 获得性 资源 谈判 分配资源 制定初始 资源责任 矩阵 2.1.2

任务2.1.1过程步骤 过程步骤 过程描述 功能参考 识别资源技能需求 项目经理分析确定工作范围所需的人员数量和技能，估算成本，并准备客户建议书 3.2.1 8.3.2.1 2.3.5 工具2-2 评估责任矩阵实例 工具3-1 资源责任矩阵 评估资源的可获得性 项目经理评估资源的可获得性，如果在当地不可获得，必须到其他地点或区域找寻并获得。 3.3.1 工具3-3 项目全体员工计划工作表 8.3.2.1 资源谈判 项目经理与合适的资源经理谈判，寻求当地资源。如果资源位于其他地区，项目经理或大项目经理/区域项目总监出面为资源的获得谈判。 3.3.2 分配资源 大项目经理/区域项目总监将资源交付给项目经理，这种分配仅供计划和建议书制定。如果合同签订，实行过程中需要同样的资源，必须为获得资源进行再次谈判。 3.3.3 工具3-8 项目原料登记表 制定初始资源责任矩阵 项目经理制定初始责任矩阵，这个矩阵起到了描述每个团队成员与各项任务的关系。初始责任矩阵只包括与建议书计划编制和开发有关的任务。 3.2.2

任务2.1.2 确定项目方法 在这一阶段任务中，销售财务经理正式将项目成本估算和为建议书计划编制团队制定提案的职责转给项目经理，项目经理起领导作用。项目经理和他/她的团队一起评审商业案例，修改启动风险评估并与运营管理层一起进行评审，随后决定如何实施项目。对于这一阶段的任务，销售团队发挥了很大作用，并且是积极的贡献者。

任务2.1.2 确定项目方法 2.1.1.1 评审概念 性方案 评审客户 项目定义 文件 主持与销售 部门的交接 会议 主持现场范 围会议 任务2.1.2 确定项目方法 2.1.1.1 评审概念 性方案 评审客户 项目定义 文件 主持与销售 部门的交接 会议 主持现场范 围会议 修改启动 风险和机 会 与运营管理层一 起评审修改后的 风险和机会 决定如 何实施 项目 2.1.3

任务2.1.2过程步骤 过程步骤 过程描述 功能参考 评审概念性方案 建议书计划编制团队评审概念性方案，并作为商业案例的一部分进行开发。这项评审与客户项目定义文件评审共同进行（下面会讨论），以确保提议的方案满足客户需求。 8.3.2.2 工具8-1 商业案例 工具8-2 RFP/RFQ评审核检清单 评审客户项目定义文件 建议书计划编制团队首先评审所有客户项目定义文件。评审这些已经被认可的文件是为了对客户需求有一个清晰的理解 。 主持与销售部门的交接会议 召开会议正式将项目的领导权由销售财务团队移交给建议书计划编制团队。与会者讨论概念性方案和客户期望值，并由销售团队提供建议书计划编制团队所需的补充信息。 9.9.1 工具9-5 项目启动会议核检清单 工具9-9 收尾会议核检清单 主持现场范围会议 如果需要的话，由建议书计划编制团队主持现场范围会议，以识别客户团队，建立沟通渠道，讨论客户关于项目范围的想法啊，并解释H企业建立和开发工作范围的流程。团队还进行初步的现场勘查。 修改启动风险和机会评估 作为现场范围会议和销售部门的交接会议的结果，一些额外的风险和机会显露出来了。建议书计划编制团队将这些新的风险和机会考虑进启动风险评估。 8.3.2.3 工具5-2 风险和机会评估模型（ROAM） 工具5-3 风险核检清单 工具5-4 机会核检清单 与运营管理层一起评审修改后的风险和机会 如果可以的话，在进行场地勘查之前，建议书计划编制团队与运营管理层一起对重新识别的风险和机会进行评审。 决定如何实施项目 根据与运营管理层的会议，决定如何实施项目，在实施之前，在可能的地点或许有必要与客户召开另一次会议，评审客户的期望值。

任务2.1.3 开发初步工作范围 这项任务是计划编制阶段最重要的环节之一。为了成功的开发出满足顾客期望值的方案，H企业必须明确理解客户的需求。为了达到这个目标，如果需要的话，由建议书计划编制团队进行调查，确定技术上、商业上和后勤方面的需求；制定定义很好并且双方同意的验收标准；制定并且与客户一起评审初步工作范围。工作范围必须要不仅将哪些交付给客户，而且要将哪些不交付给客户明确表述。在工作范围中明确定义这些信息将有助于避免日后实施阶段关于希望得到的和要求得到的服务的混淆。 2.1.2 进行场地 勘查 确定客户 验收标准 制定初步 工作范围 与客户一起 评审初步工 作范围 2.1.4

任务2.1.3过程步骤 过程步骤 过程描述 功能参考 进行场地勘查 如果有必要的话，建议书计划编制团队进行场地勘查，在进行场地勘察时，所收集的数据要与项目的需求保持一致。数据收集工作包括场地条件评估、现有设备的评审和，实力的证明，硬件和软件需求的识别，解释破坏活动并收集图纸。 1.3.1.1 工具1-3 场地勘查报告 确定客户验收标准 建议书计划编制团队会同客户明确确定哪些客户认为“可以接受的业绩” 和争取这个成绩的过程。这个预期必须在这个阶段确定好，一旦确定它就成为建议书整体的一部分，H企业会把可接受的业绩的定义看作项目团队业绩的最低。 1.3.1.2 工具1-4 客户验收标准 制定初步工作范围 建议书计划编制团队遵循数据收集活动的结果制定初步工作范围。 1.3.1.3 工具1-5 工作范围核检清单 与客户一起评审初步工作范围 建议书计划编制团队与客户一起评审初步工作范围。团队与客户评审项目需求和客户期望值并就此问题取得一致意见。 1.3.1.4

任务2.1.4 制定详细工作范围 建议书计划编制团队评审初步工作范围，整合附加详细情况，并开发出最终的详细工作范围。这个文件由下列文件组成：项目可交付物清单，高水平进度表，高水平的启动项目计划，任务和责任矩阵以及机会风险分析核检清单。团队必须确保工作范围内被提议的技术解决方案满足客户明确表示的要求，并清晰陈述，满足对客户要求的解释和澄清。一旦制定下来评审详细工作范围并由客户同意。这个过程可能是不断重复的，在工作范围最后确定之前需要几次会议。 2.1.3 评审初 步工作 范围 构建详 细工作 与客户一 起评审详 作范围细 工 最后确定 详细工作 2.2.1

团队与客户一起评审详细工作范围，以确保所提议的解决方案满足客户的全部需求 任务2.1.4过程步骤 过程步骤 过程描述 功能参考 评审初步工作范围 建议书计划编制团队评审初步工作范围以确保在进行详细工作范围的制定时所有必需的资料可以获得。如果有必要的话，向 咨询寻求帮助。必须号召评审办公室评审客户的条款和情形。 1.3.2.1 工具1-5 工作范围核检清单 构建详细工作范围 建议书计划编制团队制定详细工作范围，其中含有范围的叙述性定义、可交付物清单、高水平的项目进度表、高水平的启动项目计划、范围以外的特定术语清单以及风险机会分析核检清单。 1.3.2.2 与客户一起评审详细工作范围 团队与客户一起评审详细工作范围，以确保所提议的解决方案满足客户的全部需求 1.3.2.3 最后确定详细工作范围 当建议书计划编制团队与客户就工作范围的内容达成一致时，工作范围就最后确定了。最终工作范围不仅要将要交付的东西而且要将不交付的东西表述清楚。在这一点上为项目设定固定参数将有助于避免日后在实施过程中混淆。 1.3.2.4

活动2.2 制定启动项目计划 建议书计划编制团队在项目经理的领导下制定启动项目计划。这项计划包含帮助项目经理和项目团队成功部署解决方案的必需元素，解决方案应站在客户的立场考虑进度、预算和必需的功能。计划包含工作分解结构（WBS），考虑依存关系和约束条件的详细进度表，成本和资源估算，详细工作计划，风险和机会管理计划以及必需的支持计划（它会根据项目变化）。启动项目计划的详细程度和范围广度与项目的类型、大小、复杂程度以及工期成正比。完成这项活动或许需要额外的专家或subject matter expert。 2.1.3 2.2.1 制定工 作分解 结构 2.2.2 制定成 本估算 2.2.4 制定资 源估算 2.2.3 制定项 目进度 2.2.5 目支持 计划 2.2.7 评审并编辑 启动项目计 划 2.3.1 2.2.6 制定风险和 机会管理计

任务2.2.1 制定工作分解结构（WBS） 建议书计划编制团队利用工业自动化和控制（IAC）工作分解结构辞典，制定工作分解结构。团队评审详细工作范围并识别将提议的解决方案传递给客户所需的工作。识别工作时工作与标准工业自动化和控制（IAC）辞典匹配，除了为即将实施的工作制定工作分解结构外，团队还要制定跟踪、管理和控制项目的工作分解结构，工作分解结构应制订到工作包层次。 2.1.3 创建到工作包程 度的工作分解结 构 评审工作 分解结构 最后确定 工作分解 结构 2.2.4

建议书计划编制团队与职能机构共同评审工作分解结构。团队负责工作实施而且，如果适当的话对客户负责。 任务2.2.1过程步骤 过程步骤 过程描述 功能参考 创建到工作包程度的工作分解结构 建议书计划编制团队应用工业自动化和控制（IAC）工作分解结构辞典，将工作分解结构制定到工作包层次。此外，团队还要制定进行项目成本控制所需任务的工作分解结构。 1.4.1 1.4.2 1.4.3 1.4.4 评审工作分解结构 建议书计划编制团队与职能机构共同评审工作分解结构。团队负责工作实施而且，如果适当的话对客户负责。 最后确定工作分解结构 建议书计划编制团队最后确定工作分解结构。因为在标准的H企业工业自动化和控制（IAC）工作分解结构中没有定义条款，团队创立了一个工作分解结构辞典，其中包含了工作包的详细信息，包括将要实施的工作的描述、可交付物、必需的投入以及约束条件，如果有的话。

任务2.2.2 制定成本估算 成本评估师制定项目详细成本估算。这项估算不仅包括人力资源，而且包括完成项目所需的其他资源（例如：设备、分包商、法律或许可费、特许权、咨询顾问以及材料）。用于估算项目成本的主要工具包括：详细工作分解结构、资源价格和工作范围。如果分包商、联盟者或咨询公司参与进来，他们必须提供报价，表明他们服务的成本。成本估算还包括识别和考虑多种备选成本方案，因此，成本估算与进度和资源估算同时进行，这样就可以评估备选方案对进度和资源的影响。 2.2.1 制定到工 作包层次 的成本估 算 将成本估 算与进度 估算和资 源估算对 比 实施计划 编制团队 评审成本 最后确 定成本 估算

任务2.2.2过程步骤 过程步骤 过程描述 功能参考 制定到工作包层次的成本估算 在建议书计划编制团队的支持下，成本估算师决定与每个工作包有联系的成本（例如：人工、材料和分包商成本）。 2.6.1 工具2-1 项目估算核检清单 工具2-2 估算责任矩阵 将成本估算与进度估算和资源估算对比 由于进度或自愿估算中的假设条件或变更会影响到项目的成本，所以成本估算师必须与制定进度或资源估算的团队成员保持紧密的联系，这种信息在制定成本方案时同样需要。 2.6.1 工具2-2 估算责任矩阵 实施计划编制团队评审成本 建议书计划编制团队评审成本以确保进度和资源估算的影响已经被考虑。 2.6.2 工具2-2 估算责任矩阵 最后确定成本估算 成本估算师通过组合与每个工作包相联系的成本，包含所有其他成本，比如行政成本和项目管理成本。最后确定估算，在建议书和项目预算阶段，最后确定的成本估算为制定销售价格提供基础。 2.6.1 2.6.2

任务2.2.3 制定项目进度 建议书计划编制团队联系成本和资源估算，制定项目进度，以确保在成本和资源估算中影响到进度的假设条件被考虑到了。为制定项目进度，团队定义活动并确定活动的顺序和工期，这项工作的主要输入物是工作分解结构和工作范围。如果可获得的类似任务历史数据可以被证明在确定任务工期时有用，在制定项目进度时也必须考虑约束条件（比如说客户托管的最终期限）。 2.2.1 2.2.5 确定项 目工期 到工作 包水平 确定工作 包从属关 系 将进度 估算与 成本估 算、资 源估算 进行对 比 执行计 划编制 团队对 进度的 评审 最后确定 项目进度

任务2.2.3过程步骤 过程步骤 过程描述 功能参考 确定项目工期到工作包水平 建议书计划编制团队利用工作分解结构和成本估算来定义项目活动（工作包）并估算他们的工期。 2.5.2 工具2-1 项目估算核检清单 工具2-2 估算责任矩阵 确定工作包从属关系 一些工作是相互依赖的，也就是说，一项工作必须等另一项工作包完成之后才能开始，其他工作是分立的，可以在任何时候执行。确定这些关系是很重要的，以便可以在可能的时间同时制定工作包活动计划。 将进度估算与成本估算、资源估算进行对比 建议书计划编制团队应用进度计划应用软件，制定并分析项目进度，与成本和资源估算同时进行，以便在制定进度时将成本和资源估算中的假设条件和变更考虑进去。 执行计划编制团队对进度的评审 团队评审进度，以确保它是可以实现的而且成本和资源估算的影响已经考虑到了 最后确定项目进度 建议书计划编制团队通过将与跟踪、管理和控制项目有关的任务整合，最后确定进度。

任务2.2.4 制定资源估算 在项目经理的领导下，建议书计划编制团队估算实施项目所需资源的数目和类型。团队根据历史数据或subject matter expert的输入，估算每个工作包必需的投入和技能。在估算必需的资源时，团队考虑任务是资源驱动型还是工期驱动型的，制定资源计划是一个反复的过程，并且与进度、成本估算同时进行。

任务2.2.4过程步骤 过程步骤 过程描述 功能参考 制定到工作包水平的资源估算 来自可靠的职能组织的 确定每个工作包所需的资源数目和技能。工作包被鉴别为资源或工期驱动型。 2.4.1 2.4.2 工具2-1 项目估算核检清单 工具2-2 估算责任矩阵 将资源估算与成本、进度估算进行比较 建议书计划编制团队将资源估算与进度和成本估算相比较，以确保他们一致，在进度或成本估算中所做的任何假定条件或变更都有可能对所用资源的数目或类型有影响。 执行计划编制团队对资源的评审 团队评审资源估算以确保它们与工期或成本估算同步。 最后确定资源估算 建议书计划编制团队通过为所有工作包编制所需资源的数目和类型（根据工作编码和必需的技能）清单，最后确定资源估算。这个清单包含在资源计划之内。

任务2.2.5 制定项目支持计划 在负责任的职能部门的支持下，建议书计划编制团队制定成功开发测试所必需的支持计划，并且部署站在客户立场的解决办法提案。支持计划的数目、类型与项目的类型、大小、复杂程度及工期成正比。建议书计划编制团队在项目经理的支持下，识别项目支持计划需求。 2.2.2 2.2.3 2.2.4 制定沟通 计划 制定质量 管理计划 制定采购 制定特殊 项目计划 制定工程 制定建设 制定变更 制定文档 化计划 2.2.6 识别计划 需求 制定资源 制定动员 制定安全

任务2.2.5过程步骤1 过程步骤 过程描述 功能参考 识别计划需求 项目经理和建议书计划编制团队识别项目所需的计划，以及计划的范围和详细程度。 1.6 工具1-3 范围调查报告 工具1-4 客户接收标准 工具1-5 工作范围核检清单 工具8-1 商业案例 制定资源计划 建议书计划编制团队制定资源计划，资源计划包括项目实施所需的人力和其他资源（例如：资金、软件、计算机时间、供应和咨询服务）。资源计划描述了所需资源的类型，为什么、什么时间需要，谁负责提供，需要花费多少钱。 工具3-1 资源责任矩阵 工具3-2 项目资源计划覆盖清单 工具3-3 项目人力资源计划工作表 制定动员计划 如果必需的话，建议书计划编制团队制定动员计划来部署解决方案。计划描述了所需设备及其他需求（比如：拖车、能源、电话、水资源、沟通设备和保险）。 工具3-9 项目动员计划核检清单 制定安全计划 如果必需的话，在建议书计划编制团队的支持下，由安全经理魏项目制定安全计划。计划是基于H企业的健康和安全程序以及实际指南的，必须服从于项目所在国的法律，而且必须包括所有客户的特殊安全需求 制定工程计划 项目经理会制定工程计划。计划描述了工程和设计工作将如何，以及在哪里实施，如何评审，以及将会交付给客户什么。 工具1-9 工程计划核检清单 制定建设计划 如果必需的话，项目经理或建设经理会制定建设计划。计划会站在客户的立场，描述建设和拆除工作如何实施。如果必需的话，计划包括建设进度表；建设可行性分析；所需材料的描述；适当的工作规范以及危险材料的处理程序。 工具1-10 建设计划核检清单

项目经理，在合适的专家的支持下（如果有的话），制定在计划需求文件中明确的支持计划。 任务2.2.5过程步骤2 过程步骤 过程描述 功能参考 制定变更管理计划 项目经理负责制定和管理变更控制程序。通过这个程序，可以识别、文档化并且处理项目变更。变更管理计划描述了变更通知单的过程流，包括影响评估以及评审和批准程序（变更通知单可以由客户或H企业提出）。变更通知单可以影响成本、进度、质量、范围或者其中的组合。 1.6 工具10-1 变更管理计划制定核检清单 工具10-2 变更管理计划模板 制定文档化计划 项目经理制定文档化计划，计划中限定了所需的文档，并且确定了哪些只应用于内部，哪些可以与客户分享。这项计划也包括ISO9000惯例中规定的地方性工作文件存档政策。 工具9-6 文档化计划制定核检清单 工具9-4 沟通和文档化矩阵 制定沟通计划 项目经理与建议书计划编制团队一起，制定沟通计划。沟通计划明确了团队内部，团队与客户、与H企业管理层如何沟通。计划还描述了状况报告以及其它的必需的沟通频率和媒介（电子的或纸质的）。 制定质量管理计划 建议书计划编制团队制定质量管理计划，计划控制项目生命周期中的几个关键因素以确保项目实施中每一步的质量。计划由一些与质量问题有关的明确的目标合并而成，例如：返工百分比，客户满意度以及对ISO9000的忠诚度。计划还包括审核程序，客户接受测试程序以及确定的接受标准。 工具6-1 质量管理计划核检清单 工具6-2 项目完工标准表格 工具6-3 质量控制计划实例 制定采购计划 如果必需的话，项目经理在采购部门的支持下制定采购计划。计划明确了项目所需的供应商采购、分包商和顾问支持，描述了这些参与者的作用、支付条款和参与进度表。如果还没有确定参与者，计划要描述确定他们的过程，包括选择供应商，制定采购设备、供给和原料的采购订单，解除RFQ，评审报价，授予分包合同，决定特殊需求和获得咨询服务。 工具3-8 项目材料登记表 制定特殊项目计划 项目经理，在合适的专家的支持下（如果有的话），制定在计划需求文件中明确的支持计划。

任务2.2.6 制定风险和机会管理计划 建议书计划编制团队根据概念阶段制定的初始风险和机会管理计划，制定完整的风险和机会管理计划。团队对最初识别的风险和机会执行风险机会评估程序，同样，也在制定初始项目计划时对识别出的新的风险和机会执行评估程序。团队成员根据风险发身的可能性和一旦发生他们造成的影响对风险进行评估。对于有高的可能性发生或影响严重的风险，他们制定风险减轻战略。因为新发现的风险和机会可能会以额外的收入或成本节约的形式出现，所以团队也制定机会最优化战略。风险和机会管理计划用文件证明了贯穿于项目生命周期的被用来管理风险和机会的程序。项目经理要确保风险和机会管理计划保持最新水平以反映项目状况中的变更或识别新的风险和机会。 2.2.5 评审初始 风险和机 会管理办 法 识别并评 估新的风 险和机会 更新风 险减轻 和机会 最优化 战略 制定风险 和计划管 理计划 2.2.7 1.2.3

任务2.2.6过程步骤 过程步骤 过程描述 功能参考 评审初始风险和机会管理办法 建议书计划编制团队评审在概念阶段制定的初始风险和机会管理计划，目的是看是否有新的风险和机会需求，更新初始风险和机会评估。 5.2 工具5-2 风险和机会评估模型（ROMA） 识别并评估新的风险和机会 在进行进度、成本和资源评估时，可能会出现新的风险和机会，建议书计划编制团队识别并评估技术方面和其他方面（进度、财务和法律，比如）新的风险和机会，内部的和外部的。团队根据风险和机会发生的可能性和它们的影响，对其进行识别、分析和优先排序，如果一项风险蕴含有相应的机会，他们评估实际的影响。 5.3.1 5.3.2 5.3.3 5.4.1 5.4.2 5.4.3 5.4.4 更新风险减轻和机会最优化战略 建议书计划编制团队制定风险减轻计划或突发事件计划，以便如果风险发生了，他们可以执行战略使得影响最小化。他们也制定机会最优化战略。 5.5.1 5.5.2 5.5.3 制定风险和计划管理计划 建议书计划编制团队通过整合风险和机会评估以及减轻和最优化战略，制定风险和机会管理计划。这项计划是个动态的文件，它必须在项目生命周期里保持最新水平。 5.5.4

任务2.2.7 评审并编制初始项目计划 建议书计划编制团队对计划和准备好贯穿这项活动的文件进行评审，并且将它们整合进初始项目计划。整合的项目计划包含了执行客户项目所必需的所有信息。计划包含导言，工作范围，详细的进度表，工作分解结构，资源计划，工程计划，变更管理计划，沟通计划，质量管理计划，风险和机会管理计划以及所必需的其他特殊计划。建议书计划编制团队与技术评审团队（一群高级技术专家）一起，评审初始项目计划。如果技术评审团队发现解决方案可行，与客户工作范围吻合，那就证明计划是可实施的。 2.2.6 制定初始 项目计划 导言元素 成本、进 度和资源 组成部分 执行初 始项目 计划技 术评审 最终确定 初始项目 计划 2.3.2 整合项目 支持计划

任务2.2.7过程步骤 过程步骤 过程描述 功能参考 制定初始项目计划导言元素 建议书计划编制团队为计划制定一个导言。导言概括了计划的目的，明确需要读计划的人员，描述计划更新的办法，定义客户并且讨论项目范围。 1.5.1 工具1-1 项目组织和计划编制核检清单 成本、进度和资源组成部分 团队将成本、进度和资源估算整合到处是项目计划里。 整合项目支持计划 建议书计划编制团队将事先制订好的、实施项目所必需的支持计划整合到计划里。 执行初始项目计划技术评审 项目经理将初始项目计划呈送给技术评审团队，征求他们的评审和批准。如果技术评审团队发现项目技术上可行且满足客户的需求，他们就会批准计划。 1.5.2 工具1-7 项目计划技术评审 最终确定初始项目计划 项目经理最终确定计划并且将它分发给所有参与项目的各方，包括负责传递服务或产品管理的职能组织和其它项目相关利益主体。项目经理将获得项目服务管理层对整个项目计划的批准，而且也要求获得项目服务工程管理层对细微的工程计划的批准。

活动2.3 生成项目建议书 项目经理与建议书计划编制团队、销售账目经理、建议书小组一起，制定客户建议书。建议书明确了客户需求以及H企业为满足这些需求而提议的解决方案。建议书所包含的细节将根据H企业与客户的关系而定。 建议书包含商务元素，包括价格和其它合同条件，初始项目计划和符合规范的技术。建议书应该被当作销售工具看待，它必须包含所有必需的关于价格、T&C和技术解决方案的信息。这些信息是客户选择H企业而不选择竞争对手所必需的。 2.2 2.4 2.3.1 制定建议 书商务元 素 2.3.2 设立建议书 2.3.3 最终确定并 提交建议书

任务2.3.1 制定建议书商务元素 建议书计划编制团队，在通用指导办公室的支持下，制定建议书的商务元素。建议书的这一部分包含所有的财务和合同信息。 2.2.2 评审项目 成本 识别资源 评审范围 和条件 确定可 接受的 边际 确定建议 销售价格 2.3.2 确定商业 发票进度 表

任务2.3.1过程步骤 过程步骤 过程描述 功能参考 评审项目成本 成本估算师带领建议书计划编制团队评审与项目有关的所有成本。这项评审的实施是为了确保在事先的成本估算中不遗漏任何东西。 8.3.2.4 2.6.2 工具1-8 合同评审核检清单 确定可接受的边际 区域项目管理团队接下来制定H企业指南，确定不同的项目类型可接受的边际。 8.3.2.4 2.6.2 确定建议销售价格 财务经理、项目经理和顾问/解决方案经理确定一个建议销售价格。销售价格反映了很多因素，例如：必需的边际利润，关系机会的重要战略，与客户和竞争对手的商业关系。 2.6.2 8.3.2.4 识别资源评审范围和条件 财务经理和项目经理，在通用指导办公室合同部的支持下，评审在客户RFQ中定义的T&C，以确保它们与H企业的通用条款和条件一致。 8.3.2 确定商业发票进度表 项目经理制定商业发票进度表。尽管在很多案例中，这个进度表是基于建立好的里程碑的，但是它也可以基于完工百分比或其他相互同意的标准。

任务2.3.2 生成建议书 项目经理和建议书计划编制团队，与财务经理一起，设立客户建议书。项目经理确定建议书成果时间，收集至今文件，从财务经理那里获得实施概要，并且将这些信息编纂，生成专业的建议书。 2.3.1 确定建 议书成 果时间 制定建 议书实 施概要 整合商 务元素 生成初 步的建 议书 2.3.3 2.2.7 确定并 整合符 合规范 的技术 整合初 始项目 计划

任务2.3.2过程步骤 过程步骤 过程描述 功能参考 确定建议书成果时间 项目经理确定客户建议书成果生成时间。 8.3.2 制定建议书实施概要 财务经理制定一个实施概要。这个实施概要是对客户需求和H企业对这些需求的解决方案的高水平的总的看法。就像第一部分一样，这个概要是要整合进建议书里。 整合初始项目计划 项目经理将事先制定好的初始项目计划整合进建议书里。 整合商务元素 项目经理将事先制定好的商务元素整合进建议书里。这些元素包含所有的财务和合同信息。 8.3.2 工具1-8 合同评审核检清单 确定并整合符合规范的技术 建议书计划编制团队，在必需的专家的支持下，基于工作范围，确定符合客户规范的技术。项目经理将符合的技术整合进建议书里。 工具1-5 工作范围核检清单 生成初步的建议书 项目经理编纂收集的信息并生成初步建议书。

任务2.3.3 最后确定并提交建议书 项目经理确定管理层评审初步建议书的时间。评审的目的是为了获得管理层的批准进一步将建议书提交给客户。合适的管理层评审建议书以确保建议书支持工业自动化和控制（IAC）的目标和战略方向，而不是将H企业置于无保险的风险之中，确保它是值得追求的可盈利的业务而且是可行的。如果需要做一些修改，项目经理和财务经理修改建议书并再次将建议书提交给管理层。 2.3.2 安排管 理层评 审 实施管 最后确 定建议 书 提交建 议书 2.4.1 获得管 理层批 准签章

任务2.3.3过程步骤 过程步骤 过程描述 功能参考 安排管理层评审 项目经理确定由合适的管理层评审初步建议书的日期和地点 8.3.2 实施管理层评审 项目经理和财务经理将初步建议书提交给管理团队评审和批复。 最后确定建议书 项目经理、财务经理和建议书计划编制团队将管理团队提出的需做的修改整合到最终的建议书里。 获得管理层批准签章 项目经理和财务经理将最后确定的建议书提交给合适的管理层批准签章。 提交建议书 财务经理将最终建议书提交给客户。

活动2.4 签订合同或协议 财务经理和项目经理与客户一起评审建议书以确保所提议的解决方案满足客户的需求。在一些情况下客户会要求对建议书做一些修改，这样就可能有必要就某些建议书元素进行磋商。在这种情况下需确定一个谈判团队来磋商双方满意的合同。谈判团队可能包括区域管理层。授予前谈判或许包括关于H企业对客户的商务和技术需求的反应或者是对H企业通用条款和条件的修改。如果是后一种情况的话，通用知道办公室的合同部有必要参与进来，因为关于T&C事务的最终决定取决于他们。谈判完成并且建议书修改之后，在提交客户之前，重新由合适的管理层评审以寻求批准（如果必需的话）。 2.3 2.4.1 参与客户建 议书评审 2.4.2 合同或协议 谈判 2.5 2.4.3 准备项目 登记

任务2.4.1 参与客户建议书评审 财务经理和项目经理（如果需要的话）将建议书提交给客户，评审客户需求和H企业为满足这些需求而提议的解决方案，并且，对客户的质疑和关注给予答复。财务经理在谈判过程中起领导作用。如果有的关注问题不能在会上给予答复，这些问题要文档化，带回办公室以便以后答复。 2.3.3 召开建议书 讨论会议 对建议书的问题 准备并提交答复 2.4.2

任务2.4.1过程步骤 过程步骤 过程描述 功能参考 召开建议书讨论会议 财务经理和项目经理（如果需要的话）将建议书呈报给客户并详细地讨论提议的解决方案如何满足客户的需求。他们也对客户的问题和关注做出答复。财务经理将会在会上不能解决的关注或问题形成文件，带回办公室做进一步分析。 8.3.3 对建议书的问题准备并提交答复 在合适的 地支持下，财务经理和项目经理评审客户关于建议书的问题并准备答复。财务经理尽可能快的给客户提供答复。

任务2.4.2 合同或协议谈判 在很多情况下，在客户签署合同或协议之前需要客户和H企业就建议书进行多次谈判，而且，在有些情况下，需要区域管理层的参与。财务经理确定一支谈判团队并要求他们与客户就合同或协议进行谈判。如果谈判涉及H企业通用条款或条件，则通用指导办公室的合同部参与谈判。成功的谈判之后，修改的建议书在提交给客户之前应再次提交给管理团队评审并批准。 2.4.1 进行 谈判 确定并 授权谈 判团队 修改建 议书 获得管理 层对修改 的建议书 的批准 2.3.2 为合同 谈判做 准备 提交修 改的建

任务2.4.2过程步骤 过程步骤 过程描述 功能参考 确定并授权谈判团队 财务经理确定合适的谈判团队并要求他们与客户就合同进行谈判。 8.3.3 工具8-3 谈判授权计划 为合同谈判做准备 财务经理和项目经理将客户提出的问题和关注简要地告知谈判团队，谈判团队准备答复。 进行谈判 谈判团队与客户碰面进行谈判。在一些情况下，由于会出现新的问题或关注，在这个过程中可能需要很多次会议。当所有的问题或关注都解决的时候，谈判成功完成。 8.3.3 工具8-3 谈判授权计划 修改建议书 财务经理和项目经理将修改的建议书提交给客户之前首先报呈管理团队 。 获得管理层对修改的建议书的批准 财务经理将批准的修改过的建议书提交给客户。 提交修改的建议书

任务2.4.3 准备项目登记 获得客户签署的合同时，财务经理通知建议书计划编制团队和管理层。项目经理和销售人员/评估人员准备接收订但所必需的文件。项目管理者从销售人员/评估人员那里获得包括协议概要的登记包。工作包当时盖有合适的签章。获得所有的签章之后，为项目经理、财务和项目控制部门提供复印件。将登记包原件送到通用指导办公室的合同部，合同部有最终的权利，决定接受或拒绝合同以及客户采购订单。合同部评审登记包，如果满意的话，则登记并作为基线，一旦项目在oracle作基线，项目经理就被授权实施项目。 2.4.1 获取签 署的合 同或协 议 登记合同 通知管 理层和 计划编 制团队 准备 登记 包 2.5.1 返还签 同工作 工作授 权 将登记 包提交 给合同 管理部

任务2.4.3过程步骤 过程步骤 过程描述 功能参考 获取签署的合同或协议 财务经理获得客户签署的附有采购订单的合同。 8.3.4.1 通知管理层和计划编制团队 财务经理通知建议书计划编制团队、管理层和其他项目利益相关者。 准备登记包 项目经理和成本估算人员/销售人员准备接受定单所需的文件。 将登记包提交给合同管理部 项目管理者从销售人员/评估人员处获得登记包。获得所有的签章之后，为项目经理、财务和项目控制部门提供复印件，登记包原件被送往通用指导办公室的合同部以登记定单。合同部评审合同和采购定单，以确保它们符合H企业的通用条款和条件。 登记合同 合同部登记定单并将其作为基线。 返还签署的合同工作工作授权 项目经理此时被授权实施项目。

活动2.5 获得并分配项目资源 一旦合同签署，定单备案，项目经理召集制定、测试和部署解决方案所必需的项目团队。项目经理负责确定实施项目所需的资源并且从H企业内部或其他地方获得资源。资源包括人力和其他资源，比如：设备，设施，材料（内部采购或从外部供应商处获得），软件和分包商。项目经理更新早些时候由建议书计划编制团队所做的资源计划，加入在制定和谈判建议书时新识别的需求。 更新资源 计划 2.6 组成项目 团队 2.7 2.4

任务2.5.1 更新资源计划 应用在客户就建议书制定和谈判过程中收集的新的需求信息，项目经理更新资源计划以反映当前需求。他或她站在客户的立场识别制定、测试和部署提议的解决方案所需的资源。这些资源包括：人工、材料、设备、设施、分包商、咨询、供应商和软件。 2.7.1 2.4.3 评审材 料需求 评审设 施需求 确定项 目组织 评审人 员需求 评审责 任矩阵 2.6.1 识别项目相 关利益主体

任务2.5.1过程步骤 过程步骤 过程描述 功能参考 确定项目组织 在建议书计划编制团队的帮助下，项目经理根据详细的项目需求，确定项目组织结构。他或她确定负责提供产品或服务，分包商，供应商，顾问和其他资源的组织。项目经理也确定客户接口。 3.4.1 评审人员需求 项目经理根据批准的建议书、签署的合同以及CWA，修改初始的人员需求。他或她也识别完成工作包所必需的人员数量和技能。 3.2.2 工具3-1 资源责任矩阵 工具3-3 项目人员计划工作表 评审责任矩阵 项目经理修改初始责任矩阵。初识责任矩阵只包括建议书计划编制团队，现要将实施项目所需的新的项目成员和任务包括进去。 3.2.3 评审材料需求 项目经理更新资源计划中材料需求部分，加入与客户进行建议书谈判以及签署合同时确定的新的需求。 工具3-8 项目资源登记表 评审设施需求 项目经理可能必须得根据客户所接受的最终建议书修改资源计划中的设施需求部分。 工具3-6 项目设施记录 识别项目相关利益主体 项目经理识别关键的项目利益相关主体，不仅在H企业内部，而且在客户组织内部识别项目利益相关主体可以对项目经理获得所需的资源提供支持。 7.2

3.1 实施阶段 活动3.1 管理项目绩效 • 任务3.1.1 测量并监控项目绩效 • 任务3.1.2 管理与需求的一致 3.1 实施阶段 活动3.1 管理项目绩效 • 任务3.1.1 测量并监控项目绩效 • 任务3.1.2 管理与需求的一致 • 任务3.1.3 执行中期验收 活动3.2 项目控制 • 任务3.2.1 项目管理信息系统的维护 • 任务3.2.2 管理项目变更控制 • 任务3.2.3 准备项目报告书 • 任务3.2.4 召开项目会议 活动3.3管理客户需求 • 任务3.3.1 监督合同的执行情况 • 任务3.3.2监控发货及付款 • 任务3.3.3 管理客户关系 活动3.4 管理采购 • 任务3.4.1 管理采购 • 任务3.4.2监控转包合同履行 • 任务3.4.3监控转包合同发货及支付 活动3.5 管理风险和机会 • 任务3.5.1 监督和缩减项目风险并最 大化项目机会 • 任务3.5.2 重新评估项目风险与机会 活动3.6 管理项目变更 • 任务3.6.1 管理成本变更

3.1 实施阶段 在项目管理生命周期的实施阶段，实施制定、测试和部署解决方案这些实际工作。所有在计划阶段生成的计划在这一行实行。项目团队根据基线项目计划实施技术和管理活动。运用工作分解结构，进度表和其他项目计划元素，团队工作以获得项目里程碑并满足客户和H企业的目标。 项目经理整合项目团队活动并处理项目变更或基线项目计划的偏差。除了跟踪、监控和报告项目状况外，他或她控制项目偏差，采取纠正行动。如果有必要的话，使项目回到进度、范围和预算范围之内。 这阶段的许多项目管理活动是平行进行而不是顺序进行的。通常这些活动承担监控和控制的职能，所以贯穿整个实施阶段。

3.1 实施阶段 4.1 2.7 3.2 控制项 目 3.4 管理流 程 3.6 管理项目 偏差 3.1 管理项 目绩效 3.3 管理客 3.1 实施阶段 4.1 2.7 3.2 控制项 目 3.4 管理流 程 3.6 管理项目 偏差 3.1 管理项 目绩效 3.3 管理客 户需求 3.5 管理风险 和机会 3.7 实施最终测 试和接受

活动3.1 管理项目绩效 管理项目绩效是项目经理的主要任务之一，它是通过与项目团队成员经常性地接口，周期性项目审计和就项目状况进行交流获得的。项目经理负责确保合同中所描述的项目过程中的技术绩效和项目计划，并且支持文档。在项目团队的支持下，他或她按照项目计划监控并管理项目绩效。测量技术过程并与基线比较。识别偏差并纠正。实施质量控制以确保与客户规范和ISO9000一致。此外，进行中期客户接收测试以确保按期完成的产品达到客户的期望值，减少返工。任何与基线之间的偏差，在过程中识别、评审、报告并采取行动来纠正不足，这个过程的执行贯穿实施阶段。 北美项目运营——当地实践办法 Oracle公司的项目重建基线——这符合Oracle公司为变更产品成本已建立的基线水平而建行的项目“重新登记”。项目运营的V.P.优先于Oracle公司任何必需的项目成本变更来评审并批准所有项目重建基线的类似需求。只有材料对最终工作成本的影响超过5%时，重建基线的要求才会被评审和/或批准。关于少于5%的产品线本影响的重建基线的要求，应该被认为是在初始评估的精确度之内，不允许重建基线。

活动3.1 管理项目绩效 2.7 管理与需求 的一致性 测量并监控 项目绩效 进行中期接 受测试 3.7

任务3.1.1 测量并监控项目绩效 测量并监控项目绩效是项目管理跟踪、控制功能的一部分。测量并评估项目技术绩效，采取贯穿于项目实施整个过程的纠正措施。项目经理评审从项目管理信息系统得来的项目信息，决定是否需要采取纠正措施使项目回到正轨。在这个过程中，可能识别出项目变更需求，而且内部变更请求可能会发生。项目经理也识别绩效问题，包括员工、分包商和设备，权宜之计是应该在变得难管理之前处理这些。 2.7.4 实施基 线项目 计划 识别变 更请求 的需要 测量技 术过程 解决项 目绩效 问题 3.7.1 评估项 结果

任务3.1.1过程步骤 过程步骤 过程描述 功能参考 实施基线项目计划 项目经理实施在计划编制阶段制定的基线项目计划，他或她把计划告知给负责实施具体项目任务或负责交付产品或服务的团体或个人。项目经理也与团队一起，评审责任矩阵，以确保每个人都清楚他或她的责任。 1.7 工具1-11 项目更新日志 工具4-1 项目跟踪、控制核检清单 测量技术过程 项目经理通过评审项目管理信息系统的数据和职能部门关于已完成工作包或过程的状态报告，确定技术过程。 4.5.1 工具4-1 项目跟踪、控制核检清单 工具4-2 月度进程报告 工具4-5 每周进程报告 工具4-6 客户项目状态报告 工具4-3 每周跟踪 工具4-4 月度跟踪、控制核检清单 工具9-4 沟通和文档化矩阵 识别变更请求的需要 在测量并评估技术绩效的过程中，项目经理或团队成员，都有可能识别出提高绩效的变更需要（关于发展进程或设备，比如）。如果合适的话，形成变更请求。 10.4.1 10.4.2 工具10-4 变更请求和评估格式 评估项目绩效结果 项目经理将技术过程与基线数据进行比较，识别出偏差。 4.6.2 解决项目绩效问题 如果与项目技术绩效有关的问题被识别出来（例如，技能、生产率或其他绩效问题），项目经理确定并检查从事他们的纠正方案。 4.7.3

任务3.1.2 管理与需求的一致性 任何项目的目标都是要使客户满意并带给H企业良好的财务收入。这个目标可以通过管理与客户需求的一致性，或从本质上来说，管理质量来实现。因为质量很大程度上是由客户定义的。项目经理最重要的目的就是确保客户需求被满足。从而，质量可以被定义为与相互同意的客户说明书的一致性。项目团队实施质量管理计划，包括质量控制、质量保障而且在适当的地方与当地ISO9000惯例保持一致。周期性进行项目质量评审和审计，确定纠正方案并实施。 2.7.4 实施质 量管理 计划 识别质 量差异 进行质 量评审 定义并实施 质量改进措 施 3.7.1

工具6-1 质量管理核检清单 工具6-3 质量控制计划实例 任务3.1.2过程步骤 过程步骤 过程描述 功能参考 实施质量管理计划 项目经理将质量评审和审计合并进项目进度表中以确保它们被实施，通过这样来实施质量计划。在实施质量计划过程中，质量经理要协助项目经理。 6.3.1 6.3.2 工具6-1 质量管理核检清单 工具6-3 质量控制计划实例 进行质量评审 项目经理确保贯穿整个实施阶段的质量评审和审计的实施，按照进度表，由项目涉及到的所有组织实施，包括分包商和vendor。 6.4 工具6-2 项目完工标准格式 识别质量差异 如何在评审和审计过程中检查出质量偏差，项目经理要确保文档化并报告。 6.5 工具6-3 质量控制计划实例 定义并实施质量改进措施 在识别质量问题或偏差时，项目经理，在质量经理和项目团队的协助下，确定纠正问题最合适的行动。 6.4 6.5

任务3.1.3 执行中期验收 在客户解决方案的制定过程中，或许有必要测试解决方案的一部分。质量管理计划将测试程序文档化，用来确保技术与项目可交付物以及客户评审和接收测试结果的过程保持一致。 测试实施由工厂接收测试（FATs）和场地接收测试组成。实施的工厂接收测试和场地接收测试都是在基线项目计划中指定的。 项目经理负责确保测试即时实施，根据进度表和质量管理计划中明确的标准。他或她也负责确保客户即时评审测试结果，以便H企业可以关闭相关的里程碑。如果测试没有按照指定的客户接收标准实施，纠正问题并重新进行测试。 2.7.4 制定中期 测试程序 评审中期 测试结果 进行中 期测试 实施改 进措施 3.7.1

任务3.1.3过程步骤 过程步骤 过程描述 功能参考 制定中期测试程序 项目团队根据在基线项目计划中指定好的标准，制定测试项目的测试程序。测试程序必须经客户评审并批准。如果有必要的话，接下来制定测试进度计划并通知客户。 6.6.1 工具6-4 客户接收日志 进行中期测试 项目经理确保测试按照基线项目计划中指定的测试和接收程序进行。 评审中期测试结果 如果必需的话，项目经理和客户评审测试结果，以确保符合已建立的标准，或者是为了识别问题。 实施改进措施 项目经理根据对测试结果的评审来实施纠正措施。问题解决之后，测试重新进行，重新评估结果。

活动3.2 项目控制 控制项目，包括跟踪、监控和控制职能，是项目经理成功实施客户解决方案的最关键任务之一。项目经理维持并更新项目管理信息系统，项目管理信息系统是监控和控制项目实施的必需品。他或她也管理变更控制过程以确保所有变更申请单对项目范围、成本和进度的影响被正确的评估；准备并将项目状态报告提交给团队、客户和H企业管理层；并举行周期性项目状态会议。 这个过程的实施贯穿于实施阶段。 2.7 准备项目 报告 维持 PMIS 召开项 目会议 3.7 管理项目 变更控制

任务3.2.1 项目管理信息系统的维护 对项目管理者成功地监督，控制并报告关于项目实施的情况来说，一个有效的修订过的PMIS是至关重要的。PMIS能使项目管理者从项目团队中搜集实施的数据并且以某种方式使其固定化，这种方式对项目团队和外部的投资者是有意义的 PMIS在实施阶段要必须不断地更新。 2.7.4 更新项目情 况报告文件 更新项目时间 与成本文件 更新通信文 件 更新跟踪日 志 3.2.3

任务3.2.1过程步骤 过程步骤 过程描述 功能参考 更新项目情况报告文件 项目管理者根据最新的信息修订情况报告文件，这一信息反应出进度、检测及对客户解答的进展情况，新的风险和机会将随着发展反应出来 4.4 更新时间与成本数据文件 项目管理者对时间和成本的修订正如接受项目的期限和类型指令一样频繁。对短期项目每周都需要修订，对长期项目每两周修订一次比较合适。修订的频率应该建立在项目的初期，并与项目进展计划相结合 更新通信文件 项目管理者或是项目监管者修订通信文件，结合发生在项目管理者与团队、客户、工作组织及H企业管理之间的所有通信。这一文件也应包括会议备忘录部分 更新跟踪日志 项目管理者使计划修订日志包括对项目计划的所有修订的信息、支持的计划及相关的文档。

任务3.2.2 管理项目变更控制 项目的实践都会有所变更，不管是技术上，计划进度上或是一些其它因素上。这些变更或者起因于内部的职员或是外部的客户。管理者通过变更清单的请求开展和管理这些变更控制过程，这一请求已被确认、文档化并评估处理过。在变更管理计划中已定义这一正式批准的控制过程。 变更清单请求可能影响范围、进度计划、成本或是一个集成体。项目管理者在接受执行这一请求之前需评估并确定它的影响。基于影响的严重性，可能需要高级管理层的评审和接受。变更管理计划需要一个给定的变更请求来确认接受的明确标准。 这一变更控制过程确保项目文件及合同已被更新以反应这些变更并且预算或进度计划也作相应调整。 2.7.4 制定变更 管理计划 准备变更请 求以识别变 更 评价项目 变更请求 接受项目 修正受影 响的项目 文件 沟通传达 项目变更 3.2.3

任务3.2.2过程步骤 过程步骤 过程描述 功能参考 制定变更管理计划 通过与客户和再项目中所涉及到的内部的组织沟通关于变更空制过程的信息，项目管理者制订变更管理计划。这一信息包括怎样提交一份变更清单请求，这一请求是怎样评估的以及是怎样接受和制订的。 10.3.1 10.3.2 工具10-1变更管理计划核检清单 工具10-2变更管理计划模版 工具10-3变更控制日志 准备变更请求以识别变更 变更请求起因于内部或者客户。项目管理者将这些提交上来的变更请求记入日志。 10.4.1 10.4.2 工具10-4变更请求和评价表单 评价项目变更请求 为作评价项目管理者将变更请求指派给适当的组织或具体科目问题的专家。评估与此请求有关的影响，包括对成本、进度计划及项目的范围。 10.5.1 10.5.2 10.5.310.5.4 工具10-5领域变更清单 接受项目变更请求 项目管理者在设立的整个区域的实践中提供或获得一致性的接受信号。多数情况下客户的接受也是必要的，因为变更请求可能涉及到成本的增加或进度计划的变化。这一接受过程可能需要与客户进行商议。 10.6.1 工具10-4变更请求和评价表单 工具10-5领域变更清单 修正受影响的项目文件 变更请求被接受后，项目管理者要更新受影响的文件（合同、进度计划、预算、工作范围、检测程序等等）。他或她也会将这一变更记录到项目计划更新日志上并修订基准的项目计划。 10.6.2 10.7.1 沟通传达目变更 项目管理者确保变更请求已被接受，项目所涉及的每个组织或个人就能马上认识到这一变更。 10.7.2

任务3.2.3 准备项目报告书 项目报告是项目管理者向团队、客户及管理层沟通传达信息的最好方法。这些报告的形式及内容因受众不同而有所变更（例如，某些信息就不该与客户共享，比如成本或其它内部的机密信息）。文档文件已定义报告的形式、内容及频率。 项目报告的目的就是向项目利益者沟通传达项目的状况及问题。可能需要沟通传达的信息类型包括违背进度计划和客户里程碑的项目进展，现有问题及潜在的风险，与原已取得一致意见的工作范围的误差及管理层要解决的问题。 3.2.1 3.2.2 制定重要 且重复出 现的项目 报告 准备项 目状况 及管理 评审和 分析项 目报告 编辑并 分发报 告和摘 要 3.2.4 对报告 问题实 行跟踪 分析

任务3.2.3过程步骤 过程步骤 过程描述 功能参考 制定重要且重复出现的项目报告 项目管理者制定此项目报告的形式、内容及频率。他或她详细说明数据和方法的来源以得到报告，并为制定报告分派责任。 4.8 工具 4-2每月进展报告 工具4-3 每周跟踪和控制核检清单 工具 4-4每月跟踪和控制核检清单 准备项目现状及管理报告 项目管理者或指定的团队成员制定项目现状报告，利用ORACLE PA的数据或PMIS中的任何资料。 4.8 工具4-2每月进展报告 工具4-5 每周进展报告 工具4-6 对客户的项目现状报告 工具4-3每周跟踪与控制核检清单 工具4-4每月跟踪和控制核检清单 评审并分析项目报告 项目管理者评审和分析制定的报告并与基准的进行比较，找出差异或其它影响项目的问题 4.8 工具4-2每月进展报告 工具4-3每周跟踪与控制核检清单 工具4-4每月跟踪和控制核检清单 编辑和分发报告和摘要 项目管理者编辑并向相应的受众分发报告。这一文件计划详细说明了所需报告的类型。 4.8 对报告问题实行跟踪分析 一些跟踪对测定报告的问题状况是很有必要的。项目管理者与个人或组织进行联系，这些个人和组织对解决问题负责。

任务3.2.4 召开项目会议 项目会议是管理项目很重要的一项内容；但是，会议应该有明确目的。会议可以是事先预定的或没预定，内部的也可以是外部的（意思就是在H企业内部或与客户）。与客户预定的会议是在项目召开会议之前就已确定。内部会议的预定在内部召开会议之前已确定。在关键情况下或是一个至关重要的问题需要解决时项目管理者将召开未经预定的会议。 每个会议都要准备议程并提前分发给参会者，给他们充分的时间去准备讨论的主题。在会议上，讨论活动条款并将其迅速指派给团队人员，这一活动条款由决议指出，有特定时间限制。做备忘录并尽可能快地分发给参会者。 3.2.3 安排设备及 预定参会者 准备并分发会 议议程 开展客户的项 目评审会议 对活动条款 和问题进行 跟踪 编辑和分发 会议备忘录 3.7.1 开展每月内部项 目评审会议评价 项目变更请求

9.9.1 工具9-7现场会议核检清单 工具9-8评审会议 工具9-9 结束会议核检清单 9.9.2 任务3.2.4过程步骤 过程步骤 过程描述 功能参考 安排设备及预定参会者 项目管理者确定会议地点和时间。邀请的参会者将基于会议的内容和范围变化而变化。 9.9.1 工具9-7现场会议核检清单 工具9-8评审会议 工具9-9 结束会议核检清单 9.9.2 准备并分发会议议程 项目管理者在开会之前准备并分发会议议程，确保参会者对议程单上指定的讨论主题有所准备。 9.9.1 9.9.2 开展每月内部项目评审会议 项目管理者担任评审会议的要职，瞄准报告进展，这一进展表述工作包或已完成的里程碑事件及识别障碍或其它问题。每个问题都尽快地追溯到某个活动条款并指派给负责解决它的团队人员。 9.9.3 开展客户的项目评审会议 基于已制定的会议进度表，项目管理者与客户开展会议评审项目现状和问题。没有预定的会议既可以由客户也可以由项目管理者召开，此会议针对影响项目输出结果的不寻常问题。 对会议活动条款和问题进行跟踪 项目管理者对会议上分派的活动条款将进行跟踪。每个活动条款都与一个问题相关联，应该有个预期解决期限。项目管理者负责确保活动条款尽可能适当地得到解决。显示所有会议活动条款的活动条款日志将被保留。 9.9.4 编辑和分发会议备忘录 项目管理者或指定的备忘录制定者编辑会议备忘录并尽快地分发给所有参会者。

活动3.3管理客户需求 项目管理者首要的目标就是使客户满意并为H企业赢得财务的利益。通过对客户的疑问与关注做出及时地反应、开展交流沟通、停止合作与联合作业、有效管理以及对项目问题采取的及时决议，项目团队能达到这一目标。项目管理者开展预定的客户会议，识别客户关注问题，作计划去解决那些被关注的问题并始终使客户明了进展情况。合同的有效管理、包括发货和付款的分派也影响客户的满意度。对客户的疑问、变更请求及关注问题建立快速的时间反馈响应对维持客户的满意度来说是另一个重要策略。 这一活动存在于项目的整个实施过程。

活动3.3 管理客户需求 2.7 3.3.1 监控合同的履 行 3.3.2 监控发货与付 款 3.3.3 管理客户关系 3.7

任务3.3.1 监督合同的执行情况 履行合同的T&C、说明书及进度计划不仅是法律的要求，而且也是项目成功的一关键因素。虽然合同的履行不能保证客户的满意，但是不履行一定引起客户的不满。项目管理者严密地监控项目的可交付物以确保其能按时达到指定工作范围的要求。他或她也会在有效的时间期限内证实客户的关注问题并给予解决。对合同的及时管理及相关的变更也是项目管理者的一项职责。

任务3.3.1过程步骤 过程步骤 过程描述 功能参考 管理客户问题 项目管理者通过会议或其它沟通方式识别客户的关注问题。在问题日志上使用条目来跟踪决议的结论问题。 □8.3.4■工具7-1 管理客户关系核检清单■ 工具 8-5 问题日志 识别和监控项目可交付物 项目管理者识别和监控项目的可交付物以确保其能按时并在客户的要求之内。所有项目的可交付物应在项目的进度计划阶段明确地识别出。 □ 8.3.4 管理合同管理任务 项目管理者要对客户合同的维持和更新负责。一些贯穿于项目整个生命周期的合同将需要作变更。如果有合同的修正或客户变更请求，必须将它们编入初始的合同文件中。项目管理者要确保合同的当前性。 □ 8.3.4■ 工具8-4 合同概要工作表 建立和维护客户委托事项日志 项目管理者建立并维护一项包含客户委托事项的日志（包括对客户关注问题的反应），附有到期日及负责当事人。

任务3.3.2 监控发货及付款 项目管理者确保依据合同的付款期限正确地开发票给客户。因为大多数的发货都是由里程碑事件引起的，项目管理者应要求（Billing Department）在完成一项特殊的里程碑事件之前发出一份发货单。强力推荐将发货请求看作项目进度计划中由特殊里程碑事件引起的任务一样。项目管理者对跟踪发货与付款并解决任何相关的客户关注问题。

任务3.3.2 监控发货及付款 2.7.4 限评审付款 期 监控里程碑事 件及可交付物 发起发货请求 监控发货处理 跟踪客户付 款 任务3.3.2 监控发货及付款 2.7.4 限评审付款 期 监控里程碑事 件及可交付物 发起发货请求 监控发货处理 跟踪客户付 款 3.7.1

任务3.3.2过程步骤 过程步骤 过程描述 功能参考 评审付款期限 依据付款合同的条款需要发货时项目管理者要进行监控。应该将这一信息列入项目进度计划中。由修正或客户变更请求引起的对付款进度计划的变更应与客户一起评审。 □ 8.3.4 监控里程碑事件及可交付物 因为由进度计划引发发货的发生，项目管理者要始终监控里程碑事件及可交付物并相应更新项目进度计划。 发起发货请求 一旦项目管理者向Billing Department发起一项发货请求，那么依据付款及项目进度计划的条款就有一个特殊的里程碑事件完成。在发货之前要通知客户，以确保及时处理。 监控发货处理 项目管理者跟踪Billing Department以确保发货的发生以及包含正确的信息。 跟踪客户付款 项目管理者跟踪客户以确保发货没有问题并且将发货按照指定的合同支付条款部分处理并得到付款。

任务3.3.3 管理客户关系 管理客户关系是项目管理者的重要工作之一。这一任务贯穿于整个项目生命周期，是项目成功的关键。管理客户关系包括了解客户的期望，提供有效的信息，及时解决客户问题及客户关注，有效地利用问题扩展，及时并准确传递现状报告并有效地履行直接影响客户的其它活动。 项目管理者是客户与H企业之间联系的关键，通过决议并从双方利益考虑负责管理每个问题或关注。若某个问题在指定的时间框架内没能得到解决，项目管理者负责将其上交属于H企业或客户的组织内的高级管理者，直到解决问题为止。 为促使对客户满意度问题的识别和讨论，客户满意度调查需分季度地制定，或根据客户的满意度（customer-agreed-to frequency）来制定。

任务3.3.3 管理客户关系 2.7.4 召开客户会议 制定阶段性客 户满意度调查 识别并解决客 户问题 3.7.1 提交进 展报告

任务3.3.3过程步骤 过程步骤 过程描述 功能参考 召开客户会议 项目管理者召开预定的客户会议来评审项目的现状及问题。没预定的会议也可由H企业或客户来召开用以讨论在项目执行中遇到的关键问题。 □ 7.4.2■ 工具 7-1 管理客户关系核检清单 制定阶段性的客户满意度调查 为促使对客户满意度问题的讨论，应制定季度性的客户满意度调查，或根据客户的满意度（customer-agreed-to frequency）来制定 □ 7.4.3■工具 7-2 管理客户关系核检清单■ 质量程序 #143客户满意度 识别并解决客户问题 客户的关注及问题随时都可能出现。因为在起始阶段解决那些问题是较容易的，所以尽可能早地识别那些问题，这是项目管理者的责任 □7.6.1□ 7.6.2■ 工具 8-5 问题日志 提交进展报告 项目管理者必须使客户始终了解项目的现状。不能对客户隐瞒潜在的问题及风险。只有在H企业与客户的相互信任与合作下才能取得项目的最大成功。 □ 7.4.1■ 工具9-4信息与文档矩阵

活动3.4 管理采购 虽然由采购部门通过与卖主、供应商及转包商的联系来买卖材料，但是项目管理者必须参与这一过程。他或她评价和接受获取请求；评价和接受卖主的发货单、供应商及转包商；监控转包合同的履行及可交付物；并评审支付的转包合同条款，跟踪支付给同一方。因为获取请求可由项目中涉及的任何功能性的组织发起，并且因为项目管理者负责项目的预算，他或她能始终控制与项目有关联的所有成本是至关重要的。

活动3.4 管理采购 2.7 3.4.1 管理采购 3.4.2 监控转包合同 的履行 3.4.3 发货及支付 3.7

任务3.4.1 管理采购 为能跟踪和管理与项目有关的成本，项目管理者必须管理采购过程。他或她跟采购部门一起工作以确保任何一项项目所需要的采购请求都要经过他或她的评审与接受。功能性组织发起一项采购请求并将其提交给项目管理者，在进行采购之前项目管理者要评审并接受。由项目管理者发起的采购请求需要他或她的直接监督人的认可。

任务3.4.1 管理采购 2.7.4 评估原料需 求 发起采购请求 评价并接受采 购请求 将申请递交给 采购部门 管理采购活 动、发货及 接收 审查并接受 供应商货物 3.7.1

将申请递交给采购部门将申请递交给采购部门 管理采购活动、发货（expedite）及接收 任务3.4.1过程步骤 过程步骤 过程描述 功能参考 评估原料需求 项目管理者及功能性组织评审基准的项目计划以确定项目的执行所需要的原料。 ■ 1.5.3■ 工具 1-8 合同评审核检清单 发起采购申请 项目管理者或任何其它组织或在项目中工作的个人，为了完成工作所需的原料而发起一项采购请求。这项请求需呈交给项目管理者来做评审和接受。 □ 8.4.2 评价并接受采购申请 项目管理者收到发起者的采购请求，评审并确信它与基准的项目计划是一致的，计入日志，并接受它。一份请求的副本留存并编入此项目的档案内。 将申请递交给采购部门将申请递交给采购部门 项目管理者将采购申请给采购部门以进行采购。 □8.4.2 □ 8.4.1 管理采购活动、发货（expedite）及接收 项目管理者或发起当事人与采购部门联系确保此定购能得到正确地处理，通过确认需要的日期、航运、场所、数量以及其它细节准确无误。作为需要项目管理者与采购部门一起安排并监控航运原料的发货（expedite）。收到定购的条款时，发起当事人通报项目管理者，项目管理者将其计入收到日期日志。 审查并接受供应商货物 项目管理者审查收到的供应商发货单以确保其正确性以及开过帐单的原料已收到。他或她接受发货单并将其记入应付的应付款中。发货单的副本保留并编入项目档案内，将PMIS中的成本信息更新。 □ 8.4.3任务3.4.1 管理采购

任务3.4.2监控转包合同履行 在实施过程中涉及承包商的项目要应用到此项工作。H企业需要雇用承包商开展特殊工作或递交项目所需要的产品或服务。H企业与成包商之间的合同包括T&C、工作范围、质量指标、里程碑进度计划，可交付物的表述以及执行标准。项目管理者监控承包商履行情况以确保其符合合同的规定。

任务3.4.2监控转包合同履行 2.7.4 制定转包合 同计划 识别并监控转 包合同可交付 物 监控转包合同 履行 管理转包合同 执行 3.7.1

任务3.4.2过程步骤 过程步骤 过程描述 功能参考 制定转包合同计划 项目管理者制定转包合同计划，其包括合同协议及其他描述H企业与转包商双方任务与责任的信息。此计划包含的是对里程碑、可交付物的描述以及接受标准 □ 8.4.3■ 工具 8-8转包合同模版 识别并监控转包和同可交付物 项目管理者识别并监控转包商可交付物，其在转包计划的合同协议中已详细说明。他或她需要定期地从转包商那得到现状更新材料。 □ 8.4.3■ 工具 8-8转包合同模版 监控转包合同履行 向客户递交的技术上解决方案的质量一定程度上取决于购买转包商的工作、产品或服务的质量。因此，项目管理者管理转包商业绩的关注点放在质量与时间上是至关重要的。 □ 8.4.3■ 工具8-8转包合同模版任务 3.4.2 监控转包合同的履行 管理转包合同执行 项目管理者或指定的团队成员执行与转包合同有关的管理任务，包括向转包商航运或接收产品、更新计划进度、安排并进行测试及接受程序、管理并跟踪变更命令、处理相关文件。 □ 8.4.3■ 工具8-8转包合同模版

任务3.4.3监控转包合同发货及支付 项目管理者监控、审查并接受所有转包商发货单及支付。H企业与转包商在合同协议的支付条款中规定了怎样、何时转包商向H企业开发货单。项目管理者确保在将发货单作为支付的应付款前保证其正确性，并监控发货及后来支付的处理过程。发货的差异性由项目管理者在采购部门的协助下给予解决。

任务3.4.3监控转包合同发货及支付 2.7.4 审查转包合 同支付条款 监控里程碑及 可交付物 审查并接受转 包合同发货单 监控发货过程 3.7.1 跟踪对转包商 的支付

任务3.4.3过程步骤 过程步骤 过程描述 功能参考 审查转包合同支付条款 项目管理者审查转包合同计划及转包商与H企业之间的协议，以确定适当的支付条款（terms）。 □ 8.4.3 ■ 工具 8-8 转包合同模版 监控里程碑及可交付物 项目管理者始终监控转包商的可交付物及里程碑事件并相应的更新计划进度。这一工作是很重要的，因为多数支付都是由里程碑事件或可交付物驱策的。 审查并接受转包合同发货单 转包商负责将货物发给项目管理者。他或她审查确保其正确性，接受发货并转作处理的应付款。如果发货有误，项目管理者与转包商一起解决这些误差。发货的副本计入项目档案内。 监控发货过程 项目管理者或指定的项目团队成员做应付款的转换为确保采购订单对应转包商的发货已存档。 跟踪对转包商的支付 项目管理者或指定的项目团队成员跟踪对转包商的支付并更新PMIS的成本信息。

活动3.5 管理风险和机会 项目风险及机会管理包含识别、分析、区分轻重次序以及对项目风险或机会做出反应。这一过程包括使积极的事项取得最大成效并使不利事项造成最小的影响结果。风险和机会的评估与管理不是一时的作用过程，它随情况的变化贯穿于整个项目生命周期。例如，高风险可能变成低风险或对项目没一点影响，并且低风险可能突然给项目带来威胁。因此项目管理者始终监控风险并定时性地重评估是很重要的，同时用新的风险减少及机会最大化战略来更新风险和机会管理计划。无论何时潜在的风险和机会都应量化。量化风险中两个因素必须考虑：风险事件的可能性（对风险事件发生可能性的估计）及风险事件的价值（若风险事件发生将导致的得失估计）。对风险的回应分成以下四种类型：避免，指通过排除诱因来消除这一具体风险；减轻，指减少风险发生或影响的可能性；接受，涉及偶然性事件的发展。

活动3.5 管理风险和机会 2.7 3.5.1 监控并减少风 险使机会最大 化 3.5.2 对项目风险与 机会进行再评 估 3.7

任务3.5.1 监督和缩减项目风险并最大化项目机会 项目管理者监控已识别的贯穿整个项目生命周期的风险和机会。项目的期限及变化都可能影响到风险或机会的可能性或效果。一项风险消减战略的实施也很可能引发另一风险的出现。这样项目管理者应在每月的项目会议上审查并更新风险与机会列表。特别推荐将风险基于其预期的对项目的影响以及发生时点（预期在月内发生的风险可能需要直接重视，但是预期在一年内发生的风险也许就不需要了）区分优先次序。有消减战略的每项高优先级风险都经讨论并以对应这一战略的任务形式编入项目进度计划内。

任务3.5.1 监督和缩减项目风险并最大化项目机会 消减及机 制定风险 评审风险事 会最大化 和机会管 2.7.4 件的现状报 3.7.1 理计划 评审风险事 件的现状报 告 消减及机 会最大化 战略 3.7.1

任务3.5.1 过程步骤 过程步骤 过程描述 功能参考 制定风险和机会管理计划 项目管理者在执行阶段起始时制定风险和机会管理计划。这一计划给出如何评估和管理风险与机会，如何经常反复评估以及如何传达。 □ 5.6■ 工具5-9 风险分析及跟踪日志■ 工具 5-10 机会分析与跟踪日志 评审风险事件的现状报告 项目团队审查项目现状报告以平价现有的风险与机会事件的影响 □ 4.8■ 工具 4-2 月进度报告 制定风险消减及机会最大化战略 利用项目团队评审的信息，项目管理者确定哪项战略应对现存的风险与机会是最适合的。然后他或她执行这些选择的战略并通知有关当事人。 □ 5.6.2

任务3.5.2 重新评估项目 风险与机会 项目团队定时地重评估项目风险与机会以确定原有的评估是否有效。多数情况下估计的风险或机会的影响随项目的进展有所变化。随着事件发生时点的临近，项目团队可能会有越来越多的信息，这样能够做出更好的估计。项目、客户或组织的变化或是不可控制的外部事件可能会改变原有的风险估计。随着项目的实施。新的风险也可能出现并且原有的风险不再有威胁。项目管理者推动重评估以及将风险和机会再次优先排序并开发新的消减战略或紧急计划等工作的开展。

任务3.5.2 重新评估项目 风险与机会 审查风险 识别并评估 消减及机 重区分项目所有风 新风险及机 2.7.4 会最大化 战略 识别并评估 新风险及机 会 修正风险及 机会的管理 计划 3.7.1 重区分项目所有风 险及机会的优先次 序

任务3.5.2过程步骤 过程步骤 过程描述 功能参考 评审风险消减及机会最大化战略 项目团队定时地评审风险消减与机会最大化战略以确定其是否需要修正。 □ 5.6.3 识别和评估新风险及机会 项目团队在项目现状评审会议期间或通过其他的消息来源（例如功能性组织、客户、卖主及转包商）识别新风险及机会。评估新的风险及机会对项目的影响。 □ 5.6.3■ 工具5-3 风险核检清单t■ 工具5-4 机会核检清单 重区分项目所有风险及机会优先次序 利用对新风险及机会评估的信息，项目团队将其再次优先排序以便对项目有最大影响的风险及机会，不管是积极的或是消极的，能得到首先处理。 修正风险及机会管理计划 项目团队根据新的优先排序列表，修正风险及机会管理计划。如果必要，就开发新的消减与最优化战略，以及新的紧急计划。这一过程贯穿项目的整个生命周期。 □ 5.6.3任务 3.5.2 重评估项目的风险及机会

活动3.6 管理项目变更 管理成本、计划进度以及资源是项目管理者执行的最重要的工作之一。这三项关键的工作状况测定是保持项目在控制之下的重要因素。工作状况测定的关键要素是一些必要条件，包括用项目的技术方面集成成本、进度及资源利用的管理，用公认的管理方法以一种连贯成体系的方式提供与这些数据相关的信息。 ？利用PMIS信息并运用“挣值”的观念，项目管理者能够测定成本与进度的差异并进行矫正以确保项目正常运行。基于绩效测量核心理论的“挣值”观念体现一种获得正确测量的原理，这一测量需要对正在开展的项目中以完成的工作的客观评价。与项目的支出比较，对已完成工作的评估体现了成本的一个真实差异并取代了较传统的与花费计划进行比较的技术。实质上，它的基本前提是基金可以花费并且工作的被计的小时数与实际作的工作量是不成比例的。 资源的利用也是项目业绩的一个重要的指标。项目管理者必须定时地评估资源的利用并决定何时、何地应用纠正行为（apply corrective actions）例如资源再分配。 这一过程主要在实施阶段完成但在项目结束阶段也将涉及到。

活动3.6 管理项目变更 2.7 3.6.1 管理成本变 更 3.6.2 管理计划 进度变更 3.6.3 管理资源变 3.7

任务3.6.1 管理成本变更 项目管理者从PMIS搜集成本信息，应用“挣值”观念，并获得成本差异（CV）。这一差异是积极的或是消极的。积极的差异表示项目在预算的框架下运行，消极的差异则表明项目的运行已超出预算。此过程是将实际完成工作的真实成本（ACWP）与实际完成工作的预算成本（BCWP）相比较。整齐地记录这一价值差异是很重要的，必须报告并跟踪准确完成的实际工作以及实际成本。这一计算也提供了成本业绩指标，已完工估计以及正要完工的估计。一旦成本差异计算出来，项目管理者决定形成差异的原因并实施正确的措施，若需要，将项目带回预算条件内。 这一记录是很重要的，即使积极的差异起初看起来像是好事，它也可能显示原有的估计是不正确的，更甚者，H企业可能会失掉标的。管理层需要知道这一信息为计算未来的估计。

任务3.6.1 管理成本变更 2.7.4 获得并评审 PMIS成本数 据 应用挣值分析 计算成本变化 分析成本变化 开发并执行纠 正成本措施 3.7.1 准备管理层的 成本报告

任务3.6.1过程步骤 过程步骤 过程描述 功能参考 获取并评审PMIS成本数据 □ 4.5.3q 4.6.2■ 工具 4-3 每周跟踪与控制核检清单■ 工具 4-4每周跟踪与控制核检清单 应用挣值分析计算成本变化 项目管理者应用挣值的计算获得成本差异。成本差异CV等于实际完成工作的预算成本BCWP减去实际完成工作的真实成本ACWP。成本差异是一项测试过去的成本业绩的很清楚的指标。 □ 4.6.2 分析成本变化 仅仅知道项目在预算内还是超出预算是不够的，项目管理者必须尽可能地识别问题所在。值得注意积极的差异未必是件好事，反而可能是坏估计的一个暗示。 □ 4.6.1 开发并执行纠正的成本措施 若需要，项目团队开发并执行纠正措施以减轻任何附加的压力。 □ 4.7.1 准备管理层的成本报告 项目管理者准备关于项目成本的管理层现状报告。此报告包括项目的成本差异、实际完成工作的预算成本、实际完成工作的真实成本以及已完工的成本。若需要，附加描述已开发的将项目带回预算内的行为报告。这一报告与计划进度和资源差异报告相结合。 □ 4.8■ 工具4-2 每月进度报告

4.1 收尾阶段 活动4.1 向客户移交 • 任务4.1.1 召开移交会议 • 任务4.1.2 项目收尾管理 活动4.2 执行最后的项目评价 4.1 收尾阶段 活动4.1 向客户移交 • 任务4.1.1 召开移交会议 • 任务4.1.2 项目收尾管理 活动4.2 执行最后的项目评价 • 任务4.2.1 准备项目摘要报告 • 任务4.2.2 与客户一起召开经验学习会议 • 任务4.2.3 在项目团队内召开项目经验学 习会议 活动4.3 重新分配项目人员与资源 • 任务4.3.1 确定参与者并给予表扬 • 任务4.3.2 描述项目团队与资源

4.1 收尾阶段 技术的解决方案实施并得到接受后，项目管理者将工作交付给客户并结束项目，确保所有文件都已完成并且没余留任何突出问题。 4.1 收尾阶段 技术的解决方案实施并得到接受后，项目管理者将工作交付给客户并结束项目，确保所有文件都已完成并且没余留任何突出问题。 同时项目团队将为客户维护功能的责任移交给H企业的服务组。在这一交付期间项目管理者确信客户理解在担保与服务期限内H企业提供哪些支持。 虽是客户已经签订项目接受文件，这一项目仍没完成直到技术上的解决方案正式过渡到客户日常运营并且客户结项信函发出为止。 在结束阶段项目管理者用最后的成本及计划信息更新项目文件，完成需要的结束文件，项目文件如档，认可个人和团队的贡献并为重分配解散项目的资源。

4.1 收尾阶段 阶段 3.0 4.1 向客户进 行交付 4.2 制定最终 的项目批 评 4.3 重分配项 目人员与 资源 项目 结束

活动4.1 向客户移交 这一活动的目标是移交责任，将技术上的运作交付客户并将对客户的支持维护交付给H企业 的服务组。在交付会议期间，项目管理者确保客户清楚理解在担保和服务期限内可从H企业接受哪些支持以及获得支持的程序。例如，发出服务请求的程序是什么，客户可接受的回应时间以及客户怎样在H企业组织内逐级提交问题。在会议期间项目管理者也会估计客户对交付的满意度，识别任何突出的交付问题并给出及时的问题解决方案。项目管理者向客户发出项目结束信函，标志项目完成并且客户承认接受，这时这一活动就已完成了。 3.7 4.1.1 制定交付 会议 4.1.2 管理项目 收尾 4.2

任务4.1.1 召开移交会议 项目管理者在H企业和客户组织内确定交付会议人员，确定时间并召开交付会议。交付会议的目标不仅仅是指导客户技术操作程序，而且提出关于由服务组提供的H企业维护服务的详细资料。H企业的问题递交程序也将简要地传达给客户？

任务4.1.1 召开移交会议 3.7.2 确定交付会 议参与者 安排并制定交 付会议时间 开展交付会议 制定交付会议 跟踪事宜 4.1.2

任务4.1.1过程步骤 过程步骤 过程描述 功能参考 确定交付会议的参与者 项目管理者确定参与交付会议H企业与客户的两者的人员。 □ 9.9.1■ 工具9-9 竣工会议和核检清单 安排并制定交付会议时间 项目管理者安排设施并确定会议时间。地点和时间的选择应尽量使参会比率最大。 □ 9.9.2■ 工具9-9竣工会议和核检清单 开展交付会议 此会议的目标是清楚说明交付过程以及H企业能向客户提供的支持维护。在会议上H企业团队应准备回答客户的多数疑问。任何没有解决的问题将签订行为条款为以后给予解决。 □ 9.9.3■ 工具9-9竣工会议和核检清单 制定交付会议跟踪事宜 H企业 与客户为交付做准备并继续履行交付会议上确定的行为条款。 □ 9.9.4

任务4.1.2 项目收尾管理 在项目收尾工作期间，项目管理者正式将技术上的运作交付给客户并确保客户对H企业提供的后来的安装维护表示满意。任何余留德问题都及时得到处理，并且标志着项目正式结束的一份结束信函发给客户。提交服务转交报告以确保正确的信息标准已在要求的时间内提交保证服务组为已完工项目的客户提供支持维护。

任务4.1.2 项目收尾管理 识别突出的问 评估客户对交 4.1.1 执行向客户 题并跟踪活动 交付 付的满意度 准备项目转交 发出项目收尾 任务4.1.2 项目收尾管理 4.1.1 执行向客户 交付 评估客户对交 付的满意度 识别突出的问 题并跟踪活动 发出项目收尾 信函 4.2.1 准备项目转交 工作包

任务4.1.2过程步骤 过程步骤 过程描述 功能参考 执行向客户交付 在与客户召开交付会议的同时，项目管理者开始正式的交付工作。 □ 7.8 评估客户对交付的满意度 项目管理者与客户评审在交付会议上提出的关注问题以保证客户对其解决方案的满意。 识别突出的问题并跟踪活动 在正式交付期间若出现新的关注问题，项目管理者识别并提出解决日期，继续进行确保所有问题都得以解决。 □ 7.8■ 工具7-6 显著条款列表 发出项目结束信函 项目管理者向客户发出项目结束信函，标志项目正式结束。 □ 7.8■ 工具 7-5 项目结束表 准备项目转交工作包 项目管理者完成项目转交工作包，确定项目从项目运作到服务的移交所提出的那些范围。这将确保在要求的时间内提供信息的正确标准，保证服务组的支持维护。 □ 7.8■ 工具7-8项目转交

活动4.2 执行最后的项目评价 此活动主要是制定后实施评价、定案并将项目文件存档。项目管理者收集最后的项目成本及计划进度数据，为管理层准备最终报告，将相关的项目文件存档并处理不相关的数据。在此活动期间执行的其他重要工作是与客户及项目团队开展的教训会议？（the lessons learned meetings）。因为项目已正式结束并且客户满意地掌握技术运作，这些教训会议？（the lessons learned meetings）提供在一个无威胁且无对抗的环境里获得对以后的项目有帮助的信息。讨论的重点应包括什么出现错误，什么作的对以及什么本该做的不同。项目管理者巩固这一输入，在适当的形式下证实它，分发给适当的个体并将其编入重要的项目数据库内为将来做参考。

任务4.2.1准备项目摘要报告 项目管理者从PMIS获取最终的进度及成本报告数据，与基准进行比较，计算差异并准备和向管理层提交最终的报告。因为项目管理者负责管理项目在预算内并按进度实施，最终的报告必须正确地陈述与基准预算及进度比较项目是如何完成的。项目管理者也将收集项目的文件，将相关的文件存档并处理不相关的文件（此文件计划表述哪些文件应保留，哪些应删除）。

任务4.2.1准备项目摘要报告 4.1.2 获得最终 的项目成 本及进度 数据 为管理层 评价准备 最终的项 目报告 将项目数据 及报告存档 4.3

任务4.2.1过程步骤 过程步骤 过程描述 功能参考 获取最终的项目成本及进度数据 项目管理者从PMIS获得最终的项目进度及成本数据并与基准进度及预算相比较。 □ 7.8 为管理层评价准备最终的项目报告 项目管理者为管理层的评审准备最终报告。此报告应正确陈述与基准预算及进度比较项目是如何完成的。应包括实际的与基准的数据，也包括预算差异、成本差异以及差异的原因。技术上的性能或客户对解决方案的满意度有多高在报告内也应该提及。 将项目数据及报告存档 利用文件计划中给定的指导方针，项目管理者将具体的文件存档并处理那些不需要保留的文件。

任务4.2.2 与客户一起召开 经验学习会议 教训为将来的效用提供了重要的数据，特别是如果H企业有机会与此客户合作另一个项目。因为项目正式结束并且技术解决方案较满意地运行，项目管理者与客户有一个开放的无对抗的讨论关于什么做错了，以及什么做的比较好。 这一讨论应包括H企业及客户的业绩并且确认二者显著的业绩。这一定义应看成是一个学习经历，不仅仅是一个单项指示会议。项目管理者以双赢的方法负责设计合作环境。

任务4.2.2 与客户一起召开 经验学习会议 4.1.2 计划并准 备客户教 训会议 评估客 户对项 目的满 意度 开展客户教 证实客户的 问题及关注 实行必要 的会议跟 踪 4.2.3

任务4.2.2过程步骤 过程步骤 过程描述 功能参考 计划并准备客户教训会议 项目管理者准备需要的材料并安排与客户的会议。通知客户会议的目的。 □ 7.8■ 9.9.2 开展客户的教训会议 项目管理者及关键的项目团队与客户开展教训会议估计哪些运行的好，哪些运行的差及哪些做的较好。项目管理者必须给客户强调此会议是教训会议而不是找机会修正过失。 □ 7.8■ 工具7-7 接受教训核检清单□ 9.9.3 证实客户的问题及关注 项目管理者证实关于客户对项目实施的反馈，也包括项目团队重视客户业绩的输入。 □ 7.8 评估客户对项目的满意度 教训会议为项目管理者又提供一个机会，评估客户对H企业提供的项目实施与解决方案的满意度。 实行必要的会议跟踪 项目管理者确保在教训会议上提出的新问题或关注能尽可能及时地得到处理。

任务4.2.3 在项目团队内召开 项目经验学习会议 与客户开展的接受教训会议使项目团队清楚地理解客户对于项目执行得如何的感觉。 记录客户的感觉很重要，不管正确或错误都有其价值？（right or wrong, is what counts）。项目团队，包括当地的合同管理代表以及负责评价或建议活动的小组代表，评审在客户会议上发生了什么并决定应不同地做些什么来提高这一感知。从事这一过程不必需要客户对项目结果的满意。即时客户满意，它仍有改进的余地。这样教训会议的目标总是确定什么做的较好。 再加上，应该进行原有的风险及机会分析的评价，应给建议组提供反馈的评价范围是： • 先前在R&O中识别的风险条款的实际风险消减成本。 • 实际发生的风险事件是难以预料的，然而，现在应属于建议组风险考虑内容的一部分。 • 实际的机会事件是难以预料的，然而，现在应属于建议组机会考虑内容的一部分。 这一反馈应该对应提高了我们以后的R&O分析，并同时识别需加强的潜在的合同政策弱点

任务4.2.3 在项目团队内召开 项目经验学习会议 开展团 队接受 教训会 议 证实团队 的认识及 关注 4.3.1 4.2.1 4.2.2 计划并准 备团队接 受教训会

任务4.2.3过程步骤 过程步骤 过程描述 功能参考 计划并准备团队接收教训会议 项目管理者为教训会议准备材料及计划。材料应包括在客户教训会议上收到的反馈。 □ 7.8 开展团队接收教训会议 项目管理者必须强调会议目标是公开、诚实地讨论哪些做的较好，而不是对做得不好的给予责备 证实团队的问题及关注 项目管理者识别并证实团队的问题及关注。找出团队控制之外的问题很重要，它将引起高级管理层的注意以便能在那个级别上得到处理。（风险及机会问题应反馈给负责的建议与合同管理组织）这一完整的教训文档文件将归档以备作以后参考。

活动4.3 重新分配项目 人员与资源 项目管理者放弃或再分配项目的资源，这不仅包括人力资源，也包括设施、设备、器械以及供应品。绩效评价，或至少显示此项目的职员如何完成工作的需呈给管理者的备忘录，为此项目的管理者准备。项目管理者也承认个人或团体对项目的成功所作的贡献。他或她发给所有参与者一个备忘录，并给各自的管理者一个副本，感谢他们的贡献及支持。很多案例中将人员再分配，项目管理者通知那些个体关于他们的新任务。所有的供应品及设备都归还到原处，并且开展项目所用的设施空间也给腾出来。

活动4.3 重新分配项目 人员与资源 4.2.3 4.3.1 确定参与 者并给予 赞誉 4.3.2 分散项目 团队及资 源 项目 结束

任务4.3.1 确定参与者并给予表扬 项目管理者准备绩效评价或备忘录，注明个人对项目工作的执行情况，并将其呈交给将人员指派给项目的功能性组织的管理者。传达这些信息是必要的，特别是对长期的项目来说，个人脱离自己的部门相当长的时间，所以传达这些信息使功能性管理者能恰当地评价他们的员工。项目管理者也将召开项目完工会议并赞誉个人或小组对项目的贡献。给所有的参与者发放感谢信并将其备一副本呈交给他们的管理者。

任务4.3.1 确定参与者并给予表扬 4.2.3 准备绩效 评价 计划并开 展项目完 工会议 4.3.2 准备并赠 与个人和 小组荣誉

任务4.3.1过程步骤 过程步骤 过程描述 功能参考 准备绩效评价 项目管理者准备并分发绩效评价或备忘录给每个参与者的经理注明个人对项目工作的执行情况。 □ 3.7.4 计划并开展项目完工会议 项目管理者召开项目完工会议标志着项目的正式完工和结束。 □ 3.7.6 准备并赠与个人和小组荣誉 项目管理者赞誉个人和小组对项目的贡献。赞誉仪式应包括在项目完工会议内容内。若方便，应邀请功能性管理者参加。给所有的参与者发放感谢信并将其备一副本呈交给他们的管理者。 □ 3.7.5

任务4.3.2 解散项目团队及其资源 解散项目团队并重分配给其他项目或是回到以前的组织，物质资源返回原处。腾出设施并归还给原有的占有者或业主。 4.3.1 确定并传 达团队人 员的分配 归还项目 供应品及 设备 项目 结束 腾出项目 设施

任务4.3.2过程步骤 过程步骤 过程描述 功能参考 确定并传达团队人员的分配 项目管理者对项目团队成员进行分配或再分配并将这一信息传达给他们。 □ 3.7.6 归还项目供应品及设备 项目管理者安排归还所有借来的供应品及其设备给原有者 腾出项目设施 项目管理者安排腾出所有项目使用的设施并归还给原有者或业主。

第三章 项目组织管理与项目经理案例

案例一 项目管理组织

3.1 项目管理组织 3.1.1建立项目管理 3.1.2指派项目管理者 3.1.3获取项目基金 3.1.4启动PMIS

组织项目的过程通常建立在由每个H企业项目实施组织生成的框架内。这一过程指导项目团队的形成并且组织在计划与实施阶段各方组织参与者的参与。 组织项目的过程就是能决定实施环境并能将以商业机会转变成有报酬的、基于项目的工作。

组织项目的主要活动 建立项目管理 指派项目管理者 获取项目基金

3.1.1 建立项目管理 识别与承认项目机会通常是销售经理的责任。有时候，在现有的客户中，项目管理者可以有机会识别新的商业机会或扩展现有的业务。 建立项目管理意味着以一种正式的且结构化的理解决定项目管理者的需要。多数客户的请求使项目管理者疏忽的级别成为必要，对大且期限长的项目用GPM的全范围方法。较小的项目，有时仅有一人完成，通常有较短的期限并且可能仅需要最小的项目管理活动，它集中在技术业绩的疏漏上。

支持指定商业机会需要考虑的因素 1、客户需求的复杂性 2、工作程序的大小及期限 3、财务与战略评估 4、风险范围

1、客户需求的复杂性 是否涉及多重技术学科？ 是否需要工作的协调？ 是否技术级的技术或新产品或服务能够融合？ 对技术方案的调整是所期望的吗？并且合同变更是否可能？

2、工作程序的大小及期限 是否有内部劳动力执行真实资源管理活动? 是否用到装包商，卖主以及外部顾问？ 是否期望项目的期限多于六周?

3、财务与战略评估 承担的疏漏是否归因于工作程序的美元价值？ 是否有特别的公司利益？它将战略的商业重要性放在工作程序上。

4、风险范围 与机会有关联的风险是否高于正常的风险因素？ 风险识别与消减是否与必需的技术业绩有关联？ 风险识别与消减是否与必需的合同类型有关联？

建立项目管理也意味着决定项目管理者需要的技术与经验。对较小的工序来说，一个人就能胜任，要求他具有自我管理能力并对基础观念及项目交付的原则有见识。较大的项目，然而，需要考虑有先进项目管理能力的多个个体。

3.1.2 指派项目管理者 针对给定的项目工作指派项目管理者是一个相对简单的过程，主要有以下三步构成： 3.1.2 指派项目管理者 针对给定的项目工作指派项目管理者是一个相对简单的过程，主要有以下三步构成： 当地的项目主管基于项目机会的已知因素识别适当的项目管理者或保留决策权。 项目管理者或当地项目主管以及财务管理者评价商业案例即类型、大小、复杂性、期限以及其它项目特征。 项目管理者或当地项目主管选择一人担任项目管理者，他是满足项目需求的最佳匹配者并且对指派是有益的。 项目管理者选择过程可能正式或不正式，取决于项目的复杂性与重要性。这一过程截至到被选择的个人正式通知的发放。

指派项目管理者需考虑的因素： 1、技术能力 证实对客户技术需求的理解； 在管理或履行必需的技术工序中前序的工作项目。 2、管理经验 对相似的类型，大小以及期限的项目，其成功的管理或是内在的重要规律 对用GPM方法去完成项目目标中使用的必要因素得到的证实的理解 3、其它因素 客户可能的接受 根据给定项目的大小及本质特征的需要，使用适当的能力去领导和激励个体以及工作团队 针对工作选用最佳的个体

3.1.3 获取项目基金 当获得经授权的基金用于执行工作时表示项目正式成立。越过项目的进程，这一基金的获得观念上依赖于客户对H企业提供的产品及服务支付的报酬大小。起初，必须获得基金能够制定初步计划以及开展提议。

获取初始项目基金的步骤： 准备基金授权请求，利用风险项目数据，或者如果赢得标的可能性很低，就利用投标建议数据。 促进基金授权请求，附有对项目管理者及当地项目主管对基金的评审及授权有意的任何必要的理由。 收到经核准的基金同时，联系财务部门建立一个账户，在这一账户中安置初始基金并为在项目计划以及建议开展活动中发生的账目服务。

3.1.4 启动项目管理信息系统 （PMIS） 收取、发生、传达以及储存信息是项目管理评论的必要条件。确保恰当的数据以及记录从开始都已保存，成立并启动项目管理信息系统（PMIS）是项目管理一重要工作。 PMIS包括硬件、软件、纸质文件以及用于跟踪、监控并报告项目数据以及情况的程序。它包括ORACLE项目会计系统（ORACLE PA）用于跟踪项目的成本并且其它经核准的项目管理应用软件用于监控项目的计划进度以及资源的利用。PMIS的启动包括建立传统的项目装订工/工作文件，或以电子的或是纸质的形式，或者以二者的结合。

案例二 项目经理

3.2 H企业项目经理 3.2 .1 项目经理的角色、 使命与要求 3.2 .1.1 项目经理的角色 3.2.1.2项目经理组织 3.2 .1 项目经理的角色、 使命与要求 3.2 .1.1 项目经理的角色 专业界面 客户界面 项目团队界面 上级管理界面 财务管理人员界面 职能经理界面 外部界面 3.2.1.2项目经理组织 3.2.1.3 项目管理人员结构 3.2.1.4 项目经理素质 3.2.1.5 项目经理指派绩效因素 3.2.1.6 项目经理调动 3.2.2项目经理的培养与培训 3.2.2.1H企业 IAC推荐的项目经理核心课程 3.2.2 .2项目管理支持结构

H企业 项目经理 GPM方法论为项目管理提供了一个一贯的方法，但他也允许项目经理根据每个项目的特性进行调整，这就要求H企业的项目经理具备高度的职业化技能。这一部分将讨论如何将GPM方法论与项目经理的角色、关系和职责相融合，以及如何促进项目经理取得进步。

3.2.1 项目经理角色、使命与要求 项目经理的角色 外部界面 专业界面 项目经理组织 客户界面 项目管理成员结构 项目团队界面 3.2.1 项目经理角色、使命与要求 项目经理的角色 专业界面 客户界面 项目团队界面 上级主管界面 财务经理界面 职能部门经理界面 外部界面 项目经理组织 项目管理成员结构 项目经理素质 项目经理任命 项目经理转换 项目经理支持结构

3.2.1.1 项目经理的角色 1、综合者 2、沟通者 3、团队的领导者 4、决策者 5、氛围创建者 3.2.1.1 项目经理的角色 1、综合者 2、沟通者 3、团队的领导者 4、决策者 5、氛围创建者 项目经理要献身于所有工作过程的持续改进上。

1、综合者 项目经理是唯一能够了解项目整体同时又能够看到项目与H企业战略计划的关系的人，他还要负责项目团队成员的协调与整合，使他们将目标集中在项目的成功完成上。作为一名综合者，项目经理主要面临着下列六个领域的问题：解决客户的需求和要求，将当地的法规定整合到项目工作流程中，促进技术问题的解决，设置优先顺序，清除管理障碍，处理冲突。

2、沟通者 项目经理必须建立和保持所有项目界面的有效沟通，没有项目组织内外部的良好沟通，团队工作也就不复存在。作为沟通者，项目经理的任务主要有如下五个方面：促进项目团队的有效沟通，加速沟通，识别所有沟通渠道，清除沟通障碍，使用紧密矩阵，开有效的会议。项目经理必须运用各种手段来确保所有项目界面之间的高效的双向沟通。GPM方法论有这方面的指南。

3、团队的领导者 项目经理必须具备团队建设的技能，它必须能够解决团队中所出现的问题，指导来自不同领域的团队成员，并且能够通过有效的领导技能指导项目活动。监督经验对于项目经理而言是必不可少的。教育和培训可以提高项目经理的能力，项目经理还必须提高安全和环保意识。

4、决策者： 项目经理必须具备资源分配的决策能力、成本与工期的平衡能力、以及范围变更、指导以及项目特性变更时的决策能力。

5、氛围创建者： 项目经理应该建立一种有助于团队成员工作的气氛，项目经理在这方面的职责主要有：确保项目团队配备了领导人、工具、支持以及激励团队成员创新和努力所必须的团队氛围；获得团队成员努力工作的承诺；获得高水平的项目产出所必须的项目小组协同工作的承诺；项目经理是项目客户在H企业组织中的代表，他负责在H企业内部获取支持以达到项目目标。

专业界面 在整个项目过程中，项目会受到H企业各个单位或部门的影响，因此，项目经理必须建立和管理好高效的与H企业不同小组协调工作的关系。

客户界面 项目经理负有让客户对H企业绩效满意并接受项目交付物的责任。与此相关的界面包括：确保清晰地理解了客户的要求和期望，这种要求和期望不仅来自于文件同时也来自于与客户的持续交流；应客户的项目成员的要求或其上层管理者的要求准备报告和召开会议，确保向客户准确及时地传达其所需的信息；监督客户需求的变更，建立对变更的双向评价和管理程序；按照客户和H企业的要求管理客户合同。

项目团队界面 项目经理负责领导项目团队。与项目团队成员的相互作用主要包括：选择项目团队成员、为他们分配任务、明确其职责；建立内部交流项目信息和报告规则与程序；领导项目执行、跟踪与评价团队绩效；准备对项目成员进行项目中期和末期的评估，进行评估会谈。

上级主管界面 项目经理负责确保高层对项目进程的了解和掌握，与上层管理者的相互作用主要包括：对战略目标的理解以及现在的项目与整个商业计划的关系；按照上层管理者的要求准备报告、召开会议以及陈述；及时准确地编辑上层要求的信息；识别、探讨和解决问题和困难。

财务经理界面 项目经理要与财务经理合作，特别是在项目生命周期的早期。与财务经理的相互作用主要包括：促进客户下定决心进行交易，接受来自财务经理对项目的控制；准备客户需要的信息，特别是价和成本信息；参与销售战略的开发、谈判准备以及客户合同谈判；向客户交货，要求客户出具发票，以及获取客户付款通知书；讨论项目过程中出现的新的或扩展的商业机会。

职能部门经理界面 项目经理在整个项目生命周期内要与职能部门经理进行合作。与职能部门经理之间的相互作用包括：向职能部门资源经理提出要求、进行谈判以及获得项目所需的员工和物质资源；作为一种保持组织对项目进程的了解，建议和讨论职能部门经理资源使用效率的手段，保持与职能部门经理以及其他项目经理的联系；与人力资源经理协调与项目有关的人员补充和新成员任务的分派事宜；保持与采购经理的联系，采购经理负责寻求卖方、次承包商和顾问；管理服务和资源的收据；批准和签发发票。

外部界面 项目经理负责在整个项目管理生命周期中与外部团体进行合作，特别是供货商、分包商及咨询师。与此接口的交互包括： 管理服务提供商的获取、绩效、评价和支付 管理设备、供应物和其它材料资源的预定、获取跟踪、接收及分发 监视所有分包合同或协议的履行情况 监视在客户的项目环境中出现的其它主要合同方和供货商的活动和影响，并为更进一步的利益建立适当的关系

3.2.1.2 项目经理组织 在未来几十年内，H企业业务和客户服务需求对我们的项目经理们的技能和能力形成直接的挑战。为迎接此挑战，我们须建立我们行业内每类最好的项目管理能力的基线，我们已经为H企业 IAC项目管理人员建立了以下结构、成长路径和指派资格。

3.2.1.3 项目管理人员结构 虽然管理组织可能随地区不同而略有差异，但Honeywll IAC项目管理人员的建构通常都为： 1、项目经理 3.2.1.3 项目管理人员结构 虽然管理组织可能随地区不同而略有差异，但Honeywll IAC项目管理人员的建构通常都为： 1、项目经理 2、高级项目经理 3、项目群经理 （也可以成为地区项目总监） 4、高级项目群经理（也可以成为地区项目总监）

项目经理 —— 项目经理已经展示出了领导项目团队的能力；对项目人员进行计划、实施和控制；并有效地处理与客户的关系和合同责任。这种能力是通过在从小型到中型再到大型项目的管理实践中表现出的令人满意的绩效确立的。项目经理通常向项目群经理报告。 高级项目经理 —— 高级项目经理和以上描述的项目经理有着相同的特征，但通常比项目经理有更多的更大、更复杂项目的经验。高级项目经理至少对项目复原（recovery）领域比较熟悉。高级项目经理可以胜任项目管理所有领域所需的角色和责任，并且能清晰地实施最低限度的监管。

项目群经理 （也可以成为地区项目总监）——项目群经理需要控制更大规模的多样的大项目，并为单个项目的项目经理提供监督和指导。通常此角色须对关于过程、时间和技术进行指导，同时提供咨询并帮助相关的专业开发。此能力来源于多年个人的业内项目管理经验。 高级项目群经理（也可以成为地区项目总监）——高级项目群经理和以上描述的项目群经理有着相同的特征，但通常比项目群经理有更多的更大、更复杂的多样化项目的经验。

3.2.1.4 项目经理资质 教育——需要受过职业或技术专业的正式教育。需要有大学学历。还需要有（正式与非正式的）继续教育和培训来补充职业经验。当达到H企业项目管理组织结构的特定水平时，则要参加H企业项目管理提高课程的培训。 经验——很多项目经理的知识和技能都是通过实战获得的。在复杂程度不断增加的指派中，需要参与者起初作为一个技术主管，而后作为项目经理在H企业项目管理组织结构中进步或提高。 职业能力——教育和经验二者对于每个项目经理的主体职业能力都有所贡献。

管理技能发展四个上升阶段的项目经理能力 基本——能够理解技术和管理概念，并能在最少的指导和监督下应用它们。 有资质——在没有指导和监督的情况下运用技术与管理概念。 高级——在最少的指导和监督下应用技术与管理概念。 专家——在最少的指导和监督下开发与应用先进的技术与管理概念。

3.2.1.5 项目经理指派绩效因素 专业技能和经验——此经理已经达到并展示出来的个人能力水平，此水平的能力与项目的能力需求是紧密对应的。 3.2.1.5 项目经理指派绩效因素 专业技能和经验——此经理已经达到并展示出来的个人能力水平，此水平的能力与项目的能力需求是紧密对应的。 相关项目经验——在开展或领导相似类型的项目过程中积累的个人经验，并且有向更高水平类型项目发展的潜力，这些都被认为是与项目和客户需求有关的。 技术专业——所有项目经理要具有指派给他的项目主要技术领域的知识和技能。此专门技术通常通过专业教育计划和应用经验获得。 项目群经理/区域项目总监合作——确定“符合”项目和客户的项目群经理，要根据对此经理当前绩效和所有主流的顾客相关问题的评价作出决定，并且这将是作出项目指派决定的一个影响因素。

3.2.1.6 项目经理的调动 偶尔需要对H企业项目经理进行重新指派。这种指派必须是势在必行的。 3.2.1.6 项目经理的调动 偶尔需要对H企业项目经理进行重新指派。这种指派必须是势在必行的。 为了支持项目经理的调动，必须由新来的项目经理制定一张核检表，并由项目群经理或商务总监批准。

3.2.2 项目经理的教育与培训 象其它职业一样，新出现的项目管理职业也有一套自己的知识和技能，这些知识和技能用于管理项目活动、领导与协调项目团队活动并达到项目目标和客户的满意。高级项目管理技能和技术的应用在许多国家都变成了主流竞争因素。这份H企业 GPM方法整合了每个项目经理必须能够应用以保障有效地对所有H企业项目进行项目管理的全部技能和技术。 所需技能的提高及对运用GPM方法的原则和实践的能力的充分理解是一种个人职业努力。通过这一部分描述的项目管理课程开发和提出，这种努力由H企业 IAC来得以实现。

3.2.2.1 H企业 IAC 推荐的项目经理核心课程 开发等级 课程需求 基础 ■ GPM方法与工具 ■项目领导、管理和沟通 ■项目计划、分析和控制 有资质 ■合同管理 ■应用管理 ■建设管理 高级 ■持续改善和全面质量管理 ■国际项目管理 ■管理项目经理 所有人员等级 ■ PMI认证考试准备

3.2.2.2 项目管理支持结构 H企业 IAC项目管理服务是在由项目管理环境中的相关角色和责任组成的组织中开展的。这些管理角色和责任因地区而有不同程度的不同。 创建H企业 IAC项目管理核心指导团队的目的目的是监察并为国际商业中心关于项目管理政策、实践和程序的发展和完善。

核心团队负责 ： 开发和维护H企业 IAC GPM方法； 确定需求并建设项目管理教育和培训课程； 规定实施项目经理开发的活动和标准； 创造项经理使用的标准度量尺度和工具； 对IAC和地区业务中心的集体项目绩效进行评价和评审； 建立一个H企业 IAC项目管理卓越中心； 进行持续的项目管理工作过程改进； 提供教训和最佳实践的国际交流平台。

核心指导团队是由一组一起合作并支持H企业能力来管理项目的人员组成。此团队将扩展到包括每个地区高级职员代表的人员。 核心指导团队将演化为项目管理卓越中心的领导团队。 核心指导团队的联系人是H企业 IAC项目服务的总监。

第四章 项目范围管理案例

4 开展项目范围工作 4.1 开展初步的项目范围工作 4.1.1进行现场调查（若需要） 4.1.2确定客户的接收准则 4 开展项目范围工作 4.1 开展初步的项目范围工作 4.1.1进行现场调查（若需要） 4.1.2确定客户的接收准则 4.1.3准备主要的的项目范围工作 4.1.4获得对主要工作范围的反馈 4.2 准备详细的工作范围 4.2.1评价主要的工作范围 4.2.2构建详细的工作范围 4.2.3获得客户反馈 4.4完成详细工作范围

开展项目范围工作 开展项目范围工作的目的就是清楚识别为成功地完成项目哪些需要以及哪些不需要。工作的范围是以产品为导向的，定义由项目产生的产品。完成项目的可交付列表，它描述了每一阶段或里程碑要完成的可交付物。有时可能包括工作程序，但通常仅仅是在客户规定的工作应怎样做的范围内。通常完成项目所需的工作在接下来的准备工作分解结构（WBS）活动中给予识别。工作的范围是项目计划编制的基础也是客户关注的主要焦点，识别客户需要什么。开展工作范围是front-end loading (FEL) 过程的关键活动。

定义工作范围的过程 开展初步的工作范围 准备详细的工作范围 进行实地调查（若需要） 评价初试工作范围 建立客户接受标准 制定详细的工作范围 获得客户对详细 工作范围的反馈 完成详细的工作范围 评价初试工作范围 开展初步的工作范围 建立客户接受标准 建立初步的工作范围 获得客户对初步 进行实地调查（若需要）

4.1 开展初步的项目范围工作 为强调其重要性以及提高完整性和准确性，在准备详细工作范围之前开展初步的项目范围工作并与客户进行评价。 4.1 开展初步的项目范围工作 为强调其重要性以及提高完整性和准确性，在准备详细工作范围之前开展初步的项目范围工作并与客户进行评价。 这一过程是很重要的因为在计划编制阶段对工作范围的简单定义很可能导致项目成本超支。

4.1.1 进行现场调查（若需要） 进行实地调查的目的是评价实地条件，评审并编制现有设备内目录，检验能力，核实或识别硬件和软件需求情况，评价并定义破坏需求以及收集与项目相关的所有有利数据。这一调查必需做好计划并尽可能完全地执行。若返回再找遗漏的内容成本会很高并消耗时间，可能会减少客户对全队能力的信心。

实地调查中详细考察的条款 概念的解决方案 建议申请书/估价申请书 (RFP/RFQ) 正式调查和附录 客户目标 行业标准 客户详述及图画 其它客户文件 会议备忘录 最初的风险消减以及机会最大化战略

4.1.2 确定客户的接收准则 接受标准对什么是完成项目所需要的定义的一项关键内容。一定程度上对任何重大项目可交付的接受标准，客户没有详细说明，基于行业标准以及项目识别的需要要求客户或提出合理的接受标准是很必要的。 提议以及追加合同二者中包括接受标准。接受标准将成为项目团队业绩的基准并对客户评价进行详细说明。

4.1.3 准备主要的的项目范围工作 由团队几个成员来评价从上几步骤得到的信息。比较、分析以及将所有输入文档化并编译成可读工作范围文件，这些是很重要的。将在信息缺乏的情况下由团队制定的任何假设文档化尤显重要。调整初步的项目范围工作文件并在客户评审下定案。

4.1.4 获得对主要工作范围 的反馈 项目的初始范围提交给客户做评审。在这一步骤内要求客户评审初始范围并确定H企业已完全理解项目需求。理论上应安排并召开一个会议介绍并讨论工作的范围。某些情况下，比如客户使用正式的投标程序时，会议也许就不需要了。然而，应做些工作与客户一起调整初始的范围陈述。

4.2 准备详细的工作范围 根据收到的客户意见，把工作的范围最后确定下来。因为这一文件作为H企业建议的一个因素的重要性，它的开展可能会从提议团队的另外成员中受益。

4.2.1 评价主要的项目工作范围 工作的初始范围由召集的准备提议回应的团队评审，其中包括第一次看到工作范围的新成员。因为这一评审必须不仅包括文件中提到的，而且还包括没有提到的，远远超出仅核查现有信息的准确性。常识、以往的相似类别的项目经验以及每个团队成员的系统思考都要用到。主体专家以及律师事务所就技术或合同问题进行商议。一旦所有的问题及疑点都得以解决，就开始着手准备工作的详细范围。

4.2.2构建详细的工作范围 范围定义的叙述 可交付列表 高级（里程碑）项目计划进度 所有经客户指示从范围中明确剔出条款 客户请求的但H企业不能接受的例外条款列表 使用的所有假设的列表 风险与机会分析核检清单 其它文件，指对高级项目可能有必要阐述的内容

详细的工作范围是一份高级的项目计划 ，提议团队，在项目管理者的指导下，将以上方面汇编成一份可读文件作为呈给委托人的提议与回应的附件。

4.2.3 获得客户反馈 在把初始的项目计划确定下来以及开展提议之前应进行最后的项目评审。此外，理论上，评审应以会议的形式开展。H企业要明确已完全探测出客户的需要，期望、RFP/RFQ需求以及规范并与其取得一致意见。本质上说H企业对客户的谚语是：“我理解你需要什么”并且客户确认对要执行工作的细节的相互理解。 与大公司合作时，客户内部组织的各方成员的参与使此过程变得很困难，特别是如果客户还没有彻底地做计划以及没有准备自己项目的目的与目标。然而，H企业在理解项目需求中用的最大的工作是最可能推动初始的项目计划与提议的准备。更重要的是，这样大大提高授予合同的可能性。

4.4 完成详细工作范围 负责工作范围开展的提议团队成员以最终的形式准备详细的工作范围。在客户评审完成之前，应考虑客户的反馈并适当的融合。完成最终的文件编辑的同时，准备工作范围并将其作为提议包的附件。详细的工作范围也将作为开展项目计划内容的基础，多数都包含在提议包内。

第五章 进度管理案例

5 WBS的创立和使用 5.1 WBS概念的理解 5.2 使用WBS模板 5.3 编制WBS 5.4 建立WBS字典

WBS的创立和使用 在开展项目范围工作之后，项目团队应完全地理解了客户的需求。这一理解使团队成员能识别为完成工作的范围所必需的所有工作因素。这一工作因素通过准备项目工作分解结构以一种合理的方式集合在一起。 工作的范围是趋向于产品导向的并以客户为焦点。相反，工作分解结构以工作为导向并集中在H企业要执行的活动与任务上。

5.1 WBS概念的理解 WBS的准备涉及到有关分解的程序并导致需执行的项目工作的一个分层。根据项目情况，工作可能要依据产品、部门、阶段、地理或其它标准进行分解。在每个分解的层面内，项目或低级的概要任务依据一个特性进行分解。然而从一级到另一级，可能使用不同的特性。

WBS分层级别 概要层次 工作包 项目

WBS的基本原理是将项目工作分解成工作包。工作包是项目WBS最低级的要素并表示的是能进行协商并指派特殊的内部管理者或外部的转包商的工作。

工作包的特点 对计划进度、预算以及集聚必需的工作时间来说，表现出一种易管理并具有逻辑的水准 包括能证实的或可测量的可交付物 为完工指出确定的期限以及进度里程碑 有个人、转包商或部门完全地负责跟随的工作工序以及对那一工作的成本记账情况 识别为完工需要的估计成本，在项目实施过程中可以监控并跟踪它

5.2 使用WBS模板 每个项目都是独特的有自己的WBS。但是H企业内的许多项目有相似的生命周期和交付物，而且他们包括同样的内部组织和一般的外部组织。H企业工业的自动操作和控制系统为项目管理专业人员开发了标准的WBS模板，当标准方法应用到项目工作的时候可以使用这些模板。这些模板是特定使用的，而且是维持在恰当的地区和优秀的中心水平上。这些模板应该尽可能被使用，直到与这些模板的偏差达到需要编制详细的商业案例的程度。（只要它们之间得偏差大到需要制定具体的商业案例时，就需要应用这些摸板）

WBS模板的使用便于追踪和完成经常重复发生的工作包的项目目标。当估算随后的项目的成本和工期计划的时候，标准工作包的项目经验的历史特别有用。对于建立质量管理的标杆也是很有用处的。 模板应该能够有最广泛的应用性，而且能够根据标准项目工作的变化来修改。

5.3 编制WBS 项目团队必须能准备一个项目的WBS，对标准项目来说进一步分解和提炼模板，对于非标准项目来说则是编制一个新的WBS。

WBS 开发流程图 识别项目 主要成分 分解项目构成， 估算工作包标准 继续分解WBS以满足工作包标准 评估合成的WBS， 如果有必要做出相 应调整 建立工作分解结构字典

确定项目的主要组成部分 决定项目如何被管理以及工作如何能够分解从而最有利于成功的管理。通常，大多数项目使用阶段、产品或部门（或分包商）来进行WBS的第一层次分解。对于可以使用WBS模板的标准项目，这步已经完成了。考虑是否需要额外的主要组成才能完成任务，或者是否需要减少主要的组成，然后对WBS做出合适的变更。

把项目组成分解到下一水平 的WBS并评价工作包标准

继续分解WBS来满足工作包标准 通过系统，地点，建筑图纸，供应商，或者子阶段，把工作活动分解到更低的层次的WBS，直到达到工作包水平。只有当有必要反映实际项目的管理时，才有必要从模板中对工作组成进行进一步分解。

评估调整最终的WBS 工作包分为可以验证和不可以验证。 验证由工作包描述的工作活动活动是： • 对完整定义所有的工作来说是充分和必要的； • 对完整定义所有的工作来说是充分和必要的； • 可以分配到责任人和责任单位； • 与清晰确定和量化的交付物一致； • 在容许成本和工期估算的水平上，而且这个估算在整个项目期间可以追踪。 不能被验证的任何条目应该通过进一步分解，消除所在层次的细节以及使用概要层次或者重建WBS的一个部分等方法来调整。 •

5.4 建立WBS字典 WBS字典是每个工作包的所有细节保存的地方。标准的WBS字典格式由大多数基于电脑的计划工具提供。它被成称为“任务查看”或者“任务细节”（“Task View” or “Task Detail.”） 从概念上看，拥有所有的已经可获得的WBS字典信息是重要的。但是，每个工作组成的部分或是全部的信息是保存在一个单独的WBS字典中，还是有组织的电子数据库中或者是以项目管理软件的方式保存取决于商业单位政策和给定工作活动的项目管理需要。

WBS字典信息 工作组成名字－工作包的参考标题 工作分解代码（WBC）－用来组织和提供每个工作组成的编码系统，使用一个独特的识别数码来避免任何误算和混淆（使用WBS模板的更进一步分解，需要在WBC中添加独特的代码） 修改编码－更新WBS字典条目的指示（通常用“O”或者“.”作为起始的条目开头） 负责的经理/组织－个体或者部门检查工作活动的身份证明。 叙述性描述－将要完成的工作的性质的书面描述 任务进度表和类型－工作活动开始和完成的详细说明和工期约束的识别 相互依赖关系－紧前工作，紧后工作，和“必须日期”的确定。包括关系的类型（完成/开始，开始/开始，提前，托后，不早于，不迟于等）

WBS字典信息 任务/子任务－相对于概要层次或父工作组成和从属任务及子任务列表的工作包水平的确定。 资源需求－完成本工作包所用人力资源和材料资源的确定 WBS概要层次的工作组成应包括WBS字典，包括所有下级工作包层次的所有信息。通常，只有有限的数据对概要层次工作有用。包括： • 工作组成名称 • WBC（工作分解代码） • 工作的书面说明 • 没有包括在低层工作组成中的工期约束 • 下一层次WBS分解中的所有下层工作包的列表

第六章 项目成本管理案例

6 成本估算 6.1 开发成本估算 6.1.1 准备成本估算 6.1.2 编制成本估算对象 6.1.3 管理成本因素 6.2 评审项目估算

6.1.1 准备成本估算 成本估算包括编制一个完成项目必须的花费和资源的全部成本的近似结果。它要求必须评估完成功能单位和其他外部组织的成本，必须确定和考虑不同的成本替代方案。例如在大多数的应用领域，在设计阶段的附加工作会有潜力来减少生产阶段的成本。减少工期或者压缩工期进度，会产生额外的成本（例如，对于加班和分包）。当编制资源、进度和成本估算的时候，计划团队必须考虑所有这些替代方案。成本估算是一个反复的由工期估算和资源估算共同作用的过程。资源分配的变更，所使用资源的类型以及工期进度将影响项目的成本。

6.1.2 编制成本估算对象 人力成本——人力资源用工作所需的全部小时数在工作包的水平上进行估算(如果需要包括加班时间)。人工成本通过使用每个工作的负荷人工劳动率来计算。 如果项目是长期的，则应该考虑薪水增加和影响未来小时率的其他因素。当直接基于WBS工作包任务的时候，人力资源或人工成本计算是最精确的。联合使用这种方法和资源责任矩阵，将产生一个决定人工成本的完美开始。 其他直接成本——就像人工成本，材料和其他资源成本可以通过将单位成本应用到每个条目来计算。对于长期项目，必须考虑通货膨胀和其他成本增加因素。项目直接成本的估算精度取决于所有与项目效果相关的并直接产生成本的材料、供应品和设备。此外，每个直接成本条目应该与WBS组成一致，

行政成本——这些成本与项目计划和控制相关，不是直接可归于任何特定的工作包。在大项目中与计划和控制相关的成本是实际存在的。因此在成本估算过程中记录这些管理成本是关键的，而且这些管理成本与其他任何发生的支出一样也是可以被跟踪的，这一点也是关键的。

6.1.3 管理成本因素 所有与项目经理、项目行政管理者以及项目团队在项目上花费的时间相关的人工成本 与项目相关的商业旅行 办公产所 6.1.3 管理成本因素 所有与项目经理、项目行政管理者以及项目团队在项目上花费的时间相关的人工成本 与项目相关的商业旅行 办公产所 管理时间，应该被估算而且应包括在全部的项目成本中，除非已经包括在管理费分配中。 应该准备成本估算的支持细节，这些细节至少包括如下信息： • 估算的工作范围的描述和WBS的说明书 • 估算的基础文档（它是如何被编制的） • 制定的假设的文档 • 估算精度的范围的说明（比如5％）

6.2 评审项目估算 成本估算编制完成以后，项目经理召开会议进行项目成本的详细评审。参加者包括项目经理、会计经理、和咨询顾问/解决方案经理，必需的计划团队成员，和其他可以提供有价值输入物的个人，比如类似过去项目的经理。这个会议必须先于提案的编制召开。 这个评审的结果是完成项目所需的成本的一种估算，它是各参与方一致同意的和被正式批准的。这个信息是决定实施项目的价格的基础。

第七章 项目质量管理案例

7 质量管理步骤 7.1 质量管理概述 7.1.1 质量管理过程 7.4 质量保证管理 7.1.2 质量管理要素 7 质量管理步骤 7.1 质量管理概述 7.1.1 质量管理过程 7.1.2 质量管理要素 7.2 质量概念的运用 7.2.1 质量定义 7.2.1.1 质量要素 7.2.1.2 产品质量和过程质量 7.2.1.3 质量与标准 7.2.2 确定质量成本 7.2.2.1 直接质量成本 7.2.2.2 间接质量成本 7.2.3 识别质量角色与职责 7.3 质量计划的实施 7.3.1 执行质量计划编制的关键 内容 7.3.2 制定质量管理计划 7.4 质量保证管理 7.4.1 质量保证的关键活动 和行动方案 7.4.2 项目经理的质量保证 活动 7.5 质量控制管理 7.5.1 质量控制的结果 7.5.2 质量控制的方法 7.6 质量验收和测试的绩效 7.6.1 厂房验收测试（FAT） 计划编制 7.6.2 现场测试和验收的计划编 制 7.6.3 获得客户的接受质量计划 的实施

7.1 质量管理概述 项目质量管理包含了为保证项目符合每个规定的项目要求以及尽可能最大程度地满足项目利益相关者的需要得到满足所必须的全部过程。对质量进行管理是在项目中工作的每位个体的责任，并且在项目生命周期的全过程中将其融进每项作业中。这一理念在H企业质量政策声明中得到了体现： 全面项目质量能使项目利益相关者满意。 H企业 IAC的每位职员必须承诺永远追求全面质量，也就是要求我们做的每一件事情都必须达到优秀。 我们频繁地按照一流的实践基准来衡量我们在朝着这一目标努力中所取得的进步。我们的目标并不仅仅是持续改进。我们要力争不断地取得业绩上的突破以使IAC持续并拓宽其世界范围内的领导地位、 我们对全面质量所作承诺的结果是：使项目利益相关者－客户、职员和股东满意。他们又会奖励我们以忠诚和赞许。

7.1.1 质量管理过程 质量概念的运用 质量保证管理 质量控制管理 检测和验收 质量 计划的制定

只有在每个项目中全面应用质量概念，质量管理过程的作用才会得到体现。它强调发起并持续进行质量计划活动。该过程也融进了质量保证、质量控制以及测试和验收过程中。这些质量管理活动符合H企业对ISO9000标准的承诺，也遵从了已建立的质量指南。 质量管理与全面的项目管理紧密地联合在一起。一些关键活动会非常关注与质量相关的问题。此外，保证项目质量的过程首先必须理解项目需求，按着为实现这些需求制定一个项目计划，并且要与项目所有的活动紧密地联系在一起。

7.1.2 质量管理要素 质量概念－理解质量管理暗含的深义及问题以使项目管理职员更有效地实施质量管理。 7.1.2 质量管理要素 质量概念－理解质量管理暗含的深义及问题以使项目管理职员更有效地实施质量管理。 质量计划－识别项目目标以及对实现目标非常关键的所有活动和事项，分析这些活动和事项的重要性，制定与重要程度相对应的控制措施，并把控制措施融进项目的所有管理中。 质量保证－提供这样一种信念：项目管理过程将满足项目的所有需求。质量保证的职能是实现质量（防止缺陷）、验证质量并保证质量。质量保证包括的范围很广，而不仅仅是质量控制、测试和验收。它是保证项目质量的核心，它要求组织中的每位员工都必须阻止缺陷的发生，以及纠正缺陷。其重心是质量改进。 质量控制－测量或验证项目需求的属性及性能标准。当实际情况不符合项目需求的属性及性能标准时采取行动。质量控制是质量保证中的关键部分。 测试和验收－针对每一个关键的产品和系统实施的系统测试和验收。客户代表在措施前批准测试和验收计划，并积极地参与测试（如果需要的话，证实测试的进行），还需批准对测试结果进行归档。测试和验收是质量控制的一部分。之所以把它分离出来，是因为它受客户的驱动。而且它把产品和系统质量过程看作是特殊的质量控制因素来处理。

7.2 质量概念的运用 质量管理是很好的商业实践。当质量管理作为有效的管理工具来使用时，项目团队成员要把精力集中于防止错误发生、符合项目需求、改进过程削减返工和延期中发生的显著成本。只要坚持把质量概念应用于所有项目中，它就会变成一项资产。它能够增加股东的价值，使投资者满意，还可以加强与供应商的关系及得到员工认可。

7.2.1 质量定义 美国项目管理协会（PMI）把质量定义为：“一个实体的特性总和，它反映了实体能否满足明确需求和隐含需求的能力”。PMI出版社，《项目管理知识指南》（Sylva，NC，PMI出版社，1996）。如上述定义所述，对质量进行定义的最大困难在于理解和界定“明确的需求和隐含的需求”。每个项目都有许多利益相关者，每个利益相关者的需求不同，需求的详细程度和精确程度也不同，而且这些需求还会随着时间发生变化。为成功地对质量进行定义，对一份清晰的项目需求说明书进行界定、归档及达成一致意见是必要的。

7.2.1.1 质量要素 满足商业需求 实现项目计划 符合规范和需求 客户满意度

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

7.2.1.2 产品质量和过程质量 测试和检查是为了识别有缺陷的产品，并防止其到达客户那里。通过质量控制来识别产品的缺陷是质量管理计划中的一个必要且重要的内容。它有利于保证产品质量，并可以带来不断地改进。对产品进行分析要注重如下问题：发生了什么缺陷？怎样发挥潜能以改进产品并减少未来缺陷的个数？ 其实，显著的质量改进的好处是能够去更深地发现哪些过程导致了缺陷的发生，并恰当地改变这些过程。对过程的质量进行测量包括检验项目计划中的步骤完成情况，以及其是否符合工期安排和预算。当参照项目计划中的工作包或活动相关的产品质量标准时，项目管理方法应该明确地强调后者。

7.2.1.3 质量与标准 在项目管理背景下，可接受的性能最低水平称作质量。质量要实现这些标准和需求。质量和标准都有许多不同水平。这些术语在日常生活中可以交换使用。但是在描述制造的产品、安装的系统或过程时则不可以交换。

质量和标准组合图 质量 标准 高质量 低标准 高标准 低质量高标 准标准 低质量

7.2.2 确定质量成本 与质量相关的成本包括可量化的和主观性成本，项目或企业的直接费用以及没有专门会计记录的成本。 7.2.2 确定质量成本 与质量相关的成本包括可量化的和主观性成本，项目或企业的直接费用以及没有专门会计记录的成本。 质量成本包括质量的直接成本和质量的间接成本 两部分。 对项目采取的质量措施都有与其相关的、直接的、可测量的成本。质量的直接成本可以从符合或不符合规格说明书来进行描述。 质量的某些成本不是很容易就能量化的。这些质量的间接成本是由交付低质量的产品和服务造成的。 间接成本一般都是主观性的，不会显示在公司的会计上。但是项目人员可以跟踪对间接成本的测量。公司拥有诸如商誉和商标价值等方面的受间接成本影响的资产。

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

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

7.2.3 识别质量角色与职责 有着良好结构的质量管理过程对于一个项目的成功实施来说极端重要。但是，如果没有每个项目团队成员的积极参与并承诺，大谈特谈质量问题是不可能的。 全面质量管理（TQM）是企业范围内的努力，它要求组织中的每个人都要致力于改进绩效。它涉及公司的每个方面，并把质量当作首要的战略目标。TQM必须由不同层次人员共同努力持续地改进绩效以增加客户满意度来实现。建筑行业协会（CII），全面质量管理：竞争的边缘，10－4（Austin，TX：C22，1990年4月） 所有项目团队成员在他们的工作中都有责任监测和控制项目质量。但为了实现真正成功的质量管理，项目团队以外的全组织的支持和承诺也是必须的。

H企业 IAC区域日常运营实践手册中列举的关键质量实施活动 IAC总裁－IAC总裁必须执行战略水平的质量活动以： 界定H企业 IAC的质量政策 制定商业运转的基本原则 区域管理层和管理层代表－指导区域日常运营的主管和经理要负责在各个区域内执行IAC质量政策。他们： 为执行区域的质量管理体系发展和维持政策、程序和实践。 发展一个能胜任的具有权力的人员以通过实现他们的角色和职责来保证质量。 通过周期性的评审以保证质量管理体系的有效性。

项目建议书的经理及其小组－项目建议书的经理及其参与人员负责界定最初的质量。他们： 在售前谈判及签订合同并收到客户订单时，把特殊的客户需求转变成一个系统的项目建议书。 保证必要文档的顺利移交，以及为那些尚需移交的文档显示承诺信息。 项目经理/区域项目总监和职能经理－该管理阶层既要看到众多的项目需求，又要看到每个客户的特殊期望。这些管理人员在项目经理完成项目的过程这给予建议和指导，并且监督质量的诸方面。其职责是： 发展、执行并保持与地方产品和环境相适应的实践。 保证地方实践符合质量管理体系。

项目经理－项目经理负责项目的最终成功，因此，他要负责项目全面质量的实现。然而，因为质量只有在每个团队成员的共同承诺下才能实现，所以项目经理必须把项目质量的责任具体到团队的每个成员。通过组织和领导技能，项目经理必须能够为产生、监测、跟踪、分析及改进质量创造一种相协调的环境。项目经理要保证每个个体在工作的各个阶段都积极地参与到质量管理体系中。项目经理所需负责的具体活动是： 号召每个团队成员针对其工作内容用可测量的、主观性的术语清晰地界定客户需求。 把客户需求融入详细完整的项目计划中。 保证把所有活动分解成全部用易于测量和跟踪的成本、工期、依赖关系、质量、完工标准等描述的可管理的任务。 鼓励由负责作业实施的团队成员制定作业说明书，并因此逐渐获得完成作业全部内容的所有权。项目经理必须－ 识别、产生和保持质量记录以监测每项作业是否按照规定的管理实践实现所有客户的需求。 制定每个项目的质量管理计划，该计划可作为支持文件包括进项目计划中；针对该质量管理计划与H企业管理层就客户需求进行协调。 保证项目计划和质量管理体系按照一种既制度化又及时的方式并周期性的升级。 与客户保持频繁地接触以确定其理想的期望和满意。 这些活动的性质因项目而异。但是，在所有的项目中，这些活动中的任何一个都可以包括进项目计划中，并例行对其进行管理，这样就能保证质量成为项目实施整体中不可缺少的一部分。

项目团队－项目团队成员必须理解并认真履行他们在项目中的角色。这些角色都不相同，但是一般都包括如下职责： 参与制定项目计划以恰当地融入到他们所负责地工作中。 按照项目计划实施他们的工作。 对产品、过程和质量体系问题进行识别、报告和归档。 采取措施以防止与工作相关的不合格产品和服务的发生。 提供精确而及时地绩效和进度报告。

7.3 质量计划的实施 质量应该作为保证客户满意和减少或删除质量的无关成本的重要工具加以计划，而不是加以检查。质量计划必须与其它项目过程的计划一起重复地进行。例如，质量计划要求必须完成工作分解结构（WBS），这样，才能对每项任务和活动进行风险评估。该风险评估的结果可能是为WBS增加一项检查任务或其它的质量需求活动。因此，直到质量计划识别出所有的与质量相关的任务，WBS才能完成。

质量计划的结果 一份描述如何执行质量政策的质量管理计划。 详细描述测量什么以及如何测量的操作定义。 帮助团队成员在特定的时间内完成所有活动的清单。 增加给WBS的为不同质量活动提供的额外工作包。

7.3.1 执行质量计划编制的关键内容 识别项目目标和需求 分析每个目标和需求的风险——该分析过程应包括识别和分析 建立控制的测量步骤 7.3.1 执行质量计划编制的关键内容 识别项目目标和需求 分析每个目标和需求的风险——该分析过程应包括识别和分析 建立控制的测量步骤 归档控制的衡量步骤

识别项目目标和需求 该活动可以在定义项目范围时完成。制定一份WBS和WBS词典可以起到对其的协调作用。项目目标和需求可以从如下几个重要来源加以识别： 项目合同 图纸和规范 规章制定机构 企业政策和标准 项目工期和成本需求 相关的项目 重要人物对上述内容的解释

为恰当地识别目标和需求，项目经理应该： 评审和分析所有声明的需求 归档任何文字的或暗含的需求 解决矛盾；理解客户期望 与客户（其满意对项目的成功来说很关键）就最终的需求清单达成共识

分析每个目标和需求的风险 该分析过程应包括识别和分析： 然后，采取措施以减缓任何潜在的失败模式或减少它们的发生。 潜在的失败因素 失败发生的概率 失败的影响和严重程度 现有控制是否恰如其分 由现存控制进行失败检测的可能性 然后，采取措施以减缓任何潜在的失败模式或减少它们的发生。

建立控制的测量步骤 这一过程着重为质量措施或问题评价每个项目任务或可交付物并评估每项任务的风险以识别是否需要采取特殊的质量控制步骤来减轻风险。

归档控制的衡量步骤 该活动要求把控制的衡量步骤、检查、监理和检测集成进项目的整体质量管理计划中。只要项目需要，任何新的任务都要加进WBS、工期和预算中。另外，还需识别出执行和管理质量过程所需的资源。

7.3.2 制定质量管理计划 质量管理计划是项目计划中不可缺少的、起支持作用的一个部分。它对质量计划的关键内容进行了归档，旨在为项目中对质量负有责任的每一个人使用。为确保关键质量内容的评审和集成，特提供制定质量管理计划的核检清单以备使用。

7.4 质量保证管理 质量保证是指执行“有计划、有系统的必要行为，以此提供对一个产品、过程或服务的足够信心，相信它们将会满足已建立的需求”。建筑行业协会，质量绩效管理体系：实施蓝图。出版10－3（Austin ，TX：CII，1990年2月）质量保证几乎一直被认作是一种管理责任，它取决于项目经理为保证质量（或防止低质量）及验证质量所作的参与。所有对计划了的质量保证活动和措施的描述归档之后可加进质量管理计划中。其实，真正的产品质量保证就是质量改进。

7.4.1 质量保证的关键活动 和行动方案 评审和修正项目计划内容（特别是项目需求、工作描述、WBS、WBS字典、项目工期、成本分析、质量管理计划和风险分析）以保证项目过程支持项目目标。 分析质量控制措施 进行成本/收益分析 标杆学习 流程图法 执行设计好的实验 参与企业的TQM，项目管理信息系统和质量保证/质量控制计划

7.4.2 项目经理的质量保证活动 评审进度的合同或采购定单以确定技术和质量需求，并分析这些文件是否有矛盾、错误、疏漏之处。 7.4.2 项目经理的质量保证活动 评审进度的合同或采购定单以确定技术和质量需求，并分析这些文件是否有矛盾、错误、疏漏之处。 控制设计过程以促进质量，主要通过发展并保持精力于性能、可靠性、施工能力、可维护性、安全、标准化、互换性和成本。 组合下列采购过程： 保证挑选对质量有明确承诺的供应商和承包商。 把详细的技术、质量和质量计划需求包括进采购文件中。 要求评审和批准任何需要提交的文件 要求证实、检查或测试供应商的材料和安装。 要求通知和批准供应商或承包商的设计、材料或质量计划变更。 参照项目需求评估供应商或承包商的绩效。 要求对缺陷和质量不利的条件采取纠正措施。 控制交付和和储蓄程序以保证只有被接受的材料和产品才能进入项目中。 控制对防止损害或损失事项的处理、清洁、防腐、储存、包装和装运。 控制不符合特定需求的活动和事项。 识别并快速纠正对质量不利的条件。 控制文档化的程序以包括进明确、产生、评审、批准和归档质量文件。

7.5 质量控制管理 质量控制是指验证项目需求的属性和性能标准，以及采取的措施。几乎所有的项目团队成员都对质量控制负有同等程度的责任。在制造、施工或其他产品或服务的交付物开发中的技术人员和监督员要对客户直接观察到的质量控制负责。因此，项目经理必须保证团队成员高度关注质量并对质量控制过程进行恰当地调整以在项目中使用。 项目质量控制涉及对项目工作的观察和测量，以对比较项目结果和项目需求。

7.5.1 质量控制的结果 带来一个验收决定 或采取措施 过程调节。 边际/少量产品或体系的返工。 移除和替代缺陷。

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

7.6 质量验收和测试的绩效 特征： 测试是客户为要求验收而进行的。 客户合同和规范包含了与测试和验收相关的确切要求。 在测试前，客户要草拟、评审和批准详细的测试步骤。 质量测试和验收涉及到来自H企业和客户中地若干人，因此重要的测试和验收计划编制通常是必须的。测试准备涉及范围非常广。在测试和验收的例子中，周围的厂房要处于正常运作，而不能受干扰。

7.6.1 厂房验收测试（FAT） 计划编制 如果需要的话，厂房验收测试是参照PO、合同、图纸和技术规格说明书在制造的产品和系统装运到安装地点之前在厂房中进行的。在一个更有助于执行质量工作而不是安装点的有力环境中，设备测试能促进对缺陷的检测和纠正，并作些调整。它能够减少安装和测试工作现场的工作量，削减因安装问题或紧接着的测试失败所导致的工作延期方面的潜在机会。

厂房验收计划编制内容 一般内容 测试内容 验收内容

一般内容 测试地点、日期和时间地确定 对什么应该测试以及一份测试方案概述进行描述并制定工期 识别测试参与人员及他们的职员 评估任何必须的特殊设备 识别需要的文档 确定期望的结果（比如系统校准、制定一份穿孔器的清单或对装运的批准）

测试内容 描述最终产品如何符合每一个标准和性能需求 设计需要完成的测试，并明确如何满足每一个客户的需求 对表明了每个系统部件性能需求的步骤进行描述 规定将由谁在什么条件下进行测试

验收内容 对用来正式归档客户需求的步骤进行描述 制定可测量的客观的验收标准 确定验收过程和参数，比如: 客户是否将逐步地接受系统的部分 逐步增加的测试是否将带来最终的验收 最终的验收是否将证实之前所有的测试是成功的 在测试中是否将允许系统维修

7.6.2 现场测试和验收的计划编制 现场测试和验收（如果需要的话）在本质上与厂房验收测试相似。最大的不同之处在于现场测试和验收是在客户的设备上进行的。 注意事项： 现场经常是处于全面或部分产品的运作中。因此，测试会涉及高风险并且需要额外的计划编制和调整工作。 环境因素，诸如闹音、温度、physical access以及项目中未涉及的操作人员的在场等，都可能不利于测试的进行。 但是，计划编制的程度和步骤与之前厂房验收测试所描述的类似。

7.6.3 获得客户的接受 客户验收的获得是一个持续且需要组织好的过程。它涉及频繁获取明确的项目需求的提前结束，注意客户的总体观察和感知，并传达这种整体意念，即项目正在以一种能胜任的小心谨慎的方式实施。 由客户确定所有进入验收的质量计划内容。

第八章 项目集成管理案例

8 变更管理 8.1 变更管理概述 8.1.1 定义变更 8.1.2 变更管理计划 8.2 建立变更管理战略 8.3 变更管理的实施 8 变更管理 8.1 变更管理概述 8.1.1 定义变更 8.1.2 变更管理计划 8.2 建立变更管理战略 8.3 变更管理的实施 8.3.1 沟通和变更过程 8.3.2 变更监督控制 8.4 识别变更需求 8.4.1 识别变更需求 8.4.2 提出和跟踪变更请求 8.5 变更评价

8.1 变更管理概述 主要内容包括： 计划如何管理变更 确定变更的实际需求 管理那些确实必要的变更

变更管理过程 编制变更 管理计划 实施变 更管理 识别变 更需求 变更评估 批准变更 并文档化 执行变更

8.1.1 定义变更 变更是那些偏离计划以及合同规定的事件、行为或者项目的规格。 8.1.1 定义变更 变更是那些偏离计划以及合同规定的事件、行为或者项目的规格。 在项目中通常有两种变更，这些变更可能是由团队内部产生的也可能是由团队外部产生的： 正式变更 ——记录分歧，并对合同进行正式的修改。所有的参与者（业主、合同工程师、卖方等）都应该意识到执行变更的结果并同意变更的安排。 这些变更通常包括在合同的变更条款中（见合同管理部分）。 建设性的变更——提出变更请求但不不作记录，这类变更通常只是作为某人指挥的结果，而不是客户采购机构或对客户负有法律职责的其它代理结构指挥的结果。

进行项目范围管理 许多项目都有必须保持范围控制的过程和交付系统。 这个范围控制不仅指交付系统，而且包括所有的计划、图纸、员工培训、以及其它保持系统完整的因素。 范围控制同样也可以运用到服务中。范围管理意味着契约导向。 它确保项目所有的层面都和客户需求相一致，并且帮助项目避免不必要的变更。 它可以筛选客户的需求，正式地跟踪已接受的变更，并确保期望的变更能够在交付系统中实施。

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

检查可能引起变更的因素 计划中的变更事件 项目团队命令的变更 机遇变更控制委员会结果的计划调整和变化 计划中包括的客户需求或者规格的变化的决策点，以及工期和文档等 需要加快工期

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

检查项目和合同的基线 为了识别出项目中可能引起变更的潜在因素，必须对所有的项目文件和合同文件（项目和合同的基线）进行深入地检查。 初始风险和机遇评估文件也必须由财务经理、合同经理以及顾问等进行审查检查，并编制出风险和机遇管理计划，该文件描述了所有风险和机遇以及相应的风险和机遇战略。 这个文件还识别出了项目潜在的变更。 最后，如果公司以前曾经为这个客户服务过， 过去的项目经理能够提供一些关于该客户处理业务的方法，如该客户偏好如何出来变更以及该客户是否热衷于提出变更等。

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

8.2.1 编制变更管理计划要求 识别评估和批准变更的角色 描述如何修改客户的需求文件才能体现被批准的变更 8.2.1 编制变更管理计划要求 识别评估和批准变更的角色 描述如何修改客户的需求文件才能体现被批准的变更 定义变更控制记录跟踪以及变更通知程序 识别配置管理者和项目管理者的名字 定义执行变更控制的责任 如果合适的话，指出变更控制委员会的成员 识别行业或者合同对变更的具体需求

8.3 变更管理的实施 在签定合同的时候， 项目和合同基线都已经确定下来了。在项目开始之前以及在项目启动的会议上都要对项目和合同范围内的工作以及工作的进度安排进行审查，这样项目成员才会对项目基线有一个相同的理解。 在这一点上，任何偏离基线的情况都需要作为“变更”， 根据制定的管理程序和合同中的要点以及变更管理计划来管理。

8.3.1 沟通和变更过程 沟通的需求是持续的，但是对于项目变更而言，在两个点引入和增强项目变更管理过程会达到长久的效果。 8.3.1 沟通和变更过程 沟通的需求是持续的，但是对于项目变更而言，在两个点引入和增强项目变更管理过程会达到长久的效果。 第一个发生在客户提议审查会议上，在这个会议上确定了管理变更的基本原则，并在利益相关者之间达成协议。 第二个沟通关键点在项目启动会议以后的变更管理过程。 在这个点，要进行合同的签订，还要规范项目变更管理过程。 沟通过程必须持续地作为项目管理过程的组成部分。应该在项目和合同生命周期中加强变更管理的需求，团队成员对于任何新的迫近需求保持一致。

8.3.2 变更监督控制 在执行变更管理功能的过程中，必须开始变更控制和监督。要建立一个变更控制日志来跟踪所发生的变更。 8.3.2 变更监督控制 在执行变更管理功能的过程中，必须开始变更控制和监督。要建立一个变更控制日志来跟踪所发生的变更。 变更控制要求持续不断的监督。这种监督通过生成或者接受周期性的报告来完成。为了识别出那些可能引起为了变更的问题，必须对现场经理、分包商和其它团队成员的周期性报告进行审查。项目状况和管理报告还应该每月审查潜在变更和变更请求的检查点。

8.4 识别变更需求 在项目和合同的生命周期中，想法和需求不是项目工作范围基线所规定的，而是来源于项目团队内部和客户。这些对于项目工作范围的背离就成为“变更”，并需要进行评价以决定影响的大小。 在某些情况下，变更请求不需要预算和时间的花费，为了保持良好的客户关系而接受并执行变更。而有时候提出一项变更则会比真正地执行它要花费更多的成本。 任何情况下，变更必须要在变更控制记录中记录，以免以后发生问题。

8.4.1 识别变更需求 分包商可以识别那些需要改变或者扩大他们努力范围的需求。 团队内部的成员可以识别能够提供更好结果的新技术和方法。 8.4.1 识别变更需求 分包商可以识别那些需要改变或者扩大他们努力范围的需求。 团队内部的成员可以识别能够提供更好结果的新技术和方法。 客户可以提出需要扩大范围或者缩短工期的变更请求。

8.4.2 提出和跟踪变更请求 项目团队与客户的合作开始启动项目变更请求和评估表，这个表格保证在评估过程中执行必须的步骤，并使变更得到恰当的批准。同时，这个标格还为积累信息提供了框架，这些信息将是发给客户的变更请求的基础。 当很大一部分变更已经发生以后，有些项目可能计划去执行那些成本要低于开始给定变更成本的变更， 即使这样，也需要对变更进行评估和跟踪；而且这个战略也需要在执行变更之前要得到客户的认可。

8.5 变更评估 理解变更 估计变更影响 准备变更计划 准备下达 变更指令 变更评估的过程

理解变更 最初的变更评价表作为合同修订文件（变更请求、提议等）的基础，因此必须清晰地描绘出相对于基线的变化。一旦理解了变更的全部区间，就应该用语言来描述出变更的影响，以及变更的其它关键因素(即，提出的变更是什么，以及会造成什么影响，采取什么行动等) 。项目团队应该在估计成本和工期影响以及开始工作之前，和客户一起检查上述信息是否准确、完备。

第九章 项目风险管理案例

9 风险与机会管理 9.4 风险与机会分析 9.1 风险与机会管理概述 9.4.1 风险与机会分析方法 9.1.1 风险与机会概念理解 9 风险与机会管理 9.4 风险与机会分析 9.4.1 风险与机会分析方法 9.4.2 确定风险发生对成本的总影响 9.4.3 确定风险与机会的发生概率 9.4.4 计算净风险与机会值 9.4.5 确定风险影响的数学方法 9.4.6 风险与机会优先级排序 9.5 制定风险管理计划 9.5.1 确定降低与优化行动 9.5.2 应用于各领域的机会优化策略 9.5.3 降低与优化行动评估 9.5.4 准备风险管理计划 9.5.5 项目风险管理计划的评审批准 9.5.6 风险和机会应对措施的控制 9.1 风险与机会管理概述 9.1.1 风险与机会概念理解 9.1.2 风险管理责任分配 9.2 投标前风险与机会评估 9.3 风险与机会识别 9.3.1 风险和机会识别步骤 9.3.2 有效的风险与机会识别技术 9.3.3 运用WBS识别风险与机会 9.3.4 风险与机会整理合并和归类

风险相关的一些费用 风险与机会管理概述 投标前风险与机会评估 风险与机会识别 风险与机会分析 制定风险管理计划 风险和机会应对措施的控制

9.1 风险与机会管理概述 风险管理是识别、分析和应对项目风险和机会的过程。它包括最大化正面事件的结果和最小化负面时间的后果。 9.1 风险与机会管理概述 风险管理是识别、分析和应对项目风险和机会的过程。它包括最大化正面事件的结果和最小化负面时间的后果。 为了在国内和国际市场中竞争，能在工业自动化操作和控制行业上赢得市场份额，H企业所出售的产品和服务必须提供最优的整体价值。要实现这一目标，通常需要承担和接受一定程度的风险。在项目实施和风险管理的过程中，确定一个可以接受的风险水平对项目成功是必要的。 风险和机会是日常生活的一个组成部分，而且只有及时、全面地认识和处理它，才能对其进行有效管理。在H企业，风险管理是企业管理的一个重要组成部分。风险和机会可以在起初的概念阶段及随后制定项目工作范围和标书的计划阶段加以识别。在计划阶段，还要制定风险管理计划来降低风险和优化机会。然后实施该计划，并对结果进行跟踪。对风险管理计划进行更新必须贯穿于整个项目管理生命周期中。

风险管理流程 风险管理 详细的风险评估 投标前的 风险和机 会评估 风险和 机会识别 机会分析 制定风险 管理计划 机会应对 控制

投标前的风险和机会评估——会计主管在咨询/解决主管和项目经理的支持下，进行高层次的风险和机会检查。当潜在的项目工作尚未知晓时，这种评估主要是证实项目的机会。评估主要关注于合同风险，评估结果用于准备项目大纲。 风险和机会识别——在制定项目标书期间，要进行详细的评估，首先确定可能会影响项目的风险和机会，然后进行归类，并将每个风险的特性编制成文档。这种评估更详细地反映了合同风险，除此外还包括关注于成本、进度和绩效风险和机会。 风险和机会分析——详细评估还要对所有风险继续进行分析、验证和优化，并对可能的项目产出物范围进行评价。 制定风险管理计划——有效的风险管理需要在风险管理计划中制定风险降低和机会优化策略。该项计划对项目生命期内用于管理风险和机会的程序进行文档化。投标报价超过500，000美元，包含一个或多个已识别的风险因素的项目，需要由风险因素评审和批准矩阵中指定的管理层级进行评审和批准。

9.1.1 风险与机会概念理解 每个风险和机会由以下三个基本要素构成： 一个可定义的事件 发生概率 发生后的后果（影响）

区分风险的其它特征还包括如下： 风险是会发生情境变化的——它们会发生动态变化，从一种情境转变到另一种情境。对风险管理工具和技术的有效应用能帮助降低风险。 风险之间是相互依赖的——它们往往是相互关联的。降低其中一个风险可能引发另一个风险或增加一个以存在的风险的不良影响。 风险量级是随其它因素而定的——收益越大，可接受的风险量级越高。风险接受水平依各人不同情况而定。 风险是基于价值观的——个体和公司的价值观都会影响对风险的接受。 风险是基于时间的——风险是当前行动所导致的一种未来现象。时间会影响对风险的感知和理解。

9.1.2 风险管理责任分配 项目的不同参与方： 会计经理和咨询/解决经理 项目经理 合同经理 项目团队成员

会计经理和咨询/解决经理 在起初的项目机会确认和验证期间，开展高层次的风险和机会评估。 根据初步风险和机会评估结论制定项目大纲，并向地区业务团队阐述，用于投标/不投标的决策。 在恰当的时候，与客户一起商讨风险和机会。

项目经理 确保对风险和机会进行了全面的识别和评估。 评审风险管理结果，并将结果合并纳入到项目投标书中。 在投标期间降低可能出现的风险。 评审风险，并获取风险因素评审和批准矩阵对风险管理计划的批准（见本核心功能下一小节“批准风险管理计划”）。 阐述风险和机会数据资料，以及降低和优化策略，以此作为投标报价的一部分。 制定风险管理计划。 定期进行风险和机会评审，评估新的风险和机会，并更新风险管理计划。 维护和保存反映已识别风险和机会的潜在财务影响的当前纪录。 向公司管理层通报项目进展和风险状态。

合同经理 确保标书中的对风险和机会的评估同H企业的政策相一致。 为风险和机会评估提供帮助和便利。 识别和发现投标邀请函/报价邀请函的各种变更，以此来降低潜在的风险。 完成对风险和机会的合同管理评估。 确保遵守和符合所实行的公司、团队政策和收入分配政策。 同客户进行协商谈判，以此降低所识别的风险和优化所识别的机会。 将协商谈判结果合并纳入到项目融资发布中。

项目团队成员 当发现新的风险或机会时，及时通知项目经理。 支持项目经理制定和实施风险降低和机会最大化战略。 帮助项目经理修正和提高降低风险和优化机会战略的有效性。

9.2 投标前风险与机会评估 会计经理，咨询/解决经理和技术设计师评审项目定义文件，制定一个概念化的解决方案，并识别该项目机会和实施中的各种潜在风险和机会。 尽管在项目生命期早期阶段对项目的机会知之甚少，但还是必须对机会进行高层次的评估。该步骤提供的高层次的风险和机会评估将合并纳入到项目大纲中，并向公司地区经营团队阐述，用于投标/不投标的决策。管理层需要该信息来做出一个明智的决策。如果潜在的风险比较大，而潜在的收益与风险不匹配（不令人满意的风险/收益率），管理层可以决定不在追求该项目机会，放弃投标。目标是在发生巨大的投标费用前，清除那些边缘临界项目。

高层次的风险和机会评估活动 筛选项目机会来确保这种项目机会与H企业的工业自动化和控制业务目标相联。 进行高层次的成本/收益分析，以确定获取潜在收益所涉及的风险和获取收益的机会。 评审概念化的解决方案，并基于当前技术评估其技术可行性。 制定高层次的风险降低和机会优化策略，以此降低潜在风险的影响和将潜在机会最大化。

9.3 风险与机会识别 项目内部和外部的风险都必须加以识别。内部风险可以受项目团队控制和影响，如资源分配或进度、成本估算。外部风险是那些项目团队不能控制或影响的风险，如客户决定，市场转变或政府行动。

项目内部风险 ●新的或未经试验的技术 ●技术专家的可获得性 ●用户化和专用化（设计风险） ●材料的可获得性 ●制造（生产）能力 类别 风险因素 技术 ●新的或未经试验的技术 ●技术专家的可获得性 ●用户化和专用化（设计风险） ●材料的可获得性 ●制造（生产）能力 ●分包商/卖方绩效 ●将设计移交给生产 进度 财务 法律

项目内部风险 类别 风险因素 技术 新的或未经试验的技术 技术专家的可获得性 用户化和专用化（设计风险） 材料的可获得性 制造（生产）能力 分包商/卖方绩效 将设计移交给生产 进度 资源可获得性 进度约束 不充分的计划 不充分的信息 财务 融资或客户预算 估算准确性 人工费用缩减 材料成本变更 法律 专利权或侵权 数据资料权 政府政策 合同模糊

项目外部风险 类别 风险因素 不可预测的 规章制度变化 自然灾害 环境影响 公共利益 可预测但不确定的 市场变化 通货膨胀 税率 汇率

风险和机会应在以下时候进行识别： 创建一个详细的项目工作范围 制定一个详细的项目工作分解结构 准备详细的资源、进度和成本估算 确定一份清晰明确的标书和合同基线

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

9.3.2 有效的风险与机会识别技术 核检清单 德尔菲技术 头脑风暴法 名义团队技术 类推技术

核检清单 核检清单通常由风险来源构成。风险来源包括项目环境（项目生命周期，组织结构，项目利益相关者，项目管理技能或社会经济影响）；项目产品或技术问题；合同因素；其它项目因素，如成本，进度，资源或采购。

德尔菲技术 团队从多位专家中获取他们对具体特定问题的观点和相应理由。 团队成员将这些观点和理由整理和归纳成标准的表述。 团队成员向各位专家说明所有受咨询的专家的整合观点。 团队成员要求各位专家在此基础上进行重新评估和更进一步的证实。 团队成员和专家之间继续进行反复的反馈，直到不再存在进一步的变化为止。 团队成员接受专家们的最终观点，并计算出其中的平均值代表团队的观点。

头脑风暴法 要求每位团队成员提出有关项目潜在风险和机会的输入。 鼓励团队成员产生新念头或详阐述其它团队成员的新念头。 指定一个团队成员记下所有提出的念头——不评估或丢弃任何一个念头。 当团队成员输入完所有风险和机会后，团队按照列出的风险和机会清单继续进行头脑风暴会议，一起商讨每个念头的优点。排除一些风险，并对保留下来的风险进行整理、合并和归类。 总结归纳结果，并将其作为团队项目风险和机会的输出。

名义团队技术 每个团队成员写下其所能看到的主要风险和机会，每个团队成员之间不发生语言上的沟通。 每个团队成员从其列出的风险和机会清单中宣读每一条，然后把每一条记录在团队前面树立的翻动图板上。 该过程一直持续到团队成员清单上的所有条目都宣读和记录完以后。 每个团队成员都各自对风险进行排序和归类。 将结果制成表格。

类推技术 团队识别所需的信息。 团队识别类似的项目或类似的项目片块。 团队收集有用的数据。 团队将当前项目与先前项目进行比较，以此识别潜在的风险和机会。

五种技术优缺点对比 核检清单 容易操作 不需要一个推动者 只是应急权宜的，且时间上分散不紧密。 仅仅只关注于核检清单会遗漏未列出的一些风险

德尔斐技术 避免集中于一种单一思想训练的倾向 许可不带偏见的专家意见 需要进行大量分析 耗时 没有考虑团队交互作用

头脑风暴法 激励团队创意 需要一个有力的推动者来防止创意生成前进行评估 允许坦率直言的个体在整个会议上自由发表意见，控制整个过程 树立一个较大的团队压力，这种团队压力可以导致一些好的创意获得通过 时间上紧密

名义团队技术 避免交互式方法所带来的观点压抑问题 避免过早开始对创意进行评估的倾向 避免关注于一个单一思想训练的倾向。

类推技术 鼓励从过去错误中学习 防止“重现创造轮子”（重复劳动） 如果存在所学到的教训资料，则可提供获取该类教训资料的简单通道 时间上紧密 需要应用相关的历史数据，这些历史数据可能较难获得 所用的历史数据可能对于新的实施项目并不正确 。

9.3.3 运用WBS识别风险与机会 合同文档，尤其是WBS，能确保项目每个领域的潜在风险和机会都被提及，从而提供了一个极好的识别风险和机会的参考框架。 如果大量的工作包使得在工作包这个层级进行风险识别变得不合实际时，项目经理可以选择在更高层级上进行风险识别。但是无论选择在哪个层级进行识别，都应该对WBS要素进行评审，每次评审一个要素，提出以下几个问题： 什么东西可能会影响该项工作任务？ 是否存在会影响该项工作任务完成的风险？ 该项工作任务中是否存在可以转化为资金的机会？ 该项工作包是否在关键路径上，因而是否需要特殊的关注？ 当识别了各种风险和机会后，应将代表所有参与者全部观点的这些风险和机会列出。仅仅是列出这些风险和机会，而不对这些风险和机会的效度进行任何判断。

9.3.4 风险与机会整理合并和归类 项目团队运用确定的风险和机会列表来讨论每个风险和机会的效度。对一些问题进行澄清和阐明，团队就可以排除一些不重要的风险。 在排除了一些不重要的风险后，团队应重新评审和整理合并列表。该步骤是很重要的，这样团队成员便能得到一份规模上可管理的列表。 在对列表进行了整理合并后，应对列表上的风险和机会进行分门归类。这种归类在随后制定风险降低和机会优化策略，风险管理计划时会有帮助。

9.4 风险与机会分析 输 入 步 骤 输 出 风险和机 会的归类 清单 确定发生 的总成本 影响 估算发 生概率 计算净 风险和 机会 9.4 风险与机会分析 输 入 步 骤 风险和机 会的归类 清单 确定发生 的总成本 影响 估算发 生概率 计算净 风险和 机会 用于跟踪的 风险和机会 排序清单 机会优 先级排序 输 出

9.4.1 风险与机会分析方法 定量方法——对每一个风险或机会事件赋予一个数值。例如，概率表述为有50％的发生可能性，成本影响表述为美元，进度影响表述为周或日。 定性方法——风险可以通过一个采用形容词（高，中，低）来表示次序的排序等级系统进行表述。在定性分析中无法获得具体数据来进行定量决策，因此需运用一个比较主观的尺度，采用语言形式诸如“这事件将发生的概率为中等”和“如果发生，将产生很大的影响。” 描述性方法——对风险进行描述，这可能会防止某些事件发生或指出风险来源以及可能的控制措施。

9.4.2 确定风险发生 对成本的总影响 风险影响就是风险事件值——一旦风险事件发生将会导致的收获或损失的估算值，项目团队一次评审一个风险，并确定一旦风险事件发生后对所有相关合同领域的影响。这种影响可能是影响成本，进度或范围，质量，或以上各种的组合。团队不仅应定义影响的大小，而且还应定义哪个项目要素会遭受最大影响。 如果可获得充足的信息，应采用比较全面的定量方法。反之，则可以采用简单的定性方法，基于对风险的主观评价赋以风险“高，中，低”级别，以此来确定风险事件发生的影响。 团队应尽可能地将风险影响定量化。但是，如果采用定性方法，则应同描述性方法结合使用。

9.4.3 确定风险与机会的发生概率 项目团队逐一对每个风险或机会进行分析，并确定风险的发生概率。该步骤可以独立地进行，也可与确定发生影响同时进行。当可以获取诸如失败平均时间，修理平均时间或其它统计或历史信息时，发生概率就可以定量化。 任何时候，只要有可能应尽量将发生概率定量化。 在有些情况下，项目团队没有足够信息来赋予风险或机会一个数值概率。这个时候可以采用简单的定性方法，基于团队对风险的主观评价，赋以风险概率“高，中或低”。 采用定性方法时，应同描述性方法共同使用。即使评级系统是清晰明白和大家共知的，诸如“中等”这类形容词对不同的人会有不同的含意。因此结合采用带有文字解释的描述性方法有助于澄清这种不同的理解。

9.4.4 计算净风险与机会值 定量 概率×影响＝总的风险或机会影响 概率×影响×权重要素＝总的风险或机会影响 定性 专家判断方法

9.4.5 确定风险影响的数学方法 预期的货币值——这种方法是两个数值的简单乘积（风险事件概率乘以风险事件影响值）。要使这种方法有价值，风险事件影响值必须同时包括有形和无形值两个方面。例如，在该项计算中如果没有包括无形影响值，而将一个小损失高发生概率的风险事件与一个大损失低发生概率的风险事件等同看待，则会严重地扭曲结果。预期的货币值通常是作为一种输入来进行更进一步的分析，并且还可以包括一个权重因素。 模拟——模拟运用代表法或系统模型来分析一个系统的行为或绩效。最常用的项目模拟是应用项目网络模型进行进度模拟。大多数的模拟是基于蒙托卡罗分析方式。这种分析可以采用一个自动软件包来很好地处理。进度模拟结果可以对各种进度备选方案的风险进行定量化。

决策树——决策树是一张描述决策者采取的各种决策以及与决策相应的可能发生情况之间的主要交互作用关系的图。 专家判断——这种方法通常可以用来替代上述的数学技术方法，或作为这些数学技术方法的补充。其包含熟悉手头具体工作包或任务的个体的观点。在某些情况下，这些专家也能给出定量化的观点，但在大多数情况下，他们的观点是定性的。例如，他们会把任务描述为具有“高，中或低”的发生概率和“严重，一般或有限”的发生影响。

9.4.6 风险与机会优先级排序 在风险分析和跟踪日志上完成优先级排序条。项目团队必须优先排序出哪些风险和机会需要立即制定降低或优化战略来解决处理，哪些风险和机会需要进行跟踪，监督和报告。项目团队选择对多少风险和机会立即采取行动将取决于诸如所识别的风险发生影响，风险事件数量及风险类型。团队至少应关注于那些总等级较高的风险。 尽管团队可能选择不关注于那些被认为只具有中等或低级总影响的风险，但是必须对这些风险及性能跟踪和监督，因为它们的发生概率及发生影响可能随着项目进展而发生变化。起初被认为是低风险的可能突然会变成具有较高总影响的风险。

9.5 制定风险管理计划 输 入 步 骤 出 风险和机会 优先级清单 ● 降低风险和追求机会 ● 接受风险和扩大机会 确定降 低和优 化行动 9.5 制定风险管理计划 输 入 步 骤 出 风险和机会 优先级清单 ● 降低风险和追求机会 ● 接受风险和扩大机会 确定降 低和优 化行动 降低行动 所带来的 附加风险 评估 降低和 优化行 动评估 风险管 理计划 准备 风险管理计划 批准风 险管理 计划

9.5.1 确定降低与优化行动 规避——通过消除风险因素来改变情况，使得风险无法再影响项目，从而消除一个具体的风险。 重新组织和设计项目结构 9.5.1 确定降低与优化行动 规避——通过消除风险因素来改变情况，使得风险无法再影响项目，从而消除一个具体的风险。 重新组织和设计项目结构 与客户协商，取消客户提出的会使H企业承受风险的各种实施要求 如果存在过多的风险，则放弃投标

减轻——通过降低风险发生概率或发生影响来减少一个风险事件的预期货币值。 制定计划来处理潜在的风险事件 严密监督和控制风险事件的成本和进度 监督和管理具有高风险的任务的技术绩效 公司对项目中具有风险的任务做出资源承诺 协商和实施变更来最小化或消除潜在的风险事件

转移——将所有风险或部分风险转移给另一方。尽管风险发生概率并没有降低或消除，但是带给H企业的后果将最小化。 将某些特定的项目任务外包给专业人员和分包商 请求客户自己执行一些对H企业而言代表风险的任务 购买保险

接受——证明了解风险，并愿意结束风险一旦发生所带来的后果。这基本上是一种无为策略，但是它是一个很明智的无为策略。 通过制定一个应急计划并在风险事件发生时执行该计划，从而来主动地，积极地接受风险

9.5.2 应用于各领域的 机会优化策略 技术调整 完成尚未决定的事情（TBDs） 变更规范 变更工作描述 融入H企业的设计 9.5.2 应用于各领域的 机会优化策略 技术调整 完成尚未决定的事情（TBDs） 变更规范 变更工作描述 融入H企业的设计 减少失败之间的平均时间（MTBF） 写下验收程序 减少客户评审次数 限制客户进行变更和批准变更的权利 取消和拒绝首件新品样本 寻求更新和交付首件新品 取消多重的低层级的测试验收 减少质量审计的次数 缩短客户批准的时间 确保在标书准备阶段可以获取所有技术文件和相关参考文件 确保客户的技术资料是准确的和完整的 确保产品验收标准是可以接受的

实施软件活动 确保保持软件所有权 澄清和确认软件需求 应用具有良好用户界面的软件 确定客户提供软件或数据的具体进度 应用现有的软件工具 将新软件工具作价到合同中 坚持从团队内部识别软件专家 确保硬件开发先于软件开发 从最好的内部专家中寻求建议 运用熟练的设计结构，语言和操作系统

实施硬件活动 认识到不断提高的设计复杂性 从实际出发计划设计的反复次数 应用经测试检验的包装技术 应用经测试检验的部件，避免“艺术级”的开发要求 应用现有的测试检验设备 对新测试检验设备作价 寻求由客户提供的测试检验设备 确保硬件合软件开发先于测试检验设备的设计 设计自动化和在线的测试检验 最小化测试装置的数量

项目规划 运用关键路径工具准备一份详细的项目规划 从实际出发，规划各个阶段期间项目人员的获取和安置 和客户和分包商确定共同一致同意的进度安排 规定足够多的重新测试检验时间 规定首件新品、技术规范和可靠性测试的结果的正常影响 限制客户在规划设计和进行测试时的干涉

可靠性/可维护性和安全问题管理 确保可靠性测试需求或承诺保证同设计需求兼容 在设计使就授予和批准需求 简明地定义如何验证和确认失败之间的平均时间（MTBF） 在设计刚开始及接下去所有设计阶段内，考虑产品地安全性和危害性

材料管理 采用合格的卖方和材料 使非标准化部分合格和标准化 评估直接采购的材料和由客户提供的材料 确保客户的质量要求基于标准要求 寻求长期的价格协议 在与客户协商之前，先和分包商协商好价格

合同管理 尽量减少那些会增加不必要的后勤和管理成本的合同条款 争取由客户提供设备和材料 请求免费租用政府的所有物 当法律和规章上没要求时，不要对外提供成本或价格数据 寻求H企业内部的检查和验收 对项目内部所拥有的数据资料保密 客观实际地进行价格担保 确保客户要求的合同条款传递到与分包商签定的合同中去 寻求一个预约的合同条款 寻求提前付款 寻求一个适当的里程碑付款进度 寻求可行的项目进度款 寻求一个可选的清算率 最少化各种抵制 取消那些合同清算时会带来危害的合同条款 寻求激励条款来抵补有害清算的合同条款 拒绝非标准化的变更条款 拒绝关键人员条款 减少定期报告 提议或限定绩效度量系统 格外谨慎和关注于合同的选项条款中所允许的外加实施期 寻求需要客户介入的具体日期 当收益延迟时，修改合同进度，以避免进度压缩 提交备选建议方案或确定备选任务 对于项目的不同部分，分别采用不同的合同类型

9.5.3 降低与优化行动评估 项目团队应为包含在优先级列表中的每个风险和机会分别制定各种降低和优化策略，并选择其中一个能提供最优方法的策略。团队成员应认识到一个降低策略的实施可能会带来新的风险。所以应对每个策略的优点及其如何影响项目的其它要素进行评估。这些策略应该在风险或机会分析工作表中列出，随后应对所选择的策略进行扩大以包含所有的详细细节，并合并融入到风险管理计划中。实施这些策略的相应行动同样应该合并融入到进度计划中，用以跟踪和控制风险。

降低行动所带来的附加风险评估 实施某些风险降低策略会带来新的和不可预期的风险 。项目团队列出所有可能的风险降低和机会优化策略，并评估这些策略，以此确定每一个策略可能给其它活动和整个项目所带来的预期结果和潜在影响。合适的策略应该使一个风险事件的发生概率或影响尽可能地低，同时使一个机会事件地发生概率或影响尽可能地高。

9.5.4 准备风险管理计划 风险管理计划是一份用于在整个项目生命期内管理风险和机会的程序化文档。在这个文档中，除了风险和机会识别与分析过程外，还包括由谁负责管理不同类别的风险，如何维护起初的识别和分析输出结果，如何实施应急计划，如何分配管理预备金等。 风险管理计划是项目计划中的其中一个支持性部分。其内容可以很详细，也可以是比较宽泛和框架式的，这主要取决于项目的需要。

项目的风险管理计划关键要素 所有已识别的风险和机会的一份总列表 所有完成的风险或计划分析工作表 对每个项目团队决定要加以处理的主要风险和机会的详细计划（降低和优化策略） 显示谁负责处理或解决每个风险和机会的责任矩阵 风险管理计划评审和更新进度安排 风险结果编档过程

9.5.5 项目风险管理 计划的评审批准 评审类型 地方评审 区域评审 业务单位评审

地方评审 项目/项目群经理、区域项目总监负责确保等级1a评审中的所有估算按照当地估算评审程序实施。当标书可能包含与绩效相关的非常风险(如违约赔偿或高技术风险)时，则项目/项目群经理、区域项目总监必须在区域或业务单位职员的帮助下对标书进行评价，而不计代价。一旦风险和机会评审获得实施，项目/项目群经理、区域项目总监必须做一份主管汇总表并签字。

区域评审 除了由项目/项目群经理、区域项目总监进行的地方评审，当项目符合由风险因素评审及批准矩阵中的等级2识别出的标准时，区域副总裁将需要实施区域定价和风险评审。被委派管理该项目的项目/项目群经理、区域项目总监需要负责协调评审，还需要帮助区域副总裁对该独立评审必须的外部资源进行人员配给和进度安排。区域副总裁，根据自己的判断，基于其对项目的了解，可以被授权加强或放松区域风险评估标准。区域副总裁负责确保下列事项的实施：按照区域等级进行充分的风险评估，以及制定合适的风险削弱计划。区域副总裁在主管汇总表上签字，这预示着授予其权利递交标书及随后预定订单。如果已完成的主管汇总表及现金流分析确实可行的话，会由当地提供，并将会与区域合同经理的独立报告一起保存进项目文件中。现金流模型软件可通过财务部门使用。

业务单位评审 当项目符合由风险因素评审及批准矩阵中的等级3识别出的标准时，定价和风险评估必须获得北美日常运营副总裁及区域副总裁所在的业务单位总部的批准。一份独立的风险评估是由区域外部的递交了标书的专业人员进行。区域副总裁负责识别出进行评审的团队主席。被委派给该项目群经理/区域项目总监负责协调评审，并帮助区域副总裁对独立的风险评估团队进行人员配给和进度安排。该团队应该由来自销售、运营、财务、法律/合同管理和工程等进行评审所需部门的人员组成。其他人员随需要增加。该独立团队会在给项目/项目群经理、区域副总裁及北美日常运营副总裁的最终报告中公布从评审中获得的信息。该最终报告与签署的主管汇总表与当地提供的现金流模型一起构成项目合同文件。

9.5.6 风险和机会应对措施的控制 输入 步骤 实际发 生的风 险和机 会事件 风险管 理计划 跟踪风 会 实施减缓 风险和机 会最大化 9.5.6 风险和机会应对措施的控制 实际发 生的风 险和机 会事件 风险管 理计划 跟踪风 会 实施减缓 风险和机 会最大化 战略 评估结果 并更新风 险管理计 划 对风险 管理结 果进行 归档 输入 步骤

第十章 项目沟通管理案例

10 客户关系 10.1 客户关系流程图 10.2 项目经理的职责 10.3 客户满意的重要性 10.4 识别重要客户利益相关者 10 客户关系 10.1 客户关系流程图 10.2 项目经理的职责 10.3 客户满意的重要性 10.4 识别重要客户利益相关者 10.5 客户需要的识别、公式化 和生效 10.6 沟通渠道的建立和维持 10.7 客户在项目计划和实施中的介入 10.7.1 客户期望的管理 10.7.2 理解客户期望 10.7.3 满足客户期望 10.7.4 测量和跟踪客户 满意的途径 10.8 项目收尾的成功实施 10.8.1 移交和项目收尾 大会 10.8.2 教训总结大会

10.1 客户关系流程图 识别重 要的项 目利益 相关者 对客户需 求进行识 别、公式 话并生效 建立并 维持沟 通渠道 客户参 与项目 10.1 客户关系流程图 识别重 要的项 目利益 相关者 对客户需 求进行识 别、公式 话并生效 建立并 维持沟 通渠道 客户参 与项目 计划编 制和实施 管理客 户期望 测量和 跟踪客 户满意 度 实施成 功的项 目收尾

10.2 项目经理的职责 识别客户的重要利益相关者。 对客户需要和需求进行识别并生效。 建立并维持沟通渠道。 管理客户期望。 10.2 项目经理的职责 识别客户的重要利益相关者。 对客户需要和需求进行识别并生效。 建立并维持沟通渠道。 管理客户期望。 测量并跟踪客户满意度。 实施成功的项目收尾。

10.3 客户满意的重要性 客户不满意的成本高昂－客户将不会跟H企业做未来的交易，除非为解决该问题做出明显的成本让步。 10.3 客户满意的重要性 客户不满意的成本高昂－客户将不会跟H企业做未来的交易，除非为解决该问题做出明显的成本让步。 对高水平的客户满意的奖赏也很高－它保证来自客户的重复交易，也可以通过交谈从新客户那里创造交易。 与客户的每次接触都是一个机会－每个与客户接触的雇员都有机会积极地或消极地影响客户满意。

10.4 识别重要客户利益相关者 利益相关者可能是终端用户、承包商或内部资源。项目经理必须识别出客户的项目利益相关者、他们的地位以及他们在项目着所起的作用，以作为需求识别和生效过程的起始。 在第一次客户会议中，项目经理必须提出如下问题：谁是重要的项目利益相关者以及他们的需要是什么？H企业如何才能，满足他们的需要？这些需要存在矛盾吗？如果存在矛盾，谁将仲裁并解决它们？这些需要能进行优劣排序吗？在客户组织中，谁对必须强调哪个需要有最终的发言权？谁将批准工作范围？谁将批准项目变更？谁将在问题调整过程中代表权威水平？ 项目经理必须识别出在客户组织中的同级别的人物以及H企业管理层的同级人物，必须为项目沟通、评审和上调制定一个草案。

10.5 客户需要的识别、 公式化和生效 对客户需要的恰当识别、公式化和生效会通过使用H企业 front－end loading（FEL）过程获得帮助。FEL 过程是指促进销售机会转向一份客户合同关系的一系列活动。更特殊的是，FEL过程用于建立基于一种交叉的广泛的客户需求评审的项目成本、工期和资源使用。FEL过程强调与客户的接触和调整以制定一份获得共同理解的客户需求。归档该需求并定义最可能的解决方案以满足这些需要。该过程应该充分与GPM方法中的活动进行集成。FEL过程保证了客户的需求得到识别。

客户需要的发展演进 需要的 识别 公式化 生效

10.6 沟通渠道的建立和维持 提供状况报告 举行面对面会议 进行客户满意度调查 实践一些非正式沟通

提供状况报告 状况报告至少应该包含下列信息： 报告期内实现的大的里程碑或交付物。 在报告期内错过的大的里程碑或交付物。 描述实际进度和基准的甘特图。 工作计划或预算的变更。 要求客户行动或帮助的问题。 预测的下一期内的大的里程碑或交付物。 （如果与基准不一致）最新的估算完工日期。 对客户提出问题的反应。

状况报告为客户提供了项目进度的信息。 应该尽可能以简洁的方式传达给客户渴望的信息。只要客户同意，它们可以书面的，也可以是电子版的。这些报告的听众在项目启动大会上就确立了，并且写进了沟通计划中。

举行面对面会议 现场工作范围会议 项目范围评审会议 项目建议书评审会议 项目启动大会 状况评审会议 技术评审会议

实施客户满意度调查 每个H企业项目至少必须履行一次这样的调查。在正常情况下，当项目进展到30％－40%时进行。 客户满意度调查主要是获得对从客户的角度来看其期望在多大程度上得到了实现的准确理解。网页或电话的使用促进了获得该信息的过程。

实践非正式沟通 非正式沟通主要由电话或简洁的备忘录组成。为保证客户对项目一定水平的满意和信心，项目经理必须与客户保持密切的接触。 非正式沟通的频率因项目而异，也因客户而异。项目经理应该按需要经常地与客户沟通，以保证客户对项目的每个方面都有正确的信息。 项目经理必须保证团队成员认识到不能用非正式方法取代必须的正式沟通。特别地，诸如协议、承诺和变更此类事情必须在H企业和客户之间进行正式地归档和沟通。非正式沟通在项目或商业环境中不具有法律效力。

10.7 客户在项目计划 和实施中的介入 界定工作范围——在制定工作范围时，客户介入是强制性的。 10.7 客户在项目计划 和实施中的介入 界定工作范围——在制定工作范围时，客户介入是强制性的。 制定测试步骤和客户验收标准－在该活动中，特别是制定验收标准，客户介入是极端重要的。 设计系统功能——一个用户顾问小组参与到系统功能的设计中是明智的。该小组可以提供设计问题、系统人机学和可用性方面的建议。早期获得用户输入为客户满意（在部署产品时）提供了更大保证。 执行和厂房测试——在厂房测试和中间可交付成果测试中，拥有一个用户测试小组帮助项目团队是非常有价值的。在早期阶段发现问题比在最后测试验收时成本低，而且容易解决。这个小组有助于保证最终交付成果如所愿的那样工作。 制定和测试原型——如果项目需要制定一个原型，那么，可通过保证在最终产品生产出来之前发现任何故障以证明在发展和测试阶段让客户们介入的益处。 参加共同的客户/H企业状况评审会议——这些会议每月或双周举行一次以与客户共同分担项目制定的进度以及所遇到的问题或难题。这些会议中的客户参与很重要。 参与技术评审——在一些情况下，技术评审必须只能由内部高级经理来执行。但是，在任何可能的情况下，能提供有价值输入的客户方的技术职员的介入也是可取的。

10.7.1 客户期望的管理 管理客户期望不存在科学的公式，该复杂多样的任务涉及与客户建设一种很牢固的关系。在这种牢固的关系中，项目状况和问题在一种及时的基础上进行沟通，在变更管理过程中变更得到控制和仔细管理，而且承诺得到归档并传递给客户。 对客户期望的管理主要注意理解客户期望和满足客户期望。

10.7.2 理解客户期望 他们期望从H企业收到的产品或服务是可用的并且符合他们预期使用的需求－比如，更换新设备却发现无法工作活不如所愿地进行工作，就是没有满足客户期望。 他们期望H企业信守其诺言－如果一项产品或服务被许以规定日期，那么H企业必须信守诺言。少承诺、多交付要好于多承诺、少交付。 他们期望H企业具有胜任力并虔诚地为他们服务－客户期望委派给他们项目的人们具有胜任力。他们也期望项目团队有着友好而职业的行为方式。 他们期望Hoeywell理解他们的需要和愿望并有效地加以强调－因此，H企业必须理解这样一种环境：客户职能，他们所面对的约束条件，他们的困难以及他们正在寻求的解决方案。

10.7.3 满足客户期望 对项目承诺进行归档并沟通－项目经理必须保证不能对交付什么、何时交付以及由谁交付存在误解。该信息应该在项目启动大会上与客户一起决定，它包括里程碑、大的交付成果、整个项目的工期、技术性能标准以及商业内容。 对项目状况进行沟通－客户应该有规律地被告知项目状况以避免吃惊。 提醒客户关注承诺－客户保持对起始承诺的注意有助于组织客户重新评估期望。 项目过程随有效的变更控制快速做出变化－起源于客户或H企业的变更应该通过变更管理过程渠道化（权宜之计）。所有受影响的文档应该尽可能快的进行升级。项目工期、范围或成本变更的任何影响都必须由客户进行评审，并在变更之前达成共识。对于大的变更，应该召开一个组合的项目团队的特别会议以制定新的期望并重新设定基准。

10.7.4 测量和跟踪客户 满意的途径 可交付成果的中间测试－在对中间可交付成果的测试和验收中，项目经理可针对可交付成果正式评估客户满意度。客户的验收者在安装时检查和评审可交付成果测试的结果。客户验收者的反应和反馈可为整个客户满意提供有价值的意见。 明智的客户和测试小组－测试可交付成果可用性和性能的终端用户小组能为项目经理提供对整个客户满意很好的反馈。 周期性项目状况会议－项目经理应该随着整个生命周期中项目的进展频繁地使用这种论坛以评估客户满意度。 销售财务经理—在大部分情况下，财务经理在项目实施中与客户保持联接，是有关客户满意信息的好的来源。 主管之间的关系—保证项目成功的最好方法之一是在H企业和客户间建立一种主管级别的关系。H企业的主管可以对客户有关其对项目的满意方面做出保证。 非正式沟通—项目经理应该与客户保持不断的接触，甚至在没有压力问题存在时，也应如此，实际上，在这些时候，客户更加放松，并可以用文字表达对项目的整体感觉。一个电话或随意会谈有助于改善与客户的关系，同时也提供给项目经理有价值的反馈。 项目移交和收尾－尽管移交是在项目生命周期的后期，但是移交给客户操作为评估客户满意度提供了一个机会。如果在此时点发现问题，那么项目经理必须尽可能快地采取立即措施解决问题。 教训学习会议－即使对项目经理来说，采取任何措施都为时已晚。但是教训学习会议为评估客户满意度提供了另一个机会。

10.8 项目收尾的成功实施 在项目收尾阶段与客户的接触在决定项目成功和评价与客户满意相关的重要因素方面是非常重要的。有两项重要的项目收尾活动可以保证客户满意的水平：移交及项目收尾大会和教训总结大会。

10.8.1 移交和项目收尾大会 举行移交和项目收尾大会是把系统移交给客户。移交问题和客户关心的地方会得到强调，诸如担保支持的水平，技术支持要求步骤，问题上调步骤以及任何其他与项目实施后支持的相关问题。项目团队可以准备一份H企业的劳动合同清单以在会议上提供给客户。 收尾会议可能导致对“公开问题”的识别。这些问题包括尚未提供给客户的事项或者要求恰当收尾的行政事务。与之相伴的工具被用来跟踪这些事项至项目结尾。

10.8.2 教训总结大会 教训总结大会是用来与客户评审项目中哪些是对的以及哪些是错的。该会议旨在学习经验而不是指出问题的。H企业和客户可以从这次会议中学到许多有关出现的问题以及在未来的项目中如何防止这些问题。双方也可以从讨论创新的工作过程和实施的解决方案中获益，并可以在未来的项目中使用。

第十一章 项目人力资源管理案例

11 项目人力资源管理案例 11.1 项目团队形成 11.1.1 构成项目团队 11.1.1.1 项目管理组成 11.1.1.2 团队参与者 11 项目人力资源管理案例 11.1 项目团队形成 11.1.1 构成项目团队 11.1.1.1 项目管理组成 11.1.1.2 团队参与者 11.1.2 指定项目经理 11.1.3 团队开发的Tuckman模型 11.2 项目团队建设 11.2.1 定义团队建设的目标 11.2.2 团队建设过程的实施步骤

11.1 项目团队形成 项目团队将在项目经理的领导下计划和执行所有的项目活动。因此参与项目团队的成员对项目的成功至关重要。有效的项目团队需要一个独特的过程来组建并开发团队成员，这些成员是在群体环境中最适合项目的人。为了实现有效的群体交互合作，选择成员时需要考虑成员的技术能力、个人兴趣，专业知识和个人性格。 这个部分检查了H企业项目团队的结构和组成部分中相关责任，项目团队形成的动态以及确保早期和持续的项目团队效率所必须的团队开发活动。

11.1.1构成项目团队 当组建H企业项目参与者的结构时，必须进行全面的考虑。项目经理必须组织项目来确定和吸收所有能参与到项目中的人。他或她应该认识到“全团队”包括内部和外部资源，每个参与者的收益水平、参与度、绩效和对项目信息的需求都不同。H企业和客户人员以及管理人员，还有外部卖主和分包商他们都是项目的利益相关者。了解这些有助于项目经理计划和实施项目，使得当项目目标实现时最大程度上满足各方的期望。

11.1.1.1项目管理组成 组建项目管理部分的目的是检查正确的项目计划、执行和控制来确保客户满意以及项目交付物的接受。项目管理组成包括的个体如下 ： 项目经理/地区项目主管－H企业项目群经理/地区项目主管负责多个项目。 会计经理－销售群的代表，领导H企业商业战略的实施。 项目经理－H企业项目经理是特定客户项目的经理和主要联系人。

H企业项目团队组成——H企业项目团队是计划和执行任务完成项目目标的技术和行政管理人员的核心群体。支持团队的成员和项目经理进行互动，但是为了管理目的他们由H企业项目团队的高级人员分配，并负责向高级人员汇报。在项目的不同时间这个团队的成员经常作为需要的能力参与到项目中来。但是对于大项目需要他们的全职参与。 客户项目团队组成是整个项目活动中最重要的部分。

11.1.1.2 团队参与者 客户发起人——客户发起人通常是执行官水平的经理，有批准和投资项目并签署合同的权力。 11.1.1.2 团队参与者 客户发起人——客户发起人通常是执行官水平的经理，有批准和投资项目并签署合同的权力。 客户项目经理——这个项目经理从客户的角度出发来指导项目的计划和执行，而且通常是H企业项目经理主要的联系人。 客户项目团队成员——这些成员是客户的技术专家，而且直接和H企业团队成员一起工作，或者观察H企业项目团队的工作。

11.1.2 指定项目经理 项目经理通常由负责的项目群的经理/地区项目主管来分派。这些经理负责评估项目和客户需求并检查可利用的H企业经理的资格技能和经验。当决定了最好的并且可实现的项目和经理的搭配之后，项目群经理/地区项目主管亲自通知收到指令的那个人。 确保制定的项目经理适合项目是关键的管理活动。当匹配的个人技术和经验应用到特定项目的时候，项目群经理/地区项目主管或委任官员应该在许多方面评估项目经理的能力。与项目分类和客户相关的每个地区必须被考虑。

11.1.3 团队开发的Tuckman模型 团队开发阶段项目经理的活动 形成－团队成员通常是在开工会议上首次集合在一起，或者项目团队成员被引入到项目中。给个体介绍所有的项目目标和项目结构，他们会对他们所适合的工作有个初始的理解。*描述项目结构和组织*确定沟通程序*指出团队成员的责任*给大项目指定任务领导*讨论个体角色 震荡－个体团队成员对简单项目需求表达出感情反应。通过项目领导层结构的测试，发现敌意和挫折感的水平明显增加*识别管理冲突*加强对目标和使用团队的集体和个体能力来完成的目标的理解*协助团队成员来处理本阶段的不幸，把它当作一个项目团队发展过程中正常的进程 规范－因为团队开始对绩效建立自己的期望和标准，所以理性的沟通和合作出现在项目团队成员中。个体现在根据团队来确定他们的角色。*促进和认可信息和影响的共享和交换*反复使用已经建立的方法和程序 执行－通过项目满足个体和群体的绩效期望，实现了项目成员团结。团队成员表现出更高的相互依赖关系。*有利于团队的绩效聚集*解决发生的问题 延期－团队表现成就感和个人满足感。当他们的任务完成以后，成员开始离开团队。*当项目接近结束的时候，建立和维持一个积极的关注*承认并讨论下一个项目中个人关系的问题*进行奖励和表扬活动

11.2 项目团队建设 项目经理必须有能力聚集不同水平的组织内外部人员，有能力和不同水平、经验和能力以及不同个人目标的个体合作。需要全团队活动来完成项目目标，在这个意义上，项目经理必须优先重视团队建设。 这部分研究了项目团队建设的关键组成。

11.2.1 定义团队建设的目标 一个功能良好的项目团队可以经常提供增效的结果－团队优于每个单独的团队成员的简单叠加。这种效果可以通过项目经理进行的团队建设活动来认识，它的目的是： 促进团队成员间的项目依赖 给出个体共同工作的原因 针对项目目标建立一个共同群体许诺 作为一个组织内的功能单位产生责任感。 允许适度的竞争和冲突 团队建设主要的焦点是必须确定和获得对项目目的和目标的共识。

11.2.2 团队建设过程的实施步骤 团队建设过程由以下一系列活动组成： 11.2.2 团队建设过程的实施步骤 团队建设过程由以下一系列活动组成： 团队建设规划：通过规划将团队建设活动归并入项目团队活动中，包括在项目计划或其它相关支持性计划中进行团队建设规划。 团队成员协调：通过获取最优秀的人员来确保项目的成功，尽最大努力来获取正确的人员加入到团队中。 团队组织和设计：运用项目工作分解结构对工作任务进行排列组合，据此确定每个项目团队成员的职责，并运用文件的形式来进行沟通和获得个体和工作小组的工作承诺。 举行内部开工会议：召开此会议，作为新组建的项目团队的一个首要行动，这一行动在团队建设过程中尤为关键。 建立沟通链接：设定沟通线路和好的沟通链接，否则团队工作将无法开展。 执行团队建设活动：将团队建设活动植入到项目平时活动中，来达到最好的效果。 团队优势和弱势诊断分析：识别团队的有效性，推动团队建设，作为一项团队努力来执行这项活动。 激励团队：运用各种手段对每个项目团队成员的工作进行肯定，让其认识到他们工作对项目的重要性。

第十二章 项目采购管理案例

案例一 合同管理

12.1 合同管理 12.1.1 合同管理框架 12.1.1.1 合同 12.1.1.2 合同要素 12.1.2 建立合同关系 12.1 合同管理 12.1.1 合同管理框架 12.1.1.1 合同 12.1.1.2 合同要素 12.1.2 建立合同关系 12.1.3 定合同定价协议 12.1.4 项目经历管理项目合同的职责 12.1.5 资产管理 12.1.6 风险和机遇的管理 12.1.7 智力资本保护机制

12.1.1 合同管理框架 客客户 合同管理 分包商和 采购管理 合同管理过程 识别合 同框架 定性分 析机会 制定项 目建议 书 执行合 12.1.1 合同管理框架 识别合 同框架 定性分 析机会 制定项 目建议 书 执行合 同谈判 履行合 同管理 确定和 管理分 包合同 的采购 履行分 管理 客客户 合同管理 分包商和 采购管理 合同管理过程

12.1.1.1 合同 不存在通用的合同法。但是世界范围内的法律体系共享这样一种核心观点：在特定情况下，当合同双方就交换的承诺达成一致意见时，必须信守这些承诺。如果合同双方没有信守承诺的话，政府会被号召通过法律体系和法庭来强制他们履行。因此，合同是私人团体间签订的具有政府强制力的协议。它代表买卖双方的关系，以特定方式表达双方在条款和条件、规范、工作说明书和其他合同中的要求。

12.1.1.2 合同要素 要约－要约是如果合同被接受了，则必须履行的一种承诺或许诺。 12.1.1.2 合同要素 要约－要约是如果合同被接受了，则必须履行的一种承诺或许诺。 验收－验收构成了无条件同意要约条款，一份要约的验收可按照表明已履行的书面文字形式制定，或者是口头文字。 具有竞争力的合同双方－合同双方必须互相了解并具有竞争力。

12.1.1.3 合同违约可能补救方案 卖方 与买方谈话 停止工作（只有在咨询过法律指导委员会之后） 通知第三方 对索赔进行归档 与买方谈判 12.1.1.3 合同违约可能补救方案 卖方 与买方谈话 停止工作（只有在咨询过法律指导委员会之后） 通知第三方 对索赔进行归档 与买方谈判 取消合同 调解 仲裁 诉讼

买方 与卖方谈话 停止支付 停止工作订单 发送显示原因的信件 与卖方谈判 取消合同 重新采购需要的产品和服务 调解 仲裁 诉讼

12.1.2 建立合同关系 每个合同或协议都建立了一种商业关系。这种关系的性质经常受下列一种或多种因素的影响： 商业战略目标 商业或销售机会 12.1.2 建立合同关系 每个合同或协议都建立了一种商业关系。这种关系的性质经常受下列一种或多种因素的影响： 商业战略目标 商业或销售机会 认知的风险 短期或长期的项目或者其他商业支持需求 介入方的需要和期望

商业和合同关系的类型 传统的供应合同 覆盖了标准产品和服务 促进了例行的、计策性的或本地的一次性采购 强调短期目标 提供有限的信息交易 要求独立的计划和运营

供应商联合 代表了重要的供应商以及可能的团队协议 表明增加的合作 集中于对每个公司重要的目标 采用商业联盟中的双赢原则

捐款 代表了参与公司的资格或证书 为H企业的产品进行服务或作为H企业产品的接口 涉及可能采用不复杂的市场活动 强调改进与每个公司提供的产品和服务相适应的成本和收入

OEM/价值增加零售商 代表了一个紧密的商业联盟 推广了根植的或H企业品牌的产品 包括了介入方共同的产品分销 强调改进与每个公司提供的产品和服务相适应的成本和收入

合作协议 代表了共同目标方面的协议，诸如： 提供了每一方支持必须的利息资金 包括了来自于介入公司的一个或多个职能领域的可能的团队信息 研究和开发 市场营销 销售和分销 服务支付 提供了每一方支持必须的利息资金 包括了来自于介入公司的一个或多个职能领域的可能的团队信息

战略协议 经常涉及共同的投资和共同的捐助 使增强合作和分享知识拥有权成为必要 追求高度战略化的共同目标

合资企业 代表了一个新的商业实体 促进了资产技术、知识、资本和技术的交换 向合资企业提供资源以进入新市场 并购 组合之前不同的公司实体 建立对内部运营的全面控制

12.1.3 定合同定价协议 风险 合同类型连续带 固定总价 成本补偿 卖方 买方 卖方和买方的相对风险的合同类型的连续带

合同和协议类型 固定总价合同 成本补偿合同 其它类型的合同或者协议

12.1.4 项目经历管理 项目合同的职责 资产管理 风险和机会管理 智力资本管理 变更管理

12.1.5 资产管理 获得部分客户的资金-如果合同资金是分阶段付款的，一定要确保客户意识到资金的要求并有足够的时间能够采取投资行动。 12.1.5 资产管理 获得部分客户的资金-如果合同资金是分阶段付款的，一定要确保客户意识到资金的要求并有足够的时间能够采取投资行动。 监督客户记帐与支付-采取一系列行动以确保客户前期付款的产品和服务能够及时提供，检查项目工期制定的方式，能够改进现金流、消除客户付款过程的障碍、客户跟踪收到的发票、处理大额发票、保证电子信箱的正确以及召开对激励支付手段进行检查的会议。 监控H企业分包商的支付-建立和客户的付款周期相匹配的分包商支付进度 完成有效的变更管理-对客户提出的变更给予及时关注，并尽早识别出建设性的变更 加快运输速度-计划运输进度并实施运输进度安排，尽快将存货转化为应收款和现金，并寻求能够加速传递和尽早支付的权力。

 最大化地使用客户设备和剩余资源-提前获得处理指示，并迅速进行处理，管理项目以避免平衡法上调整的需求，在必要时在以后或者相关的合同之间保持和转化客户财产。 降低清算和结果损失条款的影响-持续地监督引起清算或者结果损失的环境，消除这些条款或者获得激励条款来弥补被罚款的风险。 保护所有者的数据-一定要保护所有者的数据，包括第三方数据，监督数据提交以确保正当营销，并恰当运用没有终结的协议等。 管理终结和停止工作命令-经过客户同意终止H企业 及其分包商的工作，保证进行部分付款以及成本恢复行动，如果需要对不履行的终结进行回应的话，能够迅速得到辩护。 检查合同执行和终结行为-保证所有的项目终结工作都及时地完成，客户已经接受了可交付物，并管理终结报告和客户付款的发票。

12.1.6 风险和机遇的管理 合同管理与风险评估，机遇优化，风险和机遇计划与管理存在着固有的联系。这项工作有利于消除能够引起意想不到的以及计划之外的损失的问题，而获得合理的利润。 有效的风险和机遇管理要求整个提议计划团队或者项目团队的共同努力。项目经理对确保全面的风险管理过程与合同的执行同时完成负有总体责任。 风险管理的关键概念是要求为所有层次人员提供清晰而能够提前预知风险。

12.1.7 智力资本保护机制 版权——确定和识别原始工作的作者，作者有权拒绝他人的复印权、发布权执行权、展览权以及由上述工作引起的工作。 12.1.7 智力资本保护机制 版权——确定和识别原始工作的作者，作者有权拒绝他人的复印权、发布权执行权、展览权以及由上述工作引起的工作。 专利权——确定和识别原始工作的发明，专利权给予发明者以下权力：发明者有权拒绝他人制造、使用、或者出售该项发明。 商业机密——不能仅仅通过观察产品、流程以及生产过程中使用的工具获得的技术性产品的设计信息。 商标——能够表明商品来源的词语、名字、符号或者图案，并且能够根据它区分出该商品与其它商品的不同。 服务商标与商品商标相似，只不过用到服务而不是商品上。

智力资本保护机制 修正——合同的修正要前面地描述出范围、时间或者价格的特定变化。一个修正文章代表了一个双方协议，在这个协议中双方都同意进行合同的变更。 变更命令——客户发出一个单方面的变更指示，要求在合同范围内进行变更，因此并不破坏合同。这是一种直接的或者正式的变更。 建设性的变更——一项由客户提出或者引起的在工作或者工期方面的变更，要求卖方执行的工作超出了合同中要求的最低绩效。这项工作不能通过一个变更命令正式地执行，卖方有权要求增加工作报酬。

案例二 采购计划和分配

12.2 采购计划和分配 12.2.1 资源管理 12.2.2 项目资源计划

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

资源管理过程 这个过程强调项目资源计划的早期准备是组织和获取完成项目目标所必需的资源的指导性文档。整个项目的资源需求应该在计划阶段确定。但是因为资源会在项目管理生命周期的不同时点进入或离开项目，所以它可能必须重复进行获取和分配活动来确保有效的资源管理。项目资源计划在成本方面非常重要，因此，资源计划必须和所有的项目估算结合起来。 项目团队的形成过程关注于在项目工作完成的过程中组建、管理和领导一个可行的和有能力的技术团队，还要考虑附属人力成员的参与和管理，还有项目团队的客户的参与。管理项目的人力组成是整个项目中必须进行的活动。

12.2.2 项目资源计划 步骤： 决定资源类型 准备资源责任矩阵 分配资源 编制资源计划

决定资源类型 人力资源 其他资源 H企业运营人员 H企业职能组织成员 H企业支持机构成员 客户人员资源 签约专业人员 手工劳动者 供应品 设备 其他项目相关的资源

准备资源责任矩阵 项目经理负责建立每个项目的资源责任矩阵。详细的资源需求应该和WBS中确定的工作一致。资源责任矩阵使资源适合他们的工作需要。它是一种工具，通过显示项目的所有资源需求，来证明项目期间的起始和附件资源的合理性，并获取这些资源。

分配资源 步骤： 确定并向单个的团队成员分配任务责任 确定并向特定的项目团队分配任务责任 给每个工作分配足够的恰当的人力资源 合并的关键材料资源分配 分配非特殊的，共有资源，比如行政管理，非技术人员

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

提示 关于本案例的进一步研究成果请参 Global project management methodology ——Honey well