IT 项目为何受阻：从审批链条到决策授权

项目背景

先说明一点：IT 企业积累一些未能成功完成的项目，并不罕见。 并非每次工作都能成为值得展示的成功案例。 真正值得警惕的是，项目受阻并非因为工程师不会解决问题， 而是因为发现问题的人，与有权解决问题的人之间相隔太远。

在17年的工作中，我参与过多种类型的项目：

• 服务项目：在 SLA（服务级别协议）范围内保障人员、服务与系统的正常运行；
• 集成项目：按照已有设计，准确完成实施工作；
• 开发项目：包括门户、软件与平台；
• 全周期项目：由同一团队先设计系统，再负责实施；
• 俄罗斯本土替代项目：我把它们单独列为一类，因为往往既要面对紧迫的工期，也要应对尚未充分成熟的解决方案。

在我看来，全周期项目尤其容易暴露企业在项目管理方面的不足。

我的经历并不是一开始就进入大型项目， 身边有成熟团队、完善流程和导师。 更多时候，我需要独立拿到技术任务书， 逐条研读、拆解工作，再寻找适合的人来执行。 当时身边并没有人能系统地告诉我应该怎样做。

因此，我的很多判断来自亲身实践， 而不是直接照搬前辈经验或教科书中的方案。

问题：需要改善的环节遍布全局

下面这个案例发生在一家服务企业。 它有丰富的客户服务经验、分布式合作伙伴网络， 以及规模可观的服务经理团队。 但它缺少全周期项目经验。

客户是一家大型能源企业。 如果借用问诊的说法，最初的对话大致是： “哪里有问题？”——“到处都有。”

基础设施逐渐老化，服务出现异常，安全要求不断提高。 客户希望尽快改善，于是要求内部各部门分别提交需要解决的问题和技术需求， 再将这些材料汇总成一份技术任务书。

最终，项目范围几乎变成了重建整套 IT：

• 更换各现场的有源网络设备；
• 设计并迁移目录服务、企业邮件和 CRM；
• 建立从恶意软件防护到移动设备管理的信息安全体系。

经过招标、确定承包方、签约，项目正式启动。 第一个也是最关键的设计阶段，合同安排了四个月。

诊断：两个月没有形成文档

第二个月接近结束时，我受邀参加面谈。

面谈中发现了一个细节： 合同执行了两个月，才有人认真读到技术任务书中有关交付文档的部分， 包括应提交哪些文件，以及按哪些标准编写。

在该俄罗斯项目的合同背景下，相关文档涉及自动化系统标准体系。 例如， ГОСТ Р 59795-2021（俄文） 规定了自动化系统文件的内容要求。 这里介绍的是原案例的适用背景，并非中国项目的统一要求。

然而，两个月过去了，要求交付的文档还没有开始形成。

与此同时，企业内部的资源安排仍在照常推进。 设计工作没有完成，却已经计划让一名工程师在下一周直接升级客户正在运行的邮件系统。 当时既没有获批的架构，也没有回退方案。

措施：明确项目决策与执行权限

团队需要有全周期项目经验的人。 面谈时，我提出了一个直接的条件： 如果由我在这种情况下接手项目并对结果负责， 就需要获得与任务相匹配的组织协调和执行权限。

这个要求听起来很强势。 但我判断，如果所有安排仍要沿着原有链条逐级协调， 就很难在剩余时间内达到要求。

对方接受了。明确分工与权限后，我们开始调整工作方式。

结果是，项目设计文档按时完整提交， 符合技术任务书、相关规范和合同要求。

随后出现了一个意外： 客户看到完整的设计材料，意识到自己无法在原定期限内完成充分评审， 也无法按原有节奏组织客户侧的集成配合。 双方明确了一个事实：按照合同原定工期，无法实施如此大规模的项目。

项目随后停止。 承包方避免了罚款、索赔和声誉损失。 需要区分的是：这里按时完成的是设计文档交付，而不是整个系统的实施。

这件事也让我开始认真思考，不同管理层级之间究竟应该如何协调。

原因：不同规模，需要不同的协调方式

一家有经验的服务企业，为什么会在项目刚启动时就面临如此大的风险？ 问题不一定在于人员能力，而在于人与人之间的沟通与决策距离。

可以用两类船来作比喻。

小型帆船，好比规模较小、行动灵活的企业。 船长可以直接下达指令，团队迅速响应，调整方向也快。 但规模过大、责任过重的合同，可能超出它的承载能力。

大型舰船，好比大型企业。 资源多，能够承担不同规模的任务， 但运转依赖清晰可靠的流程。 甲板上发现前方障碍的人，就像项目经理： 他可以识别风险，却未必有权直接调动资源、改变方向。 结果取决于信息能否及时、准确地传给有决策权的人。

如果传递链条过长，组织就可能错过调整时机。

红色文件夹：信息在传递中发生了什么

电影《Ford v Ferrari》中有一幕，很形象地表现了这个问题。 Carroll Shelby 与 Henry Ford II 讨论赛车项目， 提到一份红色文件夹在抵达决策者之前，已经经过多次转手。

这里不逐字引用电影台词。 这一场景表达的意思是：反复转交材料，不能代替明确的项目领导与及时决策。 MIT News 在讨论该片的商业启示时， 也用这一场景说明中间环节形成的“隐形工厂”—— 管理者不易察觉、却可能降低质量与效率的额外工作。 参见 MIT News（英文）。

IT 项目中也会发生类似情况。 项目经理发现技术任务书没有被充分研读， 文档工期即将耗尽，工程师却准备在缺少方案的情况下修改生产环境。 他提交报告并发出警告， 但他与能够调整资源或优先级的人之间，还隔着多个层级。

信息在转述中被不断弱化。 最初明确的风险，最后可能被概括成“总体可控，还有一些工作细节”。 等到管理层获知完整情况，项目可能已经失去补救窗口。

康威定律与沟通结构

组织的沟通方式与系统设计之间，也存在值得关注的联系。 1968年，Melvin Conway 在 《How Do Committees Invent?》（英文）中提出： 组织设计出的系统，往往会体现其自身的沟通结构。

这一观察后来被称为康威定律。 Martin Fowler 也讨论了它与软件架构的关系，参见 《Conway's Law》（英文）。

对管理者而言，它提醒我们： 组织规模、协调方式和团队边界，可能影响最终系统的结构。 如果沟通路径复杂，而项目团队又无法围绕共同目标协调行动， 这种复杂性就可能反映到交付结果中。

这并不意味着所有审批都应该取消。 关键是区分必要的专业审查、风险控制， 与没有增加判断价值的重复转述和等待。

复盘结论

回到能源企业的案例， 局面能够得到控制，一个重要原因是我获得了明确的项目管理权限， 减少了不必要的中间转交，并承担相应责任。

由此，我总结出一个实践原则，称为“一次握手”： 项目经理与关键决策者之间，最好能够直接沟通； 如需协调，中间尽量不超过一个明确的责任节点。

例如：项目经理 → 交付负责人或项目主管 → 总经理。 具体安排应与项目规模和治理要求相适应。

如果链条中不断增加职责重叠的中间层，就可能出现三类问题：

• 信息失真：真实风险被弱化，管理层只听到“按计划进行”；
• 决策延迟：项目经理知道需要调整，却没有权限，而请求在多轮审批中耗尽时间；
• 责任模糊：参与协调的人很多，但权限与结果责任并未清晰对应。

想让企业积累更多成功案例，就需要缩短结果责任人与关键决策者之间的距离， 让项目经理承担责任的同时，也拥有与任务相匹配的权限。

否则，相同的协调问题就可能反复出现在新的项目中， 带来本可避免的成本与损失。