缺乏真正的风险管理与控制是导致软件项目失败的最重要原因。实施有效的风险管理，做到真正风险驱动的迭代式开发，尽早排除架构（性能上）的风险也是最重要的。因此，风险管理是软件项目管理的第一管理要点。
软件项目失败的种种问题
当笔者三年前读到《漫谈企业应用项目的软件开发过程:一个PRM系统实施的经验与教训》时，就发现它是一篇非常难得的好文章。
国内类似这样的软件工程案例分析太少了，很多人没有时间写或舍不得与旁人分享其中的美妙，何况这篇文章还是专门针对XP、RUP并涉及到敏捷统一过程实践的。
除了这篇PRM（伙伴关系管理）案例外，Johnson其实早在2002年7 月还发表过一篇《从一个项目谈XP在国内的应用》，该文在网络上流传甚广。
这两篇文章好像是国内互联网上最早公开的XP（极限编程）实践案例，还是尝试XP、RUP整合的案例。姑且不论它们是否真正做到了敏捷，整合是否成功，但这两个应用案例的结果恰好一个成功，一个失败，其价值就在于真实性和典型性，具有很好的说服力和教育意义。
不管结果如何，PRM原文的篇幅不长，却有很多值得我们借鉴和学习的地方。笔者认为这个项目无论从商务角度，还是从工程技术的角度来看，都是比较失败的。
PRM系统虽然通过2个月紧张的敏捷、迭代开发并准时交付使用，但却后来出现性能问题，大半年之后仍然没有通过客户验收，不但有几十万尾款没有收到，而且还影响了开发商其它项目的投标。
为什么一个曾一度成功按时交付的系统，在新旧系统数据集成、上线运行的几个月后会出现严重的性能问题，并暴露出系统架构设计上的缺陷，导致迟迟无法获得客户的信任，让项目各方都陷于被动和尴尬呢？
是XP、RUP不行？还是敏捷过程、方法不行？有没有可能事先避免这种典型的风险呢？以上所有这些有趣的问题，都值得我们深入探究。
敏捷开发的基础是首先做到迭代式（Iterative）开发。迭代不仅仅是把整个系统开发任务逐一分解、按阶段分步骤来实现的。
如果迭代的含义仅仅停留在这个层面上，那么提出用迭代演进式过程取代瀑布型开发模型也就毫无意义，因为我们做任何工作本来就是要一天一天、一块一块地来完成，不管瀑布型还是演进式皆如此。
迭代真正的目的是为了通过加速客户反馈，显著地消除开发风险，这就要求每次迭代结束必须有一个可运行、可演示的系统。这时的系统可能功能上还不完整，仅仅是一个骨架，但它总是系统开发中最难、最重要同时是风险最大的部分。
RUP核心之一:风险驱动的迭代
风险驱动的迭代是RUP的核心特征之一，XP对此强调的不够，在早期的XP项目中主要是客户驱动的。所以，真正的迭代式开发在项目早期就允许客户对可运行的系统进行验证，从而使项目的风险减到最小。
开发工作也应该根据风险的大小来安排，通过迭代及时调整优先级，风险越大的任务越应该及早设计、实现、测试和反馈。
我们知道，RUP从风险驱动出发把一个软件项目分为四个阶段:起始阶段、细化阶段、构造阶段和移交阶段，这四个阶段分别对应着项目的四个里程碑。起始阶段主要消除项目的业务风险，细化阶段应该尽力消除项目的主要技术风险:架构风险（同时包括功能和非功能两方面）。
很遗憾，PRM项目是在到了项目最后一个阶段:移交阶段。在系统运行了几个月、数据迁移完成之后才发现架构设计上存在着严重的性能缺陷需要修补。重要的是:在项目之初的合同上其实就已经对数据迁移、上线运行的要求作出了规定。
这导致了最大架构级风险:系统性能满足用户的真实需要吗？直到临近项目结束也未能被消除。实际上PRM项目的“细化阶段”并未真正完成