项目管理基本法

六、完整制度正文

以下保留长期稳定的治理原则。人员名单、审批权限、预算比例、UT及绩效数字统一下沉附件，避免每次人员或参数调整都修改基本法。

第0条 项目治理总则与红线

（一）基本目的

项目管理基本法的目的不是增加审批，而是确保公司所有项目在资源投入前完成四个确认：

1. 值不值得做：项目目标、业务价值、收入或战略意义是否成立；
2. 能不能做成：负责人、团队、关键资源、交付边界是否清晰；
3. 花多少钱做：预算、成本上限、投入产出和成本归集方式是否明确；
4. 按什么规则做：立项、Code、报工、变更、冻结、退出是否合规。

（二）纳入项目管理的事项边界

凡符合以下任一情形的事项，原则上必须纳入项目管理：

• 涉及客户交付承诺、合同履约或中标后交付；
• 涉及跨部门资源投入或需要明确项目负责人；
• 涉及独立预算、成本归集、报工或费用报销；
• 涉及客户级或商机级售前投入，需要识别客户关系拓展、售前差旅、解决方案人员报工等成本；
• 涉及明确的业务目标、收入目标、验证目标或里程碑；
• 涉及公司级创新、AI原生探索、0→1业务验证；
• CEO、高管或部门负责人要求按项目管理的事项。

不符合上述条件、且仅属于部门日常运营、数据维护、例行支持、日常运维的事项，可归入部门日常成本管理，不单独立项。

（三）项目治理红线

以下情形为项目治理红线，PMO应前置预警并要求补齐流程：

1. 未立项先持续投入：未完成正式立项或提前建 Code 审批，却已持续报工、报销或投入交付资源；
2. 以老项目名义规避新项目审批：客户虽为存量客户，但场景、合同范围、预算、人力、收入模型或交付风险发生实质变化，仍按老项目续约处理；
3. 临时 Code 长期化：提前建 Code 到期后未补正式立项，却继续投入或重复申请临时 Code；
4. 项目冻结后无闭环：Code 已冻结，但未明确关闭、续立项、例外变更或成本归集方案；
5. 目标与资源不匹配：立项目标、收入预算、团队投入、AI/人力分工、里程碑之间明显不自洽；
6. 关键假设不显性：0→1、AI原生或新业务项目未明确关键假设、验证节点和暂停/转向条件；
7. 售前成本无归属：客户关系拓展、售前差旅、解决方案人员报工等投入未按客户+商机颗粒度归集，导致商机阶段成本不可见。

（四）项目分类判定表

（五）CEO / 高管前置判断触发条件

以下项目即使尚未正式签约，也应在正式立项前进行 CEO / 高管前置判断或同步：

• 新客户、新产品、新业务模式或 0→1 探索；
• 单项目预算、人力或机会成本显著；
• 涉及 AI原生业务验证、公司级能力建设或战略方向；
• 项目目标、收入模型、交付路径存在重大不确定性；
• 老客户项目但合同范围、预算、人力、收入模型或交付风险发生实质变化；
• PMO判断存在“先干后批”“临时 Code 长期化”“目标资源不匹配”等治理红线。

---

第1条 项目主责交接

（一）合同签订前：由 GTM/CST 部门主责，负责指定项目负责人、发起立项或提前建 Code、推动审批流程。

（二）合同签订后：3 个工作日内，由原主责部门发起项目移交，交付一级部门（能力中心/客资/数资）接收主责。项目管理小组同步变更系统内项目负责人。

（三）移交内容至少包括：

• 已签署合同或中标/成交依据；
• 售前交接纪要；
• 已承诺的交付范围与关键里程碑；
• 预算、报价、成本测算和资源投入假设；
• 未决风险项和客户关键承诺；
• 若涉及 AI原生项目，需补充 AI/人力分工、关键假设、验证节点。

（四）项目移交不是责任结束。合同签订前形成的客户承诺、报价假设、交付边界，由原主责部门与接收部门共同确认后完成交接。

---

第2条 外部项目-老项目续约类立项

（一）适用范围

本类适用于客资及数资业务线中，已有合作基础且项目边界未发生实质变化的客户续约、授权延续、或既有合同范围内终端扩展类项目。

（二）不得按老项目续约处理的情形

虽为老客户，但出现以下任一情形的，不得直接按老项目续约类处理，应按新项目签约类或重大变更处理：

• 新增合同范围或交付内容明显变化；
• 新增业务场景、产品形态、区域范围或客户组织；
• 项目预算、人力投入、成本结构显著变化；
• 收入模型、回款方式、结算方式发生变化；
• 交付风险、合规风险、客户承诺明显增加；
• 需要提前建 Code 或已发生先投入后审批情形；
• PMO、预算管理小组或立项主审人判断不宜简化审批。

（三）项目负责人和审批权限

项目负责人指定、预算主审人和立项主审人按公司现行审批权限执行。人员调整不影响本条治理原则。

（四）立项程序

基于预算审批已通过：

1. 预算审批通过后，项目负责人在合同签订 7 个工作日内完成立项材料，提交项目管理小组初审；
2. 初审通过后，项目负责人在企业微信拉群，发起立项审批，附在线立项文档；
3. 立项文档需明确负责人、周期、预算目标、项目目标、项目里程碑、成本归集方式；
4. 审批节点依次为：预算管理小组主审人 → 立项主审人；
5. 审批通过后抄送 CEO，由项目管理小组开立项目 Code。

---

第3条 外部项目-新项目签约类立项

（一）适用范围

本类适用于客资类新客户签约项目（如银行外呼等）、数资类首次合作项目，以及虽为老客户但已触发第2条“不得按老项目续约处理”的项目。

（二）前置条件

正式立项前，应至少完成以下前置条件：

• 已按公司售前管理规定完成投标/报价审批；
• 已完成预算审批或形成预算测算版本；
• 合同已签订、已中标公示，或具备明确成交依据；
• 项目负责人、交付边界、关键里程碑、成本上限已明确。

（三）签约前/中标前的业务判断

对符合第0条“CEO / 高管前置判断触发条件”的项目，原则上应在正式签约或重大资源投入前完成业务判断，重点回答：

1. 为什么值得做；
2. 收入、成本、毛利或战略价值是否成立；
3. 交付承诺与团队能力是否匹配；
4. 是否存在必须提前暴露的风险；
5. 是否需要进入 CEO审查框架进行立项审查。

（四）项目负责人和审批权限

项目负责人指定、预算主审人、立项主审人及审批链按公司现行审批权限执行。

（五）立项流程

基于预算审批已通过：

1. 合同签订或中标公示后 7 个工作日内，项目负责人完成立项材料，提交项目管理小组初审；
2. 初审通过后，项目负责人在企业微信发起立项审批，附在线立项文档；
3. 立项文档需明确负责人、周期、预算目标、项目目标、项目里程碑、成本归集方式；
4. 审批节点依次为：预算管理小组 → 项目管理小组 → 立项主审人 → CEO；
5. CEO 审批通过后，由项目管理小组开立项目 Code。

---

第3A条 售前商机 Code 管理

（一）设立目的

为准确识别不同客户、不同项目商机在售前阶段投入的成本，公司可在“GTM售前”下，按“客户 + 项目商机”的颗粒度建立售前商机 Code 子项目。

售前商机 Code 的目的不是替代正式项目立项，也不是提前进入交付，而是解决三类管理问题：

1. 商机成本可见：识别客户关系拓展、售前差旅、售前解决方案人员报工等投入；
2. 投入产出可追踪：将售前投入与商机预计收入、商机类型、转化结果建立关联；
3. GTM经营可复盘：帮助 GTM 判断不同客户、行业、商机类型的售前投入效率。

（二）适用范围

售前商机 Code 适用于尚未进入正式项目立项，但已形成明确客户、明确商机或明确售前推进动作的事项，包括但不限于：

• 客户关系拓展；
• 售前拜访、客户沟通、商机推进；
• 售前差旅、招待等经审批的商机相关费用；
• 售前解决方案、方案设计、Demo、POC 前期准备；
• 投标、报价、商务方案、技术方案支持；
• GTM 判断需要独立核算售前投入的重点客户或重点商机。

不具备明确客户和明确商机的日常市场活动、行业研究、通用产品资料建设，原则上不使用售前商机 Code，应归入 GTM 或相关部门日常成本。

（三）Code 颗粒度

售前商机 Code 原则上按“客户 + 项目商机”颗粒度开立。

同一客户下，如存在多个独立商机，且预计收入、解决方案、销售路径、资源投入或决策链条不同，应分别开立或分别归集，避免一个客户 Code 混合多个商机成本。

示例：

（四）预算规则

售前商机子项目必须设置预算上限，预算额度由商机预计收入、商机类型和售前复杂度共同决定。具体比例属于待确认执行参数，确认后生效；未确认前不得将建议比例视为正式制度。

（五）发起与审批

售前商机 Code 由 GTM 发起。

申请材料至少包括：

1. 客户名称；
2. 商机名称和商机阶段；
3. 商机预计收入及测算依据；
4. 商机类型（A+B+X、A+B、纯B或其他）；
5. 拟申请售前预算额度及预算比例；
6. 预计使用范围：客户关系拓展、差旅、售前方案、Demo/POC、投标支持等；
7. 商机负责人、售前负责人、预算负责人；
8. 预计关闭时间或下一决策节点；
9. 若商机失败，售前成本归集方式。

审批路径按公司现行售前审批口径执行。基本法仅明确责任边界：GTM 对商机价值和投入负责，预算管理小组对预算上限负责，项目管理小组对子项目结构、Code 开立、备案和预警负责。

（六）成本归属与使用范围

售前商机 Code 归属于 GTM 成本。

可归集成本包括：

• 客户关系拓展相关费用；
• 售前差旅费用；
• 售前解决方案人员报工；
• 售前方案、Demo、POC 前期准备相关投入；
• 经 GTM 和预算管理小组确认的其他商机推进成本。

售前商机 Code 不得用于正式交付阶段成本归集。商机转化为正式项目后，应按第2条或第3条完成正式立项，并开立正式项目 Code；后续交付成本应进入正式项目 Code，不得继续占用售前商机 Code。

（七）转正式项目、关闭与复盘

售前商机 Code 应设置明确的商机关闭或复盘节点。

• 商机成功转化：正式项目立项通过后，售前商机 Code 停止新增成本，相关售前投入可作为项目投入产出复盘依据；
• 商机失败或暂停：由 GTM 在 5 个工作日内提交关闭说明，明确已发生售前成本、失败原因和后续是否保留客户跟进；
• 商机长期未决：超过预计关闭时间仍未转化的，由 GTM 说明是否继续保留 Code，必要时调减预算或关闭；
• 项目管理小组可将售前商机 Code 纳入 PMO 看板，用于观察重点商机的售前投入、转化状态和成本归集风险。

（八）与正式项目 Code、提前建 Code 的区别

售前商机 Code 不应被用作规避正式立项或提前建 Code 审批的通道。凡已进入交付承诺、客户验收、正式项目资源投入的，应按第2条、第3条或第5条处理。

---

第4条 内部项目类立项

（一）立项原则

内部项目以目标投入产出为依据，评审聚焦目标、策略、近期里程碑计划、所需资源及预算。

内部项目不因“无外部合同”而降低管理要求。凡涉及公司级资源投入、AI原生探索、跨部门协同或可单独归集成本的内部项目，均应按项目管理。

（二）项目负责人和审批权限

内部项目由项目收益部门或主责部门作为 Owner 发起；具体负责人、预算主审人和立项主审人按公司现行审批权限执行。

（三）立项流程

1. 项目管理小组初审通过后，项目负责人基于在线立项文档组织线下评审会；
2. 在企业微信发起立项审批，附在线立项文档；
3. 立项文档需明确负责人、周期、预算目标、项目目标、项目里程碑、验证节点、资源投入；
4. 审批节点依次为：重要相关方 → 预算管理小组 → 项目管理小组 → 立项主审人 → 高管 → CEO；
5. 经 CEO 明确立项通过后，由项目管理小组开立项目 Code。

（五）内部创新 / AI原生项目补充要求

内部创新或 AI原生项目，立项材料中必须明确：

• 关键业务假设；
• AI 改变了什么，不做 AI 与做 AI 的差异；
• 人与 AI 的分工；
• 前三个月验证节点；
• 暂停、转向或继续投入的判断条件。

（六）例外

• 若立项未通过，但经决策确认部分工作可先行推进，且临时项目 Code 有效期已临近截止，可申请将 Code 有效期顺延不超过 15 个自然日。项目负责人须在顺延期内完成待补齐事项并再次发起立项。
• 纯成本支撑类工作（如数据运营、日常运维等）：归入部门日常成本管理，无需走立项评审流程。

---

第5条 提前建立项目 Code

（一）适用情形

项目合同审批、正式立项或必要审批尚未完成，但因业务需要必须提前启动并产生成本投入的，可申请提前建立临时项目 Code。

提前建 Code 是例外机制，不是常规立项通道。

（二）申请前提

申请提前建 Code 必须同时说明：

1. 为什么不能等正式立项后再启动；
2. 预计立项材料完成时间；
3. 预计正式立项通过时间；
4. 前期投入人员范围；
5. 前期成本上限；
6. 若合同或正式立项未通过，成本如何归集；
7. 项目负责人和立项主审人。

（三）规则

• 仅开放人工报工，不预设费用预算额度；
• 确需发生费用的，一事一议，单独审批；
• 必须明确前期成本上限，不得以“待确认”替代；
• 有效期不超过 15 个自然日，到期 Code 自动冻结；
• 冻结后不可报工、不可报销、不可继续发生成本；
• 原则上不得通过重复申请临时 Code 规避正式立项。

（四）项目负责人和审批权限

项目负责人、立项主审人和例外审批权限按公司现行审批权限执行。

（五）申请程序

项目负责人以邮件审批发起申请，经主审人审批通过后，由项目管理小组开立临时项目 Code，并纳入 PMO 跟踪清单。

申请邮件至少包括：提前启动必要性、预计立项材料完成时间、预计正式立项通过时间、前期成本上限、15天内闭环计划、未正式立项时的成本归集方案。

（六）关闭与转正式立项

• 15 天内正式立项通过的，由项目管理小组将临时 Code 转为正式项目 Code 或完成关联处理；
• 15 天内未完成正式立项的，Code 自动冻结，并进入 PMO 红灯清单；
• 合同最终未签署或正式立项未通过的，由项目负责人在 3 个工作日内发起成本归集方案，经预算管理小组主审人确认后执行，临时 Code 关闭；
• 如确需顺延，必须说明不可抗或明确决策原因，并经相应主审人及项目管理小组确认。顺延不得成为常态。

第5A条 提前开工确认单

（一）适用情形

外部项目（尤其 A+B 类）在合同签订前，因业务需要已发生或即将发生提前投入服务（提前驻场、提前数据分析、提前策略设计、提前交付准备等），或已与客户形成“提前服务、后续调整投入”等安排的，须在投入发生前或安排形成时办理《提前开工确认单》。

（二）解决什么问题

合同签订前的提前服务，以及“合同期后减少投入”“绩效结算”等安排，实践中多为口头沟通，事后难以书面确认。提前开工确认单把这些约定前移为可追溯的书面记录，避免“先干了、事后无法证明”，也避免减投约定无法写入合同时没有经营基线。

（三）确认单至少包括

1. 客户名称、项目或商机名称；
2. 提前服务的范围和交付内容；
3. 提前投入的岗位、人数、方式和预计成本；
4. 预计合同签订时间及当前进展；
5. 合同签订后的投入安排（减投岗位、减投幅度、保留的现场/非现场投入）；
6. 绩效/结算口径与客户的确认情况；
7. 客户确认方式：双方会议纪要、书面确认单、邮件或月度计划确认；
8. 项目负责人、商务负责人、客户对接人及签署日期。

（四）与提前建 Code 的关系

提前建 Code 解决“开 Code 报工”的合规问题，提前开工确认单解决“提前服务事实与后续投入安排”的书面留痕问题。二者可并行：需要报工归集的走提前建 Code，需要确认提前服务与后续安排的走提前开工确认单。已签订合同的，不适用本确认单，直接按第2条、第3条正式立项。

（五）未形成书面确认的处理

对已发生提前服务但未形成书面确认的项目，商务须尽快补办确认单或等价书面记录（会议纪要、邮件确认）；无法补办的，按正常投入情形更新经营测算，不得以“此前口头沟通过”作为控制资源的依据。

---

第6条 例外变更管理

（一）原则

涉及项目关键要素的变更，须以正式邮件发起审批，抄送执委会及关联系统负责人。

项目变更不只是系统字段变化。凡影响项目目标、预算、结束时间、负责人、交付边界、客户承诺或成本归集方式的，均应纳入变更管理。

（二）变更类型与审批流程

A 类变更（正式审批）

• 负责人变更、名称变更、项目结构变更：项目管理小组发起 → 部门负责人审批。
• 项目结束时间变更：项目负责人发起 → 部门负责人 → 预算管理小组 → 项目管理小组 → CEO 审批。
• 预算变更：项目负责人发起 → 部门负责人 → 预算管理小组 → 项目管理小组 → CEO 审批。
• 项目目标变更：属于 A 类，参照结束时间变更流程。
• 项目交付范围或客户关键承诺变化：属于 A 类，参照预算/结束时间变更流程。

B 类变更（备案制）

• 里程碑调整（不影响项目结束时间）：项目负责人发起，部门负责人审批后执行，抄送项目管理小组备案。
• 团队成员调整（非核心角色）：项目负责人自主调整，月底统一报项目管理小组备案。

（三）通报机制

所有 A 类变更审批通过后，由项目管理小组统一发邮件通报执委会及关联系统负责人。

---

第7条 项目管理机制

（一）项目冻结

以下情形由项目管理小组发起项目冻结：

• 项目 Code 到期且未完成续期审批；
• 提前建 Code 到期且未完成正式立项；
• 项目预算耗尽且未完成预算变更审批；
• 项目结束日期已过但仍需报工、报销或发生成本；
• 经 CEO 或部门负责人决策要求暂停的项目；
• PMO 发现存在重大流程违规或成本归集风险。

冻结后，报工、分贝通、汇联易系统全部禁用，不得发生任何成本。完成相应例外变更、续立项、成本归集或关闭审批后，方可解冻或关闭。

（二）冻结后的闭环要求

项目冻结不是处理结论。冻结后必须形成闭环：

1. 项目负责人须在 3 个工作日内提交处理方案；
2. 处理方案至少明确：关闭、续立项、例外变更、成本归集、暂停观察中的一种；
3. 7 个工作日内完成路径确认，或升级至部门负责人 / CEO 判断；
4. 项目管理小组将冻结项目纳入红灯清单，直至关闭或解冻；
5. 冻结期间如继续发生项目成本，由项目负责人和相关审批责任人承担管理责任。

（三）报工、UT 与绩效管理

项目报工必须真实、完整、及时，并由项目负责人审核。UT 目标、填报时限、审批时限及绩效奖惩属于动态执行参数，按公司现行报工及绩效管理办法执行；基本法不固化具体比例、分值和人员名单。

---

第8条 PMO 预警与看板机制

（一）PMO预警对象

项目管理小组应持续跟踪以下项目：

• 立项材料已提交但未通过；
• 提前建 Code 项目；
• 15 天内到期项目；
• 已冻结项目；
• 预算即将耗尽或已耗尽项目；
• 审批链超过 3 个工作日未处理项目；
• 老项目但疑似新范围、新预算、新交付风险项目；
• 售前商机 Code 预算接近上限、商机长期未决或成本归集异常项目；
• CEO / 高管关注项目。

（二）预警分级

（三）PMO建议输出原则

PMO对项目的提醒和建议必须基于以下依据之一：

• 项目管理基本法具体条款；
• CEO立项审查框架；
• 已归档会议纪要、审批记录或项目大盘数据；
• 项目负责人补充说明和证据材料。

无依据的判断不得写成结论，只能标注为“待确认”。

---

---

第9条 立项材料审核口径（七问）

PMO 审立项材料，先看项目基线是否成立，再看材料格式和文字细节。立项至少回答七个问题：

1. 本期到底做什么，哪些不做；
2. 从投入到结果的完整业务链路是什么；
3. 哪几个假设决定项目能不能成立；
4. 前两三个月先验证什么，未达到预期怎么办；
5. 每个里程碑交什么、谁负责、谁确认；
6. 人员、技术资源和预算是否与任务逐项对应，真实成本是否完整；
7. 收入、结算和毛利依据是什么，较差情况下公司承担多大损失。

来源：2026-07-14 泛普洛斯立项会领导审核意见（详见《泛普洛斯立项会_领导对立项材料的要求》）。立项反馈也按这个顺序写，七问结论用于判断“建议上会 / 需返工 / 需补材料 / 需拍板”。

---