以下为本册完整章节试读。案例用于说明分析方法，不代表真实客户效果记录。
案例二｜跨部门协同
为什么所有部门都在做自己的工作，项目仍然持续延期？
情境
一个跨部门项目持续延期。销售认为：
客户需求已经明确。
产品认为：需求还在变化。执行团队认为：每次快完成时标准又改变。管理层认为：各部门执行力需要加强。
组织边界
当前只分析：这个跨部门项目。不分析整个企业。
核心问题
为什么项目持续延期？
角色视角
销售关注：客户要求。产品关注：方案完整性。执行团队关注：最终交付标准。管理层关注：项目时间。
共识与分歧
共识：项目确实延期。分歧：延期究竟来自需求、产品、执行还是决策。
九轴观察
重点进入：协同解释链；目标定义权；目标资源落差；超频运转；反馈归因闭环。
F1看什么
共同目标是：按期交付。但不同角色实际上拥有：不同版本的“完成”。因此组织内部可能同时存在多个预期状态。
F2看什么
大量投入可能进入：反复确认；修改；返工；等待决策；跨部门协调。
组织很忙，但有效交付比例仍然有限。
现实反馈
本项目在需求变化和交接中持续出现返工与延期。这提示需要检查本项目的完成标准与变更关系，不能由此直接推断整个企业都存在同一问题。如果其他项目也持续出现相同现象，才进一步讨论它是否构成跨项目的重复模式。
事件还是机制
如果：需求确认、变更、责任和交接长期重复出现同样问题，就需要继续看：是否形成持续协同机制阻点。
F3：反馈与结构更新
观察：当前协同机制是否还能有效吸收项目反馈。
主导机制阻点
可能位于：完成标准与变更权没有形成统一解释链。
最小机制行动
例如：在一个项目周期内统一“完成标准、变更入口、最终确认人和变更后的资源/时间处理”。
核心判断
所有部门都在努力，不等于所有投入正在流向同一个结果。
怎样使用这个判断
各角色对完成的理解不同，与临近交付又变更的现象相互对应。因此，本项目可以先把完成标准和变更确认作为行动重点；这些信息还不能说明整个企业都存在同一机制问题。
让需求提出人与交付承接人核对同一次变更：改了什么，由谁确认，时间或范围怎样处理。若标准其实一致，延期仍然存在，就要转向资源、技术依赖或等待决策，而不能把所有问题都归于沟通。
项目负责人先在下一次交接使用共同约定，回看返工是否仍来自标准不同。若减少了此类返工却增加决策等待，就调整确认方式。判断的价值在于让下一步有明确对象，并能随反馈修正。
填写示范｜让一次交接有共同的完成条件
以下为教学情境的填写示范，用来展示怎样组织观察，不代表真实客户的测量或改善结果。
组织边界
本次跨部门项目涉及销售、产品、执行与管理角色，观察范围从需求确认到交付验收。
共同结果
各方需要共同交付客户可以验收的版本。实际销售关注最新诉求，执行依据最初清单，两者没有同步到同一份完成标准。
角色与交接
销售关注客户变化，产品关注版本确认，执行关注完成后又返工，管理者看到的是延迟。几种反馈都指向需求变更后的交接，需要放在一起理解。
事件与机制
这次材料足以提出一个机制判断：变更没有同步更新完成标准、资源与时间。是否已经形成长期重复模式，还要看其他实际交接记录，不能由一次事件推广到全组织。
最小机制行动
项目负责人组织相关角色，将下一次交接的完成条件与变更确认方式写在一起。后续记录返工原因和交付变化，判断共同约定是否真正进入使用，而不是只多了一份文件。