错误一：在RUP的阶段上叠加瀑布型阶段
RUP开发周期由四个阶段组成(起始、细化、构建和移交)，导致RUP实施失败的最常见策略就是把这四个阶段与瀑布阶段(需求、分析设计、实现和部署)直接等同起来。在此对RUP的四个阶段作一简短描述。
1. 起始：制定系统的业务依据；探查一小部分(大概占10%)但很重要的需求，以便对项目范围的大致规模和关键风险有比较准确的把握，并决定是否值得为细化阶段拨付资金。
2. 细化：迭代地构建核心架构，消除项目的主要技术风险。所谓的构建架构，是指真正地编程、集成和测试——决不是纸面上的练习或可抛弃的原型。为了达到这一目的，可能需要迭代地详细探查绝大部分的需求(可能占到80%)，并同时并行地实现系统中有风险的核心部分。在这一阶段中，通过反馈-适应周期不断地评估部分实现，需求则可能发生显著的变化。请注意与经典的瀑布式需求定义不同，RUP的绝大部分需求是在与开发核心架构的工作并发的过程中精化的，而且从实际的开发当中获得了反馈。在此阶段，还要决定是否为项目的最终完成拨付资金。
3. 构建：迭代地构建在细化阶段尚未完成的内容，进行迭代集成和质量保证，为部署作准备。在这一阶段需求变化较少，因为大部分需求的不稳定性已经在前面阶段得到了迭代式的澄清。
4. 移交：完成Beta测试，解决遗留问题并部署系统。
错误二：迭代不是太长就是太短
如果把计划的平均迭代长度定为6～12个月，在绝大多数情况下是很不适宜的。RUP有一条惯例：“在理想情况下，一个迭代的工期应该是2～6周。”迭代式开发与RUP方法的精华在于通过小规模的工作步骤逐步获得一个可能不完善的实现，接着快速集成，进行QA和测试，快速获得反馈，然后基于该反馈调整需求、设计和实现。短小的步骤、反馈和调整是关键的思想。过长的迭代则达不到这种效果，因而是使RUP实施失败的一个良好策略。
错误三：在设计前磨亮需求
迭代式方法允许有指导方向的试验和创造，而瀑布方法迫使我们从一开始就必须做到聪明绝顶，这种在没有反馈的情况下，把绝大部分需求定义并稳定下来的想法与软件开发的现实不符。
假设用瀑布方法建议我们购买软件的方式来购买衣服，那么，我们必须要在看不见能得到什么的情况下来确切地描述我们需要什么，甚至还不能先试穿一下，看看穿上这件衣服效果如何。我们必须要在真正收到这件衣服的几个月甚至几年之前，精确地指明每一个测度。一旦我们改变了主意，或者长胖了、变瘦了，那只有老天来帮忙了。不错，这恰恰就是瀑布方法的解决之道——在设计或实现之前确定绝大部分的需求。如果我们连买衣服都不想用这种办法，那么，凭什么让我们相信它对软件开发也是有效的呢？
错误四：项目刚开始就期望获得可信的估算和详细的计划
一位石油业高层主管对您说：“我听说FooBarKhan那里有石油，我太想要了！请您赶紧用一周的时间写一份报告，告诉我那里有多少石油，在那里建油田需要花多少钱、多少时间、多少资源。”在石油业中，这样的场景是很滑稽的，为什么同样的做法反而被软件工业接受了呢？理智的石油人士知道：没有预先在试验性钻探上大量投入是不可能获得答案的。只有通过调查发现了储量和地质情况的真相，作出估算或初步的计划才有可能。可是，在同样的不确定性和高复杂度的情况下，我们却奢望没有投入实际的“试验性钻探”调查就能对软件项目进行估算和计划，这不是很可笑吗？
仅仅因为我们能够作出计划显示出我们正取得进展，并不意味着我们真的能够做到。在没有获得任何关于未完成工作量的真实信息的情况下，在日程表上填上精确的日期是容易的。如果我们依赖完美的计划来交付一个项目，那么失败将是注定的。迭代方法允许我们边干边学，随着迭代的进行，我们获得了有关真实需求的更多信息，对真正的风险有了更好的了解，对我们应对项目的各项挑战的能力也有了更为清晰的认识。
有时固定价格交付要求的存在被当成瀑布方法的一个理由，因为在没有真实信息的条件下作出决策也是合理的。迭代方法对初始的估算可能并没有什么改善，不过您能很快知道您做得怎么样，然后您可以更加容易地选择必要的时机启动协商，设定干系人的期望和管理项目范围。正如RUP所倡导的，一个处理固定价格投标与合同的理智方法是一种两阶段的策略。在第一阶段中，针对初始短暂(比如4周)的固定时间和固定价格签订合同，以便开展实际的调查和试探性编程，以产生更加成熟的范围、风险和需求规约。这一经改进的规约随后可被用作第二阶段(完整的开发)投标的基础。第一阶段调查的投入并没有浪费，其结果将节省第二阶段的工作量，并有助于产生第二份(最终的)更加符合实际的合同。
第二招：把RUP当作一个重型的、先断性的过程来用
重型或轻型、先断性或适应性的过程常常被人提及，而一个“重型过程”的称谓通常具有贬义，它具有以下性质：刚性和控制；许多活动和RUP工件是在一种官僚主义的氛围当中创建的；大量的文档；细致入微的长时间的详细计划；在基本工作之上存在大量的过程开销；以过程为本，而不是以人为本；以一种机械的方式把人视为可插拔的部件；先断性而非适应性。一个先断性的过程企图在一段相对长的时间段里(比如几乎在项目的整个周期中)计划和预测活动与资源(人员)的分配，其价值观隐含着对瀑布型的偏好。
相反，一个轻型或敏捷的过程意味着“精简与平实”，它具有如下特点：除去了所有不必要的官僚主义的过程开销，尽量减少创建低价值或无意义的文档；专注于工作环境中人的本性之现实，让软件开发成为一种乐趣；它是适应性的。
为了促成RUP实施的失败，请采取以下重型、先断性的做法：
* 对整个迭代项目进行详细的计划。从一开始就定义所有迭代的编号和日期，规定每个迭代中将要发生的事情。
* 创建绝大部分甚至所有的RUP工件。
* 增加大量项目和过程的正规程式，甚至建立几个项目委员会。
* 在项目中追求一种机械的时钟驱动感，把人当作整个项目机器中的专用齿轮。
把RUP设计成一个重型或先断性的过程并非其创始人的本意，造成这一假象主要是由于人们误添了错误的过程观点或对RUP本身有误解，而RUP产品提供的庞大的详细过程文档又加剧了错误的印象，极容易导致RUP被错误地实施。RUP作者们的本意是鼓励人们以一种轻型的、敏捷的、适应性的过程实质来运用它。比方说：
● 应该创建RUP活动和工件的一个最小集，即只包含那些真正有附加值的东西；随着项目的进展，如果任何的过程开销活动没有附加值，那么就果断地抛弃它。
● 对所有的迭代，都不预设详细的计划。有一个高层的计划(叫作阶段计划)估计项目的完工日期和其他主要的里程碑，然而它并不详细指定通向这些里程碑的路径。一个细化的计划(叫作迭代计划)只是提前对一个迭代(比如下一个两周的迭代)进行较细致的计划。从一个迭代到另一个迭代的详细计划是适应性地完成的。
