指导委员会应该在整个项目生命周期的早期开始关心项目的质量问题。我们不能仅仅根据已经完成的项目来衡量项目的进展，这样当我们发现质量差的时候已经太晚了，这是我们低估了检测需要付出的努力。在可迭代化方法中，我们很早有次品率的指标，也很早要求投入精力来进行检测，但是管理委员会可能不知道需要在整个项目的早期开始费心问一些有关质量的问题。因此，初级的RUP项目管理者可能不能遵从RUP的指导方针，在一开始的时候不能全面地检测。但是不幸的是，很多这样的管理者声称他们在用RUP管理项目，但是他们其实还是在采用瀑布式技术。通常来说，他们会将他们的任务计划按照RUP方法组织阶段分类，尤其是在测试领域。指导委员会必须检查确认项目管理者在项目开展的早期有测试者，并且给测试者分配好任务检查使用情景下的任务执行情况。

总之，委员会应该对项目组做出以下的要求：

    使用演示版本展示项目进度：
        你完成了多少用例场景?
        在这次迭代过程中你完成了什么功能?
        在下一次迭代过程中你将创建什么功能?
    说明你已经完成的系统的质量：
        缺陷数是多少，并且这些缺陷的严重级别是什么？
        缺陷趋势是怎样的？（发现率和解决率）

消除不必要的关闭

将RUP引入传统的瀑布式环境一个富有挑战性的方面是：它对于结束的依赖性大大降低。人们只有在确保文档是完整和准确的情况下才会结束文档。因此，他们总是倾向于坐等而耽误了决策，这会推迟决策，从而减慢项目的进程，浪费经费。作为新的选择，RUP承认我们从过去的经验中得到的知识：在任何情况下文档都不可能完整和精确。因此RUP指导方针鼓励我们接受这样的现实：所有事情都会改变，都会往前走。.

软件开发界流行的名言是：你付出的努力的20%用以完成你80%的工作。因此这意味着你需要付出你80%的努力来完成剩下的20%的工作。很符合逻辑推论的结论是：在项目的迭代过程中，好先做完那80%的工作，然后再完成那剩下的20%。敏捷的迭代开发都和追求“足够好”有关，你会在你的工作中继续改进你的产品。相关利益方和项目开发组连续的日常协作保证项目的进展而言，是一个比间歇生产和关闭正式文档方法好得多的方法。

然而，对于重要的项目工件，我还是会要求正式关闭的文档，比如在先启阶段结束时的远景文档和软件开发计划，还有在精化阶段结束时。通常，当项目组对整个需求有更进一步理解的时候，在精化阶段的结束会产生重大的变更。尽管我倾向于调整范围维持预算和计划，但是有时重新规划剩下的迭代开发阶段是很有意义的，尤其是在你不能够降低功能范围，或者在项目还存在着交付功能的不确定性而引入另一个精化阶段的迭代的情况下。
不断调整计划和期望

我经常说管理一个瀑布式的或者传统的项目，在项目的前80%非常直接而有趣，在那段时间内，任务是线性的，在一段时间内你可以集中注意于一项规则（比如需求）. 然而当集成和测试开始的时候，你会经常发现不是模版不能整合，测试很费劲，系统架构有缺陷，执行效果很差，是用户提出这个应用不是他们所需要的。如果你在管理一个瀑布型的项目，你在项目临近结束的时候，需要找一个借口将这个项目转交给另一个可怜人。

管理一个RUP项目在开始的阶段会更有些挑战性，因为我们同时考虑各种条件约束，包括需求、编程以及测试。然而在接下来的阶段，非正式沟通和良好的生命周期管理工具支持会使得项目的复杂性容易管理得多。

对一个RUP项目管理者来说困难的阶段是精化过程的末期。这时候他们会发现范围、预算以及时间计划没有意义。这时候他们不得不做出很艰难的决定，可能还需要重新规划整个项目的一部分。但是这也有好的一方面，这发生在项目的先启阶段，这时候能让相关利益方调整他们的期望。

在整个项目的后，尽管我们可能不能达到相关利益方开始的 预期， 我们应该可以达到我们在精化阶段后达成的协议所规定的要求。让相关利益方学会期望团队实现在精化的后阶段所拟订的要求，而不是他们开始所期望的要求，这是成为一个成功RUP项目管理人的关键所在。

我希望我已经向大家说明，在建立部门应用软件的时候，采用不断增强的版本策略可以在IT投资上有非常显著的好处。RUP为这种方法提供了很好的指导。我希望您的组织可以考虑这种方法。 如果你已经决定创造一个迭代化软件开发环境，那教育相关利益方非常重要，你必须让他们懂得RUP项目的合作特性。你的指导委员会管理你开发应用的方法对你的成功有效地使用预算，避免传统瀑布式方法的不佳行为有着非常重要的意义。

祝你好运！