裁剪是什么
裁剪是依据项目规模、复杂度、不确定性、治理要求与团队成熟度，对方法、过程、文档深度与评审频率做调整，让管理投入与项目风险匹配。裁剪不是随意简化：每一项增删都要写明理由、风险与补偿措施，并由有权限的人批准。涉及安全、财务与法规的过程通常不可裁剪。
基本信息
| 裁剪维度 | 生命周期选择、过程深度、文档与报告、评审频率、角色与治理层级 |
|---|---|
| 依据输入 | 项目目标与复杂度、合同与法规、干系人需求、组织方法论 |
| 落地载体 | 裁剪说明与项目管理计划中的相应章节 |
| 批准层级 | 通常由发起人或 PMO 批准，重大裁剪需与治理要求核对 |
| 复核时点 | 阶段关口或重大变更后复核裁剪是否仍然合适 |
典型使用场景
- 小型内部工具项目，合并若干子计划文档，减少编制成本
- 高风险或合规类项目，在标准流程上增加独立评审与审计环节
- 新型技术项目不确定性高，增加原型验证与迭代评审，减少前期详细设计
- 多供应商项目，强化接口与验收相关的过程，弱化内部协作类流程
- 敏捷与预测型混合场景，用迭代交付但对合同节点保留阶段评审
裁剪决策记录模板
裁剪决策记录模板
要素：过程 / 文档 / 会议名称 # 逐项登记，避免笼统写「简化流程」
现状：标准方法论要求做什么
裁剪：本项目怎么做（增加、删除、简化或合并）
理由：依据是什么（规模、风险、合规、团队经验） # 理由需可核对，不写「大家都知道」
风险：裁剪带来的风险与补偿措施 # 补偿措施是裁剪被批准的前提
批准：谁批准（发起人 / PMO）与批准日期
复核：什么时点回看这项裁剪是否仍然合适裁剪维度与常见取舍
| 维度 | 可裁剪的方向 | 通常不可裁剪 |
|---|---|---|
| 过程深度 | 合并子计划、简化审批层级 | 安全、财务与合规相关评审 |
| 文档与报告 | 缩减文档篇幅、改用看板与图表 | 合同要求的交付文档与验收记录 |
| 评审频率 | 小项目减少评审次数 | 阶段关口与合同验收评审 |
| 角色与治理 | 项目经理兼任部分协调角色 | 决策授权与升级路径的明确性 |
| 生命周期 | 选择迭代或增量方式 | 法规或合同指定的强制节点 |
裁剪不等于省略风险与合规评审。若为压缩工期去掉变更控制、独立测试或安全评估，代价通常在上线之后以缺陷、返工或处罚的形式集中出现，且无法用当初节省的时间弥补。