你以前听过的事后分析

如果你花过时间实际建立网络，你就会一次又一次地听到同样的事后总结：

*"我们在等许可证" *"电力公司还没批准电线杆的安装" *"工作人员都忙不过来了"

都是真实的。也都不完整。

因为如果你仔细观察大多数延迟的宽带项目，尤其是中小型建设项目，真正的问题并不在于组织外部发生了什么。而是组织内部发生了什么。

延误不是从你想象的地方开始的

在纸面上，当外部依赖性出现问题时，项目就会被延误：许可证需要的时间比预期的长，电线杆申请被拒绝，货物延迟到达。

但在实践中，这些事件很少会影响到准备充分的项目。实际发生的情况更像是这样：

提交的许可证数据缺失或不一致
设计变更没有在需要的地方得到反映
施工计划在过时的假设基础上推进
施工队在开工后才发现冲突

因此，当延迟出现时，就会被归咎于外部触发因素。但延迟的基础早在几周前就已经打好了。

虚假延迟问题

大多数项目并不像团队想象的那样经常受阻。它们是错位了。

六周的 "许可延迟 "往往会变成两周的实际处理时间和四周的内部来回、澄清和返工时间。

这种区别很重要。因为你不可能通过对市政当局加大力度来解决为期四周的内部延误。

电子表格在超过一定范围后就无法缩放

这是人们不愿承认的部分。大多数宽带建设--即使是价值数百万美元的建设--仍然是通过电子表格、电子邮件线程、共享文件夹和拼凑的点工具来运行的。

它在小范围内有效。直到行不通为止。

故障模式并不引人注目。它很微妙：

同一计划有多个版本
任务所有权不明确
存在于某人头脑中的依赖关系
更新太迟而不重要

没有任何一个问题会扼杀项目。但这些问题加在一起，就会造成持续的摩擦。而这些摩擦又会导致延误。

线性构建的神话

我们在谈论网络部署时，仍然把它当作一个简单的顺序：设计→许可→构建→激活。但实际上项目并不是这样运行的。

实际上

设计在许可过程中不断发展
根据现场条件改变许可要求
施工决策反馈到设计中
启动取决于可能仍在移动的上游部件

这是一个平行系统，充满了移动目标。如果试图以线性方式管理，就会出现问题。

交接是项目悄然失败的原因

如果说有什么地方需要寻找隐藏的延误，那一定不是在那些重要的里程碑上。而是在它们之间的过渡阶段--从设计到许可、从许可到施工、从施工到启用。

每次交接都会丢失一些东西：背景、假设、限制和时间。

审批团队并不总能看到最新设计的细微差别。施工团队并不总是知道审批过程中发生了什么变化。启动团队会遇到他们没有预料到的意外。没有人能够掌控团队之间的差距。而这种差距正是返工和延误的根源所在。

为什么经验丰富的团队仍会被抓

这不是能力问题。你可以拥有强大的工程师、经验丰富的项目经理和可靠的承包商，但仍然会遇到同样的问题。

因为问题不在于个人表现。而是他们所处的系统。

当信息支离破碎、更新不同步、依赖关系不实时可见时，即使是优秀的团队最终也会根据不完整或过时的数据做出决策。在数十个决策中重复出现的微小失误，会导致重大延误。

您不存在许可问题

或者是劳动力问题。甚至是资金问题。

你的协调能力有问题，表现为所有这些问题。

这就是为什么在外部限制上加大力度只会让你走得更远。如果提交的材料不一致，加快许可速度也无济于事。如果施工人员按照过时的计划施工，再多的施工人员也无济于事。如果执行无法预测，再多的资金也无济于事。

是什么让针头动起来

最大的收益不会来自于边缘的优化。它们来自于对核心的强化：

使各团队之间的依赖关系清晰可见
确保每个人都根据相同的最新信息开展工作
减少交接时的返工
更早地发现问题--在解决问题的成本还很低的时候

换句话说：将执行视为一个系统，而不是一系列步骤。

换一种方式思考工具

该领域的大多数工具都能实现某种功能--设计工具、许可跟踪器、施工管理系统。缺少的是将它们连接起来的那一层。

这就是像 Aptli 这样的平台的用武之地--不是作为另一种工具添加到堆栈中，而是作为缩小步骤之间差距的一种方法：

** 将计划与执行联系起来。** 在计划阶段做出的决定在工作向下游推进时始终可见。

**让整个项目都能看到变化。**当信息发生变化时，每个人都能看到，而不仅仅是做出决定的团队。

** 跟踪依赖关系，而不仅仅是任务。** 问题不在于任务是否被勾选。问题不在于任务是否被勾选，而在于依赖于它的事物是否准备好移动。

**项目经理不再从回顾性更新中了解问题，而是在问题发展的过程中就能看到它们。

与其说是做得更多，不如说是失去得更少--更少的时间、更少的环境、更少的调整。

不舒服的收获

把延误归咎于自己无法控制的事情，会更容易些。许可证。公用事业。天气。供应链。

但很大一部分延误是内部原因造成的--通过协调中可修复的小故障造成的。解决这些问题并不像宣布新的资金或加快审批那样显而易见。但这才是真正的杠杆作用所在。

因为一旦工作获得批准，问题就不是网络能否建成。问题在于你是否能按时、按预算、不间断地完成任务。

摘要

大多数宽带项目的延误都归咎于外部因素--许可证、公用事业、供应链--但这些延误的基础通常早在几周前就在企业内部打好了。
许可证延期六周通常只包含两周的实际处理时间，其余时间都是内部错位、返工和澄清。
耗资数百万美元的建设工作通常仍在电子表格、电子邮件线程和互不关联的点工具上运行--这种设置造成了持续、复杂的摩擦。
网络部署并非线性顺序。设计、许可和施工是并行的，每个环节都会反馈到其他环节。线性管理是项目失败的根源。
从设计到许可，从许可到施工，从施工到激活，团队之间的交接会导致背景、假设和时间的丢失。没有人能够掌控差距。
根本问题是协调问题，根据你所处的位置，协调问题会表现为许可问题、劳动力问题或资金问题。
真正的收益来自于使依赖关系清晰可见，确保团队根据当前信息开展工作，减少交接返工，并在问题解决成本较低时及时发现。
Aptli 等平台解决了连接层的问题--将计划与执行联系起来，使整个项目的变化浮出水面，并为项目经理提供实时清晰的信息，而不是事后的意外。
内部杠杆作用。如果下面的协调出现问题，再快的许可和再多的施工人员也无济于事。