工作包估算与团队确认
工作包估算应由实际执行者参与并确认：自上而下分摊容易造成低估，且执行阶段缺乏承诺感；自下而上汇总更易获得执行者的认同。当汇总结果超出管理层给出的约束时，需要讨论缩减范围或调整时点，而不是简单把数字改小。
基本信息
| 估算方式 | 自下而上汇总为主，自上而下用于校验 |
|---|---|
| 参与角色 | 实际执行者、技术负责人、项目经理 |
| 确认载体 | 估算确认单、系统记录、评审纪要 |
| 差异处理 | 估算高于约束时缩减范围或调整时点 |
| 复核要求 | 确认后发生变更需重新走确认流程 |
典型使用场景
- 计划编制：由执行者按工作包估算并汇总，形成承诺基础
- 约束冲突：管理层给出的总工期不足时，用差异分析讨论范围与资源
- 乐观偏差纠正：估算明显低于历史同类工作时，复核关键假设
- 变更后重新确认：范围或人员变化后重新估算并确认
- 绩效归因：偏差出现时判断是估算问题还是执行问题
确认机制示例
确认机制示例
1) 管理层给出总工期与成本约束（含关键里程碑）
2) 团队按工作包分解估算并汇总
3) 差异分析：若超出约束，讨论缩减范围或调整时点
4) 确认：执行者签字或在系统确认估算与承诺
5) 变更后：重新估算并重新确认，更新基线
提示：没有执行者参与的估算，执行阶段常以估算不合理为由失去约束力差异处理
| 情形 | 动作 | 注意 |
|---|---|---|
| 估算高于约束 | 缩减范围或调整时点 | 明确削减项与影响 |
| 估算低于经验值 | 复核乐观假设 | 检查是否遗漏工作内容 |
| 存在未确认项 | 补齐确认后再入基准 | 禁止默认接受 |
| 确认后再变更 | 重新走确认流程 | 保留新旧版本记录 |
确认的形式可以简单，但必须留痕：一句话的书面确认也强于口头同意，因为后续偏差归因时需要依据。
没有执行者参与的估算在执行阶段常以「估算不合理」为由失去约束力，项目进度与成本都难以追责。