项目管理是以任何所需的方法，来增加实现积极结果的几率和速度。
完美的进度表并不能解决项目本身带来的所有问题。进度表不能挽救糟糕的设计或者编程实践，它也不能保护一个项目免遭无力的领导，不明确的目标或者低效的沟通。因此，即使花了很多的时间去设计进度表，它们也只是一堆堆的文字和数字罢了。现在该轮到有人把进度表当成工具去管理和驱动项目了。
把焦点置于方法和过程上，而非建立过程以支持人员，项目就会通过限制个人的贡献来开始安排进度过程。这会制定出很多必须遵守的规则，而不是思考及调整或改进规则。所以，当你采用方法论时，对其使用方式要非常小心：他不应该变成打击团队的东西 ；相反地，它应该支持、激励以及协助团队把工作做好。
如果一个团队在开始一个项目的时候，就充分了解进度表可能出现问题的原因，并且采取措施去减少这些出错的风险，那么这个进度表就为成为开发过程中更加有用和精确的工具。
进度表无需完美（当然，这是个安慰，因为没有完美的进度表）。进度表只需好到让团队及领导者相信，它能提供跟踪及调整的基础，并有个成功的几率，以满足客户、业务或整个项目的赞助者。
进度表的产生过程非常重要，你需要确认团队是否对进度表有拥有感和承诺感？如果没有，为什么？团队成员是否参与了进度表以及要完成的工作项目的制定？还是把制订好的进度表传递给他们？，有效使用进度表的唯一方式就是要知道为了使项目成功，必须要做哪些事情。
要想让你的进度表实实在在起作用，你需要考虑以下几点：
1、 对远景要乐观，对进度表要存疑。
安排进度的主要心理挑战就是利用适当的怀疑，同时又不能挫伤团队的热情和积极性。写远景文件时，需要对未来乐观且充满信心，但对于进度表则不同，要用相反的观点。在写下工作花费时间的估算数字时，需要对墨菲定律（Murphy law）保持真诚的敬重（该错的一定会错）。进度表不应该反映，在理想情况下会发生什么；相反地，好的进度表会宣称什么事将实际发生，尽管几项重要事情并不能如期进行。
2、告知团队进度表计划的原理。
要让实际执行计划的人参与计划的拟定， 无论采用什么控制进度的手段或技巧，都应该使其称为团队的共同知识。
3、通过问题空间来衡量团队经验。
关于进度安排的神奇变量之一，就是团队对即将解决的这种问题有多少经验。
4、衡量团队合作的信心和经验。
在创建一个完整的事物时，项目团队是以一个整体在一起工作。即使团队中都是超级明星，如果以前从没合作过（或者一起面对困难挑战），还是难以达到预期的效率。如果采用新组成的团队来完成大型高风险的项目，或者需要承诺完成非常紧张的进度，那就非常危险了。
5、尽早考虑风险。
如果你知道张三负责实现最复杂的组件，那么在进度初期就要处理这些挑战。风险越大，你就会需要越多的时间来处理它。如果到了进度表后期才开始处理风险，就没多少自由度来应对它了。对于政治、组织或资源相关的风险也是这样。
总之，应该将大进度表分成小进度表，以最小化风险，同时便于增加调整的频率。 所有估算都是一种几率。因为进度表是一堆估算的集合，所以也是几率的集合。由于几率会累积（80%×80%=64%），因此这将影响进度表的准确度。 越早作估算，准确度就越低。但是，只有进行粗略估算才能拥有一个起点，以做更好的估算。 应该以怀疑而非乐观的态度来制定进度表。把精力投注在设计上，使各种假设公开，以产生可靠的信心。
