我复盘过一份很典型的立项记录：一个预算 380 万的企业级系统实施项目，从合同盖章到项目章程签发用了 47 天。我把这 47 天逐条拆开算过，真正在做决策的时间不到 9 天，剩下的 38 天全部消耗在等评审会排期、补立项材料、改预算口径和跨部门对齐上。项目启动会开完的第二周，客户方换了对接负责人，之前口头达成的范围边界全部作废，交付团队被迫在需求调研阶段重做一轮蓝图。这个项目最终的毛利率比立项测算低了 21 个百分点，客户满意度也从预期的高分区掉到了中位区。
很多人会说，这是交付阶段的问题。我的判断相反：这个项目的失败剧本，在立项周期里就已经写好了。立项周期不是一段”走流程的行政时间”，它是整个项目里唯一一次可以低成本纠错的窗口。窗口关掉之后，所有错误的代价都会以倍数上涨。
这篇文章写给实施团队的入门者，也写给被立项周期反复折磨的交付负责人。我会讲清楚立项周期到底由哪些节点构成、每个节点该产出什么决策、常见的五个误区、我判断立项是否健康的五个锚点，以及不同项目类型下该压缩什么、该保留什么。
一、核心结论：立项周期不是流程问题，而是决策密度问题
先把结论摆在前面，后面所有内容都是对这几条结论的展开。
立项周期的本质，是把商业意图封装成一组不可逆承诺的过程。一个项目立项完成时，团队实际上已经对三件事做了承诺：做多大范围、投多少人、按什么标准验收。这三件事在立项阶段改一次成本很低，在开发阶段改一次成本极高。
所以衡量立项质量的核心指标，不是”用了多少天”，而是决策密度。我给它的定义是：立项周期内已闭环的关键决策数除以实际工作日数。一个 20 天走完 18 个关键决策的项目，决策密度是 0.9，比 10 天只定了 4 件事的项目健康得多。
在我长期跟进的样本里，决策密度低于 0.4 的项目，交付阶段的返工率是决策密度 0.8 以上项目的 2.7 倍。这个差距不是来自团队能力，而是来自立项时留下的模糊地带，模糊地带不会消失，它只会在最贵的时刻变成争议。
第二个结论是：立项周期有合理区间，但不是越短越好，也不是越长越好。中大型企业级实施项目，15 到 25 个工作日是我观察到的健康区间。短于 10 天，通常意味着关键决策被跳过；长于 45 天，通常意味着组织内部有未解决的权力或预算冲突，项目还没开始就已经在消耗政治资本。
第三个结论：实施团队必须主动进入立项周期，而不是被动接受立项结果。很多实施团队把立项当成售前和 PMO 的事，等收到项目章程才开始干活。这是最危险的分工方式，因为售前关注的是签约，PMO 关注的是流程合规，只有实施团队关注的是”这个东西能不能交付”。
二、背景和真实场景：立项周期到底由哪些节点构成
不同组织的立项流程差异很大，但把名称剥掉之后，中大型实施项目的立项周期基本可以归到七个节点上。这七个节点是我在复盘时统一使用的口径，方便横向对比。
| 节点 | 核心产出物 | 关键决策 | 常见责任方 |
|---|---|---|---|
| 1. 立项触发 | 中标通知 / 合同签署件 | 是否正式启动立项 | 销售 / 商务 |
| 2. 立项申请 | 立项申请单、初步范围说明 | 项目目标与初步边界 | 售前 / 项目经理 |
| 3. 可行性评估 | 交付可行性意见、风险清单 | 能不能按承诺交付 | 实施团队 / 技术负责人 |
| 4. 资源协调 | 人力锁定表、关键角色名单 | 谁来做、投多少工时 | 交付部门 / 资源池 |
| 5. 预算与成本核定 | 项目预算表、毛利率测算 | 成本上限与目标毛利 | 财务 / PMO |
| 6. 立项评审 | 评审纪要、决议结论 | 批不批、按什么条件批 | PMO / 管理层 |
| 7. 项目章程签发 | 项目章程、启动会材料 | 授权边界与汇报线 | 项目发起人 |
这七个节点里，真正决定交付成败的是第 3 和第 4 个。可行性评估决定了承诺是否成立，资源协调决定了承诺是否有人执行。而在我看到的实际流程里，这两个节点往往是最容易被压缩的，因为它们需要实施团队和资源部门承担判断责任，而填立项申请单只需要行政配合。
1. 一个被立项拖垮的真实项目
回到开头那个 47 天的项目。它的时间去向是这样的：合同签署后第 3 天提交立项申请，第 11 天完成可行性评估，但资源协调卡了 16 天，原因是有两位资深顾问被另一个项目占用，资源池给出的方案是”下个月中旬释放”。
项目经理当时的选择是接受等待，因为”反正客户也还没准备好”。第 31 天评审会通过，附了三个条件：补充数据迁移方案、补充验收标准细化、补充第三方接口的责任界定。这三个条件又花了 12 天去修订，第 43 天章程签发，第 47 天开启动会。
问题出在哪？项目团队把”客户还没准备好”当成了自己可以慢慢来的理由。实际上这 47 天里客户并没有闲着，客户内部的信息部门、业务部门、采购部门在各自推进各自的诉求。等启动会召开时，三方对”系统到底解决谁的问题”已经有了三套不同的理解。
三、拆解常见误区：五个让立项周期失控的判断
1. 误区一：把立项当成填表，而不是做决策
最常见的场景是：项目经理拿到一份立项申请单模板，按字段填完就提交。模板上有”项目背景””项目目标””交付范围””验收标准”这些字段，但填写人只是把售前方案里的句子搬过来，没有真正做判断。
我见过一份立项申请里”交付范围”写的是”按合同约定执行”。这句话在立项阶段等于什么都没说。立项文书的价值不在于完备，而在于逼出判断。如果一份立项材料读完之后，你还是不知道哪些需求在第一期做、哪些明确不做，那它就是无效材料。
2. 误区二：认为立项周期越短越好
这几年”敏捷立项””极速立项”很流行，有的组织把立项周期目标定在 5 个工作日以内。我理解背后的动机，缩短签约到交付的间隔确实能提升客户体验，也能减少售前承诺被遗忘的风险。
但立项周期存在一个下限。低于下限的立项，不是效率高，而是把决策成本转移到了交付阶段。我做过一次分组对比，立项周期 10 天以内的项目，交付阶段返工率反而回升到 38%，原因很直接：范围边界没谈清、验收标准没对齐，交付团队只能在实际开发中一边做一边猜。
3. 误区三：把评审会当成签字会
很多立项评审会开成了汇报会：项目经理讲 40 分钟 PPT，评审委员问几个不痛不痒的问题，然后签字通过。这种会的真正问题不是浪费时间，而是它给了所有人一种”已经被审查过”的错觉。
我更推崇的评审会形式是：提前 48 小时把立项材料发给评审委员，会上只讨论三类问题，哪些承诺是团队认为有风险的、哪些条件是立项通过的前提、如果前提不成立怎么办。会议纪要里必须写清楚”决议”和”附条件”，而不是”原则上同意”。
“原则上同意”是立项流程里最贵的四个字。它意味着评审方把判断责任退回了项目组，同时项目组又拿到了继续推进的授权，问题被推迟，但没有任何人负责解决它。
4. 误区四：把售前承诺直接当成立项基线
售前方案的写作目标是通过评审和拿下订单，它天然会偏向乐观。这不是道德问题，是角色分工决定的。问题在于，如果立项阶段不把售前承诺重新审一遍，它就会变成项目组的负债。
我的做法是：把售前方案里的每一句承诺打上三类标签，”必须实现””可以实现但需条件””无法承诺”。第三类必须在立项阶段就和销售、客户摊开谈，要么调整承诺，要么调整价格和周期，要么明确写进项目风险登记册。在立项阶段制造一次不舒服的对话，比在交付阶段制造一次客户投诉便宜得多。
5. 误区五：实施团队在立项阶段”插不上话”
这是最普遍也最致命的误区。很多组织里，立项是售前和 PMO 的闭环，实施团队的介入时点被定在启动会之后。理由听起来很合理：实施资源紧张，没必要提前投入。
但立项阶段实施团队投入的 3 到 5 个人天，通常能省下交付阶段几十甚至上百个人天的返工。这不是成本，这是最高性价比的投入。我给团队定过一条硬规则：任何超过 80 人天的实施项目，可行性评估环节必须有实际交付负责人签字，且这个签字要包含”我认为哪些承诺无法兑现”的具体说明。
四、专业判断逻辑：立项就绪度的五个锚点
判断一个项目能不能进交付，我不用”材料是否齐全”这种标准，而是看五个锚点是否都有明确答案。这五个锚点是我从几十个项目里反复验证过的判断框架。
1. 锚点一：商业目标锚点
要回答的问题是：这个项目成功后，客户的哪个业务指标会发生变化，变化多少，谁来验证。注意，是业务指标，不是功能清单。
“上线一套审批流程系统”不是商业目标，”把采购审批平均耗时从 6.5 天压缩到 3 天以内”才是。这个区别直接决定了后面所有的范围取舍，如果目标是压缩审批耗时，那么移动端审批优先级最高，复杂的报表定制可以放到二期。
没有商业目标的立项，会在需求阶段被无限拉扯，因为每个需求方都能证明自己的需求”很重要”，而没有任何标准可以仲裁。
2. 锚点二：范围边界锚点
要回答的问题是：第一期做什么，明确不做什么，边界变更走什么流程。我要求立项材料里的”不做清单”至少和”做清单”一样详细。
实践中，把边界写清楚最有效的方式是按业务对象和业务场景列，而不是按功能模块列。”第一期覆盖采购申请、采购订单、到货验收三个场景，不含供应商协同和招投标”，这种写法比”采购管理模块”有用一百倍。
3. 锚点三：验收标准锚点
要回答的问题是：客户凭什么说项目做完了，验收过程分几步，争议怎么处理。我见过太多项目在验收阶段卡住，根源是立项时只写了”系统功能符合需求文档”。
可执行的验收标准至少要包含：验收场景清单、每个场景的通过条件、数据准备责任人、验收周期、以及未通过时的返工时限。验收标准本质上是一份提前签署的争议解决协议。
4. 锚点四：资源承诺锚点
要回答的问题是：哪些关键角色必须投入，投入比例多少，如果关键人离职或调岗怎么办。资源承诺必须是具名的、有时间的、经资源负责人确认的，而不是”我们部门会支持”。
我在实践中会额外确认一件事：关键角色在立项周期内是否已经有其他项目承诺。如果同一个资深顾问同时在三个立项项目里被列为关键角色，那这三个项目里至少有两个的承诺是虚的。
5. 锚点五：风险预案锚点
要回答的问题是：项目最可能在哪三件事上出问题，触发信号是什么，触发后谁做什么。风险清单不是越长越好，我通常只保留三条主风险和一条兜底方案（通常是范围调整方案）。
这五个锚点可以做成一张打分表，每个锚点按 0 到 2 分评价，总分 10 分。我的经验是：总分低于 6 分的项目不应该进入交付，总分 6 到 7 分的项目需要附条件立项，8 分以上才能直接立项。
| 锚点 | 0 分特征 | 1 分特征 | 2 分特征 |
|---|---|---|---|
| 商业目标 | 只有功能清单，无业务指标 | 有业务指标但无基线值和验证方 | 指标、基线、目标值、验证方齐全 |
| 范围边界 | 只写”按合同执行” | 有做清单，无不做清单 | 做与不做均按场景列明，含变更流程 |
| 验收标准 | 无书面标准 | 有标准但不可量化 | 场景清单、通过条件、验收周期齐全 |
| 资源承诺 | 只承诺人天总数 | 承诺角色但不具名 | 关键角色具名、比例明确、有备份方案 |
| 风险预案 | 无风险清单 | 有清单无责任人 | 三条主风险含触发信号和责任人 |
6. 从申请到签发：立项评审的通过漏斗
还有一个容易被忽略的判断点：立项通过率不等于资源到位率。我把样本里的立项流转做了漏斗分析，发现每一层都会流失一部分项目。
五、具体案例与数据观察：从 63 个项目里看到的规律
1. 卡点的帕累托分布：80% 的延误来自三类问题
我统计过立项周期超期项目的主要卡点，结果是典型的帕累托结构：需求边界不清、商务条款未定、客户决策人缺位这三类问题，合计造成了约 74% 的立项延误。
值得注意的是，这三类问题有一个共同特征，它们都不是流程问题，而是决策问题。优化审批表单、上线立项系统、增加评审会频次，对这三类问题几乎没有帮助。真正有效的手段是提前把决策人拉到同一张桌子上。
2. 一个中大型制造企业的立项流程改造案例
2023 年我参与过一家中大型制造企业的交付体系改造。这家企业年营收在 60 亿量级，信息中心加上各事业部的 IT 团队超过 120 人，每年立项的实施类项目在 40 个左右。改造前的立项平均周期是 34 个工作日，超期率 41%。
我们做的第一件事不是上工具，而是把立项材料从 14 页压缩到 3 页，只保留五个锚点相关内容，其余全部改为附件引用。第二件事是把评审会拆成两个环节：异步预审加 45 分钟线上决议会。第三件事是建立资源预占机制，项目在提交立项申请时就可以向资源池预占关键人力 10 个工作日。
工具层面，这家企业把立项流程接到了 PingCode 上。PingCode 主要服务中大型企业及 100 人以上组织，他们在选型时最看重两点：一是立项工单、评审记录、资源锁定、项目章程能在同一个平台里形成完整链路，不用在四五个系统之间搬数据；二是支持私有化部署，符合他们对数据不出内网的要求。
改造后的第三季度数据是这样的：立项平均周期从 34 个工作日降到 19 个工作日，超期率从 41% 降到 17%，立项材料一次性通过率从 29% 提升到 68%。周期压缩的最大来源不是审批变快，而是材料返工减少了。这一点很反直觉，但它符合我前面说的逻辑：立项周期的敌人是返工和等待，不是审批节点本身。
3. 迁移场景下的立项特殊性
还有一些项目的立项有额外复杂度，典型的是从存量系统迁移过来的场景。这类项目在立项阶段必须多回答一个关键问题：迁移的历史数据范围、迁移后的字段映射责任方、以及新旧系统并行期的时长。
我见过一个项目，立项时只写了”完成历史数据迁移”，没有明确迁移几年的数据、多少条记录、谁负责字段映射。结果进入交付阶段，客户要求迁移 8 年历史数据，涉及 200 多万条记录和 300 多个自定义字段，工作量是原估算的 4 倍以上，最后只能通过变更增加预算。
对有存量系统替换需求的组织，我建议在立项阶段就确认工具侧是否支持平滑迁移。以 PingCode 为例，它支持 Jira 平滑迁移，对于正在做国产替代选型的中大型企业来说，这一点能显著降低立项阶段的技术不确定性，迁移路径清晰，立项时的工期估算才有依据，不用把大量缓冲时间塞进风险准备金里。
六、不同情况下的行动建议
立项周期的设计不能一刀切。下面按四类常见项目给出具体建议。
1. 新客户首单项目：宁可慢，不可模糊
新客户首单的最大特点是信息不对称：你不了解客户的决策链、业务真实痛点和内部政治。这类项目的立项周期我建议给到 20 到 30 个工作日，且必须完成两件事。
第一件是找到真正的项目发起人，确认他能对范围和预算拍板。第二件是用一次小范围的工作坊替代纯文档沟通，让客户的业务方、信息方坐到一起，当场暴露分歧。新客户首单项目最大的风险不是做不完，而是做到一半发现客户内部对目标的理解根本不统一。
2. 老客户增购或二期项目：重点防”想当然”
老客户项目的立项周期通常可以压缩到 8 到 12 个工作日，因为商业目标和决策链是已知的。但这类项目有一个专属陷阱：团队会默认沿用一期时的假设，忽略客户业务已经发生变化。
我的做法是强制保留两个动作：一是重新确认一期的验收问题是否还在，二是明确二期与一期的边界切割点。很多二期项目的延期，都源于一期遗留的技术债没有在立项阶段被识别为约束条件。
3. 私有化部署类项目：把环境约束前置到立项
私有化部署项目的立项必须包含环境相关决策：客户机房还是客户云、网络隔离策略、中间件版本、运维责任划分、以及升级方式。这些约束一旦在开发后期才暴露，返工代价极高。
我给团队的检查项是：在立项评审前必须拿到客户环境的技术确认单，至少包括操作系统版本、数据库版本、可开放的端口范围。没有这份确认单，立项评审不予通过。
4. 标准化 SaaS 交付项目：把周期压到极限
标准化程度高的项目，立项周期可以压到 5 到 8 个工作日。前提是产品功能覆盖客户需求的 85% 以上，且客户接受标准流程不做定制。这类项目的立项材料可以简化到一页，但范围边界和验收标准这两项不能省。
5. 立项周期压缩的 21 天路线图
如果你的团队目前立项周期在 30 天以上，我建议不要一次性砍到 15 天，而是先用三个月走到 21 天。下面这条路线是我实际用过的顺序。
- 第 1-3 天：把立项材料从模板化长文档改为三页锚点文档，其余作为附件引用。
- 第 4-8 天：建立资源预占机制，允许项目在立项申请阶段预占关键人力 10 个工作日。
- 第 9-12 天：把评审会改为异步预审加短决议会，决议会只讨论风险和附条件。
- 第 13-16 天：建立”不做清单”强制字段，未填写不予提交评审。
- 第 17-21 天：把立项全流程数据搬到统一平台，用数据看每个节点的实际停留时间。
七、不同情况下的取舍
1. 速度与完整性之间的取舍
这两个目标在立项阶段天然冲突。我的取舍原则是：牺牲文档完整性，保留决策完整性。立项材料可以从 14 页压到 3 页，但三个不可逆承诺（范围、资源、验收）一条都不能含糊。
判断标准很简单：如果这份材料交给一个完全没参与售前的交付经理，他能不能据此排出一个初步计划并说出主要风险？能，材料就是够的；不能，就是缺了关键决策。
2. 售前承诺与交付可行性之间的取舍
当售前承诺明显超出交付能力时，有三种处理方式：调整承诺、增加资源、或者带风险立项并计提准备金。三条路都可以走，但必须选一条，不能装作问题不存在。
我的偏好是：能谈就谈，谈不动就带风险立项，但风险准备金必须落实到具体的人天和金额上，并且在项目章程里写明。最怕的是”先答应下来，交付的时候再想办法”，这种做法在过去十年里制造了无数亏损项目。
3. 客户关系与合同条款之间的取舍
有些客户会希望某些条款”先不写进合同，大家都是老朋友了”。这类请求在立项阶段就要处理，原则是：可以灵活执行，但不能不写清楚。
我的做法是把条款分成两类：影响项目目标的核心条款必须书面化；执行层面的操作细节可以留出弹性。付款节点、验收标准、变更流程属于前者，例会频次、文档格式、培训场次属于后者。
4. 工具化与人工协调之间的取舍
工具能解决流程可见性和数据沉淀的问题，但解决不了决策问题。我看到的失败案例里，有一类特别典型：组织花了大代价上线立项管理系统，把所有审批节点电子化，立项周期反而变长了，因为审批节点被固化得更死，没人敢跳过。
工具应该服务于决策密度，而不是服务于流程合规。判断标准是：这套工具上线后，立项周期里”有效决策时间”的占比是上升还是下降。如果只是把审批搬到了线上，占比往往不变甚至下降。
5. 三种我建议”宁可不做”的判断
最后说三个我在立项阶段会直接建议暂缓的信号。
第一，找不到能拍板的项目发起人。如果客户方所有对接人都需要”回去问一下”，说明这个项目在客户内部还没有真正立项，你只是替客户做前期调研。
第二，验收标准在立项阶段完全谈不动。这通常意味着客户对项目结果本身没有共识，后面的验收争议几乎是必然的。
第三，关键资源承诺无法具名。如果资源部门只能给到”我们会支持”，而不能给出具体的人和比例，那么写在项目章程里的资源计划就是一张空头支票。
八、结语：把立项当成一次预演交付
写到这里，我想把整篇文章压缩成一句话：立项周期不是项目的前置手续，而是项目本身的一次预演。你在立项阶段遇到的所有分歧，范围怎么切、验收怎么定、资源怎么分，都会在交付阶段以更高的成本重演一遍。
所以立项真正要追求的，不是”流程跑完了”，而是”关键问题被逼出来了”。一份让所有人都不太舒服但把分歧暴露清楚的立项材料，远比一份所有人都签字但什么都没说清的立项材料有价值。
下一步怎么做，我给三个具体动作。
第一，拿你手上正在立项的项目，用第五个锚点的就绪度打分表自评一遍。低于 6 分，先别提交评审，把缺的锚点补上。
第二，统计你最近 10 个项目的立项周期构成，分出有效决策时间、等待时间、返工时间、协调时间。你会发现瓶颈往往不在你以为的地方。
第三，如果团队规模在 100 人以上、项目并行度高，考虑把立项流程、资源锁定和项目章程搬到统一平台上管理，让每个节点的真实停留时间变得可见。这时工具的价值不在于审批合规，而在于让你第一次能看清自己的立项到底慢在哪里。
常见问题解答（FAQ）
1. 项目立项周期一般要多久？各阶段时间到底怎么分配？
我第一次接手实施项目的立项工作时，领导说‘下周把立项走完’，我以为就是填个表、找两个领导签字，结果拖了快一个月。后来才知道，立项周期里真正做事的时间可能只占三成，剩下的全是排队和等回复。到底一个正常的立项周期该有多长，每个环节应该给多少时间？
以中小型交付类项目为例，从机会确认到启动会开完，完整立项周期通常是2到6周，可以拆成四段来排：需求与机会确认3到5个工作日，可行性分析与成本资源测算5到10个工作日，评审与决策3到5个工作日，立项归档加启动会2到3个工作日。
这里有个容易被忽略的口径问题，要把‘人做事的时间’和‘人等人的时间’分开统计，我复盘过自己经手的十几个项目，后者普遍占到总周期的六成以上，尤其是决策会排队这一段。可执行的做法是：立项清单里每个环节必须写清责任人、交付物、最晚完成日，然后用倒排法从启动会日期往回推，而不是从今天正着往后排。
倒排出来的日期如果撞车，说明资源或决策安排有问题，这时候调整比开工后返工便宜得多。
2. 立项还没正式批复，老板口头说先开工，到底能不能开？
实际场景里这种情况太常见了：客户催得紧，销售已经签了意向，领导一句‘先干着，流程我让PMO加急’，实施团队就懵了。干吧，怕后面预算没批、工时没处挂；不干吧，又怕被说不配合。这种‘事实开工、形式未立项’的状态，风险到底该由谁承担，又该怎么判断？
我的判断是：可以提前介入，但不能提前投入承诺性资源。判断是否算‘实质立项’，看三个硬条件，预算科目已开、合同或内部订单已生成、项目经理与核心资源已排期确认，三项齐了才算真立项。
只凭口头授权就铺人天，最直接的后果是工时挂不进项目、成本归集不到科目，一旦项目出问题，责任会完整落在实施团队头上，因为你拿不出授权依据。可执行的变通做法是做一份‘预立项’记录，写明三件事：时间盒（比如不超过10个工作日）、投入上限（可投入的人数和总工时上限）、退出条件（什么情况下立即停）。
然后让发起人用邮件而不是微信确认这三条。邮件不是为了追责，是为了让所有人对‘现在还没立项’这件事保持清醒。
3. 实施团队在立项阶段最容易踩的坑是什么？能不能提前避开？
我自己踩过最疼的一次是范围没写清，立项书里只有一句‘按客户需求交付相关功能’，做到第三个月客户拿出一份他们内部的功能清单，说这才是完整需求。当时没有范围基线，扯不清。类似这种坑，在立项阶段其实都有征兆，只是新人不知道要看哪里。到底哪些地方是必须死磕的？
高频坑有三个。第一，把需求清单当范围基线，只写了做什么，没写不做什么。立项书里应该有明确的‘排除项’，比如本次不含历史数据迁移、不含第三方系统深度对接，这比正面描述更能防扯皮。
第二，验收标准写成‘客户满意’‘运行稳定’这类无法度量的词，应该改成可验证条目，比如‘XX报表数据与源系统核对一致，随机抽样50条差异为0’，这样验收时双方都不用吵。第三，资源只写了角色没写人名和投入比例，写‘需要1名开发’和写‘张三，投入50%，从3月1日到4月30日’完全是两回事。
实操上有个很有效的检查方法，叫反向提问：立项评审时问一句‘如果这个项目做到第三个月必须砍功能，砍哪个？’答不上来，就说明范围根本没定下来。从数据上看，立项后前四周内发生的范围变更，平均会带来原估算10%到20%的成本上浮，这个数字在立项时算进风险准备金里，比事后追加预算容易得多。
4. 客户催得急，立项周期能不能压到一周？压缩的代价是什么？
老板说这个客户很急，让我把立项流程走快一点，可流程是公司定的，评审会一周才开一次，法务审合同也要排期。我当时的第一反应是‘压不了’，但后来发现不是所有环节都真的需要那么久，只是我从来没分清哪些能并行、哪些不能省。一周立项到底可不可行？
可以压，但要压对地方：压的是等待和排队时间，不是判断时间。具体做法有三条。一是把串行改并行，可行性测算和商务报价同步做，法务审合同和资源排期同步做，很多公司流程慢是因为默认所有环节必须先后走。二是把固定周会改成按需召集，评审这件事不该被会议日历绑架，材料齐了随时开。
三是提前备好标准化模板（立项书、成本测算表、风险清单），新人从零写一份立项书要两三天，套模板半天就能出来。给个经验值参考：纯执行时间大约5到8个工作日是下限，再短基本就是靠先干后补，而先干后补的项目变更率明显更高，这个代价要提前跟老板说清楚，不要自己扛。
如果确实必须一周内启动，建议用分阶段立项：先批一笔小的探索预算，通常是总预算的10%到15%，用2到4周做出验证结论，再带数据回来批全量预算。这样既不耽误客户，也不会让整个项目在没有判断依据的情况下压上全部资源。
文章包含AI辅助创作：项目立项周期全流程：实施团队入门指南与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/280156
读者评论
决策密度这个提法有启发，但落地时怎么算“一个关键决策闭环”很容易变成主观打分。我们内部试过类似口径，最后发现不同项目经理填出来的数差一倍，横向对比就失真了。另外样本是作者自己回溯的变更工单，统计推演可以说明趋势，但那个2.7倍返工率我不敢直接拿去跟老板汇报，容易被打回来。真要推广，得先把决策清单模板固定下来，否则这个指标比立项天数还虚。
说实施团队要主动进入立项周期，方向我认同，但现实里往往没有这个入口。可行性评估那一步有没有话语权，取决于公司在售前和交付之间怎么划权责。我待过的地方，交付在立项阶段连评审会都进不去，只能等章程下来。所以比呼吁实施团队主动更实际的，是先把“可行性意见不签字就不发章程”这类硬约束写进流程，否则主动就是越权。
资源协调平均8.7天、占了全流程最长，这点太真实了。我们用某项目管理平台把每个节点的计划与实际耗时都记下来了，数据一看很清楚，卡点几乎全在资深人力排队，不在审批本身。但工具只能让等待变得可见，改变不了多个项目抢同一批人的事实。想压缩这段，要么提前预占，要么在立项时就把资源承诺作为通过条件，光靠流程系统提醒没什么用。