在PMP中，《活用PMBOK指南》（第6版）把风险分为四个大类及其对应的小类，见表9-1。

表9-1 风险分类

对一个IT项目而言，常见的风险通常逃不出这四个大类，但是有其特殊性和专业性。

9.2.1 IT项目中常见的风险

1. 需求风险

（1）需求已经成为项目基准，但需求还在持续变更。

（2）需求范围已确定，但仍需添加额外的需求。

（3）产品定义模糊的部分比预期需要更多的时间。

（4）在做需求调研室时，客户参与度不够。

（5）缺少有效的需求变更管理过程。

2. 计划编制风险

（1）计划、资源和产品定义全凭客户或上层领导的口头指令，并且不完全一致。

（2）计划是优化的，是“最佳状态”，如果计划不够现实，只能算是“期望状态”。

（3）计划基于使用特定的小组成员，而那个特定的小组成员其实指望不上。

（4）产品规模（代码行数、功能点、与前一产品规模的百分比）比估计的大。

（5）完成目标日期提前，但没有相应地调整产品范围或可用资源。

（6）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的多。

（7）项目经理需要注意加以识别并做好应对措施。

1.​ 客户风险

（1）客户对于最后交付的产品不满意，要求重新设计和重做。

（2）客户的需求未被满足，造成产品最终无法满足用户的要求，因而必须重做。

（3）客户对文档、原型和规格的审核、决策周期比预期的长。

（4）客户答复的时间（如回答或澄清与需求有关问题的时间）比预期更长。

（5）客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的相关方沟通工作。

（6）客户没有或不能参与文档、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更。

2.​ 过程风险

（1）大量的文档工作导致进程比预期的慢。

（2）不遵守规范流程（缺乏对软件开发策略和标准的遵循），导致沟通不足，质量欠佳，甚至需要重新开发。

（3）任何细节都遵循规范流程（教条地坚持软件开发策略和标准），导致消耗太多时间在无用的工作上。

（4）前期的质量保证措施不真实或失效，导致后期的重复工作。

（5）向管理层撰写绩效报告占用开发人员的时间比预期的多。

（6）风险管理不到位，导致未能发现重大的项目风险。

3.​ 组织和管理风险

（1）低效的项目组织结构降低生产率。

（2）管理层审查决策的时间比预期的更长。

（3）预算被削减，打乱项目计划。

（4）仅由管理层或市场人员进行技术决策，导致决策错误，项目进度缓慢，计划时间延长。

（5）组织缺乏必要的项目治理规范，导致工作失误与重复工作。

（6）组织没有建设项目经验，无法提供相应的支持，甚至拖后腿。

（7）组织本身效率低下，影响项目团队。

（8）第三方的非技术工作（预算批准、设备采购批准、法律方面的审查、安全保证等）时间比预期的更长。

（9）管理层作出的某些决定打击了项目组织的积极性。

4.​ 人员风险

（1）开发人员和管理层之间关系不佳，导致决策缓慢，影响全局。

（2）作为先决条件的任务（如培训和其他项目）不能按时完成。

（3）某些人员需要更多的时间适应还不熟悉的软件工具和环境。

（4）项目后期加入新的开发人员，需要进行培训并逐渐与现有成员沟通，从而使当前成员的工作效率降低。

（5）不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性。

（6）没有找到项目急需的具有特定技能的人。

（7）由于项目团队成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作。

（8）缺乏激励措施，士气低下，降低了生产效率。

5.​ 开发环境风险

（1）项目所需设施、硬件没有及时到位。

（2）设施虽然到位了，但是细节不配套，如没有网线、电话、办公用品等。

（3）环境不佳，如场地拥挤、设施杂乱或者破损。

（4）项目所需的开发工具没有及时到位。

（5）所需第三方组件、硬件没有支持，自行学习探索浪费时间。

（6）新的技术、开发语言、开发工具不如期望中的那样有效，开发人员需要时间创建工作环境或者切换新的工具。

（7）新的技术、开发语言、开发工具的学习周期比预期的长，内容繁多。

6.​ 产品风险

（1）纠正质量偏差，修正不可接受的产品，需要比预期更多的测试、设计和实现工作。

（2）严格要求与现有的系统兼容，需要进行比预期更多的测试、设计和实现工作。

（3）要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作。

（4）开发额外的、不需要的功能（镀金），延长了计划进度。

（5）一些变更涉及底层、核心代码或技术框架，将大大延长计划进度。

（6）开发一种全新的模块将花费比预期更长的时间。

（7）依赖正在开发中的技术将延长计划进度。

（8）在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料的问题。

7.​ 设计和实现风险

（1）产品设计质量低下，导致重复设计。

（2）产品设计质量低下，在编码阶段无法实现，需要重新设计。

（3）代码质量太低，耦合度过高，导致无法复用，重复造轮子。

（4）代码和库质量低下，导致需要进行额外的测试，修正错误或重新开发。

（5）过高估计了自动化工具对计划进度的节省量。

（6）分别开发的模块无法有效集成，需要重新设计或开发。

（7）一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能。

（8）以上都是在IT项目中常见的风险，由于软件本身的特点，而导致IT项目与传统项目有很大差异，因此IT项目的风险管理难度比传统项目大。

9.2.2 IT项目风险的特征

综合以上常见的风险来说，我们可以看到IT项目风险都有以下三种特征。

1.​ 需求多变

在第三章项目范围管理中说过了，软件项目的需求多变已经成为软件业界的共识，正因为需求的多变，才让瀑布模型一直遭受到软件工程界的抨击，因此而诞生了敏捷开发。在IBM的RUP和众多的敏捷方法论中，一直将需求不确定列为软件项目的最大特点，因此出现了“拥抱变化”一说。

当一个IT项目已经开始在实施的时候，如果客户连他需要做什么，要实现什么功能都不能确定，那么做软件实施的工程师又如何能够知道自己要开发一个什么样的软件系统出来呢？所以，他们只有在漫长的等待过程中不断遭受到客户的“批评”，在经历了“九九八十一次磨难”之后才恍然大悟，原来是要做这样的系统啊！

2.​ 项目规模估计不准确

当老师给我们布置作业的时候，如果他多布置了几个题目，下面的同学便会说：“又要多做一个小时了!”学生们在很短的时间内就能够准确地估计作业量大不大，他们的估计凭借他们每天一次做作业的经验和那一瞬间对题目的印象，虽然他们并没有做过刚布置的这些题目，但是估计得仍然是那么准确。

任何一个建筑工程的项目经理都能够对自己的项目进度掌握得很准，在他们的眼中，只要资金没有问题，进度就可以得到保证。工地需要多少人，什么时候需要进行哪个工序的施工，什么时候需要加班，这些都在他们的心中掌握着。资金就是他们最大的风险，只要资金到位了，一切工作都开始了。

而软件项目与之不同，在软件项目开始后，很少有缺资金的。但是再优秀的软件项目经理，也无法预计自己的项目什么时候能够完成，因为在他进行估算的时候，客户的需求还不清楚。建筑工程可以通过预算很准确地计算整个建筑的工程造价，而软件项目却很难，因为不管是代码行估算法，还是功能点方法，都远不及“猜”得准确。

3.​ 人的因素对项目影响很大

就像对软件工程做出重大贡献的书——《人件》中表达“人就是一切”的那样，我也持相同的观点，人可以说是整个软件项目的灵魂。

软件项目不需要钢筋、水泥和沙石，也不需要任何的施工机械。软件项目的原材料就是人的思想和智慧，而计算机和IDE软件是项目的施工工具。通过键盘和鼠标，无数的程序代码在程序员的手中诞生了。如果要问软件项目最大的成本在哪里，那么答案只有一个，就是人力成本。

《人月神话》中曾经引用了一组数据，说明了一个惊人的结果：同样拥有两年经验而且在受到同样培训的情况下，优秀的程序员的生产率是较差的程序员的10倍，最好的和最差的程序员表现在生产率上面的差距居然达到了惊人的10:1。也就是说，一个优秀的程序员的工作效率远远大于一个蹩脚的程序员，一个程序新手甚至不能够产生任何生产效率。不仅如此，最让人扼腕的是，新手的错误行为，还会让熟练员工牺牲很多时间来帮助新手纠正他们的错误，甚至可能导致降低软件开发的效率。

虽然软件项目已经实施角色分工和管理，但是相对于其他工程的分工来说分工比较单一。软件项目中，一般就只分有系统分析师、架构师、设计师、程序员、测试工程师及配置管理人员和项目经理等。在实际工作中，除了顶部的大型企业或者国企能够配备这么多岗位，一般中小企业只有两种角色：项目经理和开发人员，其他的角色全都由这两类人员充当。

专业的人干专业的事情。在软件项目中，现实情况是，不仅人手不够，分工还非常混乱，对人的不当使用也是一个很大的风险来源。