实施者应该是计划人员
创建项目计划的非常好的人员是负责实施该计划的人员。当规划由一个人创建而由另一个人实施时，如果项目不能按时完成或超出预算，他们不太会相信计划，而很有可能会责备它。也就是说，参与项目的每个人都应该投入到项目计划的开发和进展中。
不要忘记“不该忘记的事”
计划不仅要反映需求设计、建模、编程和测试的“真实”工作，而且还应该反映辅助活动（然而仍是重要的），它包括：休假和法定假日、培训和教育、项目管理活动（如规划和人员管理）、开销（如系统当机时间、会议和回复电子邮件）、体系结构定义、测试之后的系统返工、系统交付、与重用相关的活动（如普遍化 ）。
将任何设想和约束编入文档
规划时您总要作一些假设，如能够及时获得应用程序服务器的新发行版，或可以得到熟悉您正在应用的技术和技巧的开发人员。同时，您将在一些约束下工作，如影响计划的强制截止期限或资源限制。将这些假设和约束编入文档，这样，当您实施项目的任何时候更新计划时，都可以记起您先前做出的一些“不寻常”决定。
认识到不同的资源意味着不同的计划
十名有经验的开发人员组成的团队创造出的成效要远远多于十名初学者组成的团队所创造的成效。要想更加实际的话，您的计划必须反映项目可使用的资源的真实情况。
创建现实的计划
项目组必须相信其项目的目的、估价和时间表。要做到这点，您必须真实地规划，避免规划超出您能理解的范围。仅当您打算研究未知事项时，才能容忍无知。
只规划有价值的事
IBM DeveloperWorks 网站提供了许多可应用于您项目的非常好的实践。然而，根据项目的性质，不是所有这些技术都将适合于您的独特情况。要将这些非常好的实践简单地看作是您放置在“项目管理工具箱”中的工具，您可以根据需要适当使用这些工具。
适当使用项目管理工具
一些项目管理工具，如 Microsoft Project，提供了重要功能， 如Gantt图表（活动时间表）的开发、规划与实际结果的比较、PERT 图表（网络图表）的开发、任务的定义、任务之间相关性的定义、对任务的资源分配和资源平衡。所有这些事情似乎象是一个好主意，并且它们通常是好主意——但它们还需要许多精力来创建和维护，而且很少为项目组提供实际价值。的确，它让一些项目管理人员感到富有成效。的确，高级管理喜欢看见您有一个计划。但是，没有一行代码是由所有这个活动产生的。规划是有价值的活动；但投入大量的时间来创建规划图表通常不是有价值的活动。
谨慎应用技术方案处理管理问题
对于在项目中遇到的问题，您确信需要用技术来解决吗？本文改编自作者所著的Process Patterns 的第五章，Scott Ambler建议改进管理，而不是新技术，可能就是您的解决方案。
还没有一种点能表明用部署最新技术中来解决通过改变管理实践去解决问题的（请参阅参考资料中 The Squandered Computer）。事实上是，您不应该将所有商业过程所得的好处都归功于支持这些更改的软件项目。没有这些新的软件或硬件，您可能会得到同样的好处。
将技术解决方案识别成非技术问题是经常重复发生在信息技术界的常见错误。这种经常发生的错误将其看成是称作 Apply Technical Solution to Non-Technical Problem（将技术解决方案应用到非技术问题）自身的过程反模式（过程反模式是一种已证明在实际运行当中并不是行之有效的方法）。
技术解决方案仅适用于解决技术问题。例如，“网络计算机”的概念仍然是计算机界中热衷的时尚。其基本概念就是通过网络计算机来替代个人计算机，组织就可以大大缩减支持计算机软硬件的开支。
研究表明，如果包括培训和支持这些计算机费用的话，那每年支持一台个人计算机的平均开支大约在 $5,000 到 $30,000 之间。网络计算机（也称之为 Java 终端，因为它们仅运行已经打包成 Java 字节代码的程序）理论上将缩减开支，因为它们仅需要简单的维护和支持。尽管做了大量的广告宣传，但迄今为止，网络计算机的销售量十分可怜。从表面上看，网络计算机试图解决的问题看起来是技术性的。但当您想到这一点的时候，问题实际已经成为管理问题之一了。
一些组织一年要花费 $30,000来支持计算机的原因不是因为个人计算机，而是由于对个人计算机的误用。这些组织不是由具有资格的专业人员来安装公共配置，而是让用户选择和安装他们自己的软件。一旦用户遇到了麻烦，组织的开支就飞涨。另外还有文件格式不相容的问题。若没有公共的软件套件，用户得浪费大量时间在同一供应商所提供的不同软件版本之间转换文件，或从不同供应商所提供的不同软件之间转换文件。基于类似的原因，当用户购买他们自己的设备时，硬件培训和支持也变得更加困难。
在这种情况下所发生的问题是与过程相关：个人计算机软硬件的管理不当。因而购置网络计算机这一技术解决方案是否能够解决问题值得怀疑。技术解决方案适用于技术问题，管理解决方案适应于管理问题，而过程解决方案则适用于过程问题。在谈完了所有内容之后，我真正的意思也许仅仅是在工作中要使用正确的工具。
基于需求的规划策略：按优先次序排序
成功的项目组认识到不能等同地创建所有的需求，因此，需要对需求进行优先次序排序并按此顺序操作。
某些需求比其它需求重要得多。例如，对于联机银行的需求来说，对帐户间资金转移的支持要比银行每月声明的 Elbonian语言版本重要得多。成功的软件团队将首先集中精力构建最重要的功能，尽可能地满足用户需求中关键的功能，而那些次关键性功能留到以后处理。需求排序使您的团队能够为组织的软件利润作出最大贡献。然而，要有效地对需求进行优先次序排序，必须考虑几个因素：商业价值、交付成本、交付日期、交付复杂程度、风险（请参阅提示“控制风险：不让风险控制您”）、与其它需求的关系、何时需要该需求。
