项目管理
项目失败发生在团队之间的接缝处，而非团队内部。工作就是处理这些接缝。
设定
- 一个目标，以业务成果的形式陈述，并附带截止日期。多个同等重要的目标意味着没有目标。
- 一个指定的负责人——一个人，而不是委员会。项目经理推动；负责人做决策。
- 用包含项和排除项来定义范围。 排除项是关键工作；未写入的排除项会变成假设。
- 依赖关系由承担方团队映射并同意，并附上他们实际承诺的日期。计划中依赖项若未得到承担方团队同意，那只是一个愿望。
排序
按依赖关系和风险排序，而不是按团队便利。前置那些可能使计划失效的因素——技术不确定性、供应商决策、可能不会获批的审批。第四个月发现计划不可行是典型的项目失败。
在集成点预留缓冲，而不是在最后预留。尾端预留的缓冲会早早被悄悄消耗掉。
值得阅读的状态
每次汇报只需三件事：我们能否按时完成，自上次以来发生了什么变化，以及需要什么决策或支持。其他一切都是附件。
根据承诺的日期跟踪状态，而不是工作量。“进度80%”不是信息；“集成已完成，迁移周一开始，签批存在风险”才是信息。
尽早且具体地升级汇报。明确说明需要什么决策以及决策截止日期的升级才能得到解决；泛泛的担忧陈述只会被确认而没有任何行动。
进度延迟时
确定是范围问题、容量问题还是依赖问题——对策完全不同，用错对策只会让情况更糟。
然后提供带后果的选择：削减范围（明确削减什么）、延期（说明延长时间以及影响的其他事项）、或增加容量（这在后期很少有帮助，而且常常有害）。
公开地一次性重新设定基线，而不是一周一周地延迟。连续的小规模延迟对信誉的破坏远大于一次诚实的重置。
绝对不要
- 在存在未解决的阻塞项时仍报告项目状态为绿色。
- 接受承担方团队未确认的依赖项截止日期。
- 向一个已经延迟的项目加人并期待加速。