# 第一章 IT 项目管理概述

# 一、项目的概念

# 1、项目的定义

• 项目是一个特殊的将被完成的有限任务。它是在一定时间内，满足一系列特定目标的多项相关工作的总称。—— 中国项目管理研究委员会

• 为提供一项独特产品、服务或成果所做的临时性努力。—— PMI 项目管理知识体系指南（PMBOK）

# 2、项目的特点

• 明确的目标，其结果只可能是一种期望的产品或服务。

• 独特性，每一个项目都是唯一的。

• 时限性，有确定的开始时间和结束时间。

• 约束性，每个项目的资源、成本和时间都是有限的。

• 目标的渐进性，目标逐步完善，需求逐渐明晰。

• 创新性，方法、技术、管理模式、信息化成果创新。

• 高风险性，需求模糊性、执行可见度低，项目的过程和结果都存在很多不确定因素。

• 智力密集型，高素质人力资源需求。

# 3、项目与运作的区别

• 项目：提供一项独特产品、服务或成果所做的临时性努力。

• 运作：连续不断周而复始的活动

# 二、项目管理概述

# 1、项目管理的定义

• 项目管理是为了满足甚至超越项目相关方对项目的需求和期望而将知识、技能、工具和技术应用到项目的活动中去。

• 项目管理是以项目为对象的系统管理方法，它通过一个临时性的、专门的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现对项目全过程的动态管理和对项目目标的综合协调与优化。

# 2、项目管理的特征

• 项目管理的对象是项目：针对项目特点形成的一种管理方法

• 系统工程思想贯穿项目管理的全过程：将项目看成是一个完整的、有生命周期的系统

• 项目管理组织具有一定的特殊性：以项目本身作为一个组织单元；临时性；柔性；协调、控制和沟通

• 项目管理的方式是目标管理：多层次的目标管理方式

• 基于团队的项目经理负责制：项目经理是组织法定代表人在项目上的代表人

• 项目管理具有创造性：继承积累性 + 综合性

# 3、项目管理的知识体系

PMBOK 把项目管理过程组分为 5 类。

• （1）启动过程组。
• （2）规划过程组。
• （3）执行过程组。
• （4）监控过程组。
• （5）收尾过程组。

# 三、软件项目管理

# 1、软件项目管理的特点

• 软件项目是设计型项目：需要创造和创新，需要技术人员

• 软件过程模型：选用瀑布模型、原型模型、迭代模型、螺旋模型等

• 需求变化频繁：软件需求的不确定性或变化频繁

• 工作量估算困难：缺乏有效的软件工作量度量方法和手段

• 以人为本的管理：人性化管理，主要成本是人力成本

# 2、软件项目管理与软件工程的不同

在软件项目管理中，项目的启动、规划、执行、控制和收尾等管理过程 (组) 则属于项目管理的范畴。

软件工程是：将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；以及对上述方法的研究。在软件开发项目中，需求分析、概要设计、详细设计测试等工作，都属于软件工程的范畴。

# 3、软件项目管理的成功

项目成功的表现主要包括以下几个方面：

• 在规定的时间内完成项目。

• 项目成本控制在预算之内。

• 产品功能特性达到规格说明书所要求的水平。

• 项目通过客户的验收。

• 项目范围变化最小或是可控的。

• 没有干扰或严重影响整个开发组织的主要工作流程。

• 没有改变企业文化或改进了企业的文化等。

# 第二章 组织环境与项目管理过程

# 一、IT 项目管理的环境

# 1、项目环境

（1）经济环境对 IT 项目的影响

• IT 项目组织的运行机制、工作内容及范围、方法体系、投资与运行等方面

（2）社会人文、政策法律对 IT 项目的影响

• 知识产权的界定、识别、运用和纠纷

• 社会伦理、文化价值取向；职业道德规范

• 社会信用体系、社会公信力要求、社会福利水平

（3）企业文化对 IT 项目的影响

• 组织的价值观、行为准则、信仰、期望、组织的政策程序、上下级关系的观点等

# 2、组织结构

组织结构是组织中的成员以怎样的形式组织起来，使他们在组织的不同位置上发挥作用。

职能型组织结构缺点与优点：

（1）职能型组织结构具有以下优点。

• 在人员使用上具有较大的灵活性。

• 技术专家可以同时为几个项目服务。

• 同一部门的专业人员在一起易于交流知识和经验，这可使项目获得部门内所有的知识和技术支持，对创造性地解决项目的技术问题非常有利。

• 当有成员离开项目组时，职能部门可作为保持项目技术连续性的基础。

• 职能部门可以为本部门的专业人员提供一条正常的晋升途径。

（2）职能型组织结构具有以下缺点。

• 这种组织结构使得客户不是活动和关心的焦点。

• 这种结构导致没有一个人承担项目的全部责任（责任淡化）。

• 项目常常得不到很好的支持。

• 调配给项目的人员其积极性往往不是很高，也不把项目看成是他的主要工作。

• 技术复杂的项目通常需要多个职能部门的共同合作，但他们往往更注重本领域，而忽略整个项目的目标，并且跨部门的交流沟通也比较困难。

项目型组织结构缺点与优点：

（1）项目型组织结构具有以下优点。

• 项目经理有充分的权力调动项目内外资源，对项目全权负责。

• 权力的集中使决策的速度可以加快，整个项目的目标单一，项目组能够对客户的需要做出更快的响应。在进度、成本、质量等方面的控制也较为灵活。

• 这种结构有利于使命令协调一致，每个成员只有一个领导，排除了多重领导的可能。

• 项目组内部的沟通更加顺畅、快捷。

（2）项目型组织结构具有以下缺点。

• 由于项目组对资源具有独占的权力，在项目与项目之间的资源共享方面会存在一些问题，可能在成本方面效率低下。

• 项目经理与项目成员之间有着很强的依赖关系，而与项目外的其他部门之间的沟通比较困难。

• 在相对封闭的项目环境中，容易造成对公司的规章制度执行的不一致。

• 项目成员缺乏归属感，不利于职业生涯的发展。

矩阵型组织结构缺点与优点：

（1）矩阵型组织结构具有以下优点。

• 项目是工作的重点，项目经理负责管理整个项目，矩阵型组织具有项目型组织的长处。

• 可以有效地利用资源，项目可以分享各个部门的技术、人才和设备。

• 这种结构更加注重客户的需求和促进项目成员之间的学习和知识交流。

（2）矩阵型组织结构具有以下缺点。

• 矩阵型组织通常是多个或多重领导，存在双层或多层汇报关系。

• 多个项目在进度、费用和质量方面能够取得平衡，工作受到影响，这既是矩阵型组织的优点也是它的缺点。

• 许多因素使矩阵项目团队非常难以管理。

• 项目与职能部门的责权不清。

# 二、IT 项目生命周期

IT 项目生命周期分为 IT 项目前期、IT 项目建设期和 IT 项目运营期

• 检查点：是指在规定的时间间隔内对项目进行检查，比较实际与计划之间的差异，并根据差异进行调整。一般每周一次，项目经理通过召开项目例会或上交周报等方式来检查项目进展情况。

• 里程碑：里程碑是项目中完成阶段性工作的标志。里程碑的建立必须连带（中间）交付物，交付物必须让客户确认。

三、项目经理的责任和权力

# 1、项目经理的职责

• 确保项目目标实现。项目经理运用合同把项目各方统一到项目目标和合同条款上。

• 确定开发计划。制定项目阶段性目标和项目总体控制计划。计划、计划、再计划。

• 组织实施。设计团队组织结构，安排合适人选，合理分配任务，营造高效环境。

• 项目控制。时刻监控项目的运行。对项目进行全方位全过程管理监控。

# 2、项目经理的权利

• 生产指挥权。根据资源变化情况进行指挥调度（资源调配），对组织计划进行优化调整。

• 项目团队的组建权。项目经理管理班子的组建权，项目团队成员的选拔权。

• 财权。承包范围内的财务决策权：利益分配权，制定奖惩制度，费用控制权。

• 技术决策权。审查和批准重大技术措施和技术方案。

# 3、项目经理的能力

• 获得项目资源的能力。获得符合质量和数量要求的资源和人员，确保项目有恰当等级的资源。

• 消除障碍和解决问题的能力。处理各种纠纷、冲突和矛盾。

• 领导能力和权衡能力。领导团队的每一个人。权衡项目的成本、进度、质量和绩效。

• 沟通能力。良好的人际交往能力。

• 管理时间的能力。时间管理，辨明先后主次。

• 灵敏性。敏锐的政治触角，对冲突有灵敏的感觉，IT 技术敏感，具有应变能力，灵活性和创造性。

# 第三章 IT 项目整体管理

# 一、项目启动和可行性分析

# 1、准备和启动过程

在项目管理中，启动阶段是识别和启动一个新项目或项目新阶段的过程。

完整的项目启动过程是指从项目的产生、项目概念的开发、机会研究，然后通过可行性分析、选择、优化，确定所要进行的项目，直到最后项目的正式启动。

（1）项目建议书

• 项目的背景。

• 项目的意义和必要性。

• 项目产品或服务的市场预测。

• 项目规模项目建设的必要条件，已具备和尚不具备的条件分析。

• 投资估算和资金筹措的设想。

• 项目经济效益、市场前景初步分析。

• 其他需要说明的情况等。

（2）项目的核准和立项

• IT 项目只有在可行性研究或初步计划完成之后才能正式启动，一般包括编写立项报告，在通过审批后召开启动会议，项目正式启动。

• 对于一个小项目，只要可行、合法，不必经过有关部门的批准就可以实施。

• 对于大项目一般需要申报到有关部门进行核准，审批通过后才能启动。这一过程称为项目立项。

• 这个阶段需要决定项目是自己开发还是采购。采购的话会进入招标环节，自己开发则开始筹备项目启动。

（3）招标投标

• 招标投标是在市场经济条件下进行大宗货物的买卖、工程建设项目有发包与承包，以及服务项目的采购与提供时，所采用的一种交易方式。

（4）项目启动

1. 立项启动准备

   项目考核管理制度。

   项目费用管理制度。

   项目例会管理制度。

   项目通报制度。

   项目计划管理制度：明确各级项目计划的制订、检查流程，如整体计划、阶段计划、周计划。

   项目文件管理流程：明确各种文件名称的管理和制定文件的标准模板，如汇报模板、例会模板、日志、问题列表等。

2. 召开项目启动会议

   项目开工的正式宣告，参加人应该包括项目组织机构中的关键角色，如管理层、项目经理、供应商代表、客户代表、项目监理、技术人员代表等。项目启动会的任务包括下面几项内容。

   阐述项目背景、价值、目标。

   项目交付物介绍。

   项目组织机构及主要成员职责介绍。

   使双方人员彼此认识，明确各个层次的接口。

   项目初步计划与风险分析。

   项目管理制度。

   项目将要使用的工作方式。

（5）制定项目章程

• 编写一份正式批准项目，并授权项目经理在项目活动中使用组织资源的文件的过程。

• 明确地给出了项目的定义，说明了它的特点和最终结果，规定了项目的发起人、项目经理和团队领导。

• 主要作用是正式宣布项目的存在，粗略规定项目的范围，并任命项目经理等。项目章程应当由项目团队之外的、适当级别的、并为项目出资的项目发起人或投资人发布。

# 2、可行性研究

可行性研究是对拟选的技术方案、项目需求进行先期的调查和研究，分析投资收益比，研究项目的可行性，提出初步的系统目标和项目计划，必要时提出对用户业务流程等进行重组等改进建议。

可行性分析一般包括初步可行性分析、详细可行性分析和提交可行性研究报告 3 个阶段。根据项目情况可以跨越阶段进行。

（1）初步可行性研究

• 分析项目的前途，从而决定是否应该继续深入调查研究。

• 初步估计和确定项目中的关键技术核心问题，以确定是否有可能解决。

• 初步估计必须进行的辅助研究，以解决项目的核心问题，并判断是否具备必要的技术、实验、人力条件作为支持。

（2）详细可行性研究

• 详细可行性研究是项目决策前进行详尽的、系统的、全面的调查、研究、分析和论证，对可能的技术方案进行详细的论证、比较，对项目建设完成后可能产生的经济、社会效益进行预测和评价，最终提交的可行性研究报告将作为进行项目决策和评估的依据。

• 可行性研究的内容一般包括技术可行性分析、经济可行性、运行环境可行性和可行性研究报告。

（1）技术可行性分析

• 在现有的技术条件下，能否达到用户所提出的要求，所需要的各种资源是否具备、是否能得到。

  • ① 项目开发的技术风险。限制范围和时间期限内，能否设计出逾期的系统。

  • ② 人力资源的有效性。技术人员队伍的建立、数量和能力。

  • ③ 技术能力的可能性。相关技术的发展趋势和当前所掌握的技术是否支持。

  • ④ 设备（产品）的可用性。用于建立系统的其他资源。

（2）经济可行性

• 估计项目的成本和效益，分析项目在经济上是否合理。

  • ① 成本分析

    • 开发成本：设备、机房及附属设施费用、软件开发费用等

    • 维护成本：系统维护费、系统运行费等

  • ② 直接经济效益分析。

    • 资金折现公式为：资金折现值 = 资金未来值 /(1 + t) T 其中，t 是银行利率，T 是年份。

    • 衡量经济效益的指标主要有以下几项。

    • 纯收入。资金收益折现值 - 成本。

    • 投资回收期。资金收益折现值 = 成本时所需要的时间。

（3）运行环境可行性。

• 从管理制度、管理方法、规章制度、人员素质、数据资源、硬件平台等评估，重点评估是否可以建立系统顺利运行所需要的环境，以及建立这个环境所需要进行的工作，以便可以纳入项目计划中。

（4）可行性研究报告。

• 结论需要明确：

  • 项目各方面条件已经基本具备，可以立即开发。

  • 项目实施的基本条件不具备，可建议终止项目或推迟到具备某些条件后再进行（资金缺口大，技术难突破等）。

  • 某些条件准备不充分，可建议修改调整原来的系统目标，使其成为可行。

# 二、项目管理计划

项目管理计划包括项目整体介绍、如何组织开展项目的描述、项目运用的管理技术与方法、时间进度表和预算等。

（1）项目管理计划的内容

• 1）项目名称。

• 2）项目需求的简要描述。项目的目标和组织项目的原因，以及大致的时间和成本估算。

• 3）发起人的名称。

• 4）项目经理与主要成员的简介。

• 5）项目可交付成果。软件、硬件设备、技术报告、培训材料、维护手册等。

• 6）重要资料清单。前期项目形成的过程、范围管理计划、进度管理计划、成本管理计划、质量管理计划、人员管理计划、沟通管理计划、风险管理计划、采购管理计划等。

• 7）有关定义和缩写词的说明。

（2）项目管理计划的作用

• 确定项目的工作规范、遵循标准，成为项目实施的依据和指南。

• 明确项目组各成员及其工作责任范围，以及相应的职权。

• 使项目组成员明确自己的工作目标、工作方法、工作途径、工作期限要求。

• 保证项目进行过程中项目组成员和项目干系人之间的交流、沟通与协作，使得项目各项工作协调一致，增加客户满意度。

• 为项目的跟踪控制提供基础。

• 项目计划在项目中起到承上启下的作用，计划批准后应当作为项目的工作指南。

（3）编制项目管理计划的注意事项

• 1）注意项目计划的弹性。滚动计划方法按照 “近细远粗” 的原则调整和修订。

• 2）注意项目计划的层次性。按照高级、分阶段、详细等层次制定。

• 3）注意计划的现实有用。

  • 充分鼓励、积极接纳项目干系人来参与项目计划的制订。

  • 充分利用历史数据。

• 4）重视与客户的沟通。

# 三、项目计划执行、监控与变更控制

# 1、指导与管理项目执行

项目计划执行是执行项目计划的主要过程，项目产品是在这个过程中产生的，管理团队需要协调、管理各种技术和组织间的接口，花费大部分的资源。

# 2、监控项目工作

监控项目工作监视和控制启动、规划、执行和结束项目所需的各个过程。贯穿项目始终。

主要监控对象包括如下几方面。

• 对照项目管理计划比较项目的实际表现。

• 评价项目的绩效，判断是否出现需要采取纠正或预防措施的迹象，并在必要时提出采取行动的建议。

• 分析、跟踪并监视项目风险，执行适当的风险应对计划。

• 建立有关项目产品及有关文件的准确和及时的信息库。

• 为状态报告、绩效测量和预测提供信息支持。

• 为更新当前的成本和进度信息提供预测。

3、项目整体变更控制

项目整体变更控制是在项目声明周期的整个过程中对变更进行识别、评价和管理。

主要目标包括如下几方面。

• 对引起变更的各种因素施加影响，以保证这些变更是征得同意的。

• 确认变更是否已经发生。

• 当变更发生时，对实际变更进行管理。

• 维护绩效测量基准计划的完整性。

• 确保产品范围的变更反映在项目范围定义中。

• 在各个知识域中协调变更。

# 四、项目收尾与验收

（1）结束项目或阶段

• 项目收尾工作是项目全过程的最后阶段，包括验收、正式移交运行、项目评价等工作。

（2）项目验收

• 项目范围确认、质量验收、项目资料验收

（3）项目移交与清算

• 项目移交是在项目收尾后，将全部的产品和服务交付给客户和用户。

• 项目验收是项目移交的前提，移交是项目收尾阶段的最后工作内容。

• 项目清算是不能成功结束的项目，需要尽快终止项目并清算。

# 第四章 IT 项目范围管理

# 一、项目范围与范围管理

项目范围管理包括确保项目做且只做所需的全部工作，以成功完成项目的各个过程。

管理项目范围主要在于定义和控制哪些工作应该包括在项目内，哪些不应该包括在项目内。

项目范围管理的过程包括以下内容。

• （1）规划范围管理。

• （2）收集需求。

• （3）范围定义。

• （4）创建工作分解结构（Work Breakdown Structure，WBS）。

• （5）范围核实。

• （6）范围变更控制。

IT 项目范围管理的重要性：

• （1）提高费用、时间和资源估算的准确性。
• （2）确定进行测量和控制的基准。
• （3）有助于项目分工。

# 二、规划范围管理

规划范围管理是为记录如何定义、确认和控制项目范围及产品范围，而创建范围管理计划的过程。在整个项目期间对如何管理范围提供指南和方向。

• 范围管理计划：如何管理项目范围以及如何将变更纳入到项目范围之内，项目范围稳定性评价，包括项目范围变化的可能原因、频率和幅度。

• 需求管理计划：项目管理计划的部分，包含如何规划、跟踪和报告各项需求活动，配置管理活动、需求优先级排序、测量指标等。

# 三、收集需求

# 1、收集需求

收集需求是为实现目标而确定、记录并管理干系人的需要和需求的过程。为定义产品范围和项目范围奠定基础。需求收集活动出现大的误差将是方向性的重大错误。

收集需求 —— 工具与技术

访谈：与干系人直接交谈。

焦点小组会议：把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。

引导式研讨会：邀请主要的跨职能干系人一起参加会议，对产品需求进行集中讨论与定义。

名义小组法。小组成员独立思考，写下自己的备选方案和意见。再按次序陈述自己的方案和意见。由小组成员对全部备选方案进行投票，根据投票结果，赞成人数最多的备选方案即为所要的方案，当然，管理者最后仍有权决定是接受还是拒绝这一方案。

群体决策技术。一致同意、大多数原则、相对多数原则、独裁。

观察法。核对清单法、级别量表法、记叙性描述。

原型法。在实际制造预期产品之前，先造出该产品的模型，并据此征求对需求的早期反馈。

需求文件：描述各种单一需求将如何满足与项目相关的业务需求。包含业务需求、可跟踪业务目标和项目目标、功能需求、非功能要求、质量要求、验收标准、体现组织指导原则的业务原则、对组织内部和外部团队的影响、对支持和培训的需求、与需求有关的假设条件和制约因素。

需求跟踪矩阵：把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

# 2、软件项目的需求管理

需求管理过程是保证软件需求以一种技术性是描述一个产品应该具有的功能、性能、性质等。从需求获取开始贯穿于整个项目生命周期。保证开发过程的一致性。

• （1）定义需求：形成经过评审的书面文档《需求规格说明书》

• （2）需求确认：沟通对不一致的需求剔除；双方承诺共同理解或用户认可的部分。

• （3）建立需求状态：用户需求的一种状态变换过程。

• （4）需求评审：正式的技术评审（开发方和客户方组成）；非正式技术评审（开发方内部）。正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。

• （5）需求承诺：开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品做出承诺。

• （6）需求跟踪：建立和维护从用户需求开始到测试之间的一致性与完整性。正向跟踪（检查《需求规格说明书》的每个需求是否在后续工作产品中找到对应点）和逆向跟踪（检查设计文档、代码、测试用例等工作产品是否在《需求规格说明书》中找到）。

• （7）需求变更控制：正确判断内在或外在原因的变更所带来的影响，并且调整开发过程以控制和适应这些变化。

# 四、范围定义

定义范围是制定项目和产品详细描述的过程。描述产品、服务或成果的边界和验收标准。

项目范围定义是根据范围管理计划，采取一定的办法，逐步得到精确的项目范围的过程。

项目范围说明书：项目目标与项目范围指标、产品描述、项目可交付成果的规定、验收标准、约束条件、假定、项目配置关系及其管理要求。

# 五、创建工作分解结构

工作分解结构是以项目的可交付成果为中心，为了完成项目的目标和创造项目的可交付成果，由项目团队进行的一种对项目工作有层次的分解。

要把整个项目工作分解为工作包，通常需要开展以下活动：

・识别和分析可交付成果及相关工作

・确定 WBS 的结构和编排方法

・自上而下逐层细化分解

・为 WBS 组成部分制定和分配标识编码

・核实可交付成果分解的程度是否恰当

分解注意事项：

• (1) WBS 必须是面向可交付成果的。

• (2) WBS 必须符合项目的范围。WBS 必须包括，也仅包括为了完成项目的可交付成果的活动。

• (3) WBS 的底层应该支持计划和控制。

• (4) WBS 中的元素必须有人负责，而且只由一个人负责，尽管实际上可能需要多个人参与。

• (5) WBS 的指导。作为指导而不是原则，WBS 应控制在 4~6 层。当然，大项目可以超过 6 层。一个工作单元只能从属于某个上层单元，避免交叉从属。

• (6) WBS 应包括项目管理工作也要包括分包出去的工作。

• (7) WBS 的编制需要所有 (主要) 项目干系人的参与，需要项目团队成员的参与。

• (8) WBS 并非是一成不变的，在完成了 WBS 之后的工作中，仍然有可能需要对 WBS 进行修改。

范围基准是由批准的项目范围说明书、WBS、和 WBS 词典组成。

WBS 词典：对每一工作包包括的详细内容进行表述，包括：编号、名称、如何做、投入资源、结果、完成的标准 / 质量、由谁做...

# 六、项目范围核实

检查。开展测量、审查与确认等活动，来判断工作和可交付成果是否符合需求和产品验收标准。检査有时也被称为审查、产品审查、审计、走查和巡检等。在某些应用领域，这些术语具有独特和具体的含义。

决策。可用于本过程的决策技术包括 (但不限于) 投票。当由项目团队和其他相关方进行验收时，使用投票来形成结论。

可交付成果。指的是在某一过程、阶段或项目完成时，经过 “指导与管理项目工作” 过程产出的任何独特并可核实的产品、成果或服务【研发完成】

核实的可交付成果。是指已经完成，并经过 “控制质量” 过程检查为正确的可交付成果。【内测通过】

验收的可交付成果。是指对核实的可交付成果，经过 “确认范围” 过程由客户或发起人确认为满足既定验收标准的产品、结果或服务。【甲方试用通过】

最终的成果、产品或服务的移交。是指对验收的可交付成果，经过 “结束项目或阶段” 过程，最终移交给客户的产品、结果或服务。

# 七、项目范围控制

项目范围控制是监督项目和产品的范围状态，管理范围基准变更的过程。在整个项目期间保持对范围基准的维护，且需要在整个项目期间开展。

IT 项目范围变更控制过程：

提交变更请求：变更请求应被记录，并提交给 CCB。

复审变更请求：在 CCB 复审会议中对变更请求进行初始复审，以确定是否为有效请求。

安排或分配工作：对于确认并批准的变更请求，实施工作分配和安排。

进行变更：对需要采取措施的地方确定应采取的具体措施。

核实或测试工作版本中的变更。

发布工作版本中的变更。

估计所采取的纠正措施的效果，如果所采取的纠正措施仍无法获得满意的范围调整，则重复以上步骤。

第五章 IT 项目进度管理

一、规划进度管理

规划进度管理是为规划、编制、管理、执行和控制项目进度而制定政策、程序和文档的过程。

本过程的主要作用是，为如何在整个项目期间管理项目进度提供指南和方向。

二、定义活动

定义活动是识别和记录为完成项目可交付成果而须采取的具体行动的过程。

本过程的主要作用是，将工作包分解为进度活动，作为对项目工作进行进度估算、规划、执行、监督和控制的基础。

三、排列活动顺序

排列活动顺序是识别和记录项目活动之间的关系的过程。

本过程的主要作用是定义工作之间的逻辑顺序，以便在既定的所有项目制约因素下获得最高的效率。

1、紧前关系绘图法（PDM）的活动关系类型

2、前导图法 (Precedence Diagramming Method , PDM)

也称紧前关系绘图法，也被称作单代号网络图 (只有节点需要编号) 或活动节点图 ( Active On Node,AON)，是用于编制项目进度网络图的一种方法，它使用方框或者长方形 (被称作节点) 代表活动，节点之间用箭头连接，以显示节点之间的逻辑关系。

编制前导图时要注意以下几个问题：

 一个网络图只有一个开始点和一个结束点。

 网络图是有方向的，不应该出现循环回路。

 网络图中不能出现无箭头箭线和双箭头箭线。

 网络图中不能出现无节点的箭线。

 在同一个网络图中的所有节点，不能出现相同的编号。

3、箭线图法（Arrow Diagramming Method,ADM）

用箭线表示活动、节点表示事件的一种网络图绘制方法。也称为双代号网络图（节点和箭线都要编号）或活动箭线图（Active On the Arrow,AOA）。

虚活动不消耗时间，也不消耗资源，只是为了弥补箭线图在表达活动依赖关系方面的不足。在复杂的网络图中，为避免多个起点或终点引起的混淆，我们可以用虚活动来解，借助虚活动，我们可以更好地、更清楚地表达活动之间的关系。

编制双代号网络图时要注意以下几个问题。

在一个图中的所有节点，不能出现相同的编号。

任意两项活动的紧前事件和紧后事件至少有一个不相同，节点序号沿箭线方向越来越大。

流入（流出）同一节点的活动，均有共同的紧后活动（或紧前活动）。

4、提前量与滞后量

提前量 (Lead) 是相对于紧前活动，紧后活动可以提前的时间量。提前量往往表示负数。

滞后量 (Lag) 是相对于紧前活动，紧后活动需要推迟的时间量。滞后量往往表示正数。

四、估算活动资源

估算活动资源是对执行项目所需的团队人力资源，以及材料、设备和用品的类型和数量进行估算的过程.

主要作用：确定出完成项目所需的资源种类、数量和特性。

1、估算活动持续时间 —— 工具与技术

专家判断。具备团队和物质资源的规划和估算方面的专业知识或接受过相关培训的个人或小组。

类比估算。将以往类似项目的资源相关信息作为估算未来项目的基础。

参数估算。基于历史数据和项目参数，使用某种算法或历史数据与其他变量之间的统计关系，来计算活动所需的资源数量。

自下而上估算。团队和实物资源首先在活动级别上进行估算，然后汇总成工作包、控制账户和总体项目层级上的估算。

数据分析。本过程建议使用：备选方案分析和储备分析。

项目管理信息系统。可以包括资源管理软件，这些软件有助于规划、组织与管理资源库，以及编制资源估算。

会议。项目团队可能会召开会议来估算活动资源。

2、估算活动持续时间 —— 输出

资源需求。识别了各个工作包或工作包中每个活动所需的资源类型和数量

估算资源

・对资源估算时所需的支持信息，它的数量和种类因应用领域的不同而不同。

・支持信息可以包括：估算方法；用于估算的资源；与估算有关的假设条件；已知的制约因素；估算范围；

资源分解结构。是资源按照类别和类型的层级展现。

五、估算活动持续时间

估算活动持续时间是根据资源估算的结果，估算完成单项活动所需工作时段数的过程。

本过程的主要作用是，确定完成每个活动所需花费的时间量。

六、制定进度计划

制定进度计划是分析活动顺序、持续时间、资源需求和进度制约因素，创建进度模型，从而落实项目执行和监控的过程。

本过程的主要作用是，为完成项目活动而制定具有计划日期的进度模型。

1、关键路径法

用于在进度模型中估算项目最短工期，确定逻辑网络路径的进度灵活性大小。

这种进度网络分析技术在不考虑任何资源限制的情况下，沿进度网络路径使用顺推与逆推法，计算出所有活动的最早开始 ES 最早结束 EF、最晚开始 LS 和最晚完成 LF 日期。

（1）关键路径

关键路径决定了项目完成的最短时间。

是时间浮动为 0（Float=0）的路径。

网络图中最长的路径。

关键路径上的任何活动延迟，都会导致整个项目完成时间的延迟。关键路径上的活动称为关键活动。

明确关键路径后，可以合理安排进度。

关键路径可能不止一条，在项目的进行过程中，关键路径可能会改变。

（2）自由浮动和总浮动时间

自由浮动 (Free Float)：在不影响紧后活动最早开始时间的情况下本活动可以延迟的时间。

计算方法：紧后活动最早开始时间的最小值减去本活动的最早完成时间。

总浮动 (Total Float)：在不影响项目最早完成时间的情况下本活动可以延迟的时间。

计算方法：本活动的最迟完成时间减去本活动的最早完成时间，或本活动的最迟开始时间减去本活动的最早开始时间。正常情况下，关键活动的总浮动时间为 0。

（3）正推法和逆推法

1. 正推法

按照时间顺序来计算路径中每项活动的最早开始时间和最早完成时间。

建立项目的开始时间。

项目的开始时间就是网络图中第一个活动的最早开始时间。

按网络图从左到右，从上到下的顺序进行计算。所用公式为：

ES + 工期（Duration）=EF

EF + 滞后量（Lag）=ESs 或 EF - 提前量（Lead）=ESs

当一个活动有多个前置时，选择其中最大的最早完成时间 (加上滞后量 Lag 或减去提前量 Lead) 作为其后置任务的最早开始时间。

1. 逆推法

按照逆时间顺序计算路径中每项活动的最晚开始时间和最晚完成时间。

首先建立项目的结束时间。

项目的结束时间就是网络图中最后一个活动的最晚完成时间。

从右到左，从上到下进行计算。所用公式为：

LF - 工期（Duration）=LS

LS - 滞后量（Lag）=LFp 或 LS + 提前量（Lead）=LFp

当一个任务有多个后置任务时，选择其中最小的最晚开始时间 (减去滞后量 Lag 或加上提前量 Lead) 作为其前置任务的最晚完成时间。

2、关键链法

是一种进度规划方法，允许项目团队在任何项目进度路径上设置缓冲，以应对资源限制和项目的不确定性。这种方法建立在关键路径法之上，考虑了资源分配、资源优化、资源平衡和活动历时不确定性对关键路径的影响。

关键链法增加了作为 “非工作活动” 的持续时间缓冲，用来应对不确定性。如图，放置在关键链末端的缓冲称为项目缓冲，用来保证项目不因关键链的延误而延误。其他缓冲，即接驳缓冲，则放置在非关键链与关键链的接合点，用来保护关键链不受非关键链延误的影响。

3、资源优化技术

（1）资源平衡，为了在资源需求与资源供给之前取得平衡，根据资源制约对开始日期和结束日期进行调整的一种技术。如果共享资源或关键资源只在特定时间可用，数量有限，或被过度分配，如一个资源在同一时间内被分配至两个或多个活动，就需要进行资源平衡。也可以为保持资源使用量处于均衡水平而进行资源平衡。资源平衡往往导致关键路径改变，通常是延长。

（2）资源平滑，对进度模型中的活动进行调整，从而使项目资源需求不超过预定的资源限制的一种技术。相对资源平衡而言，资源平滑不会改变项目关键路径，完工日期也不会延迟。也就是说，活动只在其自由浮动时间和总浮动时间内延迟。因此，资源平滑技术可能无法实现所有资源的优化。

4、甘特图

甘特图（Gantt Chart 或 Bar Chart）是表示项目各阶段任务开始时间与结束时间的图形，它把计划和进度安排组织在一起。

甘特图用水平线段表示阶段任务，线段的起点和终点分别对应于任务的开始时间和结束时间，线段的长度表示完成任务所需要的时间。

甘特图的优点是表明了任务的进度计划和当前进度，能直观反映项目的进展情况。

甘特图的缺点是不能反映某一项任务的进度变化对整体项目的影响，它把各项任务看成是独立的工作，没有考虑项目之间存在着因果和逻辑关系。

5**、计划评审技术（PERT）**

与三点估算的计算方法相同，三点估算用于估算单个活动历时，是活动历时估算过程中用到的技术；而 PERT 是一种进度表编制技术，用于制订进度表的过程中。

在 PERT 图中，用箭号表示事件，即要完成的任务。箭头旁给出子任务的名称和完成该子任务所需要的时间。用圆圈节点表示事件的起点和终点。

6、进度压缩

赶工：通过增加资源，以最小的成本代价来压缩进度工期的一种技术。

快速跟进：一种进度压缩技术，将正常情况下按顺序进行的活动或阶段改为至少是部分并行开展。

1. 进度控制

控制进度是监督项目状态，以更新项目进度和管理进度基准变更的过程。

本过程的主要作用是在整个项目期间保持对进度基准的维护，且需要在整个项目期间开展。

第六章 IT 项目成本管理

一、项目成本管理概述

1、项目成本管理

项目成本管理包括为使项目在批准的预算内完成而对成本进行规划、估算、预算、融资、筹资、管理和控制的各个过程，从而确保项目在批准的预算内完工。

2、软件项目成本

（1）软件产品的生产不是一个重复的制造过程，项目成本是以 “一次性” 开发过程中所花费的代价来计算的。

从系统生命周期构成的开发阶段和维护阶段看，IT 项目的成本由开发成本和维护成本构成。

其中开发成本由软件开发成本、硬件成本和其他成本组成，包括软件的分析 / 设计费用（包含系统调研、需求分析、系统设计）、实施费用（包含编程 / 测试、硬件购买与安装、系统软件购置、数据收集、人员培训）及系统切换等方面的费用。

维护成本包括运行费用（包含人工费、材料费、固定资产折旧费、专有技术及技术资料购置费）、管理费（包含审计费、系统服务费、行政管理费）及维护费（包含纠错性维护费用及适应性维护费用等）。

（2）在产品或系统的整个使用生命期内，在获得阶段（设计、生产、安装和测试等活动，即项目存续期间）、运营与维护及生命周期结束时对产品的处置所发生的全部成本。

直接成本是与开发的具体项目直接相关的成本，例如人员的工资，材料费，外包外购成本等，包括开发成本，管理成本，质量成本等。

间接成本不能归属于一个具体的项目，是企业的运营成本，可以分摊到各个项目中。例如房租，水电，保安，员工福利，保险，税收，行政管理，市场费用。

成本基准是经批准的按时间安排的成本支出计划，并随时反映了经批准的项目变更（所增加或减少的资金项目），被用于度量和监督项目的实际执行成本。

1. 规划成本管理

规划成本管理是为规划、管理、花费和控制项目成本而制定政策、程序和文档的过程。

本过程的主要作用是在整个项目中为如何管理项目成本提供指南和方向。

成本管理计划：项目管理计划的组成部分，描述将如何规划、安排和控制项目成本。包括计量单位、精确度、准确度、控制临界值、绩效测量规则、报告格式、其他细节。

三、估算成本

估算成本是对完成项目工作所需资源成本进行近似估算的过程。

本过程的主要作用是确定完成项目所需的成本数额。

・估算成本步骤

（1）识别并分析成本的构成科目。

（2）根据已识别的项目成本构成，估算每一科目的成本大小。

（3）分析成本估算结果，找出各种可以相互替代的成本，协调各种成本之间的比例关系。

・软件项目规模度量单位：

LOC (Lines of Code)：源代码程序长度的测量

FP (Function Point)：系统功能数量的测量

・软件项目工作量是指为了提供软件的功能而必须完成的软件工程任务量。其度量单位为：人月、人天、人年：人在单位时间内完成的任务量

为了确定工作量度量单位，可设定一个 “标准程序员”，例如具有 15~18 个月开发经验的程序员。

・工作量是成本的主要考虑因素，项目的工作量估算和成本估算常常同时进行。

・如果确定了单位工作量的成本，则可根据项目工作量直接计算出项目成本。

例如：如果一个软件项目的工作量是 20 人月，而企业的人力成本参数是 2 万元 / 人月，则项目的成本是 40 万元。

・代码行估算

某软件公司统计发现该公司每一万行 C 语言源代码形成的源文件（.c 和.h 文件）约为 250K。某项目的源文件大小为 3.75M，则可估计该项目源代码大约为 15 万行，该项目累计投入工作量为 240 人月，每人月费用为 10000 元（包括人均工资、福利、办公费用等）

则该项目中 1LOC 的价值为：（240×10000）/150000＝16 元 / L

1、类比估算

使用场景：

（1）类比方法常在项目详细信息有限的情况下使用；

（2）通常在项目早期计划编制阶段使用；

（3）类比估算的费用较低，精确度通常也差。

2、自下而上估算

（1）估算具体活动或工作包括的成本；

（2）将它们汇总得出项目总成本；

（3）比其他估算法更为准确 — 当所有人都能如实估算其负责的工作包成本时；

（4）各项目组进行估算时可能发生 “虚报” 现象。

3、参数估算

（1）以数学模型为特征；

（2）需要准确的历史信息；

（3）可以根据参数的不同赋予不同的权重；

（4）准确度取决于模型的复杂性等因素。

4、三点估算

四、制定成本预算

制定成本预算是汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准的过程。

本过程的主要作用是，确定可据以监督和控制项目绩效的成本基准。

・制定成本预算步骤

（1）将项目总成本分摊到项目工作分解结构的各个工作包。

（2）将各个工作包成本再分配到该工作包所包含的各项活动上。

（3）确定各项成本预算支出的时间计划及项目成本预算计划。

储备分析 - 准备金分析

（1）应急储备应对 “已知的未知” 包含在成本基线当中，根据定量风险分析的结果；

（2）管理储备应对 “未知的未知” 花费前需获得批准，不是成本基线的一部分，但是包含在预算之内。

资金限制平衡

（1）在资金支出的界限内平衡；

（2）可以作为限制条件；

（3）有时需要对工作进度进行调整。

成本基准：经过批准的、按时间段分配的项目预算，不包括任何管理储备，只有通过正式的变更控制程序才能变更，用作与实际结果进行比较的依据。成本基准是不同进度活动经批准的预算的总和。

项目资金需求：

根据成本基准，确定总资金需求和阶段性（如季度或年度）资金需求。成本基准中既包括预计

支出及预计债务。项目资金通常以增量的方式投入，并且可能是非均衡的，如果有管理储备，

则总资金需求等于成本基准加管理储备。

五、控制成本

控制成本是监督项目状态，以更新项目成本和管理成本基准变更的过程。

本过程的主要作用是，在整个项目期间保持对成本基准的维护。

1、挣值管理 (Earned Value Management)

(1) 是一种测量项目绩效的客观方法，综合考虑了项目的范围、时间和成本；

(2) 能够有效地测量项目的健康状况和项目的执行绩效；

(3) 并且能够预测项目的未来绩效和完成情况

(4) 在某一时间点进行评估。

计划工作的预算成本 PV (Planned value),BCWS ( budgeted cost of workscheduled) 按预算价格和预算工作量计算。

PV = 预算价格 × 预算工作量

已完成工作的实际成本 AC (Actual cost), 也称 ACWP ( actual cost of workperformed), 按实际价格和实际已完成工作量计算。

AC = 实际价格 × 已完成工作量

已完成工作的预算成本 EV (Earned Value)), 也称 BCWP ( budgeted cost of work performed), 按预算价格和实际已完成工作量计算。

EV = 预算价格 × 已完成工作量

成本绩效分析

成本偏差 CV (Cost variance)，CV=EV-AC

CV>0, 结余；C<0, 超支；CV=0, 实际成本与预算相符。

成本绩效指数 CPl (Cost Performed Index)，CPl=EV/AC

CPI>1, 实际成本低于预算成本，效益好；CPI<1, 效益不好；CPI=1, 实际成本与预算成本吻合，效益达到预定目标。

进度绩效分析

进度偏差值 SV (Schedule variance)，SV=EV-PV

SV>0, 进度提前；SV<0, 进度延误；SV=0, 实际进度与计划相符。

进度绩效指数 SPI (Schedule performed index)，SPI=EV/PV

****SPI>1, 进度提前；SPI<1, 进度延误；SPI=1, 实际进度与计划进度吻合。

项目绩效评估 - 预测技术：

(1) 假定项目未完成部分将按照目前的效率去进行的预测方法

EAC =AC+(BAC-EV)/CPI=BAC/CPI，ETC=(BAC-EV)/CPI（典型偏差）

(2) 假定项目未完成部分将按计划规定的效率进行的预测方法

EAC =AC+(BAC-EV)，ETC=BAC-EV（非典型偏差）

(3) 用重估所有剩余工作量的成本作出预测的方法

EAC=AC + 重估剩余工作量

** 练习 1：** 项目进行到第 8 周末，利用成本绩效分析和进度绩效分析方法分析成本、进度情况。

项目进行到第 8 周末，计算剩余工作量。

成本绩效分析：成本超支

CV=EV-AC=27000-34000=-7000<0

CPI=EV/AC=27000/34000=0.79<1

进度绩效分析：进度滞后

SV=EV-PV==27000−32000=−5000<0

SPI=EV/PV=27000/32000=0.84<1

剩余工作按现在的效率 0.79 进行

EAC =BAC/CPI=50000/0.79=63290

剩余工作按计划效率进行

EAC =AC+(BAC-EV)=34000+(50000-27000)=57000

剩余工作重新评估后进行 (项目实际与计划严重背离时使用)

EAC=AC + 重估剩余工作量

练习 2：

第七章 IT 项目质量管理

一、项目质量管理概述

1、质量标准

ISO9000 系列质量标准是国际标准化组织颁布的在全世界范围内通用的关于质量管理方面的系列标准。8 项基本原则：

（1）以顾客为中心（2）领导作用（3）全员参与（4）过程方法

（5）管理的系统方法（6）持续改进（7）基于事实的决策方法（8）与供方互利的关系

2、软件质量属性

正确性：系统满足规格说明和用户的程度，即在预定环境下能正确地完成预期功能的程度；

健壮性：在硬件发生故障、输入的数据无效或操作错误等意外环境下，系统能够做出适当响应的程度；

效率：为了完成预定的功能，系统需要的计算资源的多少；

完整性：对未经授权的人使用软件或数据的企图，系统能够控制的程度；

可用性：系统在完成预定应该完成的功能时令人满意的概率；

风险性：按预定的成本和进度把系统开发出来，并且使用户感到满意；

可理解性：理解和使用该系统的容易程度；

可维修性：诊断和改正在运行现场发生的错误所需要的概率；

灵活性：修改或改正在运行的系统需要的工作量的多少；

可测试性：软件容易测试的程度；

可移植性：把程序从一种硬件配置和（或）软件环境转移到另一种配置和环境时，需要的工作量多少；

可重用性：在其他应用中该程序可以被再次使用的程度（或范围）；

可运行性：把该系统和另外一个系统结合起来的工作量的多少。

二、规划质量管理

规划质量管理识别项目及其可交付成果的质量要求和 / 或标准，并书面描述项目将如何证明符合质量要求或标准的过程。

本过程的主要作用是，为在整个项目期间如何管理和核实质量提供指南和方向。

1、成本效益分析

对每个质量活动进行成本效益分析，就是要比较其可能成本与预期效益。减少返工、提高生产率、降低成本、提升干系人满意度及提升盈利能力等。

2、标杆对照

将待实施的项目实践与可比项目（标杆项目）的实践进行对照，以便识别最佳质量实践，形成改进意见，并为质量绩效考核提供依据。标杆对照也允许用不同应用领域的项目做类比。

3、实验设计

用来识别哪些因素会对正在生产的产品或正在开发流程的特定变量产生影响。

4、质量成本法

质量成本指在产品生命周期中发生的所有成本，包括为预防不符合要求、为评价产品或服务是否符合要求，以及因未达到要求而发生的成本。

质量成本包含一致性成本和非一致性成本。一致性成本包含预防成本和评估成本，非一致性成本包含内部失败成本和外部失败成本。

5、七种基本质量工具

老七工具：包括因果图、流程图、核查表、直方图、帕累托图、控制图、散点图

新七工具：包括亲和图、过程决策程序图、关联图、树形图、优先矩阵、活动网络图和矩阵图

老七工具

（1） 因果图 (shikawa 图，石川图或鱼骨图)

因果图，又称 “鱼骨图” 和 “石川图”, 将问题陈述的原因分解为离散的分支，有助于识别问题的主要原因或根本原因。

（2）流程图

流程图展示了引发缺陷的一系列步骤。

（3）核查表（经常用于质量控制）

用于收集数据的核对清单，合理排列各种事项，以便有效地收集关于潜在质量问题的有用数据。

（4）直方图

直方图是一种展示数字数据的条形图，可以展示每个可交付成果的缺陷数量、缺陷成因的排列、各个过程的不合规次数，或项目或产品缺陷的其他表现形式。用于描述集中趋势、分散程度和统计分布形状。

（5）帕累托图

用于识别造成大多数问题的少数重要原因。在帕累托图中，通常按类别排列条形，以测量频率或后果。

一般 80% 的问题是由 20% 的原因（帕累托法则 80/20 原则）造成的。从而可以知悉问题的主要原因或找出事情发生的主要矛盾。

（6）控制图

用于确定一个过程是否稳定，或者是否具有可预测的绩效。规格上限和下限是根据要求制定的，反映了可允许的最大值和最小值。

（7）散点图

散点图是一种展示两个变量之间的关系的图形，它能够展示两支轴的关系，一支轴表示过程、环境或活动的任何要素，另一支轴表示质量缺陷。

新七工具

（1）亲和图

亲和图与心智图相似。针对某个问题，产生出可联成有组织的想法模式的各种创意。

亲和图的核心是头脑风暴法，属于根据结果找原因。通过将大量创意进行分类，以便审查和分析。分类依据是创意之间的相似性。

（2）过程决策程序图（PDPC）

用于理解一个目标与达成此目标的步骤之间的关系。PDPC 有助于制订应急计划，因为它能帮助团队预测那些可能破坏目标实现的中间环节。

（3）关联图

用来分析事物之间 “原因与结果”、“目的与手段” 等复杂关系的一种图表，它能够帮助人们从事物之间的逻辑关系中，寻找出解决问题的办法。适合中等复杂情形中创新性地解决问题。

（4）树形图

也称系统图，可用于表现诸如 WBS、RBS（风险分解结构）和 OBS（组织分解结构）的层次分解结构。

（5）优先矩阵

用来识别关键事项和合适的备选方案，并通过一系列决策，排列出备选方案的优先顺序。先对标准排序和加权，再应用于所有备选方案，计算出数学得分，对备选方案排序。

（6）活动网络图

包括两种格式的网络图：AOA（活动箭线图）和最常用的 AON（活动节点图）。活动网络图连同项目进度计划编制方法一起使用，如计划评审技术 (PERT)、关键路径法 (CPM) 和紧前关系绘图法 (PDM)。

（7）矩阵图

从多维问题的事件中，找出成对的因素，排列成矩阵图，然后根据矩阵图来分析问题，确定关键点的方法，它是一种通过多因素综合思考，探索问题的好方法。在行列交叉的位置展示因素、原因和目标之间的关系强弱。

在复杂的质量问题中，往往存在许多成对的质量因素，将这些成对因素找出来，分别排列成行和列，其交点就是其相互关联的程度，在此基础上再找出存在的问题及问题的形态，从而找到解决问题的思路。

4、质量管理计划：

质量管理计划包括（但不限于）以下组成部分：

项目采用的质量标准；项目的质量目标；质量角色与职责；需要质量审查的项目可交付成果和过程；为项目规划的质量控制和质量管理活动；项目使用的质量工具；与项目有关的主要程序，例如处理不符合要求的情况、纠正措施程序，以及持续改进程序。

5、质量测量指标

质量测量指标专用于描述项目或产品属性，以及控制质量过程将如何验证符合程度。

质量测量指标包括：按时完成的任务的百分比、以 CI 测量的成本绩效、故障率、识别的日缺陷数量、每月总停机时间、每个代码行的错误、客户满意度分数，以及测试计划所涵盖的需求的百分比即测试覆盖度。

6、质量核对单

核对单是一种结构化工具，通常列出特定组成部分，用来核实所要求的一系列步骤是否已得到执行或检查需求列表是否已得到满足。基于项目需求和实践，核对单可简可繁。许多组织都有标准化的核对单，用来规范地执行经常性任务。在某些应用领域，核对单也可从专业协会或商业性服务机构获取。质量核对单应该涵盖在范围基准中定义的验收标准。

三、实施质量保证

实施质量保证是审计质量要求和质量控制测量结果，确保采用合理的质量标准和操作性定义的过程。

本过程的主要作用是，促进质量过程改进。

质量保证旨在建立对未来输出或未完输出（也称正在进行的工作）将在完工时满足特定的需求和期望的信心。质量保证部门或类似部门经常要对质量保证活动进行监督。

1、软件质量保证思想

（1）在产品开发的同时进行产品测试

测试工作提前，可以有效地防止 “失之毫厘，谬以千里” 的严重后果。

（2）在项目的各个阶段保证质量的稳定性

每隔一段时期，项目组织就应花费相应的时间对当期完成的产品特性进行测试、稳定和集成。

（3）尽可能早地使项目质量测试自动化

利用自动化测试平台不仅可以降低测试成本，而且可以提高测试效率。自动化测试工具：IBM Rational Quality Manager

（4）确保项目成员和企业文化都重视质量

产品质量是每个人的事情，而不仅是测试人员的事情

2、质量保证体系的总体要求

对于软件项目来说，质量保证体系需要负责调整所有影响产品质量的因素，例如：

 使用的方法和工具；

 在开发和维护过程中应用的标准；

 对开发和维护过程所进行的组织管理；

 软件生产环境；

 软件开发中人员的组织和管理；

 工作人员的熟练程度；

 对工作人员的奖励和工作条件的改善情况；

 对外部项目转包商交付的产品的质量控制。

3、质量审计

又称质量保证体系审核，是对具体质量管理活动的结构性的评审。

质量审计的目标是：

（1）识别全部正在实施的良好及最佳实践

（2）识别全部违规做法、差距及不足

（3）分享所在组织或行业中类似项目的良好实践

（4）积极、主动地提供协助，以改进过程的执行，从而帮助团队提高生产效率

（5）强调每次审计都应对组织经验教训的积累做出贡献

质量审计可以是事先安排，也可以随机进行。在具体领域中有专长的内部审计师或第三方组织都可以实施质量审计，可以由内部或外部审计师进行。

4、过程分析

过程分析是指按照过程改进计划中概括的步骤来识别所需的改进。

过程分析包括根本原因分析 —— 用于识别问题、探究根本原因，并制定预防措施的一种具体技术。

四、控制质量

控制质量是为了评估绩效，确保项目输出完整、正确且满足客户期望，而监督和记录质量管理活动执行结果的过程。

本过程的主要作用是，核实项目可交付成果和工作已经达到主要干系人的质量要求，可供最终验收。

质量控制是监督并记录质量活动执行结果，以便评估绩效，并推荐必要的变更的过程。

1. 软件项目常见的质量问题

（1）违背软件项目规律：如未经可行性论证；任意修改设计；不经过必要的测试；……

（2）技术方案本身的缺陷

（3）基本部件不合格（选购的软件组件、中间件、硬件设备等）

（4）实施中的管理问题（计划、监控、沟通障碍……）

2、控制质量过程的目的和方法

控制质量过程的目的是在用户验收和最终交付之前测量产品或服务的完整性、合规性和适用性。本过程通过测量所有步骤、属性和变量，来核实与规划阶段所描述规范的一致性和合规性。

软件项目质量控制采用的主要方法是技术评审、代码走查、代码会审、单元测试、集成测试、系统测试、验收测试、缺陷追踪等。

（1）技术评审（技术评审会议）

软件项目中主要的评审对象有：软件需求规格说明书、软件设计方案、测试计划、用户手册、维护手册、系统开发规程、产品发布说明等

（2）代码走查

代码走查的第一个目的是通过人工模拟执行源程序的过程，特别是一些关键算法和控制过程，检查软件设计的正确性。第二个目的是检查程序书写的规范性。

（3）代码会审

代码会审是由一组人通过阅读、讨论和争议对程序进行静态分析的过程。会审小组由组长、2～3 名程序设计和测试人员及程序员组成。

（4）软件测试

软件测试所处的阶段（单元 / 集成 / 验收测试）不同，测试的目的和方法也不同。例如，单元测试是指对软件中的最小可测试单元进行检查和验证。

（5）缺陷跟踪

从缺陷发现开始，一直到缺陷改正为止的全过程为缺陷追踪。

3、质量保证与质量控制的区别

实施质量保证是针对过程改进和设计的，强调的是过程改进和信心保证。

实施质量控制是按照质量要求，检查具体可交付成果的质量，强调的是具体的可交付成果。

质量保证（QA）是针对项目实施过程的管理手段，质量控制（QC）是针对项目产品的技术手段。

QA 只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而 QC 来检查产品是否符合质量要求。

第八章 IT 项目人力资源管理

一、项目人力资源管理的概念

1、项目人力资源管理

项目人力资源管理就是根据项目的目标、项目活动进展情况和外部环境的变化，采取科学的方法，对项目团队成员的思想、心理和行为进行有效的管理，充分发挥他们的主观能动性，实现项目的最终目标。

2、软件项目人力资源的特点

知识型员工具有较高的知识、能力，具有相对稀缺性和难以替代性。

知识型员工工作自主性要求高。

知识型员工大多崇尚智能，蔑视权威。

知识型员工成就动机强，追求卓越。

知识型员工的能力与贡献之间差异较大，内在需求具有较多的不确定性和多样性，会出现交替混合的需求模式。

知识型员工工作中的定性成分较大，工作过程一般难以量化，因而不易控制。

对于知识型员工，更需要新型的管理方式，员工希望：

（1）“以人为本” 给予知识型员工充分的尊重与认可。

（2）创造一种自由、民主、公平的工作氛围，提倡民主参与的决策方式要更优于高度集权。

（3）在完成任务的同时，员工不断进步，其知识、能力、素质不断提高，实现全面发展。

二、规划人力资源管理

规划人力资源管理是识别和记录项目角色、职责、所需技能、报告关系，并编制人员配备管理计划的过程。

本过程的主要作用是，为在整个项目期间如何管理人力资源提供指南和方向。

1、团队角色和职责的确定

软件项目团队中常见的角色包括：项目经理、系统分析人员、架构师、开发人员、测试人员、质量保证人员、项目管理和支持人员、市场人员、用户支持人员等。

项目经理的权利

1. 职位权力，来源于管理者在组织中的职位和职权
2. 惩罚权力，使用降职、扣薪、惩罚、批评、威胁等负面手段的能力
3. 奖励权力，给予下属奖励的能力
4. 专家权力，来源于个人的专业技能
5. 参照权力，由于成为别人学习参照榜样所拥有的力量

职位权力、惩罚权力、奖励权力来自于组织的授权，专家权力和参照权力来自于管理者自身

可釆用多种格式来记录团队成员的角色与职责。大多数格式属于以下三类 (如图所示): 层级型、矩阵型和文本型。通常，层级型可用于规定高层级角色，而文本型更适合用于记录详细职责。

2、责任分配分配矩阵 (RAM): 将所分解的工作任务落实到项目有关部门或个人，并明确表示出他们在组织工作中的关系、责任和地位的一种方法和工具。通过责任分配矩阵可以显示工作包或活动与项目团队成员之间的关系，可以确保任何一项任务都只有一个人负责，从而避免职权不清造成的混乱。

3、项目组织图的确定

在大型软件项目中，通常根据软件的功能模块将从事开发的人员划分为若干小组 (Team)，每个小组负责一个功能模块的开发。

4、人员配置管理计划的编制

人员配置管理计划描述何时以何种方式满足项目的人力资源需求。包括：人员招募、资源日历（每种资源可用工作日和工作班次等信息）、人员遣散计划、培训需要、认可与奖励、合规性、安全等。

三、组建项目团队

组建项目团队是根据项目团队的角色和职责、项目组织结构图和人员配备管理计划，获取完成项目工作所需的人力资源。

本过程的主要作用是概述和指导人力资源的选择，并将其分配给相应的活动

预分派：在某些情况下，一些成员已预先分派到项目中工作，例如在竞标过程中承诺分配特定人员到项目中，或项目的成功依赖于特定人员的专有技能。

谈判：大多数人员的获取需要经过谈判。例如项目经理需要与职能部门经理或其他部门负责人谈判，以获得所需要的人员。在谈判时，项目的影响力会起作用。

招募：当企业缺少完成项目所需的内部人才时，就需要从外部获得所需服务，包括招聘和分包。在获取和任用项目团队人员时，除考虑人员的专业技能外，最好能结合人员的性格特征和兴趣，做到 “知人善任”。。

虚拟团队：具有共同目标、在完成角色任务的过程中很少或没有时间面对面工作的一群人。

多标准决策分析：使用多标准决策分析工具制定出标准，用于对潜在人员进行评级或打分。

四、建设项目团队

建设项目团队是是提高工作能力，促进团队成员互动，改善团队整体氛围，以提高项目绩效的过程。

本过程的主要作用是，改进团队协作、增强人际关系技能、激励员工、减少摩擦以及提升整体项目绩效。

1、塔克曼阶梯理论

（1）形成阶段

在本阶段，团队成员相互认识，并了解项目情况及他们在项目中的正式角色与职责。团队成员倾向于相互独立，不一定开诚布公。有疑问和焦虑的情绪。

为减轻人们的焦虑，项目经理领导风格应该是指导型的，让团队成员着手参与一些具体工作，如制订项目计划。

（2）震荡阶段

在本阶段，团队开始从事项目工作，制定技术决策和讨论项目管理方法，一般会遇到超出预想的困难，希望被现实打破。个体之间开始争执，互相指责，并且开始怀疑项目经理的能力。

这是项目经理创造一个充满理解和支持的工作环境的好时机，要允许成员表达他们所关注的问题，项目经理要致力于解决矛盾。在这个阶段，项目经理的领导风格应该是影响型的。

（3）规范阶段

在规范阶段，团队成员开始协同工作，并调整各自的工作习惯和行为来支持团队，团队成员开始相互信任，项目经理能够得到团队的认可。

在本阶段，项目经理应尽量减少指导性工作，经常对项目团队所取得的进步给予公开的表扬，培育团队文化，注重培养成员对团队的认同感、归属感、努力营造出相互协作、相互帮助、相互关爱、勇于奉献的精神氛围。在这个阶段，项目经理的领导风格应该是参与型的。

（4）成熟阶段

进入这一阶段后，团队就像一个组织有序的单位那样工作。团队成员之间相互依靠，平稳高效地解决问题。项目团队能开放、坦诚、及时地进行沟通。对项目经理的信任加强。这时团队成员的集体荣誉感会非常强。

在本阶段，项目经理应完全授权，赋予团队成员权力。在这个阶段，项目经理的领导风格应该是授权型的。

（5）解散阶段

在解散阶段，团队完成所有工作，团队成员离开项目。

2、激励理论

（1）马洛斯的需求层次理论

人的需要可按等级层次向上或向下移动，当一个层次的需要被满足之后，这一需要就不再是激励的因素了，而更高层次的需要就成为新的激励因素。

1. 双因素理论（心理学家赫茨伯格）

（3）X 理论和 Y 理论（对激励问题研究比较全面）

（4）期望理论（对激励问题研究比较全面）

动力（激励力量）= 效价 × 期望值

其中，效价是个人对于某一成果的价值估计，期望值是指通过某种行为会导致一个预期成果的概率和可能性。

当人们有需要，又有达到这个需要的可能，其积极性才高。

1. 团队绩效评价

   对项目团队的有效性进行正式或非正式的评价。

实际上是对你已经进行的团队建设活动成果的评价，目的是为了了解我们已经使用的团队建设工具和方法的有效性，以便决定是否要继续进行团队建设活动。

指标包括：

・个人技能的改进；

・团队能力的改进；

・团队成员离职率的降低；

・团队凝聚力的加强。

五、管理项目团队

管理项目团队是跟踪团队成员工作表现，提供反馈，解决问题并管理团队变更，以优化项目绩效的过程。

本过程的主要作用是，影响团队行为、管理冲突以及解决问题。本过程需要在整个项目期间开展。

**1、观察和交谈：** 可通过观察和交谈，随时了解项目团队成员的工作和态度。

**2、项目绩效评估：** 包括澄清角色与职责，向团队成员提供建设性反馈，发现未知或未决问题，制定个人培训计划，以及确立未来目标。

软件团队绩效考核指标

（1）定性指标。

 工作态度：如责任心、敬业精神、工作热情等。

 工作氛围：如团队士气如何，精神状态如何等。

 工作经验：如工作方法高效与否，知识的传递正确、及时与否。

 应变能力：对于变更的控制、计划、实施和监督的效果如何。

 处理问题的能力：对于出现的问题能否及时、正确地解决。

（2）定量指标。

 工作量

 工作效率

 工作质量

 按时完成

3、冲突管理：撤退 / 回避，缓和 / 包容，妥协 / 调解，强迫 / 命令，合作 / 解决问题。

**4、人际关系技能：** 恰当地使用人际关系技能，可充分发挥全体团队成员的优势。

项目经理常见的人际关系技能有：

• 领导力（成功的项目需要强有力的领导技能，例如，项目不同阶段，领导风格不一样）
• 影响力（具有一定影响项目干系人的能力，对保证项目成功非常关键）
• 有效决策力（包括判断能力等）
• 激励
• 冲突管理

第九章 IT 项目沟通管理

一、项目沟通管理概述

项目沟通管理就是通过开发工件以及执行用于有效交换信息的各种活动，来确保项目及其相关方的信息需求得以满足的各个过程。也就是为了确保信息及时且恰当地规划、收集、生成、发布、存储、检索、管理、控制、监督和最终处置所需的各个过程。

1、项目经理在沟通中的作用

项目经理 75%-90% 的时间用于沟通，沟通是项目经理成功领导的重要手段

项目经理必须熟练掌握与高层管理者、项目团队、客户及项目以外的干系人的沟通技巧

2、项目经理在沟通中的角色

项目沟通的中枢，必须掌握沟通的主动权

冲突的解决者和谈判者

计划的制定者，过程的监控者，渠道的建立者

沟通的聆听者、解释者

沟通的协调者和促进者

信息的综合者，障碍的消除者

3、沟通活动

内部 / 外部：内部沟通活动针对项目内部或组织内部的干系人。外部沟通活动针对外部干系人，如客户、供应商、其他项组织、政府、公众和环保倡导者等。

正式 / 非正式：正式沟通可以采用报告、正式会议 (定期及临时)、会议议程和记录、干系人简报和演示等。而非正式沟通可以采用电子邮件、社交媒体、网站以及非正式临时讨论的一般沟通活动。

向上 / 向下 / 横向的层级沟通：这是根据干系人或干系人群体相对于项目团队的位置来进行划分的。如果是针对高层干系人，就是向上沟通；如果针对承担项目工作的团队和其他人员，就是向下沟通；横向沟通就是针对项目经理或团队的同级人员。

官方 / 非官方沟通：比如说年报、呈交监管机构或政府部门的报告就是官方沟通，而非官方沟通就是采用灵活的手段，往往是非正式的手段，来建立和维护项目团队及其干系人对项目情况的了解和认可，并在他们之间建立强有力的关系。

书面 / 口头沟通：口头及非口头，社交媒体和网站、媒体发布等。

二、规划沟通管理

规划沟通管理是基于每个干系人或干系人群体的信息需求、可用的组织资产，以及具体项目的需求，为项目沟通活动制定恰当的方法和计划的过程。

本过程的主要作用是为及时向干系人提供相关信息，引导干系人有效参与项目而编制书面沟通计划。

1. 沟通需求分析

分析沟通需求，确定项目干系人的信息需求，包括所需信息的类型和格式以及信息对干系人的价值。

（1）需要给哪些干系人发信息；

（2）谁需要什么样的信息；

（3）谁什么时候需要何种信息；

（4）如何将信息发送给不同的干系人。

2、沟通技术

在沟通过程中使用的具体手段和工具，如谈话、会议、书面文件、在线资料查询等。

（1）会议沟通

成本较高，沟通的时间一般比较长，因此常用于解决较重大、较复杂的问题。

（2）Email 沟通

成本低，方便快捷，小范围沟通，有时间思考斟酌等；

（3）口头沟通

是一种自然、亲近的沟通技术。加深彼此之间的友谊、加速问题的解决。几种应用场景：办公距离近；存有误会，采用 Email 无效等

（4）电话沟通

成本较低，距离远无法当面沟通，问题相对简单，采用 Email 无效等情况下适用。

（5）即时通讯

QQ/MSN/ 微信（群），快捷，方便，可以群讨论，但是闲聊可能会影响工作。

3、沟通模型

可以是最基本的线性（发送方和接收方）沟通过程，也可以是增加了反馈元素（发送方、接收方和反馈）、更具互动性的沟通形式，甚至可以是融合了发送方或接收方的人性因素、试图考虑沟通复杂性的更加复杂的沟通模型。

沟通模型的关键要素

(1) 编码。把思想或想法转化为他人能理解的语言。

(2) 信息和反馈信息。编码过程所得到的结果

(3) 媒介。用来传递信息的方法。

(4) 噪声。干扰信息传输和理解的一切因素 (如距离、新技术、缺乏背景信息等)。

(5) 解码。把信息还原成有意义的思想或想法。

4、沟通方法

・交互式沟通：在两方或多方之间进行多向信息交换，确保全体参与者对特定话题达成共识的最有效的方法，如会议、电话，即时通讯、视频会议等。

・推式沟通：把信息发送给需要接收这些信息的特定接收方，可以确保信息的发送，但不能确保信息送达受众或被目标受众理解，如新闻、公告、电子邮件、报告、日志等。

・拉式沟通：用于信息量很大或受众很多的情况，要求接收者自主自行地访问信息内容，如企业内网、电子在线资源、经验教训数据库、知识库等。

二、管理沟通

管理沟通是确保项目信息及时且恰当地收集、生成、发布、存储、检索、管理、监督和最终处置的过程。

本过程的主要作用是促成项目团队与干系人之间的有效信息流动。

报告绩效：收集和发布绩效信息，包括状况报告、进展测量结果及预测结果。应该定期收集基准数据与实际数据，进行对比分析，以便了解和沟通项目进展与绩效，并对项目结果做出预测。

项目管理信息系统（PMIS）：项目管理信息系统能够确保干系人及时便利地获取所需信息。用来管理和分发项目信息的工具主要包括电子项目管理工具、电子沟通管理工具和社交媒体管理工具。

三、控制沟通

控制沟通是在整个项目生命周期中对沟通进行监督和控制的过程，以确保满足项目干系人对信息的需求。

本过程的主要作用是，随时确保所有沟通参与者之间的信息流动的最优化。

1、沟通障碍

在项目管理工作中，存在信息的沟通，也就必然存在沟通障碍。项目经理的任务在于正视这些障碍，采取一切可能的方法来消除这些障碍，为有效的信息沟通创造条件。有三类沟通障碍：

（1）主观障碍

个人的性格、气质、态度、情绪、见解等的差别，使信息在沟通过程中受个人素质、心理因素的制约。

知觉选择偏差所造成的障碍。

经理人员和下级之间相互不信任，这主要是由于经理人员考虑不周，伤害了员工的自尊心，或决策错误所造成的，而相互不信任则会影响沟通的顺利进行。

沟通者的畏惧感以及个人心理品质也会造成沟通障碍。

信息传递者在团队中的地位、信息传递链、团队规模等因素也都会影响有效的沟通。许多研究表明，地位的高低对沟通的方向和频率有很大的影响。

（2）客观障碍

信息的发送者和接收者如果空间距离太远、接触机会少，就会造成沟通障碍。社会文化背景不同、种族不同，而形成的社会距离也会影响信息沟通。

信息沟通往往是依据组织系统分层次逐渐传递的。

（3）沟通联络方式的障碍

语言系统所造成的障碍。

沟通方式选择不当，原则、方法使用不当所造成的障碍。

2、冲突管理的技巧

做好团队的思想工作

有意识地培养心理相容

公平竞争，减少冲突

冲突发生，迅速解决

帮助双方学习提高

运用权威

制定预警方案

引发建设性冲突

（1）鼓励冲突。

（2）引进冲突机制。

3、有效沟通的方法和技巧

（1）沟通要有明确目的

（2）提高沟通的心理水平

要克服沟通的障碍必须注意以下心理因素的作用。

1. 在沟通过程中要认真感知，集中注意力，以便信息准确而又及时地传递和接受，避免信息错传和接受时减少信息的损失。
2. 增强记忆的准确性是消除沟通障碍的有效心理措施，记忆准确性水平高的人，传递信息可靠，接受信息也准确。
3. 提高思维能力和水平是提高沟通效果的重要心理因素，较高的思维能力和水平对于正确地传递、接受和理解信息，起着重要的作用。
4. 培养镇定情绪和良好的心理气氛，创造一个相互信任、有利于沟通的小环境，有助于人们真实地传递信息和正确地判断信息，避免因偏激而歪曲信息。

（3）沟通中 “听、说、问” 交替出现

（4）避免无休止的争论

（5）保持畅通的沟通渠道

（6）充分利用信息技术加强沟通

四、识别干系人

识别干系人是定期识别项目干系人，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程。

本过程的主要作用是使项目团队能够建立对每个干系人或干系人群体的适度关注。

1、干系人分析

系统的收集和分析各种定量与定性信息，以便确定在整个项目中应该考虑哪些人的利益。通过干系人分析，识别出干系人的利益、期望和影响，并把他们与项目的目的联系起来。干系人分析也有助于了解干系人之间的关系，以便利用这些关系来建立联盟或者伙伴合作，从而提高项目成功的可能性。在项目的不同阶段应该对干系人施加不同的影响。

干系人分析的步骤：

(1) 识别干系人及其相关信息

(2) 分析干系人可能的影响并把他们分类和排序

(3) 评估干系人对不同情况可能做岀的反应，以便制定相应策略对他们施加正面影响。

干系人的参与程度可按照如下标准分类。(1) 不知晓。(2) 抵制。(3) 中立。(4) 支持。(5) 领导。

权利 / 利益方格

2、干系人登记册

应包括如下内容：

（1）基本信息，如姓名、在组织中的职位、地点、在项目中的角色、联系方式等；

（2）评估信息，如主要要求、主要期望、对项目的潜在影响、与项目生命周期的哪个阶段最密切；

（3）干系人分类，如内部 / 外部，支持者 / 中立者 / 反对者等。

应定期查看并更新干系人登记册，因为在整个项目生命周期中干系人可能发生变化，也可能识别出新的干系人。

第十章 IT 项目风险管理

一、项目风险管理概述

1、风险概念

风险是不确定的事件，一旦发生，将会造成消极影响。

风险的三要素：一个未来的事件、事件发生的概率、事件的影响

风险发生的概率越高，造成的影响越大，就越是高风险，否则就是中等风险或低风险。

2、风险分类

从风险的范围角度上看，可将软件项目的风险分为若干类型：

管理风险：潜在的预算、进度、资源、用户和需求等方面的问题。

技术风险：实现和交付产品过程中所应用的各种技术所包含的风险。技术的正确性、不确定性、复杂性、技术陈旧等因素都可带来技术风险。

商业风险：与市场、企业产品策略等因素有关的风险。

人员风险：与参与项目的软件人员的稳定性、总体技术水平及项目经验相关的风险。

开发环境风险：与用以开发产品的工具的可用性和质量相关的风险。

客户风险：与客户的素质以及开发者与客户的定期沟通相关的风险。

过程风险：与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。

从风险可预测的程度来看，可将风险分为以下三种类型：

已知风险：通过评估项目计划、项目的商业和技术环境以及其它可靠的信息来源之后可以发现的那些风险。

可预测风险：能够从过去的项目经验中推测出的风险。

不可预测风险：事先很难识别出来的风险。

3、风险的基本性质

客观性：首先表现在风险的存在是不以人的意志为转移的。不管风险主体是否意识到风险的存在，在一定条件下风险都可能变为现实。其次，风险的客观性还表现在它无时不有、无所不在，它潜在于各种活动之中。

不确定性：风险何时何地有可能变为现实是不能确定的。由于人们对客观世界的认识受到各种条件的限制，不可能准确预测风险的发生。

不利性：风险一旦发生，就会给风险主体带来挫折、失败、甚至损失，对风险主体不利。

可变性：在一定条件下风险可以转化，风险可以转化为非风险，非风险的事件也可转化为风险事件。

相对性：对于相同的风险，不同的风险主体的承受能力不同，不同的组织和个人往往对风险有着不同的容忍限度。

风险和利益的对称性：风险和利益总是同时存在的，风险是利益的代价，利益是风险的报酬。

4、IT 项目的风险主要表现

（1）用户需求不一致、变化大。

（2）技术变革。

（3）系统部署风险。

（4）流程重组风险。

（5）组织与人力资源变动。

（6）开发方式风险。

5、风险管理的力度（4 个层次）

危机管理：风险已经造成麻烦后才着手处理。

风险缓解：事先制定好风险发生后的补救措施，但不制定任何防范措施。

着力预防：将风险防范作为项目的一部分加以规划和执行。

消灭根源：识别和消灭可能产生风险的根源。

6、项目风险管理的作用

有效的风险管理可以提高项目的成功率。

提前对风险制定对策，就可以在风险发生时迅速做出反应，避免忙中出错造成更大损失。

风险管理可以增加团队的健壮性。

有效的风险管理可以帮助项目经理抓住工作重点，将主要精力集中于重大风险，将工作方式从被动救火转变为主动防范。

二、规划风险管理

规划风险管理是定义如何实施项目风险管理活动的过程。

确保风险管理的水平、方法和可见度与项目风险程度，以及项目对组织和其它干系人的重要程度相匹配。

本过程仅开展一次或仅在项目的预定义点开展。

1、风险管理计划

（1）风险管理战略。管理项目风险的一般方法。

（2）角色与职责。确定风险管理计划中每个活动的领导者和支持者，以及风险管理团队的成员，并明确其职责。

（3）预算。制定应急储备和管理储备的使用方案。

（4）时间安排。确定风险管理的时间和频率，风险管理活动并纳入项目进度计划中。

（5）风险类别。通常借助风险分解结构 (Risk Breakdown Structure，RBS) 来构建风险类别。

（6）干系人风险偏好。可把干系人的风险偏好表述成可测量的风险临界值。

（7）风险概率和影响的定义。

三、识别风险

识别单个项目风险以及整体项目风险的来源，并记录风险特征的过程。

记录现有的单个项目风险，以及整体项目风险的来源；同时，汇集相关信息，以便项目团队能够恰当应对已识别的风险。

1、识别风险的过程

识别并确定项目有哪些潜在的风险

识别引起这些风险的主要影响因素

识别项目风险可能引起的后果

2、软件项目风险

（1）需求风险（IT 项目最大的风险是所完成的产品不能让用户满意）

识别需求风险时，重点分析以下因素：

用户是否充分参与需求分析。

优先需求是否得到满足。

需求变化的程度。

有无有效的需求变化管理过程。

（2）技术风险（信息技术的发展和更新速度极快）

识别技术风险时，可以分析以下因素：

对方法、工具和新技术的理解程度。

应用领域经验。

产品需求是否要求采用特殊的功能和接口。

需求中是否有过分的产品性能要求和约束。

客户所要求的功能是否技术可行。

是否有恰当的技术培训。

（3）商业风险

与商业风险有关的因素有：

本产品是否得到应有的高管层重视与支持。

交付期限的合理性如何。

本产品是否满足了用户的需求。

最终用户的水平如何。

延迟交付所造成的成本消耗如何。

产品缺陷所造成的成本消耗如何。

（4）开发方式的风险

自主开发往往面临技术实力不足的问题；外包可能存在合作和沟通的问题。采用多方合作方式时，风险就可能来自合作伙伴、技术及设备供应商等方面。

（5）数据迁移风险

系统集成环境复杂，需要迁移的数据量庞大，而且数据迁移对数据的准确性和完整性有着很高的要求。数据质量风险也不可忽视。

（6）进度风险

进度风险是指由于种种不确定性因素的存在而导致项目完工期拖延的风险。

（7）组织与人力资源风险

软件行业的人员流动性大、沟通难度大。

3、风险登记册

风险登记册：风险登记册记录已识别单个项目风险的详细信息。随着实施定性风险分析、规划风险应对、实施风险应对和监督风险等过程的开展，这些过程的结果也要记进风险登记册。取决于具体的项目变量（如规模和复杂性），风险登记册可能包含有限或广泛的风险信息。当完成识别风险过程时，风险登记册的内容可能包括（但不限于）：

・已识别风险的清单。在风险登记册中，每项单个项目风险都被赋予一个独特的标识号。要以所需的详细程度对已识别风险进行描述，确保明确理解。可以使用结构化的风险描述，来把风险本身与风险原因及风险影响区分开来。

・潜在风险责任人。如果已在识别风险过程中识别出潜在的风险责任人，就要把该责任人记录到风险登记册中。随后将由实施定性风险分析过程进行确认。

・潜在风险应对措施清单。如果已在识别风险过程中识别出某种潜在的风险应对措施，就要把它记录到风险登记册中。随后将由规划风险应对过程进行确认。

根据风险管理计划规定的风险登记册格式，可能还要记录关于每项已识别风险的其它数据，包括：简短的风险名称、风险类别、当前风险状态、一项或多项原因、一项或多项对目标的影响、风险触发条件（显示风险即将发生的事件或条件）、受影响的 WBS 组件，以及时间信息（风险何时识 别、可能何时发生、何时可能不再相关，以及采取行动的最后期限）。

四、实施定性风险分析

实施定性风险分析是通过评估单个项目风险发生的概率和影响以及其他特征，对风险进行优先级排序，从而为后续分析或行动提供基础的过程。

本过程的作用重点关注高优先级的风险。

1、风险数据质量评估

风险数据是开展定性风险分析的基础。风险数据质量评估旨在评价关于单个项目风险的数据的准确性和可靠性。

2、风险概率和影响评估

风险概率评估考虑的是特定风险发生的可能性，而风险影响评估考虑的是风险对一项或多项项目目标的潜在影响，如进度、成本、质量或绩效。威胁将产生负面的影响，机会将产生正面的影响。要对每个已识别的单个项目风险进行概率和影响评估。

3、概率和影响矩阵

概率和影响矩阵：把每个风险发生的概率和一旦发生对项目目标的影响映射起来的表格。基于风险的概率和影响，对风险进行优先级排序，以便未来进一步分析并制定应对措施。采用风险管理计划中规定的风险概率和影响定义，逐一对单个项目风险的发生概率及其对一项或多项项目目标的影响（若发生）进行评估。然后，基于所得到的概率和影响的组合，使用概率和影响矩阵，来为单个项目风险分配优先级别。

4、风险紧迫性评估

可以把近期就需要应对的风险确定为更紧迫的风险。此外，风险的可监测性、风险应对的时间要求、风险征兆和预警信号，以及风险等级等，都是确定风险优先级应考虑的指标。

5、风险分类

项目风险可依据风险来源（如采用风险分解结构 [RBS]）、受影响的项目领域（如采用 工作分解结构 [WBS]），以及其他实用类别（如项目阶段、项目预算、角色 和职责）来分类，确定哪些项目领域最容易被不确定性影响；风险还可以根据共同的根本原因进行分类。应该在风险管理计划中规定可用于项目的风险分类方法。

五、实施定量风险分析

实施定量风险分析是就已识别的单个项目风险和不确定性的其他来源对整体项目目标的影响进行定量分析的过程。

本过程的作用量化整体项目风险敞口，并提供额外的定量风险信息，以支持风险应对规划。

1、敏感性分析

把所有其他不确定因素固定在基准值，考察每个因素的变化会对目标产生多大程度的影响，有助于确定哪些风险对项目具有最大的潜在影响。

2、决策树分析

预期货币价值分析（EMV) 用以计算在将来某种情况发生或不发生情况下的平均结果（即不确定状态下的分析）。

3、模拟

项目模拟一般采用蒙特卡洛技术。在模拟中，项目模型经过多次计算 (叠加), 其随杋依据值来自于根据毎项变量的概率分布，为每个迭加过程选择的概率分布函数 (例如，项目元素的成本或进度活动的持续时间)。据此计算概率分布 (例如，总成本或完成日期。

六、规划风险应对

规划风险应对是针对项目目标，制定提高机会、降低威胁的方案和措施的过程。

本过程的作用制定应对整体项目风险和单个项目风险的适当方法；本过程还将分配资源，并根据需要将相关活动添加进项目文件和项目管理计划。

1、消极风险或威胁的应对策略

规避和减轻策略通常适用于高影响的严重风险，而转移和接受则更适用于低影响的不太严重威胁。

规避。风险规避是指项目团队釆取行动来消除威胁，或保护项目免受威胁的影响。

转移。转移涉及到将应对威胁的责仼转移给第三方，让第三方管理风险并承担威胁发生的影响。

减轻。风险减轻是指采取措施来降低威胁发生的概率和 (或) 影响。

接受。风险接受是指承认威胁的存在，但不主动采取措施。

2、积极风险或机会的应对策略

开拓。如果组织想确保把握住高优先级的机会，就可以选择开拓策略。

分享。分享涉及到将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。

提高。提高策略用于提高机会出现的概率和（或）影响。

接受。接受机会是指当机会发生时乐于利用，但不主动追求机会。

3、应急应对策略

可以针对某些特定事件，专门设计一些应对措施。对于有些风险，比如不可预测的风险，项目团队可以制定应急应对策略，即只有在某些预定（触发）条件发生时才能实施的应对计划。

七、监控风险

监控风险是在整个项目中规划风险应对、跟踪已识别风险、监督残余风险、识别新风险，以及评估风险过程有效性的过程。

本过程的主要作用是使项目决策都基于关于整体项目风险和单个项目风险的当前信息。

・实施的风险应对是否有效；

・整体项目风险级别是否已改变；

・已识别单个项目风险的状态是否已改变；

・是否出现新的单个项目风险；

・风险管理方法是否依然适用；

・项目假设条件是否仍然成立；

・风险管理政策和程序是否已得到遵守；

・成本或进度应急储备是否需要修改；

・项目策略是否仍然有效……

风险再评估。对新风险进行识别并对风险进行重新评估。

风险审计。是检查并记录风险应对措施在处理已识别风险及其根源方面的有效性，以及风险管理过程的有效性。

技术绩效测量。把执行期间所取得的技术成果与关于取得技术成果的计划进行比较。

第十一章 IT 项目采购管理

一、项目采购管理概述

项目采购管理包括从项目团队外部采购或获得所需产品、服务或成果的各个过程。

项目组织既可以是项目产品、服务或成果的买方，也可以是卖方。项目采购管理过程围绕包括合同在内的协议来进行。

1、项目采购的方式

（1）公开竞争性招标。

（2）有限竞争性招标。

（3）竞争性谈判。

（4）询价采购。

（5）直接签订合同。

（6）自制或自己提供服务。

2、项目采购的重要性

（1）降低成本。

（2）可以把主要精力放在核心业务上。

（3）可以从外界获得专门的技能和技术。

（4）提高灵活性。

（5）提高责任性。

（6）能有效减少贪污、浪费等现象的发生。

二、规划采购管理

规划采购管理是记录项目采购决策、明确采购方法，及识别潜在卖方的过程。

本过程的主要作用是，确定是否从项目外部获取货物和服务；如果是，则还要确定将在什么时间、以什么方式获取什么货物和服务。货物和服务可从执行组织的其他部门采购，或者从外部渠道采购。

1、自制或外购分析

制定自制或外购決策时应考虑的因素包括；组织当前的资源配置及其技能和能力，对专业技术的需求，不愿承担永久雇用的义务，以及对独特技术专长的需求；还要评估与每个自制或外购决策相关的风险。

在自制或外购分析中，可以使用回收期、投资回报率 (ROI)、内部报酬率 (IRR)、现金流贴现、浄现值 (NPV)、收益成本 (BCA) 或其他分析技术，来确定某种货物或服务是应该在项目内部自制，还是从外部购买。

2、合同类型选择

（1）总价合同

1. 工作任务和范围、目标和验收标准很明确，且项目设计已具备详细细节
2. 工程量小、工期短（1 年内），施工环境因素变化小，工程条件稳定
3. 如果卖方承担成本风险

（2）成本补偿合同

1. 工作性质、工作范围都不清楚或项目存在较高风险
2. 如果买方承担成本风险

（3）工料合同

1. 工作性质清楚，但范围不是很清楚，工作不复杂，又需要快速签订合同
2. 如果双方分担风险

（4）单边合同（订购单）

购买标准产品，且数量不大

3、采购管理计划

包含要在采购过程中开展的各种活动。它应该记录是否要开展国际竞争性招标、国内竞争性招标、当地招标等。如果项目由外部资助，资金的来源和可用性应符合采购管理计划和项目进度计划的规定。

4、供方选择标准

在确定评估标准时，买方要努力确保选岀的建议书将提供最佳质量的所需服务。这个标准用于从潜在的卖方中选中符合要求的、合格的卖方。

它包括：能力和潜能、产品成本和生命周期成本、交付日期、技术专长和方法、具体的相关经验、用于响应工作说明书的工作方法和工作计划、关键员工的资质、可用性和胜任力、公司的财务稳定性、管理经验、知识转移计划，包括培训计划。

5、采购工作说明书

对所购买的产品、成果或服务来说，采购工作说明书定义了与合同相关的那部分项目范围。每个采购工作说明书来自于项目范围基准。

采购工作说明书会充分详细地描述拟采购的产品、服务或成果，以便潜在卖方确定是否有能力提供此类产品、服务或成果。根据采购品的性质、买方的需求，或拟采用的合同形式，工作说明书的详细程度会有较大不同。工作说明书的内容包括：规格、所需数量、质量水平、绩效数据、履约期间、工作地点和其他要求。

三、实施采购

实施采购是获取卖方应答、选择卖方并授予合同的过程。

本过程的主要作用是，选定合格卖方并签署关于货物或服务交付的法律协议。本过程的最后成果是签订的协议，包括正式合同。

1、采购实施过程

有如下过程，它们可能相互重叠。

（1）采购计划编制。包括确定采购产品需求，自制或外购决策，合同类型，编制采购管理计划和采购工作说明书等。

（2）招标计划编制。包括：编写并发布采购文件，制定招标评审标准。

（3）招标。包括：发布采购广告；召开投标会议；获得标书或建议书。

（4）选择承包商或供应商。

（5）合同管理。包括监督合同的履行，支付及合同的修改等

（6）合同收尾。包括产品检验、结束合同、文件归档等

2、招标书的主要内容

招标书主要分为 3 大部分：程序条款、技术条款、商务条款。

一般包含下列主要内容：招标公告（邀请函）；投标人须知；招标项目的技术要求及附件；投标书格式；投标保证文件；合同条件（合同的一般条款及特殊条款）；设计规范与标准；投标企业资格文件；合同格式等。

3、投标决策

企业要进行投标决策时主要考虑以下几个方面的内容。

 竞争对手分析。

 风险分析。

 目标分析。

 声誉与经验分析。

 客户资金分析。

 项目所需资源分析。

 客户本身的资信问题。

4、采购谈判

采购谈判是指在合同签署之前，对合同的结构、要求及其他条款加以澄清，以取得一致意见。

谈判的内容应包括责任、进行变更的权限、适用的条款和法律、技术和商务管理方法、所有权、合同融资、技术解决方案、总体进度计划、付款和价格等。

5、合同管理

一旦卖方选定，接下来就应该签订采购合同。采购合同中包括条款和条件，也可包括其他条目，如买方就卖方应实施的工作或应交付的产品所做的规定。 签订软件项目采购合同时应注意：

（1）规定项目实施的有效范围。经验表明，软件项目合同范围定义不当而导致管理失控是项目成本超支、时间延迟及质量低劣的主要原因。

（2）合同的付款方式。对于软件项目的合同而言，很少有一次性付清合同款的做法。付款条件是一个比较敏感的问题，签订合同时在付款条件上规定得越详细、越清楚越好。

（3）合同变更索赔带来的风险。在软件的设计与开发过程中，存在着很多不确定因素，因此，变更和索赔通常是合同执行过程中必然要发生的事情。

（4）系统验收的方式。从严格意义上说，成果一经客户认可，便不再有返工之说，只有索赔或变更之理。因此，客户必须高度重视系统验收这道手续。

（5）维护期问题。系统最终验收通过之后，一般都有一个较长的系统维护期，这期间客户通常保留着 5%～10% 的合同费用。

• 需方（甲方）合同管理

验收过程是需方对供方的产品或服务进行验收检验，以保证它满足合同条款的要求。

违约事件处理。

• 供方（乙方）合同管理

项目计划的执行，用以授权软件提供商在适当的时候进行工作。

执行报告，监控合同方的成本、进度和技术绩效。

质量控制，检验合同方的产品是否合格。

变更控制，确保变更被正确地批准，以及需要了解情况的人知晓变更的发生。

四、控制采购

控制采购是管理采购关系，监督合同绩效，实施必要的变更和纠偏，以及关闭合同的过程。

本过程的主要作用是，确保买卖双方履行法律协议，满足项目需求。

1、索赔管理

如果买卖双方不能就变更补偿达成一致意见，或对变更是否发生存在分歧，那么被请求的变更就成为有争议的变更或潜在的推定变更。此类有争议的变更称为索赔。

在整个合同生命周期中，通常应该按照合同规定对索赔进行记录、处理、监督和管理。谈判是解决所有索赔和争议的首选方法。

2、检查与审计

检查是指对承包商正在执行的工作进行结构化审查，可能涉及对可交付成果的简单审查，或对工作本身的实地审查。

审计是对采购过程的结构化审查。应该在采购合同中明确规定与审计有关的权利和义务。

3、数据分析（绩效审查）

依据合同来审查卖方在规定的成本和进度内完成项目范围和达到质量要求的情况。绩效审查的目标在于发现履约情况的好坏。

五、结束采购

采购结束管理的一个重要工作就是采购审计，采购审计是指对从采购管理规划过程到采购控制过程的所有采购过程进行结构化审查。其目的是找出合同准备或管理方面的成功经验与失败教训，供本项目其他采购合同或执行组织内其他项目的采购合同借鉴。