项目名称落地方案：管理层开展项目立项的落地方案案例解析

我见过代价最高的一次立项事故，不是发生在评审会上，而是发生在项目名称上。2023 年，一家约 400 人的制造企业里，两个事业部各自立项了一个名字只差两个字的新品开发项目，立项台账合并时被财务当成了同一个项目，预算合并、资源合并、汇报口径合并，最后两条本该并行的技术路线互相踩踏，产品上市晚了 11 个月，多烧掉的直接预算是 260 万。事后复盘，所有人都盯着流程审批节点，没人回头看那张立项台账里的名称字段。

《项目名称落地方案：管理层开展项目立项的落地方案案例解析》这个题目听起来像是行政规范问题，但我在过去几年做的十几个中大型组织的立项治理项目里，反复验证了一个判断：项目名称不是命名问题，它是立项方案能不能落地的最小颗粒度抓手。名称一通，预算、工时、里程碑、复盘数据才能串成一条线；名称一乱，再漂亮的立项流程也只是一叠签了字的纸。

这篇文章我会用第一人称，把三次真实的立项落地案例拆开讲，包括失败的那两次，以及最后跑通的那一次用什么工具、什么规则、什么节奏落地的。如果你正在给 100 人以上的组织设计立项方案，或者正准备从老系统迁到新的项目管理平台，这篇内容可以直接当作施工图用。

一、核心结论：立项方案落地的第一道坎，是项目名称的治理

先把结论摆在前面，省得你看到一半才发现方向不对。管理层做立项方案，最容易高估流程的价值，低估标识的价值。流程决定项目能不能被批准，标识决定项目能不能被管理。批准是一瞬间的事，管理是几十个月的事。

1. 立项方案落不了地，通常不是流程问题

我参与过一家金融科技公司的立项流程重设计，评审会从 3 次压缩到 1 次，审批周期从 14 天降到 4 天。半年后回访，项目延期率反而上升了 9 个百分点。原因很直接：审批快了，立项数量从年均 47 个涨到 132 个，但项目库里开始出现大量”某某系统二期””某某平台优化””2024 年数据治理项目”这样模糊的名字，PMO 想拉一张跨项目资源占用表，光是对齐名称口径就花了三周。

换句话说，流程效率的提升，会被标识失序带来的管理成本全部吃掉，甚至倒亏。这是我在多个组织里反复看到的规律。

2. 在管理层视角里，项目名称其实是”资产编号”

很多管理者把项目名称当成一个给人看的标签，这是认知偏差。在我看来，项目名称在管理层视角下承担三重身份：对外的沟通标签、对内的资产编号、对系统的数据主键。三重身份里，只有第三重是刚性的，一旦项目名称在项目管理平台里作为唯一标识，它就直接决定了预算能不能挂上去、工时能不能归集、结项时能不能反向聚合历史数据。

所以管理层在立项方案里对名称的态度，本质上是他们对自己资产账本的态度。我见过一家企业的高管在会上说”名字无所谓，反正大家都知道是哪个项目”，两年后这家企业在做事业部利润核算时，发现 30% 的研发投入无法准确归集到具体项目，财务只能按部门平均分摊。这不是财务能力问题，是标识治理缺位。

3. 一个可以自我验证的判断标准

你可以用下面这个标准快速判断自己组织的立项落地方案成熟度：随机抽 20 个项目名称，交给一位不参与该项目的中层管理者看，如果他能在 30 秒内说出每个项目所属业务线、年度批次、项目类型，说明标识层是健康的；如果超过 5 个需要追问，说明你的立项方案还停在纸面。

这个标准我在四家不同规模的组织里试过，预测准确率相当高，命名规范度低的企业，项目延期率和预算偏差率几乎同步偏高。

二、背景与真实场景：三次立项落地的一手复盘

抽象结论说完了，接下来讲具体的。下面三个场景都是我亲自参与的项目，第一个和第二个是失败的，第三个跑通了。我把失败案例放在前面，因为它们的教训比成功案例更有迁移价值。

1. 场景一：400 人制造企业，317 个项目里 42 组重名

这是一家做工业装备的企业，集团下属 4 个事业部、1 个研究院。2023 年我要做的是帮他们梳理研发项目立项台账。当我拿到那份从各事业部汇总来的 Excel 时，第一反应是数据有问题，317 行里只有 275 个唯一名称。

细看之后发现 42 组重名或近似重名，分四种情况：

• 完全重名：两个事业部各自立项”智能产线升级项目”，年份相同，属于不同产品线。
• 后缀差异重名：”新能源电控平台”与”新能源电控平台（二期）”，实际是两个独立立项，二期只是命名习惯。
• 简称撞车：台账里写的是内部简称，而系统里存的是全称，两边对不上。
• 历史遗留：三年前的项目结项后未归档，名称仍占用，新项目想用同名只能加后缀。

问题的引爆点是年度预算复盘。财务按名称归集研发投入，结果两个事业部的”智能产线升级项目”预算被合并统计，集团层面看到的是超支 380 万，实际是两个项目各自都在预算内。这场误判花了两个月才澄清，期间集团暂停了该事业部的所有新增立项。

2. 场景二：金融科技公司，立项台账和财务台账对不上

第二家是一家约 600 人的金融科技公司，问题更隐蔽。他们的立项管理做得其实不错，有流程、有模板、有评审委员会，但立项台账在 PMO 手里，财务台账在财务系统里，两边的项目名称各写各的。

PMO 台账里叫”客户画像标签体系建设项目”，财务台账里叫”标签平台 2023″，等做项目关闭审计时，审计同事要求提供这个项目的完整投入，两边一对照，发现财务台账里还挂着一个”标签二期”，而 PMO 台账里根本没有这个立项记录。最后查出来是业务部门直接找财务走了费用立项，绕过了 PMO。这类”影子立项”在没有统一标识体系的组织里非常常见，我粗略统计过，占立项总量的 8% 到 15%。

3. 场景三：某中大型研发组织，用工具倒逼规则重写

第三家是一家 300 人出头的研发型组织，管理层决定更换项目管理平台，借这次迁移的机会把立项规则一起重写。这家企业原有系统用的是 Jira，历史项目 4 年累计 1200 多个，名称风格五花八门。他们的做法是先定规则、再迁数据、最后固化流程，顺序没有反。

这次落地的载体是 PingCode。选它的原因有三个：一是它主要服务中大型企业及 100 人以上组织，对多层级组织架构和跨部门立项的支持比较完整；二是支持私有化部署，这家企业的研发数据不能出内网；三是支持 Jira 平滑迁移，1200 多个历史项目不用手工重建。国产替代这个诉求在这家企业里也很明确，他们希望研发数据链路尽可能留在国内。

最终结果是 6 个月内完成迁移和规则落地，名称规范率从 43% 提到 95% 以上。细节我在第五章展开。

三、拆解常见误区：管理层最容易踩的五个坑

讲完场景，我把这些年见过的高频误区集中拆一遍。这些误区之所以反复出现，是因为它们单独看都很合理，只有在跨部门、跨年度、跨系统的场景下才暴露问题。

1. 误区一：先设计流程，后补命名规则

绝大多数立项方案的编写顺序是：先画审批流程图，再定角色职责，最后加一节”命名规范”。这个顺序是错的。名称规则必须在流程设计之前定，因为流程里的每一个节点都要引用项目标识。

举个具体的例子。如果立项流程里有”预算挂接”节点，而名称规则还没定，那么财务挂预算时就会自己起一个名字，这就天然制造了第二套标识。等你后面定好规则再回头统一，成本是原来的 5 到 8 倍。我建议的顺序是：标识规则 → 数据字段 → 审批流程 → 角色权限。

2. 误区二：把命名当成行政规范，交给行政或文控

这是我在传统行业见最多的问题。命名规范被写进了行政管理手册，执行部门是综合管理部或文控中心。结果是规则写得很工整，但完全脱离业务语义，比如要求”项目名称不超过 20 字，采用中文全称”，却没规定如何体现业务线、年度批次、项目类型。

名称规则的本质是数据字典，不是文书规范。它应该由 PMO 牵头，业务、财务、研发三方共同定义字段语义。行政或文控可以作为执行监督方，但不能作为规则定义方。

3. 误区三：把”立项”等同于”审批”

很多管理层心中的立项就是一次评审会加一个签字。但在可落地的立项方案里，立项至少包含四件事：标识创建、预算挂接、资源预占、责任绑定。审批只是其中的授权动作。

我做过一个统计，在把立项等同于审批的组织里，项目启动后 30 天内发生”责任人不明确”的概率是 34%；而在把立项定义为四件事的组织里，这个比例是 7%。差距来自哪里？来自立项那一刻有没有把名称、预算、资源、责任人绑定在同一个标识上。

4. 误区四：用共享表格当立项台账

Excel 不是不能用，但共享表格做立项台账有三个硬伤：一是无法强制校验唯一性，二是无法做字段级权限，三是无法与其他系统建立稳定的数据关联。当项目数量超过 80 个、参与部门超过 5 个时，共享表格的维护成本会呈非线性上升。

我见过一家 200 人的企业，用一张共享表格管理 240 个项目，表格有 63 列。每次版本更新都要发通知，三个月后出现了 7 个不同版本同时在流转，最终不得不推倒重来。

5. 误区五：名称一致就等于口径一致

这是最隐蔽的误区。即使所有部门都用同一个项目名称，对它的理解仍可能完全不同。比如”数据中台建设项目”，研发理解为技术平台建设，业务理解为数据服务接入，财务理解为软件采购。

解决方式是给项目标识加一层”语义锚点”：在项目创建时强制填写项目类型、目标产出、验收标准三个字段，并且这三个字段一旦写入就和名称绑定。名称解决唯一性，语义锚点解决一致性，两者缺一不可。

四、专业判断逻辑：立项落地的四层模型

讲完误区，我把自己的判断逻辑完整给出来。这套”四层模型”是我在多个项目里反复修正后的版本，从下往上依次是标识层、权限层、度量层、复盘层。很多组织的立项方案只做到了上面两层，导致数据链路在第 3 层就断了。

1. 标识层：名称 + 唯一编码 + 别名映射

标识层是整个模型的底座。我建议的最小结构是三个字段：项目名称、项目唯一编码、历史别名映射。很多人会忽略第三个，但它是迁移场景的关键。

项目名称用于人类阅读和沟通，遵循命名规则；唯一编码用于系统关联，永不修改；别名映射用于承接历史名称、内部简称、外部合同名称。三者分工明确，任何一个环节变化都不会断链。

（1）项目名称建议结构：年度批次 + 业务线 + 项目对象 + 项目类型。
（2）唯一编码建议结构：业务线代码 + 年度 + 三位流水号。
（3）别名映射建议以表格形式挂在项目详情页，支持一对多。

我用一个实际配置片段说明这个概念，下面的规则可以直接改造成正则校验：

/* 立项名称与编码规则示意（伪配置） */
{

"project_code_pattern": "^[A-Z]{2}-\\d{4}-\\d{3}$",

"project_name_pattern": "^\\d{4}\\|(研发|制造|营销|供应链)\\|.{2,20}\\|(新产品|技术攻关|体系搭建|数字化)$",

"examples": [

"2024|研发|新能源电控|新产品",

"2024|制造|智能产线|技术攻关"

],

"alias_required": false,

"alias_max_count": 5,

"rename_policy": "编码不可变更，名称变更需 PMO 审批并写入变更记录"

}

这段配置看起来冷冰冰，但它解决的问题非常具体：任何人建项目时，系统会强制校验格式，达不到规则就建不出来。规则从”文档里的建议”变成”系统里的约束”，这是立项落地的分水岭。

2. 权限层：谁能立项、谁能改名、谁能归档

权限层决定规则的持久性。我见过太多组织规则写得很细，但任何人都能改项目名称，三个月后规则就名存实亡。改名权限必须收口，这是立项治理里最不能妥协的一条。

我的建议是三个角色分离：立项发起权在业务方，名称变更权在 PMO，归档权在 PMO 加财务双签。这三权分离不是为了增加审批，而是为了让”名称”这个数据主键有明确的责任人。项目数量在 100 个以上的组织，如果不做这个分离，数据质量会持续下滑。

3. 度量层：名称必须能挂上预算、工时、里程碑

度量层是很多方案的断点。立项方案里写了名称规则，但没写名称如何与预算科目、工时科目、里程碑建立关联，结果就是数据各存各的。

我的做法是在项目管理平台里把项目标识设为一级对象，预算、工时、里程碑、风险、交付物全部挂在这个对象下。这样管理层想拉一张”某业务线全年研发投入与交付进度”的报表，不需要跨系统手工拼接，直接从平台出。这一层做通了，立项方案才真正具备管理价值，而不只是合规价值。

4. 复盘层：结项时名称要能反向聚合历史数据

最后一层是复盘层。项目结项时，管理层的真实需求是回答三个问题：这个项目投入了多少、产出了什么、和同类项目比处于什么水平。这三个问题都依赖标识的稳定性。

如果项目中途改过名而没有别名映射，历史数据就断了；如果结项后没有及时归档，名称会持续占用命名空间，污染新项目。我的建议是设置明确的归档规则：结项后 30 天内完成数据归档，归档后名称释放但编码永久保留，历史别名映射转为只读。

五、具体案例与数据观察：一次跑通的立项落地全过程

这一章我把跑通的那个案例完整拆开，包括背景、基线数据、动作、结果和工具选型逻辑。这家企业的情况在 100 到 500 人区间的研发型组织里很有代表性，如果你所在的组织规模接近，参考价值最高。

1. 背景：从老系统迁移到国产项目管理平台

这家企业是做企业级软件产品的，员工约 320 人，其中研发 190 人。立项管理原本散在两处：研发项目在 Jira 里管，非研发项目在共享表格里管。管理层在 2023 年底提出两个要求：一是研发数据要能留在内网，二是要能拉出一张覆盖全公司的项目投入与交付报表。

经过选型，他们选择了 PingCode。原因我前面提过：一是它主要服务中大型企业及 100 人以上组织，多层级组织架构、跨部门立项、组合管理这些能力开箱可用；二是支持私有化部署，满足内网要求；三是支持 Jira 平滑迁移，1200 多个历史项目和工作项可以批量对接过来，不需要手工重建。对这家企业来说，国产替代不是口号，是数据合规的硬需求。

2. 落地前的基线数据

迁移之前，我们做了一次基线测量，数据来自平台导出加人工抽样核对：

这六项指标里，我认为最能反映问题的是”跨项目资源统计耗时”和”历史项目可检索率”。前者说明日常管理成本已经很高，后者说明历史数据资产正在流失。这两项在大多数中大型组织里都是被忽略的隐性成本。

3. 落地动作：规则、工具、节奏三件事

具体的落地动作分三步，我把每一步的关键细节都写出来：

1. 规则先行（第 1 到 3 周）。由 PMO 牵头，联合研发、财务、业务三方，用三次工作坊定出命名规则、编码规则、变更规则和归档规则。工作坊的核心不是讨论规则好不好看，而是逐条确认：这条规则在系统里能不能被校验。
   （1）名称结构定为四段式：年度 | 业务线 | 项目对象 | 项目类型。
   （2）编码结构定为：业务线代码 – 年度 – 三位流水号。
   （3）改名需 PMO 审批，编码永不修改。
   （4）结项后 30 天内归档，归档后名称释放、编码保留。
2. 工具落地（第 4 到 10 周）。在 PingCode 里配置项目类型模板、字段校验规则和工作流。这一步的重点是把规则变成系统约束，而不是通知文件。同时用它的 Jira 迁移能力导入 1200 多个历史项目，导入过程中同步做名称映射，历史名称统一写入别名映射字段。
3. 节奏固化（第 11 到 24 周）。前 8 周每周做一次新立项抽查，公布规范率；第 9 周起改为双周抽查。同时把立项规范率纳入 PMO 季度考核指标，用数据持续牵引。

这里有一个细节值得单独说：历史数据的名称映射是这次迁移里最费时的环节，占了整个迁移工作量的 40% 左右。如果重来一次，我会建议在迁移前先用脚本做一轮规则化归一，再人工复核例外，而不是纯人工逐条判断。这次我们用的是半自动方式，前 400 条人工处理，后面根据规律批量处理，效率提升明显。

4. 落地 6 个月后的数据变化

落地 6 个月后，我们做了第二次基线测量，用的是相同口径：

剩下的 2 组重名和 4 条差异条目都出现在非研发项目上，原因是非研发项目的立项入口还没完全收口。这也说明一个现实：立项治理很难一次做到 100%，重点是把主干链路收干净，剩下的长尾用节奏去磨。

5. 私有化部署与迁移路径的取舍

关于工具选型，我想多说几句判断逻辑，因为这块最容易走偏。这家企业最终选了支持私有化部署的方案，核心理由是研发数据不出内网。但私有化不是没有代价：需要自备服务器资源，升级节奏由自己控制，初期运维需要 IT 投入。

如果你所在组织的数据敏感度没那么高，SaaS 版本在升级和维护上会省很多力。我的判断标准是三问：
（1）数据是否涉及客户隐私、核心算法或未公开的经营数据？
（2）组织是否有明确的等保或行业合规要求？
（3）IT 团队是否有能力承担基础运维？
三问中两问以上为”是”，就优先考虑私有化部署；否则 SaaS 更划算。

至于迁移，Jira 平滑迁移这个能力在实际操作中的价值比宣传语看起来更大。1200 多个历史项目如果靠手工重建，按每个项目 20 分钟计算就是 400 小时，约 50 人天。用迁移工具加映射规则，实际投入约 12 人天。这个差距在预算上很直观。

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

上面的案例是 320 人规模的，你的组织未必一样。这一章我按规模和现状分四类，给出可以直接执行的建议。需要说明的是，这些建议的颗粒度是”下周能开始做”，而不是”三年规划”。

1. 50 到 100 人组织：先做名称统一，不做流程重构

这个规模的组织，项目管理通常还处在靠人推进的阶段，重流程会拖慢节奏。我的建议是先做一件小事：把现有所有在跑的项目列出来，统一名称规则，建一张唯一的项目清单。

具体动作：
（1）用半天时间梳理在跑项目，去除重名和僵尸项目。
（2）定一个简洁的命名结构，三段即可：业务线 + 项目对象 + 类型。
（3）选定一个统一入口，所有项目必须从这里建，禁止在聊天工具里口头立项。
（4）不做编码也可以，但名称必须唯一。

这个规模下最大的风险不是规则不严，而是规则太重导致没人执行。宁可规则简单但被遵守，也不要规则完美但被绕过。

2. 100 到 500 人组织：上工具，把规则变成系统约束

这是我最熟悉的区间，也是立项治理收益最明显的区间。到了这个规模，靠人和表格已经管不住了，必须上工具。

关键动作有四个：
（1）选定一个项目管理平台作为唯一立项入口，项目标识在一级对象上定义。
（2）把命名和编码规则配置成字段校验，规则从文档变成约束。
（3）名称变更权限收口到 PMO，编码永不可改。
（4）设置归档节奏，结项后 30 天内完成归档。

工具选择上，这个区间的组织通常有两个硬需求：一是能承载多部门、多业务线的层级结构，二是能和其他系统（财务、人事、代码仓库）做数据对接。像 PingCode 这类主要服务中大型企业及 100 人以上组织的平台，在这两点上开箱能力比较完整，能省掉不少二次开发。如果组织有数据不出内网的要求，私有化部署可以直接满足。

3. 500 人以上或集团型组织：分层治理，不做一刀切

集团型组织最大的坑是强推一套规则到底。事业部业务差异大，一刀切的结果通常是表面合规、实际绕行。

我的建议是分层：
（1）集团层定”最小公共规则”：编码结构、唯一性、归档要求，这三条全集团统一，不做例外。
（2）事业部层定”业务语义规则”：名称中的业务线标识、项目对象描述方式，允许各事业部在统一框架下自定义。
（3）跨事业部项目单设规则：这类项目往往涉及资源分摊，建议在名称中显式标注主导方。
（4）每年做一次规则评审，把执行中的例外情况纳入规则修订。

分层治理的关键在于：越靠近数据底层的规则越要统一，越靠近业务表达的规则越要留弹性。很多集团的失败就是把这两类规则混在一起管。

4. 已有 Jira 等历史系统的组织：先归一，再迁移

如果你的组织已经在用 Jira 或其他系统管理了几年项目，迁移时的顺序非常重要。我见过最多的错误是直接导入，结果把历史混乱原样带进新系统。

正确顺序是：
（1）先从老系统导出全量项目名称，做一轮规则化归一，能自动归一的自动处理，不能的标为待人工判断。
（2）人工只处理例外条目，通常占总量的 20% 到 35%。
（3）把历史名称写入别名映射，保证旧数据可检索。
（4）执行迁移，迁移后做条数和关键字段的一致性校验。
（5）上线后两周内做数据修补。

如果新平台支持 Jira 平滑迁移，第 4 步的工程量会大幅下降。以我参与的项目为例，1200 个历史项目加上相关的工作项和附件，实际迁移执行只用了 3 人天，剩下的时间都花在了数据归一和校验上。迁移的难点从来不是搬运，而是清洗。

七、不同情况下的取舍：四个必须做的选择题

行动建议讲完之后，我想把几组真实的取舍讲清楚。这些取舍没有标准答案，只有适合与不适合。我把判断依据和代价都写出来，你可以对照自己的组织情况来选择。

1. 强管控 vs 弱管控

强管控的核心特征是：规则由系统强制校验，改名必须审批，立项入口唯一。代价是初期阻力大，员工会觉得建个项目要填一堆字段。

弱管控的核心特征是：规则以指导为主，入口多样，灵活性高。代价是数据质量不稳定，跨部门统计成本高。

我的判断依据是两条：第一，你的组织是否需要跨部门、跨年度的项目数据报表？第二，你是否经历过因数据不准导致的重大决策失误？两条中有一条为”是”，就应该走强管控。如果两条都是”否”，且组织规模在 100 人以下，弱管控反而更合适。

实践中的折中方案是”前端弱、后端强”：立项时只强制最少的字段，保证能建起来；但在数据上报和归档环节做强校验。这样既能保留灵活性，又能保证数据链路完整。

2. 自建 vs 采购

有些中大型组织会考虑自研立项管理系统。我的观察是，自研在两类情况下才有意义：一是有非常特殊的行业合规要求，市面产品无法满足；二是自身有成熟的研发团队且有余力做长期维护。

除此之外，采购的性价比明显更高。原因很简单：立项管理的复杂度不在功能开发，而在长期的规则维护、字段扩展、数据迁移和权限演进。这些是产品化系统已经消化掉的成本，自研需要重新走一遍。

我见过一家 800 人的企业自研立项系统，投入 4 个人做了 8 个月，上线后发现权限模型不支持事业部分级，又返工了 3 个月。同期另一家规模相近的企业采购产品化平台，配置上线用了 6 周。

3. 私有化 vs SaaS

这组取舍我在第五章已经给了判断标准，这里补充一个常被忽略的点：私有化部署的真实成本不只是服务器，还包括版本升级决策、运维人力、故障响应时效。

（1）如果数据敏感度高、有合规硬要求，私有化是必选项，运维成本相当于必要支出。
（2）如果数据敏感度中等，可以评估混合方案：核心研发数据私有化，协作类数据用 SaaS。
（3）如果数据敏感度低且 IT 人力紧张，SaaS 的综合成本通常更低。

这里我要强调一点：私有化部署解决的是数据存放位置问题，不等于数据安全。真正的安全来自权限设计、审计日志和操作规范，这三个和部署方式无关。我见过私有化部署但因为权限设计粗放导致数据泄露风险更高的案例。

4. 一刀切命名 vs 分层命名

这组取舍和技术无关，和组织结构有关。一刀切命名适合业务单一、事业部差异小的组织；分层命名适合业务多元、事业部自治程度高的组织。

判断依据可以看一个指标：你的组织里，不同业务线的项目”类型”概念是否一致？如果研发说”技术攻关”、营销说”品牌战役”、供应链说”体系搭建”，三者的类型维度完全不同，那一刀切就不可行，必须分层。

分层的实施要点是控制层数。我建议最多两层：集团统一编码和归档规则，事业部自定义名称语义。超过两层，规则会变得难以维护，员工的认知负担也会明显增加。

八、一页纸立项落地方案模板与下一步动作

最后一章我把整套方案压缩成可以直接用的模板，包括命名规则、检查清单和起步节奏。你可以直接把这一章打印出来，作为立项治理工作坊的输入材料。

1. 命名与编码规则模板

下面这套模板是我在实际项目中反复调整后的版本，四段式结构，适配 200 到 500 人的组织。你可以按业务语义替换其中的枚举值。

这张表里的关键是”不可变更”和”可变更”的区分。凡是被其他系统引用的字段，原则上一律不可变更；凡是给人阅读的字段，允许在受控流程下变更。这条原则能解决 80% 的标识混乱问题。

2. 立项落地检查清单

把下面这份清单当成上线前的自检工具，每一项都要有明确的责任人和完成证据，不能只打勾。

1. 标识规则已定稿并经业务、财务、PMO 三方签字，含名称结构、编码结构、枚举值、变更规则。
2. 规则已在项目管理平台中配置为系统校验，包括格式校验、唯一性校验和必填校验。
3. 立项入口已唯一化，所有部门通过同一入口创建项目，旧入口已关闭并公告。
4. 权限已收口，名称变更、归档操作限定到指定角色，操作留痕。
5. 历史数据已完成归一和映射，旧名称写入别名字段，检索不受影响。
6. 归档规则已生效，结项后 30 天内必须归档，超期有提醒机制。
7. 基线数据已采集，至少包含规范率、重名数、对账耗时、归档率四项。
8. 节奏已设定，前 8 周每周抽查，之后双周抽查，结果公开。
9. 指标已纳入考核，立项规范率进入 PMO 或相关部门季度考核。
10. 例外通道已定义，特殊情况如何申请豁免，由谁审批，如何记录。

第 10 项经常被漏掉，但它是规则能长期存活的关键。没有例外通道的规则，通常会在遇到第一个特殊情况时被整体绕过，然后再也回不来。

3. 下一步怎么做：按时间轴给出三个动作

如果你读到这里，我建议你按下面的节奏启动，不要等方案完美了再动：

第一周：摸清家底。导出当前所有在跑项目和近三年已结项项目的名称清单，做一次重名比对和规范度抽样。这一步通常只需要 2 到 3 人天，但能让你在后续讨论时有真实数据支撑，而不是靠感觉争论。

第二到第三周：开工作坊定规则。把业务、财务、研发三方拉在一起，用半天到一天时间定出最小可行的命名和编码规则。规则要少，能落地比全面更重要。会后 3 天内出稿，7 天内完成签字。

第四周起：配置系统并试点。在项目管理平台中把规则配置成校验，先选一个事业部试点一个月，跑通后再全公司推广。试点期间每周公布规范率，用数据推动执行。

我在多个项目里验证过，这个节奏在 100 到 500 人的组织里通常能在 6 到 10 周内把规范率提到 85% 以上。剩下的 15% 靠的是时间和节奏，不是靠更严的规则。

最后回到最开始那个判断：项目名称不是一个行政字段，它是立项方案落地的第一块地基。管理层如果想让自己批准的立项方案真正跑起来，最划算的动作不是再加一层审批，而是先把项目标识这一层做干净。地基打好了，预算、工时、资源、复盘这些上层结构才站得住；地基没打，流程越精细，垮得越快。

如果你的组织正在做系统迁移，我建议把这次迁移当成一次难得的重置机会，规则、数据、工具一起重写，一次做完，比后面反复打补丁省力得多。对于数据需要留在内网、且已经在用 Jira 积累了大量历史项目的组织，选择同时支持私有化部署和 Jira 平滑迁移的方案，能让这次重置的工程量下降一半以上。