为什么许多项目在开始执行前就失败了
2 分•作者: BenWebbProject•6 个月前
在各类项目中——基础设施、数字系统、组织变革——我注意到一个反复出现的模式:当执行开始时,结果往往已经受到限制。
这并非因为无能或恶意,而是因为早期的决策往往比理解更早固化。
以下是一些似乎重复出现的观察:
早期的时间表成为社会事实
最初的时间表通常是在信息有限的情况下制定的,但一旦向上级分享,它们很快就不再是临时的。它们成为资金、声誉和信心的锚点。后来的证据被迫适应日期,而不是日期根据证据进行调整。
风险被记录而不是被管理
风险登记册通常是全面而真诚的,但记录风险的行为可以替代实际改变决策。解决某些风险需要重新审视范围、顺序或假设——这通常被视为不稳定而不是负责任。
治理过滤现实
报告结构倾向于优化以获得安心。坏消息被延迟或软化,并非出于恶意,而是因为它在没有解决方案的情况下感觉没有建设性。当问题清晰浮出水面时,剩余的选择通常是昂贵的或二元的。
复杂性被推迟,而不是被降低
早期的批准倾向于奖励简单性。接口、依赖关系和操作约束被最小化以推动事情进展。复杂性并没有消失——它只是在以后出现,那时灵活性最低。
令我印象深刻的是,许多项目与其说是“出错”,不如说是从它们所建立的假设出发,这些假设往往从一开始就是错误的,并在此基础上合乎逻辑地进行。
查看原文
Across different types of projects — infrastructure, digital systems, organisational change — I’ve noticed a recurring pattern: by the time execution starts, the outcome is often already constrained.<p>Not because of incompetence or bad intent, but because early decisions tend to harden faster than understanding does.<p>A few observations that seem to repeat:<p>Early schedules become social facts
Initial timelines are usually created with limited information, but once shared upward they quickly stop being provisional. They become anchors for funding, reputation, and confidence. Later evidence is forced to fit the date, rather than the date adjusting to evidence.<p>Risk is recorded instead of managed
Risk registers are often thorough and sincere, but the act of documenting risk can substitute for actually changing decisions. Addressing certain risks would require revisiting scope, sequence, or assumptions — which is often seen as destabilising rather than responsible.<p>Governance filters reality
Reporting structures tend to optimise for reassurance. Bad news is delayed or softened, not out of malice, but because it feels unconstructive without a solution. By the time issues surface clearly, the remaining options are usually expensive or binary.<p>Complexity is deferred, not reduced
Early approvals tend to reward simplicity. Interfaces, dependencies, and operational constraints are minimised to get things moving. The complexity doesn’t disappear — it just shows up later, when flexibility is lowest.<p>What’s struck me is that many projects don’t so much “go wrong” as proceed logically from the assumptions they were built on - which were often incorrect from the outset.