工作计划落地方案：PMO开展项目规划的制度设计案例解析

我最早做 PMO 是 2016 年，接手的第一件事就是写一份《项目规划管理办法》。那份文件我写了 32 页，含 9 个流程、6 张模板、4 张审批表，自认为逻辑闭环、滴水不漏。发布三个月后，我在一次项目例会上问在场的二十多个项目经理："谁能说出规划评审的准入门槛是什么？"没有人举手。又过了两个月，我在系统里统计了一下，真正按新流程提交过完整规划的项目占比是 17%，而变更登记率反而比之前更低了，因为大家干脆不登记了。

这件事让我得出一个反常识的判断：工作计划落不了地，绝大多数时候不是计划本身写得不好，而是制度没有回答"谁在什么时点、依据什么标准、做什么规划决策"这个问题。大多数 PMO 写的是"文档规范"，而真正需要的是"决策规则"。这篇文章我用一个脱敏的真实改造案例，把项目规划制度的设计逻辑、落地机制、取舍标准完整拆一遍，包括我在 18 个月里踩过的坑、用过的度量口径，以及制度怎么固化进项目管理平台才有生命力。

一、先给结论：项目规划制度的本质是决策规则，不是文档集合

我把话放在最前面：如果你现在手上的《项目规划管理办法》主要由"应提交哪些文档""文档应包含哪些章节""由谁审批"三部分组成，那它大概率会在半年内变成墙上的文件。这不是执行不力，是设计方向错了。

1. 我的核心判断：制度要解决的是"决策时刻"，不是"文档形态"

项目规划这件事，日常真正发生的不是"写文档"，而是一连串决策：这个需求要不要立项？同期五个项目谁先排资源？这个里程碑能不能承诺？范围加了两周，基线要不要改？谁有权拍板？

每一项决策都对应三个要素：触发条件、决策人、判断依据。制度的价值就在于把这三要素固定下来，让决策可预期、可复核、可追责。文档只是决策的副产品，不是目的。

我后来给自己定了一个检验标准：把制度文本里所有的"应提交""应包含"全部划掉，如果剩下的内容不足以支撑一场资源冲突会议的决策，那这份制度就是空的。

2. 三个可验证的结论

这套逻辑我在三家公司验证过，也跟十几位同行做过交叉访谈，结论比较一致：

• 结论一：制度强度必须匹配 PMO 定位。管控型 PMO 写赋能型制度，会失控；赋能型 PMO 写管控型制度，会被业务绕开。
• 结论二：规划深度必须分类分级。用同一套规划要求覆盖 10 人月的小项目和 300 人月的大项目，必然导致小项目"走形式"、大项目"不够用"。
• 结论三：制度落地靠嵌入，不靠宣贯。培训能解决"知不知道"，解决不了"做不做"。真正的杠杆在流程入口、工具字段、会议议程和考核口径。

这三条听起来平淡，但真正执行到位的不多。我在一次行业交流里做了个非正式小样本统计，12 家做过 PMO 制度建设的企业中，明确写了"项目分类分级标准"的只有 5 家，把分类标准写进项目管理系统必填字段的只有 2 家。

3. 什么叫"最小可用制度"

我现在做制度设计，会刻意追求"一页纸能说清主干"。不是内容少，而是主干必须能压缩成一页，细节放附录。判断标准很简单：一个新入职的项目经理，看完这一页能不能独立完成一次立项判断和一次变更申请。

如果看完一页还是不知道怎么判断，说明主干没提炼出来，制度就还有继续长的空间，而越长的制度，被执行的概率越低。

二、真实场景：一份"完美工作计划"是怎么在三个月内失效的

下面这个案例我做了脱敏处理，代号 A 公司，工业软件行业，全员约 1200 人，其中研发和交付约 700 人，常态并行项目 45 到 60 个，横跨 3 个事业部。文中数据是脱敏后的区间值，部分指标是我根据当时台账重新核算的，标注为"脱敏区间"。这不算精确统计，但足以说明趋势。

1. 表面问题：计划表很漂亮，项目还是乱

我进场时看到的第一个材料，是一份做得非常漂亮的组合计划表：甘特图、资源直方图、里程碑看板、风险矩阵，一应俱全。每个项目的计划都至少有 40 行 WBS 任务。

但当我随机抽 8 个项目做回溯时，发现了一个尴尬的事实：这 8 个项目的实际执行路径，和当初提交的基线计划平均偏离了 3 个以上里程碑，而系统里记录在案的变更申请只有 2 条。也就是说，计划是纸面的，变更是不记录的。

2. 冲突爆发的三个时间点

我复盘了当时的会议记录和工单，冲突集中爆发在三个场景：

1. 季度初的资源排布会。三个事业部同时声称某个骨干架构师"已经在我的项目上"，而项目管理系统里他同时挂在 4 个项目上，没有投入比例。
2. 月度经营会前两天。销售承诺的交付日期和交付团队承诺的日期，连续三个月对不上，原因是销售用的是"合同口径"，交付用的是"排期口径"，两套语言。
3. 每季度的复盘会。每个项目都说"延误是因为需求变更"，但没人能拿出变更量化的数据，最后变成互相指责。

这三个场景的共同点是：没有人缺努力，大家缺的是同一套判断依据。

3. 根因不是执行力，是四项设计缺失

我当时的诊断结论是四项缺失，后来在很多公司反复见到同样的组合：

三、拆解误区：PMO 做项目规划制度最容易踩的六个坑

这六个坑我基本都亲自踩过，或者作为外部角色目睹过全过程。它们的共同点是：在制度设计的当下看起来很合理，在执行半年后才暴露问题。

1. 误区一：把模板当制度

我见过最厚的一份"制度"实际上是 11 张 Excel 模板加一句"各项目按此填报"。问题在于模板只定义了"填什么"，没有定义"什么时候填、不填会怎样、填错了谁负责"。

我的判断：模板是制度的产物，不是制度的替代品。先写清决策规则，模板自然能推导出来；反过来先做模板，最后一定退化成填表运动。

2. 误区二：把审批当管控

很多制度的实际形态是"加一层审批"。立项要审批、排期要审批、变更要审批、结项要审批。审批节点一多，业务方的应对策略不是更规范，而是在提交前把所有东西做得表面合规，真正的问题藏在审批之后。

我自己的经验：一个项目从立项到基线建立，正式审批节点不要超过 3 个。超过 3 个，就要问一句"这个节点拦住的到底是什么风险，如果拦不住，能不能改成事后抽查"。

3. 误区三：PMO 定位含糊，制度里同时写"管控"和"赋能"

这是最隐蔽的坑。制度文本里一边写"PMO 有权暂停项目"，一边写"PMO 为项目提供方法支持与教练服务"，两种定位同时出现，执行时就会精神分裂，项目经理不知道你是裁判还是教练，于是既不敢暴露问题，也不愿向你求助。

我现在的做法是：定位只选一个为主，另一个作为例外清单明确列出。比如"以赋能为默认，仅对 A 类项目行使管控权"，这句话必须写进制度第一节。

4. 误区四：规划深度一刀切

前面已经说过，这里补充一个具体细节。A 公司最初的模板要求每个项目都要做"完全量化的风险概率与影响评估"，结果 40 万的小项目也填了 6 个风险项，全是"需求不明确""人员流动"，没有任何区分度。当所有项目填写的内容都一样时，这份数据就失去了筛选功能。

5. 误区五：工具替代管理

有一类公司特别喜欢上线"项目管理平台"来解决问题。工具确实重要，但工具是制度的执行载体，不是制度本身。没有决策规则就上线工具，只会把混乱搬到线上，并且让混乱变得更难改。

我见过上线工具后指标不升反降的情况，原因很简单：工具把流程变得更"可见"，原本模糊地带的操作被强制暴露，但没有配套的决策规则，冲突反而提前爆发了。

6. 误区六：没有度量，制度价值无法自证

PMO 最常见的困境是"说不清自己创造了什么价值"。解决办法不是写总结报告，而是在制度设计阶段就定义好度量口径，并且保证数据能从系统里自动取出来。

我现在会把度量分成三类：过程指标（规划覆盖率、评审及时率）、质量指标（基线变更率、返工工时占比）、结果指标（按期交付率、资源冲突次数）。每类不超过 3 个，多了必然没人看。

四、专业判断逻辑：一套可复用的四层制度结构

我把项目规划制度拆成四层，从下往上依次是定位层、分类层、规则层、嵌入层。这个顺序不能颠倒，先建规则再嵌入，顺序反了就是返工。

1. 第一层：定位层，先回答 PMO 是哪种角色

三种典型定位，对应的制度强度完全不同：

我自己最推荐混合型，前提是分类标准必须可判定、无争议。如果分类标准需要开会讨论才能定，那这个标准还不能用。

2. 第二层：分类层，项目分级决定规划深度

我用的是四分级：A 类（战略级，跨事业部或合同额超阈值）、B 类（重点项目，单事业部内关键交付）、C 类（常规项目）、D 类（小微改进类）。分类维度建议用三个就够了：影响范围、投入规模、风险等级。维度超过三个，判定就会开始扯皮。

每一级对应的规划要求差异巨大，我在 A 公司落地的配置如下（这些数字是我们的实践值，不是行业标准）：

这套配置最直接的效果是：C、D 类项目的规划成本下降，项目经理不再抵触；A 类项目的规划深度上升，关键风险提前暴露。

3. 第三层：规则层，六个必须写清的模块

规则层是制度的实体部分。我把项目规划制度拆成六个模块，少一个都会在半年内出问题：

1. 分类分级与规划深度映射：哪一级项目要做多深的规划，判定标准是什么。
2. 规划入口与优先级机制：谁可以提报项目，优先级排序依据什么，冲突时怎么裁决。
3. 规划内容标准：目标、范围、WBS、里程碑、资源投入比例、预算、风险，每一项的最低要求是什么。
4. 角色与权责（RACI）：谁提报、谁审核、谁批准、谁维护，必须逐项明确到岗位。
5. 评审与决策机制：评审要素、准入门槛、会议频次、决策记录形式。
6. 基线与变更管理：基线何时建立、变更如何分级、例外如何处理。

这六个模块里，我最想强调的是第 6 个。没有基线概念的项目规划，本质上只是一份意向书。基线建立意味着"从这个时点起，偏离需要有正式记录"，这是后续所有度量的基础。

4. 第四层：嵌入层，四个嵌入决定制度能不能活

规则写完只是开始。我总结的落地机制是"四个嵌入"：

• 嵌入流程入口：立项、规划、评审、变更走同一个入口，不允许存在平行的"特殊通道"。一旦有一条通道可以绕过，三个月内所有人都会走那条。
• 嵌入工具字段：分类级别、投入比例、基线日期、变更类型，必须在项目管理系统里是必填字段，不填无法流转。
• 嵌入会议议程：经营会、项目例会、复盘会使用同一套术语和同一张数据看板。会议语言统一，比培训十次有效。
• 嵌入考核口径：不建议直接考核"计划准确性"，那会诱导虚报。建议考核规划覆盖率和变更登记率这类过程指标，它们更难作假。

五、案例解析：A 公司从"救火"到"规划治理"的 18 个月

这一节我把 A 公司的改造过程按四个阶段拆开。需要说明的是，这不是一个"成功学"案例，第 4 个阶段我们仍然有很大阻力，有些问题至今没有完全解决。

1. 阶段一：诊断（第 1-2 月），先把数据取出来

我做的第一件事不是写制度，而是从现有系统里把过去 12 个月的项目数据导出来，重新计算了四个口径：按期交付率、变更登记率、资源冲突工单数、返工工时占比。

这一步的价值在于：它把"大家觉得乱"变成了"具体哪里乱、乱到什么程度"。当我拿着 54% 的按期交付率和 19% 的变更登记率走进会议室时，讨论的起点就从"要不要做制度"变成了"先解决哪个数字"。

（1）数据口径必须当众确认。不同部门对"按期"的定义不同，是"合同日期"还是"内部排期"，一定要在会上定死。
（2）不要追求完美数据。当时我的返工工时占比只有 60% 的样本可靠，我直接标注了"样本覆盖 60%"，反而没人质疑。

2. 阶段二：试点（第 3-6 月），选一个"输得起"的试点

试点选择上我踩过一次坑。最初想选最重要的 A 类项目做试点，被事业部负责人直接否了：万一试点失败，损失太大。

后来改成选 6 个 B、C 类项目试点，覆盖 2 个事业部。试点项目的选择标准应该是"改进空间大、政治风险低"，而不是"最重要"。这一点很多人搞反了。

试点期间我们只做了三件事：

1. 建立分类分级标准，并在系统里加了一个必填的"项目级别"字段；
2. 对 A、B 类项目强制执行规划评审，评审要素不超过 8 项；
3. 建立基线概念，变更必须登记，登记流程压缩到 3 步以内。

3. 阶段三：推广（第 7-12 月），阻力主要来自中层

推广阶段的阻力来源，跟我最初预判的完全不一样。我以为阻力会来自一线项目经理，实际统计下来，阻力最集中的是事业部的中层管理者。

原因也很清楚：新制度要求资源投入比例透明化，而资源不透明恰恰是中层在多项目之间腾挪的空间。制度一旦透明，他们的调度自由度就下降了。

我们的应对不是压服，而是做了两件事：

• 把"资源冲突次数"作为事业部层面的正向指标，冲突提前暴露是好事，不是坏事，帮中层把这件事重新定义。
• 在中层最关心的"交付日期承诺"上，给了他们清晰的依据链条：因为有了基线，销售再压交期时，他们可以拿出数据说"不"，而不是靠吵架。

第二条特别有效。让制度成为管理者的谈判工具，而不是约束工具，推广阻力会明显下降。

4. 阶段四：固化（第 13-18 月），把规则写进系统

最后 6 个月的核心工作是把规则固化进工具。我们做了三件事：字段必填化、审批流与制度条款一一对应、看板自动出度量数据。

这个阶段最容易被忽略的是"数据自动可取"。如果每个月的度量数据还需要人工整理三天，这个度量体系一定活不过半年。

5. 结果与复盘：哪些做对了，哪些到现在还不行

做对的三件事：分类分级解决了"一刀切"、评审要素压缩到 8 项保证了会议能开完、度量数据自动可取保证了复盘能持续。

到现在仍然不理想的：D 类小微项目的规划登记率长期在 60% 左右徘徊，因为这类项目太碎，登记的成本感很强。我们最后的结论是接受这个数字，而不是继续加码管控。制度设计里必须有"接受不完美"的空间，否则会为了 5% 的边缘场景消耗掉 50% 的管理成本。

六、工具落地：制度怎么固化进项目管理平台

前面说"工具不能替代管理"，但这不等于工具不重要。恰恰相反：没有工具支撑的制度，最后一定会退化成靠人盯人执行，而人盯人的成本随规模线性上升。

1. 为什么制度必须"代码化"

A 公司改造过程中最明显的一个转折点是：我们把"项目级别"设成了必填字段，且不同级别触发不同的审批流。这个动作上线后的第一个季度，规划评审覆盖率从 22% 直接拉到 91%，比之前三次宣贯加起来的效果都强。

原因很朴素：制度写在文档里是"建议"，写在系统字段和流转规则里是"约束"。人要绕过文档很容易，要绕过系统就很难，因为绕过的成本从"忽略"变成了"另找路径"。

这也是我在做工具选型时最看重的能力：能不能把制度规则配置成系统规则，而不是靠人记。这个能力比界面美观重要得多。

2. 中大型企业的四个硬指标

我服务过的企业多数在 100 人以上，有的超过 3000 人。这个规模区间选项目管理平台，我通常看四个硬指标：

以 PingCode 为例说明具体形态。PingCode 主要服务中大型企业及 100 人以上组织，在这四个维度上的匹配度比较高：工作项与流程可配置，能按项目级别挂不同的必填字段和流转规则；支持私有化部署，满足数据不出内网的要求；同时也支持从 Jira 平滑迁移，这对于原本使用海外工具、现在需要做国产替代的团队来说，是比较现实的路径。

我个人的判断是：100 人以下、流程规则简单的团队，工具选择的权重可以低一些；但超过 100 人、且存在多事业部或多条产品线的组织，工具的流程配置能力和迁移能力应该排在选型的前两位。原因很直接，这个规模下，制度的执行已经不可能靠人盯人，只能靠系统承载。

3. 制度条款到系统字段的映射示例

很多 PMO 卡在"制度怎么落到工具里"这一步。下面是我用过的映射方式，可以直接改成配置清单使用（示例为配置结构示意，非某平台的实际语法）：

项目级别字段（必填，单选）

A类战略级 → 触发流程：规划评审流-A（3 级审批）

B类重点级 → 触发流程：规划评审流-B（2 级审批）

C类常规级 → 触发流程：规划评审流-C（1 级审批 + 事后抽查）

D类小微级 → 触发流程：无需评审（仅登记）

规划必备字段（按级别动态必填）

目标与成功标准 A/B/C 必填，D 选填

WBS 或任务分解 A/B 必填，C 选填，D 免填

里程碑与基线日期 A/B/C 必填，D 免填

资源投入比例 A/B/C 必填（人力以人月计），D 免填

风险清单与应对 A 必填（至少 5 项且需量化），B/C 选填

预算 A/B 必填，C/D 免填

变更管理规则

变更类型 = 范围变更 且 影响人月 > 20 → 需 PMO 审批

变更类型 = 基线日期变更 且 影响里程碑 > 1 个 → 需 PMO + 事业部审批

变更类型 = 内部任务调整 → 自动登记，无需审批

这张映射表的价值在于：它把抽象的"分级管理"变成了可以配置的规则，也让项目经理第一次清楚地知道"我这类项目到底要交什么"。制度能不能落地，很大程度上取决于这个问题有没有明确答案。

4. 迁移和上线阶段的三个提醒

（1）不要在新工具上复刻旧制度的全部复杂度。迁移是清理历史包袱的最好时机，我通常会砍掉 30% 以上的冗余字段。
（2）迁移前先冻结一次口径。历史数据里的"按期交付"定义往往和新制度不同，直接迁移会污染指标基线，建议在迁移报告中明确标注断点。
（3）上线后第一个月必须有人盯。工具上线的前 30 天是习惯形成的窗口期，这期间的执行率决定后面两年的基线。

七、不同情况下的行动建议

制度设计没有通用答案，但有比较明确的"按规模选路径"的逻辑。下面四档是我在不同规模组织里验证过的做法。

1. 50 人以下：不要叫制度，叫约定

这个规模的项目数量通常不超过 15 个，靠周会和一张共享看板就能管住。写正式制度的投入产出比很低。

我的建议是：只做三件事，确定项目优先级排序规则、确定资源投入比例的登记方式、确定变更必须留痕。形式可以是一页纸的团队约定，甚至是一张共享表格。这个阶段的核心是养成留痕习惯，而不是规范文档形态。

2. 50-300 人：混合型 PMO + 分类分级

这是最需要制度化的一档。项目数通常在 20 到 80 之间，靠个人记忆已经管不住，但还没到需要重型流程的程度。

建议路径：先做四分级（可以先做三级），A、B 类强制评审，C、D 类登记即可；同时上线一个支持流程配置的项目管理平台，把级别字段和审批流配好。这一档的关键成功因素是分类标准足够简单，简单到项目负责人能自己判断。

3. 300 人以上或多事业部：先解决口径统一，再谈流程

这个规模最常见的问题不是流程缺失，而是不同事业部对同一个指标的定义不同。我见过一个公司，研发的"按期交付"指内部里程碑，交付部门的"按期交付"指客户验收，两个数字差了 20 个百分点，在同一个会上讨论了半天才发现说的不是一件事。

建议顺序：先统一 3 到 5 个核心指标的口径并写进制度，再推流程分级，最后才做工具固化。口径不统一就推流程，等于给混乱加了一层流程外壳。

4. 强监管或涉密场景：私有化部署是前置条件，不是加分项

金融、军工、医疗、政务以及部分工业软件交付场景，数据出内网这条红线直接决定工具可选范围。这类组织在选型时，应该把"是否支持私有化部署"作为筛选条件而不是评分项，先过筛再比较其他能力。

同时，这类场景的规划制度通常需要额外覆盖：审计留痕、变更的合规审批链、文档版本的可追溯性。制度文本会比常规企业厚 30% 到 50%，这是必要的成本，不建议压缩。

八、不同情况下的取舍

制度设计本质是一连串取舍，没有"全都要"的选项。我把最常遇到的四组取舍列出来，附上我的选择和理由。

1. 管控强度 vs 执行效率

这是最根本的一组。管控越强，执行效率越低，但基线越可靠。我的选择是：对 A 类项目接受效率损失换取可靠性，对 C、D 类项目接受一定的不确定性换取效率。

具体到操作上，我通常会把正式审批节点控制在项目总数的 20% 以内，也就是说，80% 的项目走轻流程。如果超过 40% 的项目需要走完整审批，制度一定过重了。

2. 制度完备性 vs 上线速度

PMO 很容易陷入"再完善一版再发布"的循环。我的经验是：第一版制度覆盖 80% 的常见场景就够了，剩下的 20% 用例外处理机制兜住。

原因在于制度是长出来的，不是设计出来的。你不发布，就永远拿不到真实反馈；而真实反馈的价值远高于多写两章推演。

3. 自建 vs 采购

我很少建议自建项目管理平台，除了两种情况：组织有极强的定制需求且已有成熟的研发团队，或者业务本身就有对外销售工具的计划。

其余情况，采购成熟平台更划算。自建的隐性成本主要在维护和迁移上，三年后的总拥有成本通常是采购方案的 2 到 4 倍。而且自建平台往往会和某几个人的知识绑定，人一走，系统就开始僵化。

4. 私有化 vs 云部署

取舍标准很清晰：看数据敏感度和合规要求。涉及客户交付数据、代码资产、涉密信息的，私有化优先；纯内部协同且无敏感数据的，云部署更省事。

这里有一个容易被低估的因素：私有化部署虽然前期投入高，但对于原本使用海外工具、现在需要做国产替代的团队，如果能同时提供平滑迁移能力，总体切换成本会被显著摊薄。这也是我在做国产替代建议时会重点确认的一项能力，迁移不只是数据搬运，还包括历史项目的工作项结构、状态流转和权限关系能否对应上。

九、落地检查清单与下一步

最后给一份可以直接拿去自查的清单。这 12 条我在每次制度复盘时都会过一遍，每一条都能答"是"的，制度大概率能活下来。

1. 十二项自查清单

1. 项目是否已经分类分级，且分级标准不超过 3 个维度？
2. 不同级别的规划深度是否有明确的差异要求，而不是同一张模板？
3. 是否定义了资源投入比例，并作为必填信息记录？
4. 是否有明确的立项优先级裁决规则，以及裁决人？
5. 规划评审的要素是否控制在 8 项以内，能否在 2 小时内开完？
6. 是否建立了基线概念，基线日期是否在系统中可见？
7. 变更是否分级，不同级别的审批路径是否不同？
8. 制度条款是否已经映射为系统中的必填字段和流转规则？
9. 经营会、项目例会、复盘会是否使用同一套术语和同一张数据看板？
10. 核心度量指标是否不超过 8 项，且能自动取数？
11. 考核指标是否避开了"计划准确性"这类容易被诱导造假的指标？
12. 是否明确了例外处理机制，允许 20% 的场景不走标准流程？

2. 我的独特观点：制度的成功标志是"没人讨论它"

写到这里，我想给出一个可能不太讨喜的判断：一套项目规划制度真正成熟的标志，是它不再被讨论。

当"项目级别怎么定""变更要不要审批""资源比例谁来填"这些话题消失在会议里，变成大家默认的操作，制度才算真正落地。反过来，如果每季度还在开会讨论制度的执行细节，说明它仍然停留在纸面上。

这也是为什么我一直强调"嵌入"重于"宣贯"。宣贯需要反复进行，嵌入只需要配置一次；宣贯的效果随时间衰减，嵌入的效果随时间固化。

3. 下一步怎么做

如果你正准备启动这件事，我建议按这个顺序走：

• 第一步，先取数。把过去 6 到 12 个月的项目数据导出来，算出按期交付率、变更登记率、资源冲突次数三个口径。没有基线，后面所有改进都无法证明。
• 第二步，做分级。用影响范围、投入规模、风险等级三个维度，把项目分成 3 到 4 级，然后为每一级定义规划深度。这一步不需要工具，一张表格就能完成。
• 第三步，压缩评审。把评审要素砍到 8 项以内，先跑两个月，看会议能不能按时结束。评审开不完，制度必然推不动。
• 第四步，固化进工具。把级别、投入比例、基线日期设成必填字段，让不同级别触发不同流程。这一步做完，执行率通常会有一次明显跃升。
• 第五步，设度量并固定复盘节奏。每月看一次过程指标，每季度看一次结果指标，坚持满四个季度再判断制度是否有效。

最后提醒一句：不要在第 4 到第 6 个月做结论。从我和同行的实践来看，过程指标半年内会有改善，但返工、交付质量这类结果指标通常滞后两个季度以上。在这个窗口期放弃，是项目规划制度最常见的死法。