第 3 章 · 预计阅读 20 分钟
专家组队与项目执行
专家都很优秀，为什么项目仍可能因为协作而失败？
围绕工作包配置专家与客户角色，用证据、评审和变更控制推进分析，而不是堆叠个人观点。
先放回整门生意
先知道这一章为什么存在
先把“专家组队与项目执行”理解成一段有触发、有负责人、有记录、也有完成标准的业务，而不是一组部门名词。
上一章“诊断、提案与范围签约”应先形成：把问题、方法、交付物、客户输入、计划、验收、价格和排除项放进可执行工作说明书。
本章把“围绕工作包配置专家与客户角色，用证据、评审和变更控制推进分析，而不是堆叠个人观点。”从一句目标变成可执行、可交接、可核验的工作。
结果将交给下一章“交付、评审与验收”：先通过内部质量评审，再与客户核对事实、方法、结论和使用条件，按约定标准关闭反馈。
- 收入怎么受影响
- 澄策咨询通过诊断项目费、顾问工时费、专项数据分析费和后续落地辅导费收费。本章形成的“新增需求没有稀释原项目”要和“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：范围变更在处理前后的状态变化”和“本步核对线索：可计费利用率在处理前后的状态变化”一起核对，才能继续判断验收、结算或后续经营；现金时点按以下规则判断：启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。
- 风险在哪里出现
- 全程要警惕“范围不清、证据不足、专业责任和回款延期”。本章至少要用“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：范围变更在处理前后的状态变化”和“本步核对线索：可计费利用率在处理前后的状态变化”留下可追溯证据。
读完这一章，你应该能自己解释
- 能用自己的话解释“专家都很优秀，为什么项目仍可能因为协作而失败？”，并说出它为什么会影响客户价值或经营结果。
- 能按依赖顺序还原4个业务步骤，并指出每一步的负责人、记录和交接物。
- 能区分业务流、钱流、信息流和责任流，不把“做过动作”误当成“完成交付”。
- 遇到相似情境时，能用“产出是否形成、证据能否核对、风险是否受控”作出判断。
先建立业务直觉
专家都很优秀，为什么项目仍可能因为协作而失败？
项目第三周，客户数据晚到且口径不一致，同时发起人新增海外仓比较要求。专家团队若各自填补假设，会产出无法相互解释的结论。
把它放进澄策咨询的经营现场：本章只聚焦“专家组队与项目执行”这一环，追踪它怎样承接已有输入，并把“围绕工作包配置专家与客户角色，用证据、评审和变更控制推进分析，而不是堆叠个人观点”变成可以执行和复核的工作。
本章从“启动工作计划”开始，依次经过“启动工作计划”、“收集验证证据”、“分析整合”和“控制变化”，最后得到“新增需求没有稀释原项目”。判断是否完成，要把动作、产出、业务记录和下一位接手者放在一起核对。
至少同时满足三件事：产出“新增需求没有稀释原项目”；关键记录“本步核对线索：项目交付物在处理前后的状态变化”、“本步核对线索：工作说明书在处理前后的状态变化”、“本步核对线索：范围变更在处理前后的状态变化”和“本步核对线索：可计费利用率在处理前后的状态变化”可以相互核对；相关负责人清楚下一步由谁接手。
完整案例推演
跟着澄策咨询，把“专家组队与项目执行”完整跑一遍
现在把镜头放到澄策咨询的“专家组队与项目执行”：专家都很优秀，为什么项目仍可能因为协作而失败？ 先读下面的经营底账，后续每一步都会复用这些数字与约束。
贯穿全课的虚构案例
澄策咨询
一家 14 人的管理咨询公司受食品加工厂委托，诊断采购缺货和库存积压同时发生的原因，并在十周内交付可执行的补货与供应商管理方案。
- 项目金额
- ¥280,000费用购买的是约定范围内的诊断、方案和辅导，不是对降本结果作无条件保证。
- 项目周期
- 10 周、6 场关键访谈工作坊每一阶段都要取得客户数据和决策人反馈，否则后续建议缺少事实基础。
- 分析样本
- 18 个月、2,640 个物料 SKU数据清洗口径会决定缺货率和库存天数是否可比，不能直接拿原始表格下结论。
- 最终交付
- 1 份诊断报告、3 套流程方案、1 次管理层评审交付物必须通过评审并形成采纳决定，发送文件不等于项目验收。
客户为什么付钱
诊断项目费、顾问工时费、专项数据分析费、后续落地辅导费
钱在什么时候进来
启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。
利润最容易被什么吃掉
顾问和专家工时、数据采购与分析工具、访谈差旅、高级合伙人复核
这笔业务怎样一步一步形成可交付结果
- 01启动工作计划可供“收集验证证据”使用的已确认的治理决定
- 02收集验证证据可供“分析整合”使用的可复核的业务证据
- 03分析整合可供“控制变化”使用的可评审的解决方案
- 04控制变化新增需求没有稀释原项目
启动工作计划
在澄策咨询，团队先面对一条共同事实：“项目金额”为¥280,000。费用购买的是约定范围内的诊断、方案和辅导，不是对降本结果作无条件保证。
拆分任务、责任、依赖、里程碑和沟通。
这一步真正要判断：协调专家与客户输入；按计划提供数据、流程与反馈
如果本步没有形成“可供“收集验证证据”使用的已确认的治理决定”，下一步“收集验证证据”就没有可靠输入。
- 谁在参与
- 项目经理、客户业务团队
- 关键记录
- 本步核对线索：项目交付物在处理前后的状态变化
- 形成产出
- 可供“收集验证证据”使用的已确认的治理决定
- 交给下一步
- 把“可供“收集验证证据”使用的已确认的治理决定”交给客户业务团队和项目经理，继续处理“收集验证证据”。
如果没做好：风险观察：结论建立在共同证据上——限制和数据口径被显式记录，不由个人猜测填补。
收集验证证据
上一步已经形成“可供“收集验证证据”使用的已确认的治理决定”。与此同时，案例里的“项目周期”为10 周、6 场关键访谈工作坊，每一阶段都要取得客户数据和决策人反馈，否则后续建议缺少事实基础。
清洗数据、访谈角色并记录限制。
这一步真正要判断：按计划提供数据、流程与反馈；协调专家与客户输入
如果本步没有形成“可供“分析整合”使用的可复核的业务证据”，下一步“分析整合”就没有可靠输入。
- 谁在参与
- 客户业务团队、项目经理
- 关键记录
- 本步核对线索：工作说明书在处理前后的状态变化
- 形成产出
- 可供“分析整合”使用的可复核的业务证据
- 交给下一步
- 把“可供“分析整合”使用的可复核的业务证据”交给项目商务经理，继续处理“分析整合”。
如果没做好：风险观察：范围变化获得选择——新增价值需求被估算，而不是无声侵占原工作。
分析整合
上一步已经形成“可供“分析整合”使用的可复核的业务证据”。与此同时，案例里的“分析样本”为18 个月、2,640 个物料 SKU，数据清洗口径会决定缺货率和库存天数是否可比，不能直接拿原始表格下结论。
用共同口径连接发现、原因和影响。
这一步真正要判断：维护范围与费用变化
如果本步没有形成“可供“控制变化”使用的可评审的解决方案”，下一步“控制变化”就没有可靠输入。
- 谁在参与
- 项目商务经理
- 关键记录
- 本步核对线索：范围变更在处理前后的状态变化
- 形成产出
- 可供“控制变化”使用的可评审的解决方案
- 交给下一步
- 把“可供“控制变化”使用的可评审的解决方案”交给项目商务经理和客户业务团队，继续处理“控制变化”。
如果没做好：风险观察：专家工时投入可见——原范围、变更和售前探索使用不同预算边界。
控制变化
上一步已经形成“可供“控制变化”使用的可评审的解决方案”。与此同时，案例里的“最终交付”为1 份诊断报告、3 套流程方案、1 次管理层评审，交付物必须通过评审并形成采纳决定，发送文件不等于项目验收。
评估新增要求对范围、计划和费用的影响。
这一步真正要判断：维护范围与费用变化；按计划提供数据、流程与反馈
这是本章最后一项可核验产出，用来判断团队是否真的完成了“专家组队与项目执行”。
- 谁在参与
- 项目商务经理、客户业务团队
- 关键记录
- 本步核对线索：可计费利用率在处理前后的状态变化
- 形成产出
- 新增需求没有稀释原项目
- 交给下一步
- 把结果带入“新增需求没有稀释原项目”，并回答：分析完成后，怎样把“专家认为正确”变成客户能验收和使用的成果？
如果没做好：风险观察：责任矩阵驱动协作——客户确认事实，专家分析，项目经理管理依赖，评审者挑战结论。
案例结束时，不是因为所有人都完成了自己的动作就算成功，而是因为“新增需求没有稀释原项目”已经形成、证据可以追溯，并且项目商务经理和客户业务团队能够解释结果怎样产生、风险怎样被控制。原三座仓库按计划推进，海外仓比较进入单独探索建议；数据口径由客户和专家共同确认。
章末经营结果
新增需求没有稀释原项目
原三座仓库按计划推进，海外仓比较进入单独探索建议；数据口径由客户和专家共同确认。
- 原范围进度
- 保持
- 新增需求
- 转后续选项
换一个视角再看
同一笔业务，同时跑着四条线
业务流说明事情怎样发生，钱流解释收入、成本与现金，信息流留下共同事实，责任流决定谁执行、谁确认、谁承担后果。点击切换，观察同一章节怎样变化。
围绕“专家都很优秀，为什么项目仍可能因为协作而失败？”，业务必须按依赖关系推进，不能把一串并行任务误当成已经交付。
- 01
启动工作计划 → 可供“收集验证证据”使用的已确认的治理决定
- 02
收集验证证据 → 可供“分析整合”使用的可复核的业务证据
- 03
分析整合 → 可供“控制变化”使用的可评审的解决方案
- 04
控制变化 → 新增需求没有稀释原项目
出现这个信号要警惕：风险观察：结论建立在共同证据上——限制和数据口径被显式记录，不由个人猜测填补。
岗位、记录与业务语言
一家公司靠什么把多人协作变成同一个结果
岗位不是孤立的名称，记录也不是多余的表格。前者分配判断与责任，后者让不同人能够核对同一件事是否真的发生。
谁负责什么，结果交给谁
| 角色 | 本章负责 | 最关心 | 交给谁 |
|---|---|---|---|
| 业务职能专业研究与解决方案 | 提供本章所需的约束、输入或审批 | 使用专业方法分析问题，形成结论、设计与可实施建议；重点关注：选择方法并验证证据 | 下一章节或业务结果的接收方 |
| 业务职能项目管理 | 提供本章所需的约束、输入或审批 | 把范围、计划、人员、输入、风险和客户决策组织成可交付项目；重点关注：建立计划、责任和沟通节奏 | 下一章节或业务结果的接收方 |
| 业务职能专业质量与评审 | 提供本章所需的约束、输入或审批 | 独立检查方法、证据、逻辑、表达和专业风险；重点关注：设置交付评审与质量门槛 | 下一章节或业务结果的接收方 |
| 业务职能项目商务与财务 | 提供本章所需的约束、输入或审批 | 维护项目预算、工时、开票条件、应收和合同变更；重点关注：跟踪预算、工时与分包成本 | 下一章节或业务结果的接收方 |
| 外部参与者客户发起人与决策者 | 提供本章所需的约束、输入或审批 | 定义项目价值，调动客户资源并作出关键取舍；重点关注：确认目标、边界和成功标准 | 下一章节或业务结果的接收方 |
| 外部参与者客户业务团队 | 启动工作计划、收集验证证据、控制变化 | 提供资料、访谈、业务判断，并承接成果使用；重点关注：按计划提供数据、流程与反馈 | 项目经理、项目商务经理 |
| 外部参与者外部专业协作者 | 提供本章所需的约束、输入或审批 | 在明确范围内提供专项研究、测试、设计或法律技术支持；重点关注：按专业边界提交成果与证据 | 下一章节或业务结果的接收方 |
| 代表岗位项目经理 | 启动工作计划、收集验证证据 | 把范围、计划、人员、输入、风险和客户决策组织成可交付项目；重点关注：协调专家与客户输入 | 客户业务团队、项目商务经理 |
| 代表岗位项目商务经理 | 分析整合、控制变化 | 维护项目预算、工时、开票条件、应收和合同变更；重点关注：维护范围与费用变化 | 客户业务团队 |
哪些记录能证明业务真的发生了
| 业务记录 | 在哪产生 | 谁形成 | 证明什么 | 下一步怎么用 |
|---|---|---|---|---|
| 本步核对线索：项目交付物在处理前后的状态变化 | 启动工作计划 | 项目经理和客户业务团队 | 可供“收集验证证据”使用的已确认的治理决定 | 收集验证证据 |
| 本步核对线索：工作说明书在处理前后的状态变化 | 收集验证证据 | 客户业务团队和项目经理 | 可供“分析整合”使用的可复核的业务证据 | 分析整合 |
| 本步核对线索：范围变更在处理前后的状态变化 | 分析整合 | 项目商务经理 | 可供“控制变化”使用的可评审的解决方案 | 控制变化 |
| 本步核对线索：可计费利用率在处理前后的状态变化 | 控制变化 | 项目商务经理和客户业务团队 | 新增需求没有稀释原项目 | 新增需求没有稀释原项目 |
本章术语：先用白话理解，再回到正式定义
- Project Deliverable项目交付物
- 白话：在约定里程碑提交、具有明确内容、格式、质量和使用目的的专业成果。
- 正式定义：在约定里程碑提交、具有明确内容、格式、质量和使用目的的专业成果。
- 放进业务里：供应链诊断不只交一份演示稿，还包括问题证据、优先级、改进路线和可编辑数据附表。
- SOW工作说明书
- 白话：描述项目目标、范围、交付物、方法、计划、客户输入、验收与排除项的执行文件。
- 正式定义：描述项目目标、范围、交付物、方法、计划、客户输入、验收与排除项的执行文件。
- 放进业务里：SOW 明确分析三座仓库，不包含运输招标实施，并列出客户必须提供的数据字段和时间。
- Scope Change范围变更
- 白话：对既定目标、交付物、分析对象、时间或责任作出需要评估和确认的改变。
- 正式定义：对既定目标、交付物、分析对象、时间或责任作出需要评估和确认的改变。
- 放进业务里：客户新增两座海外仓分析，会增加数据清洗、访谈和模型工作，不能仅当作一句补充要求。
- Billable Utilization可计费利用率
- 白话：专业人员在一定周期内投入可向客户项目计费工作的时间，占其可用工作时间的比例。
- 正式定义：专业人员在一定周期内投入可向客户项目计费工作的时间，占其可用工作时间的比例。
- 放进业务里：利用率过低会闲置专家能力，过高则可能挤压研究、培训、销售支持和质量评审。
- Project Responsibility Matrix项目责任矩阵
- 白话：明确每项工作由谁负责、批准、协作和知会的项目组织约定。
- 正式定义：明确每项工作由谁负责、批准、协作和知会的项目组织约定。
- 放进业务里：库存数据由客户团队提供，项目专家分析，客户发起人批准口径，质量评审人独立检查结论。
新手最容易误解的地方
团队内部加班吸收
为什么不对：隐性扩围会挤压原交付、评审和团队可持续性，客户也看不到真实取舍。
应该继续追问：如果改成“形成变更或下一阶段”，需要谁确认、留下什么证据？
“启动工作计划”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：结论建立在共同证据上——限制和数据口径被显式记录，不由个人猜测填补。
应该继续追问：是否已经形成“可供“收集验证证据”使用的已确认的治理决定”，并留下“本步核对线索：项目交付物在处理前后的状态变化”供下一步核对？
“收集验证证据”只要动作做完，就可以直接进入下一步。
为什么不对：风险观察：范围变化获得选择——新增价值需求被估算，而不是无声侵占原工作。
应该继续追问：是否已经形成“可供“分析整合”使用的可复核的业务证据”，并留下“本步核对线索：工作说明书在处理前后的状态变化”供下一步核对？
先复盘，再做判断
现在，试着不用页面原话把这一章讲出来
- 为什么本章必须先做“启动工作计划”，如果跳过会影响哪一步？
- 在“收集验证证据”中，谁执行、谁提供约束，应该留下什么记录？
- 本章怎样影响诊断项目费、顾问工时费、专项数据分析费和后续落地辅导费？结合“启动收 40%，中期诊断评审后收 40%，最终成果验收后收 20%；范围外工作先签变更再执行。”判断它何时才会形成收入或现金。
- 如果只看到“新增需求没有稀释原项目”的口头结论，你还会要求核对哪些业务记录？
新增海外仓比较如何处理？
要求有价值，但缺少海外数据和当地专家，若强行纳入会推迟原定交付。