1. 从一开始进度的安排就是错误的。

　　人们总是倾向于乐观的估计，常常无视那些“可能需要作”的工作，尽管你可能对项目规模作了认真的估算，但是估算的结果仍可能太小，这也就直接导致进度的安排常常比应有的更紧张，在这种情况下能够产出的成果也很有限。但是人们常常被这种看上去激励人的进度安排所蒙蔽，失去了对这项风险的警惕。

　　尽管对项目规模作完全的估算并不能保证进度的安排是准确的，但是起码不会使它和实际相差太远。对那些无法估算出的工作量作好准备能是你在风险出现时不至于手忙脚乱。

　　对于大型项目来说，进度安排失误的风险比较小，因为大型项目一般都对项目规模作了大量的估算，再者，这样的项目更有机会重新进行估算，调整进度。

　　2. 需求膨胀或变化。

　　从项目的角度来说，需求总是向着膨胀的方向发展，即使是去掉已有功能的要求也是一种膨胀，因为这增加了工作量。我们总要“击中移动的目标”，那种在项目一开始就试图将需求固定下来，不允许任何变动的想法无异于刻舟求剑。例如一个为期两年的项目，可能在开发的过程中用户的业务发生了变化，我们就必须对软件作出相应的改动。

　　我们需要有一个可以接受的变化的范围，这样在客户要求变更需求的时候，我们能够确定将增加多少工作量，对进度产生多大的影响，告诉客户他将增加多少成本，得到什么样的结果。

　　3. 项目人员流失。

　　常常会有成员在项目进行过程中离开，也许他没有留下任何文档，也许除了他没有人掌握项目的某些细节，也许新人不能很快的掌握项目所需的知识。对付这项风险的最好的办法就是留住团队成员，人脑比任何文档都精确，更高效。如果你不能作到这一点，就要让知识在团队中广泛的传播。而过去，我们总是认为有了足够的文档就可以使每个开发者都是可替换的。

　　4. 规约崩溃。

　　这种风险不同于其他几种，它要么不发生，要么发生，直接导致项目失败，不会对项目产生不同程度的影响。

　　在项目启动的时候，双方会坐在一起确定需求的范围。如果在这个过程中大家谈不拢，那么最好取消，这样双方都不会有什么损失。但是，这样的情况很少发生，很多时候，双方得到的是一个可以勉强接受的结果，于是项目带着一个不明确的，含混的目标开始了。

　　被掩盖的问题虽然一时不会打扰你，但不会是永远。当交付一个带有缺陷，含糊不清的产品时，双方付出的时间，金钱都已经无法挽回，当任何一方已不再有耐心继续下去时，项目就只有死路一条。也许这还是好的，更糟糕的是双方在进行了多次的修改和谈判后项目依然无法走出泥潭。当认识到“缺乏共识”是根本原因时，项目已经无药可救。

　　5. 生产效率低下。

　　开发者的工作效率存在着很大的差异。如果从团队的角度看，这种差异将会有某种程度的弱化。很少情况下，这种风险会对项目产生致命的影响，更多的是对项目进度产生影响。

　　可以看到，在这五种风险中，真正和效率有关的只有第五种，而且，很明显的，前面四种风险对项目产生的影响要大的多。所以，不能认为风险管理导致了低效率，而是认识到这些风险的存在，为这些不确定因素作好准备，预留好足够的资源，真正敢于直面困难，而不是为自己的逃避寻找借口。