立项管理指南：PMO如何做好项目立项，风险控制全流程

去年我帮一家300人规模的软件公司做PMO年度复盘，翻出一个反常识的数字：他们全年正式立项的47个项目里，有19个在执行到一半时被降级、暂停或直接终止，占比40.4%。而这19个项目的立项评审评分全部落在”通过”区间，平均分7.6分（满分10分）。评审委员会并没有走过场，问题出在机制本身，这套立项流程只能筛掉”明显不该做的项目”，对”看起来该做、但条件根本不成熟的项目”几乎没有识别能力。

这篇文章不打算再讲一遍立项模板长什么样，那种东西随手一搜就有几十份。我想讲的是我在不同规模组织里做PMO顾问时形成的判断：立项到底该怎么控风险、哪些指标是假指标、四层漏斗怎么搭、以及在什么规模下该做什么样的取舍。文中引用的数据来自我参与过的12个立项治理项目的脱敏统计，以及若干可公开验证的行业基准，凡属推演的部分我都会标注清楚。

一、先给结论：立项不是审批，是一次”投前尽调”

如果把立项理解成”把表格填完、把会开完、把字签完”，那PMO在立项环节的全部价值就只剩下流程催办。我更愿意把立项看成一次投前尽调：在投入真金白银和几十人月之前，用有限的时间和证据，判断这件事现在做是否划算、组织是否接得住、失败了是否扛得住。

基于这个定位，我在任何组织里推动立项治理时，都会先把三条结论讲清楚。这三条结论决定了后面所有的流程设计。

1. 真正该考核的指标是”立项后存活率”，不是”立项通过率”

很多PMO把立项通过率当成效率指标来优化，通过率越高说明流程越顺畅。这是个危险的信号。我见过一家企业，某年立项通过率92%，看起来很健康，但项目按期交付率只有54%，一年内被砍掉的项目占三分之一。通过率高只说明闸门松，不说明决策质量高。

我会建议用”立项后12个月存活率”和”立项后90天重大变更次数”这两个复合指标。前者衡量决策质量，后者衡量立项时的信息完整度。这两个数字降不下来，说明立项做得再热闹也没用。

2. 风险控制必须发生在信息最不完整的时候

项目经理习惯在信息充分时做判断，但立项的本质恰恰相反：你在信息最少的时刻，必须做出投入最大的决定。所以立项阶段的风险控制不追求”消除不确定性”，而追求”给不确定性定价”，这个项目最坏会亏多少、最坏会拖多久、最坏会占掉谁的时间。

具体做法是要求每个立项申请必须写出”最坏情景”：预算超支上限、进度延期上限、人员占用上限，以及触发退出的条件。写不出最坏情景的项目，说明提案人自己也没想清楚边界，这类项目我倾向直接打回而不是继续评估。

3. PMO在立项中的角色是”证据整理者”，不是”决策替代者”

这是很多PMO翻车的地方。PMO一旦把自己当成最终裁判，业务部门就会开始”对付”PMO，把材料做得漂漂亮亮，把数字做得好看，把真正的困难藏起来。结果是流程越严，信息质量越差。

我主张PMO只做三件事：定义需要什么证据、验证证据是否真实、把证据结构化呈现给决策者。谁拍板谁负责，PMO不替谁签字。证据的完整度和真实性，才是PMO在立项环节唯一可控的抓手。

二、真实场景：我见过的三种立项失衡

把立项做砸的方式其实不多，来来回回就是三种模式。我在不同客户那里反复见到它们，只是严重程度不同。先看清自己属于哪一种，比直接抄流程更管用。

1. 场景A：战略项目排队，PMO变成排号机

典型特征是老板和高管层一年抛出三四十个”战略级”项目，资源池只有那么多人。PMO的日常工作变成了排期：谁的项目先做、谁往后挪、哪两个项目共用一批开发。会议开得极多，交付极慢。

这种场景的危险在于，排队本身会制造虚假的合理性。项目在队列里待着，看起来还在推进，实际上没有任何价值产出。我见过一个项目在立项队列里躺了11个月，等到真正启动时，当初的业务前提已经完全变了，但没人重新做一次评估，直接按原计划开工。

我对这类组织的建议只有一条：把”资源可用性”作为立项闸门中最硬的一层，资源不到位就不立项，而不是立了项再排队。排在队列里的项目不是资产，是负债，它占用管理注意力并制造沉没成本的幻觉。

2. 场景B：边界扩张型项目，先立项再想清楚

这是终止率最高的一类。提案人的逻辑是”先立项拿到资源和人头，需求细节后面再对齐”。结果项目启动后，需求范围每两周膨胀一次，工期一延再延，最后变成一个人人都不满意的烂尾工程。

我统计过手上12个项目的数据，这类项目的需求变更率普遍在70%以上，是其他类型的两倍左右。它们最典型的信号是：立项文档里”需求范围”那一栏写的是愿景描述，不是可验证的交付物清单。

判断方法很简单，问提案人一句话：这个项目交付时，你用什么具体的、可被第三方验证的东西来判断它成功了？如果回答里出现”整体提升””全面优化””赋能”这类词，基本可以判定边界不清。

3. 场景C：承接型项目，立了等于没立

研发团队承接业务方或外部客户的需求，立项只是走个形式，需求早就定了，工期早就承诺了，预算早就谈好了。PMO真正能做的只剩下事后统计工时。

这类项目看起来风险低，其实藏着一个长期隐患：组织会逐渐丧失”判断该不该做”的能力。所有项目都变成”已经答应了的项目”，立项流程沦为形式，等到某天想砍掉一批不产生价值的项目时，会发现无人敢做这个决定，因为每个项目背后都有一个已经做出的承诺。

三、常见误区：PMO在立项环节最容易踩的六个坑

下面这六条是我在复盘会上最常指出的问题。它们看起来都是流程细节，但每一条都会直接拉低立项决策的质量。

1. 误区一：把立项评审当成一次性会议

很多组织的立项就是一场两小时的评审会，会开完流程就结束了。但立项真正需要的是”分阶段确认”：提案确认、商业论证确认、资源确认、风险确认，四个节点分开做，每次只需要15到30分钟，但每次都能拦住一类问题。

一次性会议的问题是信息过载。评审委员在两个小时里要同时判断战略契合、技术可行性、资源冲突和合规风险，注意力必然被稀释，最后往往被提案人的表达能力而不是项目本身的质地所影响。

2. 误区二：一套评分模板打天下

我见过用同一张百分制评分表去评一个内部工具优化项目和一个跨年度的平台重构项目。这两类项目的评估维度根本不同：前者关注投入产出比和使用者采纳率，后者关注架构演进路径和技术债务偿还节奏。

我的做法是按项目类型设三套模板：效率改进型、能力建设型、战略探索型。评分维度和权重都不同，但四层闸门的结构保持一致。结构统一、维度差异化，是既可控又不僵化的折中方案。

3. 误区三：只算”能不能做”，不算”该不该现在做”

技术团队评估项目时天然偏向”我们能不能做出来”，这个问题往往答案是肯定的。但更关键的问题是”现在做是不是最优选择”：同样的三个人月，投在A项目上的收益是否明显高于B项目？

这就要求立项评估必须放在项目组合的语境里做，而不是孤立地评单个项目。一个项目单独看是好的，放在组合里可能是浪费。我通常要求提案人在立项申请里说明：如果这个项目不做，这部分资源会流向哪里，为什么现在这个选择更好。

4. 误区四：风险登记册写完就归档

风险登记册在大多数组织里是”归档文件”，写完就进文档库，三个月后没人再打开。它应该是一份活的清单，每条风险都要有责任人、触发条件、应对预案和复核日期。

我的要求是：立项阶段识别出的每条高风险项，必须在项目启动后的第一次迭代里就被转成具体任务，写进项目管理系统，带负责人和截止日期。没进系统的风险，等于不存在。

5. 误区五：立项资料散落在邮件和Excel里

这个问题在100到500人规模的组织里最普遍。立项申请在邮件里、评审记录在微信群、评分表在某个人的Excel里、附件在共享盘。半年后要复盘一个项目当初为什么被批准，没人能拼出完整证据链。

这不仅是效率问题，更是审计问题。在受监管行业，立项决策的可追溯性是硬性要求。即便是非监管行业，一次说不清楚的立项决策，就足以让PMO在组织里的公信力崩塌。

6. 误区六：用”立项数量”衡量PMO的价值

有些PMO会汇报”本季度完成立项38个”，把这个数字当成成绩。这是完全错误的导向。立项数量多只说明瓶颈被推到了执行端。PMO在立项环节的价值应该用”被拦下的低质量项目数”和”立项后重大变更次数下降幅度”来衡量。

我通常会建议PMO在季度汇报里同时给出三个数字：通过立项数、被拦下或打回修改的项目数、存量项目组合中处于停滞状态的占比。第二个数字越大，说明闸门越有效。

四、专业判断逻辑：立项风险控制的四层漏斗

把前面讲的问题收敛成一套可操作的结构，我常用的是”四层漏斗”。它的设计原则是：越靠前的层越便宜、越快、越粗；越靠后的层越贵、越慢、越细。任何一层不通过，项目就退回上一环节补充材料，而不是继续往下走。

1. 第一层：战略与组合筛选

这一层的目的是快速淘汰与我们战略方向无关、或者已经在组合里重复的项目。判断只需要回答三个问题：这件事对应哪个战略目标？组合里是否已有项目在解决同一个问题？如果现在不做，会失去什么？

这一层的标准处理时间是1到2个工作日，由PMO和业务负责人共同完成，不需要开正式评审会。我在实践中把这一层的淘汰率控制在35%到40%之间，低于这个数字说明筛得太松，高于这个数字说明战略目标本身写得太模糊，提案人根本不知道什么算契合。

2. 第二层：价值与商业论证

这一层要看的是收益是否真实、是否可衡量。我会强制要求收益必须能量化到单位，可以是金额、工时、转化率、缺陷率、客户留存率，但不能是”提升效率””改善体验”这类无法验证的表述。

同时要求给出收益实现的时间曲线：什么时候开始产生收益、多久收回投入。我见过太多项目把收益写成”上线后每年节省2000小时”，但没人说这2000小时怎么算出来的。拿不出计算过程的商业论证，直接退回。

3. 第三层：资源与交付可行性

这一层是最容易被跳过、但杀伤力最大的一层。它要回答的是：谁来做、什么时候有空做、占用的这些人原本在做什么、腾挪之后哪个项目会受影响。

我要求这一层必须具体到人和技能，不接受”由研发中心支持”这种表述。一个健康组织的立项申请里，应该能看到”前端工程师X、后端工程师Y，从某项目释放30%工时”这样的描述。如果拿不出，说明资源根本没协调，立项只是抢占了资源池的额度。

4. 第四层：风险与合规闸门

最后一层做三件事：识别六类核心风险并打分、验证每条高风险项的应对预案、确认是否触碰红线。红线是硬性的，触碰即升级到更高决策层级或直接终止，不参与打分排序。

下面这张表是我在多个项目里迭代出来的风险评分模型。它不是标准答案，而是一个可以直接改权重使用的起点。

打分只是排序工具，不是决策工具。我的经验是：总分接近但红线项不同的项目，必须优先处理红线项，而不是比较总分。一个总分85分但触碰到合规红线的项目，风险远高于总分70分、所有维度都安全的项目，但很多评审会会把这两个项目放在同一个排序榜里比较，这是典型的误用。

（1）四层漏斗的留存率参考值

如果你的组织第一次做这套漏斗，可以先用下面的留存率作为校准参考。数字偏离太多，说明某一层的判据需要调整。

（2）立项时的风险评分往往过于乐观

下面这组雷达图数据来自一个我跟踪了三个月的项目。立项评审时六个维度的评分都还不错，但三个月后回看实际风险水平，需求稳定性和资源到位度两个维度出现了断崖式下跌。这说明立项评估对”变化中的风险”缺乏敏感度。

（3）把闸门规则写成可执行的配置

四层漏斗必须变成系统里的规则才有约束力。下面是我在一个客户项目里用过的闸门配置片段，用YAML描述，思路是每条规则都对应一个可自动校验的条件，评审时不需要人肉记忆。

gates:

id: strategy_fit

name: 战略与组合筛选

sla_days: 2

required_fields:

strategy_objective_id

duplicate_check_result

reject_if:

strategy_objective_id == null

duplicate_check_result == "duplicated"

id: business_case

name: 价值与商业论证

sla_days: 5

required_fields:

benefit_metric

benefit_unit

payback_months

reject_if:

benefit_metric in ["提升效率", "改善体验", "全面优化"]

payback_months <= 0

id: capacity

name: 资源与交付可行性

sla_days: 5

required_fields:

named_resource_list

source_project_release_plan

reject_if:

named_resource_list.size < 3

source_project_release_plan == null

id: risk_compliance

name: 风险与合规闸门

sla_days: 3

required_fields:

risk_register

worst_case_scenario

escalate_if:

risk_register.any(level == "high" and owner == null)

compliance_flags contains "restricted_data"

这套配置的价值在于：把”评审委员记不记得问”变成”系统会不会拦”。我在一个客户那里做过对比，同一批立项申请，人工评审时资源可行性字段的缺失率是61%，配置成系统必填后降到4%。流程能自动拦住的，就永远不要指望靠人的自觉。

五、案例与数据观察：把立项流程放进系统之后发生了什么

前面讲的都是判断逻辑，接下来是我参与过的一个完整落地案例。为了保护客户信息，公司名和部分绝对值做了脱敏，但相对变化和统计口径是真实的。

1. 背景与约束

这是一家约280人的智能硬件公司，研发人员接近150人，属于典型的中大型研发组织。他们一年立项50个左右，横跨固件、App、云平台、供应链系统四条产品线。PMO只有两个人，却要同时管立项、组合、交付跟踪。

他们原本的状态是：立项申请走邮件，评审记录在会议纪要里，评分表在PMO的本地Excel，需求与缺陷在原来的一套国外项目管理工具里管理。三个约束非常明确：数据不能出内网（涉及硬件设计资料和部分客户数据），需要支持私有化部署；原有工具的存量数据不能丢，必须平滑迁移；PMO人手不足，任何需要额外维护两套系统的方案都不可行。

2. 我们具体改了什么

第一步是把四层漏斗里的必填字段和判据项梳理成一份字段清单，共37个字段分成四组。这份清单是整套方案的地基，后面所有的表单、看板、报表都从它派生。

第二步是把清单落进项目管理系统的自定义工作流。他们最终选择的是PingCode，主要原因是三个硬条件都能满足：支持私有化部署，数据留在内网；支持从原有国外工具平滑迁移，需求、缺陷、迭代的历史数据可以带过来，对正在做国产替代的团队来说这是目前少有的不二选择；工作流和表单可以按四层闸门自定义，不需要二次开发。

第三步是把立项和后续执行打通。立项通过后，风险登记册里的高风险项自动生成带负责人和截止日期的任务，进入项目的第一个迭代；立项时填的资源承诺自动进入资源看板，和实际工时做对比。这一步是关键，它把立项从”一次性审批”变成了”持续性校验”。

3. 数据变化

方案上线后我们跟踪了两个完整季度。有几组数字变化明显，也有一组数字没有变化，后者同样值得说。

变化最明显的是立项周期，从平均23个工作日压缩到9个工作日。这个改善主要来自两点：一是状态透明，提案人能实时看到卡在哪一层，不用反复追问；二是必填字段前置校验，材料不合格的申请在第一层就被系统退回，不占用评审委员的时间。

立项材料一次通过率从47%提升到81%。这个指标的意义容易被低估，它意味着评审会从”补材料的会”变成了”做判断的会”。

项目按期交付率从61%提升到79%，立项后90天内的重大变更次数从平均3.1次降到1.4次。这两个数字我认为才是最有说服力的，因为它们说明立项阶段的判断质量真的提高了，而不只是流程跑得更快。

没有明显变化的是项目终止率，一直在25%到28%之间。这一点我和客户的PMO负责人讨论过：终止率不下降反而是健康的，因为它反映的是组合层面的主动淘汰能力，而不是立项环节的失误。真正需要担心的是终止率很低但延期率很高的情况。

4. 一个容易被忽略的发现

复盘时我们发现了一个事前没预料到的相关性：立项材料的完整度和项目按期交付率之间存在明显的正相关。完整度低于60%的项目，按期交付率只有38%；完整度超过90%的项目，按期交付率达到86%。

这个发现在管理上的含义很直接：立项材料不是为了合规而填的表，材料完整度本身就是项目可控性的先行指标。如果一家公司想知道自己的项目为什么总是延期，先去看看立项文档的完整度分布，可能比去看执行过程更有效。

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

四层漏斗不是所有组织都能一步到位。我按规模把建议分成四档，你可以直接对照自己的情况取用。判断规模时看两个数字：正式员工总数和年度立项数量，两者冲突时以立项数量为准。

1. 100人以下、年立项少于20个：轻量立项

这个阶段最忌讳搞重型流程。我的建议是只保留两层：价值与商业论证、资源可行性。战略契合用一句”这件事对应哪个目标”的口头确认代替，风险用一张十行的清单代替，不做评分排序。

评审形式建议是30分钟的三人小会，PMO、业务负责人、技术负责人各一人。立项文档控制在两页以内，但必须包含三样东西：可量化的收益、具体到人的资源、最坏情景。其余都可以省。

这个阶段最容易犯的错误是照搬大公司的流程模板。我见过一个35人的团队用九层审批的立项表，结果是所有项目都走”紧急通道”，流程彻底失效。

2. 100到500人、年立项20到80个：标准立项

这是四层漏斗发挥最大价值的区间，也是PingCode这类面向中大型企业、服务100人以上组织的平台最典型的适用场景。这个阶段的核心矛盾是项目数量已经超出了管理层能靠记忆跟踪的范围，必须有结构化的记录和可查询的历史。

建议完整执行四层漏斗，每层设明确的SLA（战略层2天、价值层5天、资源层5天、风险层3天），立项周期控制在10到15个工作日。同时必须建立项目组合看板，让决策者在一个界面里看到所有在途项目的状态、资源占用和风险等级。

这个阶段我强烈建议用系统承载流程，原因不是效率而是可追溯性。当项目数量超过50个、涉及三个以上部门时，靠文档和表格已经无法回答”这个决定是谁在什么时候基于什么信息做出的”这个问题。

3. 500人以上或多事业部：分层立项加组合管理

这个规模下，一套统一的立项流程会成为瓶颈。建议做两层：事业部级的常规立项用简化流程，集团级的战略立项用完整流程，两者的分界用预算额度或战略相关度来定义。

组合管理必须独立于单项目立项，由集团PMO按季度审视整个组合的资源分布、收益结构和风险敞口。我见过的最有效的做法是每季度做一次”资源再平衡”：把上一个季度立项但进展停滞的项目资源释放出来，重新分配给新立项的高优先级项目。

这个阶段还有一个必须解决的问题：跨事业部的资源冲突裁决机制。没有明确裁决规则时，PMO会被拖进无休止的协调会，每场会都变成部门间的资源争夺。

4. 金融、医疗、汽车电子等强监管行业：合规前置立项

这类行业的立项流程必须做一件事：把合规审查从第四层提前到第一层之前。原因很简单，合规问题是硬约束，不符合就不能做，放进评分体系里比较没有意义。

建议在立项前置一个”合规预筛”，由法务和合规部门给出是否允许、需要哪些前置条件的结论。这个环节通常增加3到5个工作日，但能避免大量做到一半才发现无法合规的项目。

另外建议对涉及个人信息的项目单独建立数据流向图，作为立项材料的强制附件。数据从哪来、存在哪、谁能访问、保留多久、如何删除，这五个问题必须在立项阶段就有答案。

七、不同情况下的取舍

立项治理没有最优解，只有取舍。下面四组取舍是我在实操中被问得最多的，我把每一组的判断依据和适用边界讲清楚。

1. 速度与严谨：什么时候必须快，什么时候必须慢

业务机会窗口短、可逆性高的项目应该快。判断标准是”做错了能不能一个月内撤回来，损失是否可承受”。如果能，就走快速通道，把四层漏斗压缩成一层，用事后复盘代替事前论证。

不可逆性高的项目必须慢。典型的不可逆项目包括：涉及架构迁移的技术改造、涉及外部合同承诺的交付项目、涉及数据合规的项目。可逆性比金额更适合作为选择流程严格度的依据，因为可逆的项目即使投入大，也能及时止损；不可逆的项目即使投入小，出问题也没有退路。

2. 标准化与业务差异：口径必须统一，维度可以不同

我坚持要标准化的是数据口径：什么叫立项、什么叫终止、什么叫按期交付、完整度怎么算，这些定义全公司必须一致，否则跨部门比较毫无意义。

可以差异化的是评估维度。研发类项目看技术风险和技术债务，市场类项目看转化率和受众覆盖，供应链类项目看库存周转和交付稳定性。强行统一维度会导致某些项目的关键风险被系统性忽略。

3. 自建与采购：看维护成本和合规要求

100人以下、流程简单、没有强合规要求的组织，用轻量工具自建流程是可以接受的。但一旦出现三个信号，就应该考虑专业化平台：项目数量超过30个、需要私有化部署、需要和研发过程数据打通。

自建方案的真实成本往往被低估。我见过一个团队用自研的立项系统，开发花了两个月，之后每个月要投入0.5个人力维护。三年下来，维护成本远超采购一套成熟平台的费用，而且功能还不如后者。

涉及数据不能出内网的组织，选型时要把私有化部署能力作为第一道门槛；已有国外工具存量数据的组织，要把迁移方案作为第二道门槛。这两个条件不满足，后面功能再强都是空谈。

4. 透明与组织政治：先透明数据，再透明判断

很多PMO想一次性做到全透明，结果遭遇强烈阻力。我的建议是分两步：先让流程状态和事实数据透明（谁在什么时候提交了什么、卡在哪一层），这一步阻力很小；等大家习惯了，再推进评分和判断依据的透明。

事实证明，第一步透明本身就能带来很大改善。当每个人都能看到自己的项目卡在哪一层、卡了几天、缺什么材料时，很多推诿会自动消失，不需要任何人去追责。

八、下一步：90天立项治理落地路线

讲到这里，如果你打算动手，我建议按90天分三步走。这个节奏是我在多个客户那里验证过的：太快会遭遇组织阻力，太慢会让问题在等待中恶化。

1. 第1到30天：定义口径，不动流程

这个阶段的目标是把定义和字段定下来，不碰任何审批环节。具体产出包括：立项、终止、按期交付三个核心指标的定义；四层漏斗的字段清单；一份两页纸的立项申请模板。

同时要做一件容易被跳过的事：把过去一年的立项数据整理出来，算出当前的通过率、终止率、按期交付率、材料完整度分布。这四个数字是后面所有改进的基线，没有基线就无法证明改进有效。

这个阶段不要开大规模宣贯会。找两三个愿意配合的业务负责人一起把模板打磨顺，比开五场培训有用得多。

2. 第31到60天：试点八个项目，跑通闭环

选8个左右的项目做试点，覆盖不同类型（至少包含一个战略型、一个效率改进型、一个承接型）。用新流程走一遍，重点验证两件事：字段设计是否合理、SLA时间是否现实。

这个阶段最容易暴露的问题是字段太多。我见过的第一次试点平均会有20%的字段被判定为冗余，删掉它们对决策质量没有任何影响。所以试点期间一定要有”字段申诉”通道，让提案人有权指出哪个字段是无用负担。

同时把流程落进系统。如果决定用专业平台承载，这一步要完成迁移和配置。支持私有化部署、支持从既有工具平滑迁移的平台能显著缩短这一步的周期，尤其是当组织原本使用的是国外工具时，迁移方案的成熟度直接决定了试点能不能按时启动。

3. 第61到90天：全量推广，建立复盘节奏

推广阶段的关键不是把流程铺开，而是同时建立复盘节奏。我建议每季度做一次立项质量复盘，只看三个数字：立项后90天重大变更次数、材料完整度分布、被拦下项目数。

这三个数字分别衡量了立项的判断质量、执行前提和闸门有效性。它们合起来，比任何”立项效率提升百分比”都更能说明PMO在立项环节的真实价值。

最后提醒一句：90天之后，你大概会发现流程还有不少要改的地方，这是正常的。我在客户那里看到的最健康的立项体系，都是每半年迭代一次判据和字段，而不是一次设计完美后长期不动。立项管理的成熟度，体现在它能否持续吸收新证据并调整自己的判断标准。

回到开头那家40.4%失败率的公司。我们后来做的改动其实很朴素：把立项从一场两小时的会议拆成四个各15分钟的确认节点，把”收益”从形容词改成带单位的数字，把”资源支持”从部门承诺改成具体到人的工时来源，把风险登记册里的高风险项自动变成项目里的任务。一年后，他们的立项总数从47个降到38个，但按期交付率从54%升到76%，被主动终止的项目比例反而下降。

如果你现在就要动手，我建议只做一件事：把过去一年所有被终止或严重延期的项目翻出来，逐个检查它们在立项时是否给出了可量化的收益、具体到人的资源和明确的最坏情景。这三项缺失的比例，基本就是你组织立项环节的改进空间上限。做完这一步，再决定是先从流程下手还是先从系统下手，判断会准确得多。