14.1 “项目是怎样延迟了整整一年的时间？?一次一天。”
14.2 一天一天的进度落后比起重大灾难，更难以识别、更不容易防范和更加难以弥补。
14.3 根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。
14.4 里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
14.5 如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。
14.6 对于大型开发项目中的估计行为，政府的承包商所做的研究显示：每两周进行仔细修订的活动时间估计，随着开始时间的临近不会有太大的变化；期间内对时间长短的过高估计，会随着活动的进行持续下降；过低估计直到计划的结束日期之前大约三周左右，才有所变化。
14.7 慢性进度偏离是士气杀手。[Microsoft的Jim McCarthy说：“如果你错过了一个最终期限（deadline），确保制订下一条deadline。2”]
14.8 进取对于杰出的软件开发团队，同优秀的棒球队伍一样，是不可缺少的必要品德。
14.9 不存在关键路径进度的替代品，使人们能够辨别计划偏移的情况。
14.10 PERT的准备工作是PERT图使用中最有价值的部分。它包括了整个网状结构的展开、任务之间依赖关系的识别、各个任务链的估计。这些都要求在项目早期进行非常专业的计划。
14.11 第一份PERT图总是很恐怖的，不过人们总是不断进行努力，运用才智制订下一份PERT图。
14.12 PERT图为前面那个泄气的借口，“其他的部分反正会落后”，提供了答案。
14.13 每个老板同时需要采取行动的异常信息以及用来进行分析和早期预警的状态数据。
14.14 状态的获取是困难的，因为下属经理有充分的理由不提供信息共享。
14.15 老板的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不越俎代庖，将能鼓励诚实的汇报。
14.16 必须有评审的机制，从而所有成员可以通过它了解真正的状态。出于这个目的，里程碑的计划和完成文档是关键。
14.17 Vyssotsky：我发现在里程碑报告中很容易记录“计划（老板的日期）”和“估计（最基层经理的日期）”的日期。项目经理必须停止对这些日期的怀疑。”
14.18 对于大型项目，一个对里程碑报告进行维护的计划和控制（Plan and Control）小组是非常可贵的。
