项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：

    第一、缺乏合理的进度安排

    这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。

    第二.它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。

    第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。

    最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。

    第二、需求的变化

    从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。

    第三、人员的变更

    在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。

    另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。

    同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。

    第四、规约崩溃

    这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。

    第五、低效率

    对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。

    正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。

    精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。

    企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益。