项目交付
一个项目是拥有明确终点且边界清晰的工作包。协调多个项目以达成共同成果属于 pmo:program-management（项目管理办公室：项目集管理）。
通过排除项界定范围
包含项容易达成一致，但理解却各不相同。真正起作用的是排除项：明确写出本项目不交付的内容，并由项目发起人确认。
未书面记录的排除项会以假设的形式重新出现，而且总是在项目后期，总是被描述为“显然应该包含的内容”。在项目结束时修复这种情况被称为范围蔓延；这通常是由于项目开始时文档化工作的失败。
以区间形式进行估算，并说明区间的含义
单点估算是一种伪装成承诺的预测。应给出一个区间，并附上可能导致估算值移动的假设条件，同时明确说明置信度。
估算的是工作量，而非期望的完成日期。向下协商的估算并不会改变工作量；它只会改变你发现真相的时间，而发现真相往往发生在最难以挽回的时刻。
将工作分解到可理解的粒度。对一个庞大未知数进行估算，得出的数字更多与乐观情绪相关，而非实际工作量。
关键路径才是关注的重点
并非所有延误都同等重要。关键路径上的延误会推迟项目结束日期；其他路径上的延误则消耗浮动时间。区分这两者，是有效关注与泛泛焦虑之间的分水岭。
随着情况变化重新计算关键路径 —— 它会移动。一个团队如果还在关注最初的关键路径，那他们就盯错了地方。
在项目层面持有缓冲时间，而不是给每个任务都添加余量。被添加了余量的任务会吸收掉自己的缓冲，并且不会提前交付，因为工作会自动膨胀，而且没有人会报告自己提前完成了任务。
跟踪完成情况，而非投入精力
百分比完成度是一种自我报告的乐观数据，而且众所周知会卡在 90%。应跟踪已定义可交付物的二进制完成状态 —— 完成或未完成，根据事先达成一致的定义来判断。
观察趋势：剩余工作量是否按所需速率下降。一个剩余工作量没有减少的项目，无论报告完成的百分比是多少，它都已经延期了。
项目恢复
首先进行诊断，因为补救措施并不重叠：范围比理解的大、产能比计划的低、依赖项未交付，或者估算从一开始就不现实。
然后提出选项并附上后果 —— 削减范围并明确削减哪些部分、延期并说明需要延多久，或者增加人员（在项目后期这通常会让事情更慢）。进行一次有目共睹的重新基线设定。连续一周的小规模延期对信誉的破坏，远大于一次坦诚的重置。
变更控制 —— 范围说明书的基石
任何人在一次谈话中就能移动的范围边界，根本算不上边界。变更控制是将范围边界固化的机制，它需要足够轻量，以便人们愿意使用它，而不是绕开它。
- 凡改变范围、日期或成本的事项均为变更 —— 包括那些被描述为“澄清”的工作。大多数范围蔓延都是以一系列小型的、看似合理的要求进入的，而这些要求从未在项目整体层面被评估过。
- 在决定之前评估对所有三个方面的影响。 “好的，但这会增加两周时间”是一个可以做出的决定。而仅仅说“好的”则是让计划悄然变得不可行的原因。
- 能够批准变更的人，是承担变更后果的人。 如果发起人批准了范围变更，但由团队来消化日期压力，那么变更就会被不断批准。
- 被拒绝的变更也要记录在案。 被拒绝的记录可以防止同一请求反复出现三次以上，并且当有人问为什么缺少某个特性时，这也是诚实的答案。
当批准的变更使得旧计划失去意义时，就进行重新基线设定，否则不要。将基线重置以掩盖偏差，只会毁掉你原有的唯一参考。
工具
交付跟踪：Jira、Asana、Linear、Monday.com、Smartsheet、Microsoft Project 以及类似工具。
组合与产能规划：Jira Align、Planview、Adaptive Work 以及类似工具。当你需要协调多个团队的计划共享一个产能池时值得使用，否则不必。
工具记录计划，但并不会让计划变成事实。一个在会议间隔期间无人更新的状态字段，比没有这个字段更糟糕。
绝对不要
- 未经书面排除项就同意范围。
- 将单点估算作为承诺呈现。
- 以百分比完成度报告进度。
- 在一个延期的项目中增加人手，并期望它能加速。