Ezpay

项目延期很少有单一原因，复盘会上常听到“供应商没按时交货”“需求改了几版”“人手被别的项目抽走”，这些说法都对，却都停在表面。真正吃掉进度的，是五类反复出现、又常被当作正常现象的机制性损耗——这也是项目管理中较难对付的一类对手。把它们逐个照亮，比追究某一个人的责任有用得多。把这些损耗称作“黑洞”，是因为它们不产生任何可交付成果，却持续吸收工时。更麻烦的是它们在进度表上不可见——任务状态仍显示进行中，百分比也在缓慢上升，直到某个关键节点才突然暴露，此时可用的补救时间已经不多。

黑洞一：等待的层层传导

一份技术方案要在设计、施工、监理三方之间来回确认，每一方都有各自的排期，等待便在链条上累加。表面看每个环节只慢两三天，落到总工期却是数周。更麻烦的是等待不产生记录，进度表上仍显示“进行中”，风险直到关键节点才暴露。等待还有放大效应：上游晚三天，下游的排期已经排满，实际接手可能要等到下一周，三天就变成了十天。

黑洞二：变更的无声累积

需求变更单独立看都合理：客户提出调整、现场条件变化、规范更新。问题在于变更没有冻结机制，基线反复移动，原计划失去参照。团队于是不断返工，已完成的成果部分作废，而工期承诺没有随之调整，压力全压在执行端。另一种情形是变更被口头接受但未入册，等到结算或验收时双方各执一词，追溯成本比变更本身更高。

黑洞三：资源的排队效应

同一个人同时挂在三个项目上，每个项目都以为他只投入三成精力。资源冲突在计划阶段看不见，在执行阶段集中爆发。关键路径上的人一旦被抽走，后续任务全部顺延，而这种顺延通常不会写进任何一份进度报告。资源问题还有隐性版本：专家型岗位全公司只有一两个人能拍板，所有项目都要在他们那里过一个关口，队伍再大也绕不开这个瓶颈。

黑洞四：估算的系统性漏项

工期估算常按“顺利情况”推算，忽略评审、报批、验收、资料归档这些不产生实体成果却必须占用的时间。漏项不会消失，只会以加班和压缩测试的形式补回来，质量风险随之上升，后期返工又把时间吃回去。审批类环节尤其容易被低估：材料准备两天，走流程却可能两周，而这周数取决于外部单位的节奏，不在项目团队掌控之内。

黑洞五：收尾期的塌陷

越接近交付，问题越集中：遗留缺陷、资料补齐、结算核对、验收整改同时涌来。收尾阶段缺少清单和责任人，团队凭感觉推进，本应两周完成的收尾拖成一个多月，前面积累的进度优势在末端被消耗掉。收尾塌陷还有一层原因：核心成员此时已被调往新项目，留下的多是经验较浅的人，处理遗留问题的效率自然下降。

把黑洞照亮的三条做法

其一，让进度可见

阶段、里程碑、任务拆到可交付的程度，进度按完成标准判定，而不是按百分比估计。计划与实际并列呈现，偏差一出现就被看见，预警才有意义。项目管理平台把全景监控与风险提示放在同一视图里，管理者不必逐个询问，也能判断哪条线正在偏航。可见的另一层含义是让等待显性化：审批中、待确认、待交付这些状态单独标记，等待时间就被计入了工期，而不再被默认忽略。

其二，给变更设闸门

变更可以提，但要评估对工期、成本、资源的影响，经确认后调整基线。冻结不是拒绝变更，而是让每一次变更都有代价记录。有了这层记录，下一次谈判与承诺才有依据，团队也不至于在无声的反复修改中耗尽耐心。基线调整之后要同步更新对外承诺，否则内部账已经改过，客户手里的版本还是旧的，新的偏差又会产生。

其三，把资源和收尾一并纳入计划

资源冲突在排期时解决，关键岗位的投入比例写进计划，避免多头占用；收尾单独设阶段，列出移交清单，明确验收标准与责任人。业财一体的设计让工时、成本与进度互相印证，哪一项失真要核对时，数据能对得上。收尾清单要具体到可以打钩：哪些资料要交、交给谁、以什么格式、由谁确认，写清楚了，末期就不会靠回忆推进。

这三条做法背后是同一个原则：项目管理管的是时间在不同主体之间的流转，而不是任务列表，而是时间在不同主体之间的流转。审批、交接、确认这些看似不产出成果的动作，恰恰是延误的高发区。把它们当成正式工作来设计——给时限、给责任人、给完成标准——进度才谈得上可控。

还有一条容易被忽略：让一线说真话。若报告延误就会被追责，现场就会倾向于把问题藏到无法再藏的那一天。把偏差当作需要共同处理的信号，而不是需要追究的错误，项目管理才拿得到真实数据；拿不到真实数据，再精细的模型也只是自我安慰。

项目总是延期，往往不是因为大家不努力，而是因为等待、变更、资源冲突、估算漏项和收尾塌陷这五处损耗被当成了常态。项目管理与项目管理系统把这些环节从“默认接受”变成“可测量、可干预”，进度才从愿望变成承诺。