项目目标管理指南：PMO如何做好项目立项，实操方法全流程

三年前我接手一家约320人规模企业的PMO，第一次参加他们的项目立项评审会，一个预算480万元、周期9个月的项目，从汇报到”通过”用了23分钟，其中18分钟在讲技术方案，4分钟讲排期，最后1分钟由分管副总说”先做起来，有问题再说”。9个月后这个项目延期了14周，超支约110万元，验收时业务方说”这不是我要的东西”。复盘时我们拉出了所有会议纪要，结论很扎心：这个项目的失败，在立项那23分钟里就已经写完了。

这不是个例。我后来在制造业、企业服务、零售三个行业做过立项流程的诊断，访谈过60多位PMO和项目负责人，发现一个高度一致的规律：项目执行阶段暴露出来的问题，大约七成能在立项文档里找到影子。目标写得含糊的，后期一定反复改需求；范围没有边界的，中期一定无限加人；资源只是口头承诺的，第一个月一定会被抽走人手。

所以这篇文章不讲教科书上的立项定义，我想讲的是一套我在真实组织里跑通过、并且被数据验证过的立项方法：PMO到底该在立项阶段做什么、做到什么颗粒度、什么时候该踩刹车、什么情况下应该放行。全文围绕”项目目标管理”这条主线展开，因为目标管不住，立项就只是走个流程。

一、先给结论：立项不是开工仪式，而是一次”可以撤销的止损决策”

我把话说在前面。立项的本质，是组织在投入真金白银之前，用最低成本换取一次”要不要做、做成什么样、值不值得”的判断机会。它是一次决策，不是一份文档，更不是一次表态。

很多PMO把立项做成了”材料收集+会议组织”，我觉得这是定位错误。PMO在立项阶段真正不可替代的价值，是把分散在业务、技术、财务、法务脑子里的隐性判断，转化成一份可以被复核、被追责、被撤回的显性证据。

1. 立项合格的五个硬指标

我在内部推行过一个”五问放行法”，任何项目在评审前都要能回答这五个问题。答不上来的，评审会直接退回补材料，不进入讨论环节。

• 问题一：不做会怎样？如果回答是”也没什么大事”，这个项目就不该立项，应该进需求池排队。
• 问题二：做成什么样算成功？必须有可量化、可验证、有截止日期的成功标准，而不是”提升效率””优化体验”。
• 问题三：谁在什么时间投入多少人？资源必须是具名的、带工时的、经过资源经理确认的，不是”研发部支持一下”。
• 问题四：最坏的情况是什么，我们承受得起吗？要有明确的下限判断，越过哪个红线就必须终止。
• 问题五：谁来签字负责？业务负责人、技术负责人、项目经理三方必须明确到人，不能是部门。

这五个问题看起来朴素，但我见过太多立项文档连第一条都答不清楚。一个组织如果连”不做会怎样”都说不明白，后面的所有排期和预算都是在给情绪买单。

2. PMO在立项阶段的四个动作，比写模板重要得多

我后来把PMO的立项职责压缩成四件事：设门槛、做证据、控节奏、留后手。

“设门槛”是定义什么级别的项目走什么流程，不是所有项目都要上评审会。”做证据”是把业务价值假设、资源承诺、风险预案整理成可复核的材料。”控节奏”是防止立项被无限拉长或者被压缩到形同虚设。”留后手”是提前约定好退出机制和重新评审的触发条件。

这四件事的共同点是：它们都不产出代码，也不产出设计稿，但它们决定了后面所有人的工作是不是白干。

我在实际推动这套方法时，第一年最重要的成果不是交付了多少项目，而是通过立项门槛挡掉了大约三分之一原本会启动的项目。这些项目里有的是重复建设，有的是价值假设根本不成立，有的是资源根本没到位。挡掉它们没有产生任何直接营收，但节省下来的产能全部投到了真正重要的事情上。

二、背景与真实场景：项目的大部分问题，在立项那一刻就被决定了

我把观点说得更直接一点：执行阶段的问题，绝大多数是立项阶段的欠账在还本付息。项目延期、范围失控、验收扯皮，这些事情在执行期看起来是管理问题，追溯回去都是决策问题。

1. 一次让我改了整套流程的复盘

回到开头那个480万元的项目。我们复盘时做了完整的数据回溯：项目执行期间共产生正式变更请求37次，其中28次可以追溯到立项文档里的一句模糊表述，”支持多渠道数据接入”。这句话在立项时没人觉得有问题，因为所有人都默认”多渠道”就是已有的三个渠道。

结果项目上线前两个月，业务新增了两个渠道的接入需求，并且认为”这是立项时就写进去的”。技术团队认为这是范围变更，业务认为这是原本承诺。争执持续了三周，最后以加人加钱收场。

这件事之后我做了一个统计：改造前的19个历史项目里，平均每个项目产生14.3次变更请求，其中约62%源于立项阶段目标或范围描述不清晰。这个数字让我意识到，与其在执行阶段拼命做变更管理，不如在立项阶段把目标写死、把边界划清。

2. 三种典型的组织立项状态

我服务过的组织，立项状态大致可以分成三种，你可以对照看看自己处在哪一档。

需要说明的是，立项耗时长短和立项质量没有必然关系。文档型组织立项耗时最长，但返工比例并不低，因为大量时间花在了填模板和层层会签上，而不是花在把目标算清楚。决策型组织反而更快，因为每个人都清楚自己要提供什么证据、由谁拍板。

这也是我一直强调的判断：立项优化的方向不是”更快”或”更严”，而是”更准”。一个组织如果能把立项评审时间从11个工作日压到5个工作日，同时把返工比例从30%降到15%，这才是真正的效率提升。

三、拆解常见误区：立项阶段最容易踩的六个坑

下面这六个误区，是我在评审会上退回材料最多的原因。每一个我都配了真实的退回理由，你可以拿它当自检清单用。

1. 把”需求描述”当成”项目目标”

我见过最常见的写法是：”建设统一的客户数据平台，打通各业务系统数据。”这不是目标，这是需求描述。目标是”到2024年6月30日，将客户主数据重复率从当前的18%降至3%以内，销售报表出具时间从3天缩短到4小时”。

区别在哪？前者无法验证，后者可以被审计。项目目标必须包含可测量的结果、明确的时间点和可归属的责任人，三者缺一不可。我在评审时有个简单粗暴的测试：如果这句话放到项目结束后，双方可以各执一词说”做到了”或”没做到”，那它就不是目标。

2. 把”领导点头”当成”资源承诺”

这是我踩过最深的坑。立项会上分管领导说”人我有，你放心用”，结果项目启动第二周，两个核心开发被抽去做另一个紧急项目。

后来我强制要求：资源承诺必须落实到”人+工时+时间窗口”三要素，并由资源所属部门的负责人签字确认。签字这件事本身不产生约束力，但它把”口头承诺”变成了”书面记录”，后续抽人时必须走变更流程，而不是一句”临时借调”。

3. 把”工期倒推”当成”计划编制”

“这个项目10月必须上线，你们倒排一下。”这句话我听了太多次。倒排本身没有错，错的是把倒排结果直接当成计划基线，而不做可行性校验。

我的做法是要求同时提交两套排期：一套是按业务要求倒排的”目标排期”，一套是按团队历史速率和实际可用人力正推的”可行排期”。两者之间的差值就是需要决策的缺口，要么加资源，要么砍范围，要么接受延期。把差值藏起来，等于把风险推到执行阶段由一线团队承担。

4. 把”风险清单”当成”风险应对”

立项文档里写”存在人员流失风险””存在需求变更风险”，这不叫风险管理，这叫常识陈述。

真正的风险应对要回答三个问题：触发信号是什么、应对动作是什么、谁在什么时候执行。比如”如果核心架构师在项目周期内离职，由技术负责人在一周内完成知识交接评估，并从A、B两名备选人员中指定接手人，同时项目排期预留5个工作日缓冲”。

5. 把”预算总额”当成”成本可控”

一个项目批了500万元预算，不代表这500万是可控的。我见过很多项目在立项时只给一个总数，没有任何分解，结果执行到一半发现人力成本已经吃掉了预算的70%，而交付物还不到一半。

预算必须在立项阶段分解到人力、采购、外部服务、应急预备金四大类，其中应急预备金不低于总额的8%-12%，并且明确预备金的动用审批权限。没有预算结构的项目，成本失控只是时间问题。

6. 把”通过评审”当成”立项完成”

通过评审只是拿到了”可以做”的许可，立项真正完成的标志是项目章程签署、基线锁定、资源到位、启动会开完。我见过太多项目在”通过评审”后直接进入开发，章程没签、基线没锁，三周后所有人对目标的理解已经出现了三个版本。

四、专业判断逻辑：四道闸门与九步实操流程

讲完误区，我说说正面方法。我把立项判断拆成四道闸门，顺序不能颠倒，因为后一道闸门的评估成本远高于前一道。

1. 第一道闸门：价值闸，不做会怎样

价值闸要回答的是”为什么现在做，而不是明年做或者不做”。这里我要求业务方给出三类证据：痛点证据、收益假设、机会成本。

痛点证据不是”用户反馈不好用”，而是具体的量化事实，比如”客服团队每月处理重复咨询4200次，占用人力约2.5个全职当量”。收益假设要给出测算逻辑，允许是估算，但必须写清假设条件。机会成本是很多组织忽略的一环：如果不做这个项目，同样的人力投入其他方向能带来什么。

（1）价值闸的三个判断问题

• 这个项目解决了谁的什么问题，问题规模有多大？
• 如果不做，有没有更低成本的替代方案（流程调整、采购现成产品、部分自动化）？
• 收益是确定性的还是概率性的，最坏情况下的收益是多少？

2. 第二道闸门：范围闸，边界用什么方式钉住

范围闸的核心不是列清单，而是定义”什么不做”。我在每个立项文档里都要求有一个明确章节叫“本期不做清单”，至少列出五条被排除的内容，并说明排除理由和后续处理方式。

这个做法看起来反直觉，但效果极好。因为大多数范围争议不是”你少做了”，而是”我以为你做了”。把不做的事情写下来并让对方确认，就把默认预期变成了显性共识。

3. 第三道闸门：资源闸，谁在什么时候投入多少

资源闸要产出一张资源负荷表，包含人员姓名、角色、投入比例、投入时间窗口。我特别强调投入比例要用百分比，不用FTE模糊描述。

这里有个实操细节：对于投入比例超过50%的关键人员，必须交叉校验其现有项目的占用情况。我做过一次抽查，发现同一个架构师在四个项目里都被标记为”投入50%”，加起来200%，这显然不可能。资源闸的作用就是提前暴露这种幻觉。

4. 第四道闸门：风险闸，最坏情况是否可承受

风险闸不做风险清单，做的是”终止条件设定”。也就是说，提前约定好：如果出现哪些信号，项目必须暂停或终止。

常见的终止信号包括：核心人员离职超过两名、关键技术验证连续两次失败、单月实际成本超出计划20%以上、业务侧负责人变更且新负责人不支持该项目。把这些写在章程里，能极大降低组织的沉没成本陷阱。

（1）四道闸门的评估顺序不能颠倒

价值闸不过，后面三闸都不用评。范围闸不过，不要进入资源讨论。这个顺序的设计逻辑是：越靠前的闸门，评估成本越低，推翻的代价也越小。很多组织的问题是把顺序做反了，先讨论技术方案和排期，最后才想起来问”这事到底值不值得做”。

5. 九步立项实操流程

下面这套流程我在两家企业落地过，从需求提出到项目启动，标准周期5-8个工作日。

1. 需求登记（0.5天）：业务方在统一入口提交立项意向，填写问题描述、期望收益、期望时间，系统自动分配编号进入需求池。
2. 初筛分级（1天）：PMO对照战略地图和在建项目清单，排查重复建设和优先级冲突，判定项目级别（A/B/C级）并确定所需流程。
3. 价值评估（2天）：业务方完成收益假设和成本测算，财务复核测算口径，PMO出具价值评估意见。
4. 方案粗设（1-2天）：技术负责人给出实现路径和关键技术风险判断，只做方案级别评估，不做详细设计。
5. 资源预沟通（1天）：PMO与资源经理确认可用人力，形成具名资源负荷表。
6. 材料合稿（0.5天）：PMO整合形成立项申请书，包含目标、范围、资源、预算、风险、终止条件六部分。
7. 评审决策（0.5天）：按项目级别组织评审，A级项目由决策委员会评审，B级由PMO+业务负责人评审，C级走简化流程备案。
8. 章程签署与基线锁定（0.5天）：项目章程三方签字，目标、范围、验收标准正式成为基线，任何变更走变更流程。
9. 启动会与移交（0.5天）：召开启动会，向执行团队完整交付立项信息，明确沟通机制和汇报节奏。

（1）立项申请书的机器可读模板

为了让评审材料能结构化对比，我把立项申请书做成了可以解析的格式，这样PMO可以批量检查哪些项目缺少关键字段，而不是靠人工逐份翻看。

project_charter:
project_id: PRJ-2024-031

project_name: 客户主数据治理一期

level: A

sponsor: 销售运营总监 张某

project_manager: 李某

objectives: # 目标必须可量化、可验证

metric: 客户主数据重复率

baseline: "18%"

target: "≤3%"

deadline: "2024-06-30"

metric: 销售报表出具时间

baseline: "3天"

target: "≤4小时"

deadline: "2024-06-30"

scope:

in_scope: [主数据标准定义, 去重规则引擎, 与CRM/ERP双向同步]

out_of_scope: # 本期不做清单，至少5条

历史订单数据回溯清洗

移动端主数据维护

第三方数据源自动采集

客户画像标签体系

多语言主数据支持

resources:

name: 王某

role: 架构师

allocation: "60%"

window: "2024-01-08 ~ 2024-06-14"

confirmed_by: 技术中心负责人 赵某

budget:

labor: 2860000

procurement: 420000

external_service: 600000

contingency: 520000 # 预备金占比约11%

risks:

trigger: 核心架构师离职

action: 一周内完成交接评估并启用备选人

owner: 技术中心负责人

termination_conditions: # 终止条件，须在评审时确认

单月实际成本超计划20%且连续两月

关键数据源接入连续两次技术验证失败

业务侧负责人变更且新任负责人书面撤回支持

approval:

business: 已签署

technology: 已签署

pmo: 已签署

date: "2024-01-05"

这个模板的价值不在于格式本身，而在于它强制要求填写 out_of_scope 和 termination_conditions 两个字段。我观察到，只要这两个字段被认真填写，项目的后期争议就会显著减少。

五、具体案例与数据观察：一家320人企业的立项改造实录

前面讲了很多判断和方法，这一节我把一个完整案例拆开讲，包括我们踩的坑和真实的数据变化。

1. 改造前的基线数据

这家企业年营收约4.6亿元，研发与交付人员总计约180人，属于典型的成长型企业：项目数量增长快，但管理依赖个人经验，没有统一门槛。

我统计了改造前2021年全年立项的19个项目，基线数据是：立项评审平均耗时11.5个工作日，平均变更请求14.3次/项目，平均返工工时约380人天/项目，按期交付率54%，验收一次通过率47%。注意这里的返工工时只统计研发侧，不含业务侧配合成本。

2. 改造的核心动作只有三件事

我没有推翻原有流程重新设计，而是做了三件事：分级门槛、具名资源、终止条件。

分级门槛是把项目分成A/B/C三级，A级走完整评审，B级简化评审，C级只需备案。这一条直接把大量小项目的流程成本降下来了，让PMO能把精力投入到真正重要的项目上。

具名资源是把”研发部支持”改成”张某某60%从1月8日到6月14日”，并要求资源经理签字。这一条最初遭到很大阻力，因为资源经理不愿意过早承诺。我们的应对方式是把承诺窗口缩短，先锁定前两个月，后续按月滚动确认。

终止条件是新增的。我们在章程里明确约定了终止触发信号，并规定由项目发起人承担终止决策责任。这条规则最大的作用不是真的终止了多少项目，而是让业务方在提需求时更谨慎。

3. 立项流程线上化过程中的工具选择

流程设计好之后，第二个问题是落地。我们用表格跑了三个月，问题很快暴露：字段缺失无法强制校验、跨部门并发编辑冲突、版本追溯困难、资源负荷无法实时汇总。

这时候我们开始评估项目管理平台。我们的约束条件比较特殊：一是公司有数据合规要求，研发数据不能出内网；二是此前有团队在用Jira，积累了大量历史项目数据，不希望迁移时丢失。

最终我们选择了 PingCode。理由有三个：第一，它支持私有化部署，能满足我们的数据不出内网要求；第二，支持从Jira平滑迁移，历史项目、缺陷、迭代数据可以整体承接；第三，在国产替代方案里，它的功能完整度对中大型企业更友好。我们公司当时320人，研发序列约180人，正好落在它主要服务的中大型企业区间内。

落地时我做了三件事，现在回头看都很值得。

（1）把立项模板做成了强制校验表单

我把前面那个 project_charter 结构变成了系统里的必填字段，out_of_scope 少于5条无法提交，目标里没有 baseline 和 target 无法提交。这一条直接让立项材料的一次通过率从改造前的约40%提升到了78%。

（2）把资源负荷做成可视化看板

资源一旦按人、按时间窗口录入，系统就能自动汇总每个人的占用率。我们设置了一条规则：任何人未来两个月内的占用率超过95%就会标红，PMO在审批立项时必须处理红色告警。这个功能帮我们抓到过三次严重的资源超配，其中一次是同一名测试负责人被排进了五个项目的验收阶段。

（3）把终止条件做成可以触发的状态

我们在系统里给每个项目加了”风险状态”字段，当触发条件被标记为成立时，项目自动进入”待决策”状态，同时通知发起人和PMO。这样做的好处是终止决策不再依赖某个人的自觉，而是由流程推着走。

4. 改造后的数据变化

我们统计了改造后2022年下半年至2023年上半年立项的24个项目，与基线对比：立项评审平均耗时从11.5个工作日降到5.2个工作日，平均变更请求从14.3次降到6.8次，平均返工工时从380人天降到约152人天，按期交付率从54%提升到78%，验收一次通过率从47%提升到81%。

我要诚实说明两点。第一，这些改善不是单一因素造成的，工具、流程、组织重视度都有贡献，我不认为上了某个平台就能自动变好。第二，立项评审耗时下降和返工工时下降同时发生，恰恰说明”更严”不等于”更慢”，关键在于严格的部分是否用在了正确的环节。

5. 我们在迁移和部署上踩过的三个坑

第一个坑是字段映射。原有Jira里的工作流状态有17个，直接迁过来会造成状态混乱。我们做了一次状态归并，压缩到6个标准状态，再迁移。这个工作花了大约四个人天，但避免了后续半年的状态混乱。

第二个坑是权限结构。私有化部署环境下，权限模型需要重新设计。我们初期把项目权限按部门划分，结果跨部门项目出现了大量权限申请。后来改成”按项目角色授权+按数据敏感级别兜底”的模型，问题才解决。

第三个坑是历史数据的使用方式。我们最初想把所有历史项目都迁进来做统计分析，但老数据的字段完整度很差。最后只迁了近两年的活跃项目和全部缺陷记录，老项目做归档处理。这个取舍很重要，历史数据的价值在于可追溯，不在于全量堆砌。

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

方法不是普适的。同样一套立项机制，放在10人团队和放在2000人集团里，做法完全不同。下面按组织规模和业务特征给出我的建议。

1. 10-50人团队：只做两件事

这个阶段不要搞立项评审会，会把人耗死。我建议只保留两个动作：一页纸目标卡和口头资源确认记录。

一页纸目标卡包含四行：要解决什么问题、成功标准是什么、谁负责、什么时候能验证。写完发到群里，业务方回复”确认”即可。口头资源确认记录是指，任何超过两周的项目，负责人都要把”谁参与、投入多少”用文字发出来，哪怕只是发在群里。

这个规模不需要工具，一张表格足够。过度流程化在这个阶段是负收益，会拖慢所有决策。

2. 50-300人成长型企业：PMO需要建立分级门槛

这个阶段的典型特征是项目数量快速增加，资源冲突开始出现，但组织还没有形成统一语言。我认为这是立项方法论投入产出比最高的阶段。

建议做三件事：建立A/B/C三级立项门槛、把资源承诺落到具名、设置项目终止条件。这三件事做完，通常能把返工比例降低10-15个百分点。

工具方面，这个规模开始需要系统支撑。选择时需要重点看两个能力：是否能按人按时间窗口做资源负荷汇总，是否支持立项字段的强制校验。这两点是纸质流程做不到的。同时要留意部署方式的灵活性，因为到了300人以上，数据合规和系统自主可控往往会成为硬约束。

3. 300-1000人多事业部组织：立项要解决”重复建设”问题

到了这个规模，最大的浪费不是单个项目做砸，而是不同事业部在重复做同一件事。我在一家约800人的企业见过三个事业部同时在自建报表平台，功能重合度超过60%。

立项阶段要增加一个动作：跨事业部查重。具体做法是建立一个在建项目公开清单，所有立项申请必须先检索清单，如果存在重合，必须说明为什么不能复用或共建。

另一个建议是把立项评审委员会做实，而不是虚设。委员会成员要固定，评审意见要记录，决策要有回执。VC（决策委员会）如果每次换人参加，标准就会漂移。

4. 强合规行业：把立项材料当成审计证据来管理

金融、医疗、能源等行业的项目，立项文档本身可能就是审计证据。这类组织的立项重点不是效率，而是可追溯性。

我的建议是：所有立项决策过程留痕，包括谁提交、谁评估、谁反对、为什么通过。反对意见尤其重要，很多年后出问题时，反对意见能证明组织当时做过合理审慎的判断。

同时建议把版本管理做扎实。立项材料修订到第三版时，必须能清楚看到每一版改了什么、由谁改的、依据是什么。这一条在纯手工流程下极难保证，通常需要系统支撑。

七、不同情况下的取舍

立项管理本质上是一连串取舍，没有全都要的选项。下面四组取舍是我在实操中被问到最多的。

1. 决策速度与决策严谨度的取舍

当一个项目有明显的市场窗口期时，我倾向于接受较低的严谨度换取速度。具体做法是把完整评审拆成”快速放行评审”和”30天复盘评审”两步：先花半天时间只判断价值闸和资源闸，允许启动；30天后再做完整评估，如果价值假设不成立就止损。

这种做法的成本是可能需要终止一个已经启动的项目，但相比错过窗口期，这个成本通常是可接受的。关键是要在第一次评审时就明确告知：这是有条件放行，30天后重新决策。

2. 标准化与灵活性的取舍

我的判断是：流程可以标准化，模板不要过度标准化。立项流程的步骤、门槛、评审角色应该统一，但立项材料的表达方式可以允许差异，尤其是技术方案部分。

我见过一些组织把模板做到200多页，结果业务方为了填模板花了两周，填完自己都不知道写了什么。模板的目的是降低沟通成本，如果它本身成了成本，就该精简。

3. 工具投入与人工投入的取舍

这里我有个明确的经验判断：年立项数量少于15个的组织，不要急着上专业平台，结构化表格加人工审核的性价比更高。当年立项数量超过25个、或者并发项目超过10个时，工具的收益会快速显现，主要体现在资源负荷汇总、字段强制校验、历史数据检索这三件事上。

选平台时，我建议把部署方式和迁移成本放在功能清单之前考虑。私有化部署能力决定了长期的数据自主性，历史数据迁移能力决定了切换成本。对于已经在用Jira的团队，能否平滑迁移往往直接决定项目落地周期是两个月还是半年。这两点在评估阶段多花一周时间，比后续返工划算得多。

4. 集中管控与前端授权的取舍

PMO常见的一个错误是把所有决策权收到自己手里，结果变成瓶颈。我的做法是按金额和风险分级授权：低于一定金额且无跨部门依赖的项目，由业务负责人自行决策，PMO只做事后备案抽查；超过阈值或有强依赖的项目，必须走完整评审。

这条规则的价值在于让PMO从”审批者”变成”规则制定者和例外处理者”，精力集中在真正有风险的项目上。

八、结尾：立项能力的本质，是组织敢于说”不”的能力

写到这里，我想说一个可能不太讨喜的观点：大部分组织的立项问题，不是方法论缺失，而是组织不愿意在做之前说”不”。

因为说”不”要承担人际成本，要面对”你是不是不支持业务”的质疑。所以很多PMO选择把力气花在执行阶段，用加班和协调去弥补立项时的妥协。但数据告诉我们，这条路走不通，立项时模糊的一句话，在执行期往往要用几十人天去填。

我在这三年里最大的收获，不是建立了多少流程，而是让组织慢慢接受了一个共识：拒绝一个不该启动的项目，和交付一个好项目，是同等重要的贡献。

如果你现在正准备优化所在组织的立项流程，我建议下一步按这个顺序做：

1. 先做一次回溯统计。把过去一年立项的项目拉出来，统计变更请求次数、返工工时、按期交付率，看看立项质量与这些指标的关系。用自己组织的数据说话，比引用任何外部报告都有说服力。
2. 再挑一个项目做试点。选一个即将立项、规模适中、业务方配合度高的项目，按四道闸门和九步流程走一遍，把过程中的阻力和耗时记下来。
3. 然后固化最小的必要规则。不要一次上全套，先落地两条：目标必须可量化验证、资源必须具名到人。这两条能解决大部分问题。
4. 最后再考虑工具承载。当规则跑通、痛点明确之后，再评估是继续用表格还是引入平台。评估时把部署方式、历史数据迁移、资源负荷汇总能力放在优先级最高的位置。

立项不会让项目自动成功，但它能让组织在错误的路上少走很远。PMO真正的专业度，体现在别人还在讨论怎么做的时候，你已经判断出这件事该不该做。这是我做了三年PMO之后，最想分享的一句话。