定义项目成功的标准
在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是唯一明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。
定义产品发布标准
在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可操作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。
沟通承诺
尽管可能无意中承诺了不可能的事件，但不要做一个明知不能保证的承诺。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。
把任务分解成“英寸大小的小圆石”
“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。
为大任务制定计划工作表
如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他必须处理的大任务相关的工作量。
为“过程改进”安排时间
你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。
识别管理项目的风险
如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。
将培训时间放到计划中
确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。
记录你的估算和你是如何达到估算的
当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。
遵守学习曲线
如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。
考虑意外缓冲
事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。
记录实际情况与估算情况
如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。
