新项目启动前，领导真正要做的那件事

会散了，纪要上写着三个项目全部通过。

设想一家设备维修服务企业，同一个季度要上三件事：客户自助查询入口、备件配发改善、维修进度提醒。提案都站得住，总经理当场表态支持，各部门自行协调。

问题在那张资源表上。三项提案都要用同一位熟悉订单数据的IT同事，方案里各写一句“兼职支持”，分开看都不多，合起来没人算过总数。

名义上拿到了三个新项目，实际上是把一次没做完的选择，交给了后面那场没人负责的排期会。支持改善，多数时候并不是多批几个提案，在承诺交付之前，领导者要先把选择做完。

第一件事，把提案从方案语言改回客户语言。

他不看方案名称，名称越完整，追问越具体。只问三句话：

这几句话立刻把三份提案分开了。客户反复来电，可能因为查不到进度，也可能因为维修本身迟迟不能完成。加查询入口和缩短等待时间，解决的是两个问题。答不出证据就写“未知”，再写清补哪类记录能补上。

还有一道容易跳过的动作，统一比较的范围。先提出一个最小但有意义的范围，范围不同，比较就是假的。

最后一条最见分量。他自己提的方案，也照填同一张表。

第二件事，把新增占用和放弃项写在纸上。范围定了，接下来的问题是它要占谁的时间。

先划基本盘。安全、合规、核心系统维护、已承诺的服务，这些能力要先扣掉，顺序不能倒。基本盘也要说明依据，别拿“维持运作”掩盖扩张意图。

成本低的方案不自动优先。只改善表面体验的投入，最后是用客户的等待时间付账。放弃项最难写，也最有价值：暂缓是等，放弃是这笔能力要挪去别处。

第三件事，在同一约束下比较少数几项。放弃项写出来了，接下来才是排先后。

比的时候不比总分。打分表看起来客观，权重一调，结论就能换一个。他只问：

这三份提案抢的是同一位分析师的一段时间。那就把这一个月摆在桌上比，谁在这个月里能带来最明确的客户变化，谁先拿。其他人的方案不是不好，是这一个月不该给它。

同一把尺子还要求同一个时间尺度、同一个需求假设。年度建设不能拿一年后的想象比一个月的实效，一个按满负荷、一个按保守值，结果也没有意义。

依赖最容易被漏掉。前置数据没整理、系统对不上，这些没人写，就会在批准之后变成“项目推进不顺”，再变成下一次会上互相指责。依赖要在提案里分两类写：这次一并解决的，和未解但必须算进投入的。

一次只比两三件。候选一多，比较就滑向排队，排队的结果是谁的理由写得最急，谁先上。

第四件事，公开启动与不启动。比较的结果必须当场说出口。

哪些启动，哪些暂缓，哪些这一轮不做，一条条说清，理由记在纪要里。没说清的默认不启动。

暂缓的项写明复看条件和日期。没有条件和日期的暂缓等于悄悄取消，提案人几个月后才发现白等，下一轮也没人愿认真提案了。

他亲自去向没排上的团队解释机会成本，最好一把手开口。谈得清楚，团队下次会来比谁的问题定义更实；谈含糊，下次会来比谁的理由更急。

获准启动，赞成的是一项提案在某一阶段占用的资源，不是把这条线永久排在前面。项目拿了资源，就有责任在下一次比较时重新证明自己。

很多改善推进到中途失速，根子在早期的承诺被当成永久优先权。情况变了没人敢动它，更重要的问题只能继续排队。

说到底，让改善真正动起来靠的是取舍做得更实，而不是批准得更多。