一定要确保标记为“已完成”的里程碑是百分百完成了，如果把“99%完成”的里程碑标记为已完成，就会打乱你的计划，你所能对项目控制的程度也会越来越弱。
绝对不能让开发人员在小型里程碑进度上偏离正轨，如果误了里程碑，并不加以改正，项目很容易偏离正轨。晚了1天的任务有可能会晚2天，晚2天就会晚3天，接下来项目实际进度就和计划完成脱节了。如果一个开发人员在里程碑上落后了，就让他当天加一下班，以赶上进度。如果是计划制定的有问题，那就要及时的修正它。
5、记录延误里程碑的原因
如果一个里程碑延误了，一定要延误原因记下来，这样可以帮你发现潜在的问题。
6、短期后修正
每1、2周都要对计划的里程碑进行修正，如果完成开发人员用5天的时间完成了3天的任务，而且没有可以改进方法的话，那么就把剩下的工作量乘以5/3，千万不要幻想着你能在以后的时间里把以前落下的任务补回来。
7、在得出有意义的进度前不要固守着某一个
在计划/进度表没有达到非常准确的情况下，不要急着把它交给领导过目，一个良好的进度/计划肯定是在从制定到跟踪，从跟踪到修正，再跟踪、再修正这样的循环中得出的。
8、勤快的进行风险管理
第三：产品(功能集)
产品的功能没有管理好，那么项目修复就是不可能的
1、稳定需求
在项目修复模式下，首先稳定需求是最为重要的任务，如果在这个时候需求还是频繁化的话，那么你就不用考虑其它修复手段了，花时间去稳定它。很多项目都是在后期还不确定究竟要完成哪些功能，这样的项目注定是要失败的。
2、修正功能集
毫不犹豫的把那些优先级较低的功能、特性剔除掉，一定要根据优先级来完成任务。
3、持续降低缺陷数目
功能、特性可以权衡，质量是不可以权衡的，项目管理三角形：成本、进度、功能。三角形里并没有质量这一角，不要为了追赶进度而在质量上做手脚。
4、去除没有用的垃圾
如果一个模块质量极其低下，改了又改，bug还是不断涌现，那么就从把这个模块的代码去除掉，重新设计它，不要让一堆无法控制的缺陷把项目拖死。