有人看了我的要素清单后，可能会非常不同意我的选择。例如，他会问，需求在哪儿呢？他们不重要吗？我会告诉他我为什么没有把它们包括进来。有时，我会问一个项目组（特别是内部项目的项目组）：“你们的需求是什么？”，而得到的回答却是：“我们的确没有什么需求。”
刚开始我对此非常惊讶（我有军方的宇航开发背景）。他们怎么会没有需求呢？当我进一步询问时，我发现，对他们来说，需求意味着一套外部提出的强制性的陈述，要求他们必须怎么样，否则项目验收就不能通过。但是他们的确没有得到这样的陈述。尤其是当项目组陷入了边研究边开发的境地时，产品需求从头到尾都在演化。
因此，我接着问他们另外一个问题：“好的，那么你们的产品的前景是什么呢？”。这时他们的眼睛亮了起来。然后，我们非常顺利的就第一个要素（“开发一个前景”）中列出的问题进行了沟通，需求也自然而然的流动着
也许只有对于按照有明确需求的合同工作的项目组，在要素列表中加入“满足需求”才是有用的。请记住，我的清单仅仅意味着进行进一步讨论的一个起点。
那么，发现了 RUP 的十大要素之后，怎样才能让它给我的职业生涯带来根本的变化呢？这儿有一些建议，能帮助我们对付各种规模的项目。
首先，如果谁来问我，在一个非常小的、没有经验的项目组（才学了 RUP ）中，如何使用RUP和Rational开发工具来构造一个简单的产品，我会与他分享十大要素列表，以使项目组不被 RUP 的细节和 Rational Suites 的功能压垮。
实际上，即使没有任何自动化工具也可以实施十大要素。管理一个小项目，一个项目笔记本，就已经是一个非常好的起点，可以把它分成十个部分，每一部分专用于十大要素中的一个要素。（我还发现及时贴对于小项目变更请求的管理和跟踪以及确定变更的优先级非常有用。）
当然，当一个项目的规模和复杂度增长时，以上这些应用十大要素的简单方法很快就变得不可操作，而对自动化工具的需求就变得比较明显了。然而，我还是愿意鼓励项目的领导者刚开始时应用十大要素和RUP的“非常好的实践”，需要时再逐步增加支持工具，而不是一下子就尝试使用全套 Rational Suites 。
对成熟的项目团队而言，可能已经在采用某种软件过程和使用 CASE 工具，十大要素可以提供一种快速评估方法，用来评估关键过程元素的平衡性，标识他们并确定改进的优先级。
当然，各个项目都不太一样，有些项目似乎并不真正需要所有的要素。在这些情况下，重要的是考虑：如果你的团队忽视某个要素后会发生什么问题。举例如下：
- 没有前景？你会迷失方向，走很多弯路，把力气浪费在毫无结果的努力上。
- 没有计划？你将无法跟踪进度。
- 没有风险列表？你的项目会陷入“专注于错误的问题上”的危险里面，可能一下子被一个没有检测的地雷击倒，并为此付出五个月的代价。
- 没有问题列表？没有定期的问题分析和解决，小问题会演变成大问题。
- 没有商业理由？你在冒浪费时间和金钱的风险。项目最终要么超支，要么被取消。
- 没有构架？在出现交流、同步和数据存取问题时，你可能无法处理。你也可能在伸缩性和性能上有问题。
- 没有产品（原型）？你将不能有效的测试，并且会失去客户的信任。
- 没有评估？你将没有办法掌握实际情况与项目目标、预算和最后期限之间的距离。
- 没有变更请求？你将无法估计变更的潜在影响，无法就互相冲突的需求确定优先级，无法在实施变更时通知整个项目组。
- 没有用户支持？用户将不能最有效的使用产品，技术支持人员也会淹没在大量支持请求中。
现在你知道了，不懂得十大要素是一件非常冒险的事情。我鼓励你把它们作为项目组的一个起点。决定哪些是你们想要的，哪些是不要的，哪些是要修改的。然后，再决定还有哪些其他因素是你们项目（无论项目大小）成功（保证项目组及时的、不超预算的交付产品，并且真正满足涉众的真正需求）的关键因素。
其他组织也出版了类似的软件工程要素列表。IEEE 软件杂志 1997 年 3/4 月号上有一篇 Steve McConnell 写的文章，“软件的十大要素”。软件项目经理网络也有一个“16 个关键软件实践”的列表，在 www.spmn.com 上可以找到。SEI-CMM 的 KPAs（Key Process Areas,关键过程域）也可以作为一种要素列表（见 www.sei.cum.edu）。
