项目目标关键结果全流程：PMO流程优化与一文讲清

2022年下半年，我作为外部顾问进过一家做工业设备的公司。他们的PMO团队只有三个人，却要盯住全公司四十多个在跑的项目。我去的第一周，拿到一份很漂亮的《年度项目目标分解表》，每一行都写着项目名、负责人、目标、关键结果、完成时间，格式比我见过的很多大厂都规范。

但当我随机问五个项目经理“你这个季度的KR现在完成到什么程度”，有三个人需要回去翻Excel，还有一个人反问我：你说的是哪个版本的KR？那一刻我基本判断出这家公司的病根，他们把目标管理做成了文档工程，而不是流程工程。

这件事后来成了我做PMO咨询时反复引用的案例。《项目目标关键结果全流程：PMO流程优化与一文讲清》这个题目之所以值得认真写，是因为绝大多数团队缺的从来不是OKR模板，而是一条从战略解码到知识沉淀、能把目标和结果真正串起来的流程链。这篇文章，我会把自己在制造、软件、金融三类组织里踩过的坑、做过的取舍、量化过的改进，按八个关口拆开讲清楚。

一、先把结论摆在前面：PMO做目标管理，本质是设计关口而不是催进度

我见过太多PMO把“目标管理”理解成“收集目标、汇总进度、开会催办”。这三个动作做完，PMO就变成了一个高级文员岗位，价值感极低，还容易被业务方嫌弃“只会添麻烦”。

做了这么多年项目治理，我的核心判断只有一句话：目标不会因为被写下来而实现，它只会因为穿过一系列设计良好的关口而实现。PMO的真正产品不是表格和会议纪要，而是这些关口的规则、模板、数据口径和升级路径。

1. 我对“项目目标关键结果全流程”的五个基本判断

在展开细节之前，先把态度亮出来。下面五条是我在多类组织里反复验证过的判断，后面所有章节都是它们的展开。

• 判断一：流程的价值在于衔接，不在于审批数量。关口太多会把项目拖死，关口太少会让目标失控，PMO要做的是找到“刚好够用”的那条线。
• 判断二：KR必须是结果语言，不能是任务语言。“参加10次评审会”是任务，“把需求返工率压到8%以下”才是结果。绝大多数失败的OKR，都死在这一步。
• 判断三：对齐要分纵向和横向两条线。纵向上接战略，横向上解依赖，只做纵向对齐的组织，跨部门项目一定会卡在接口上。
• 判断四：治理强度必须分级。战略级项目和试验型项目用同一套汇报半径，是PMO流程被吐槽“太重”的头号原因。
• 判断五：度量不是为了考核，是为了发现问题。指标一旦被直接挂到个人绩效上，数据质量会在一到两个周期内迅速恶化。

2. 为什么我坚持用“关口”而不是“阶段”来描述全流程

“阶段”是一个时间概念，它暗示流程是自然推进的；“关口”是一个判断概念，它强调每个节点都必须有人做出明确的“通过/退回/带条件通过”决定。

这中间的差别非常大。用阶段思维管项目，PMO会问“现在到哪个阶段了”；用关口思维管项目，PMO会问“这个关口的输入齐不齐、输出达没达到、谁签字放行”。前一个问题业务方可以敷衍，后一个问题敷衍不了。

3. 这篇文章的阅读方式

如果你是PMO负责人，建议重点看第四章的八个关口和第六章的案例数据；如果你是项目经理，第三章的六个误区和第七章的分规模建议会更直接可用；如果你是中高层管理者，第一章的判断和第八章的取舍逻辑，是帮你判断“要不要给PMO放权”的关键。

二、为什么“有目标没结果”：三个我亲历的真实场景

我几乎每次做PMO诊断，都会先让团队把当前在跑的项目目标和最近一次的实际进度同时打开。十次里有七次，两边对不上。不是数据错了，而是目标和执行早就脱钩了。

1. 场景一：目标写在立项书里，从签字那天起就没人再看

2021年我在一家做医疗器械的公司做流程优化。他们每个项目立项时都要写一份《项目目标说明书》，内容包括业务目标、关键结果、里程碑、预算、风险，写得非常认真。但我抽查了二十份立项书，发现只有两份在项目执行中期被打开看过，其他十八份的生命周期止于签字。

问题不在立项书本身，而在立项之后没有任何机制让这份文件和后续执行产生联系。周会上讨论的是任务列表，月度汇报讲的是人力占用，没有一处和当初写下的KR做对照。目标文件成了合规凭证，而不是执行指南。

2. 场景二：KR被翻译成任务清单，负责人以为自己在做OKR

这是一个软件团队的例子。他们的季度KR写着“优化系统稳定性”，下面挂了十几条待办：做压测、改配置、加监控、写文档……团队每周更新一次待办进度，完成度看起来很好。

但到了季度末，系统可用性指标只提升了0.3个百分点。原因很简单：他们优化的是“做了哪些事”，不是“系统变得多稳”。待办全做完了，结果却没什么变化，因为最影响稳定性的那个老模块根本没人动。

3. 场景三：PMO沦为催办员，业务方开始躲着走

有一次我旁听某公司的项目月度评审会。整场会议两个小时，PMO的工作人员逐个点名：“这个项目进度滞后三天，请说明原因”“那个项目预算超了5%，请解释”。会议结束时，我旁边一位业务负责人小声跟我说了一句让我记到现在的话，“他们不是在帮我解决问题，他们是在给我做笔录。”

这是一个典型的PMO定位失败。当PMO只能提供“催办”和“记录”两种价值时，它一定会被业务方视为成本中心。真正能立足的PMO，要么帮业务方解掉依赖，要么帮管理者看清风险，这两件事都需要流程设计能力。

4. 三个场景背后的共同结构性问题

这三个场景看起来是三种不同的病，但根子上是同一个问题：目标没有嵌入流程，只是被记录在文档里。

医学上有个说法叫“循证”，意思是任何决策都要有证据链支撑。目标管理也需要一条证据链：战略解码产生项目优先级，项目立项产生目标和KR，对齐机制保证目标和资源匹配，跟踪机制保证执行不漂移，复盘机制保证经验能被复用。缺了任何一环，目标都会变成墙上的一幅画。

三、六个把目标管理做垮的高频误区

下面这六个误区，我几乎在每个诊断现场都会遇到其中三到四个。它们不是低级错误，很多是团队“认真做错”的结果，正因为认真，才错得更深。

1. 目标口号化：把所有美好愿望都写成目标

“提升协同效率”“打造一流团队”“增强客户满意度”，这类表述的共同问题是没有可验证的完成状态。你永远不知道它做到了没有，也就永远没法判断资源投入值不值。

我的纠正方法很简单：给每个目标加一句“完成时我能看到什么”。如果答不上来，这个目标就不合格，回炉重写。

2. KR任务化：把待办清单当成关键结果

这是最普遍、也最难改的一个误区。很多人写KR时会不自觉地列出一串动作，因为动作是可控的，结果是不可控的。可控带来安全感，但安全感不等于有效性。

区分方法只有一个：把KR的动词换成“被完成”是不是还通顺。“完成压测报告”不是结果，“系统在峰值负载下错误率低于0.5%”才是结果。前者是你做了什么，后者是世界变成了什么样。

3. 对齐会变汇报会：开成了念进度条

对齐会的目的应该是解决三件事：依赖没对上、资源有冲突、方向和战略有偏差。但现实中很多对齐会开成了逐个念进度，每个人说完“我这个项目正常”就散会，跨部门的接口问题一个都没碰。

我主持对齐会时有个硬规则：每人只讲两件事，我需要谁的帮助，我能帮谁。进度状态走系统看，会上只处理需要协调的部分。

4. 变更无记录：需求一变，目标也跟着悄悄变

项目执行中变更几乎是必然的。问题不是变更本身，而是变更没有留痕、没有影响评估。半年后复盘的时候，没人记得当初为什么把范围砍掉一半，也就无法沉淀教训。

我的原则是：任何影响目标、范围、预算、里程碑的变更，都必须留下书面记录，并明确写出“这个变更对KR的影响是什么”。可以不复杂，但必须有。

5. 复盘走过场：开完会什么也没改变

很多团队复盘开得很勤，但复盘结论永远是“加强沟通、提高效率、持续优化”。这三个词几乎没有信息量，无法变成任何实际行动。

有效的复盘必须产出三样东西：改进项、负责人、截止日期。少一样，这次复盘就是浪费时间。

6. 工具替代治理：以为上了系统，流程就自动好了

我见过不少团队花大价钱买了项目管理平台，用了半年，数据依然靠人工填，填得还是假的。工具是流程的载体，不是流程的替代品。没有清晰的规则和责任划分，再好的系统也只能装下一堆漂亮的空数据。

四、全流程地图：八个关口的专业判断逻辑

这一章是全篇的核心。我把“项目目标关键结果全流程”拆成八个关口，每个关口都统一按五个元素来讲：输入是什么、PMO做什么、输出什么、检查问题是什么、最容易踩的坑是什么。这套结构可以直接拿去对照你们现有的流程，缺哪个补哪个。

1. 关口一：战略解码与项目组合筛选

输入：公司年度战略、部门目标、经营预算、上一周期的复盘结论。

PMO做什么：组织战略解码工作坊，把战略意图翻译成可投资的项目清单，并对候选项目做优先级排序。排序标准建议不超过四个维度，比如战略契合度、收益规模、实施难度、资源可用性。

输出：年度或半年度的项目组合清单，含优先级、预算区间、预期收益。

检查问题：每个项目能不能说清它服务哪一条战略？如果砍掉它，公司哪项业务目标会受影响？

常见坑：把“领导提过的项目”默认当成高优先级项目，结果项目组合变成一锅粥，没有取舍。

2. 关口二：立项评审与目标设定

输入：项目组合清单中的高优先级项目、初步可行性分析。

PMO做什么：设计立项标准模板，强制回答三个问题，为什么做、做到什么程度算成功、谁对结果负责。同时组织独立评审，避免业务方自说自话。

输出：立项批复、项目目标说明书、初步的关键结果集、项目经理任命。

检查问题：目标是否可验证？KR是否描述了结果而非任务？负责人是否明确到人而非部门？

常见坑：立项会开成了拍板会，没有对目标本身做质量审查，结果一开始就埋下“无法验证”的雷。

3. 关口三：纵向与横向双向对齐

输入：已批复的项目目标、部门目标、跨部门协作需求。

PMO做什么：纵向把项目目标与部门目标、公司战略对齐；横向识别项目之间的依赖关系，明确接口责任人和交付时间。

输出：目标对齐矩阵、依赖关系图、资源冲突清单及解决方案。

检查问题：项目目标和部门目标是否存在矛盾？跨部门依赖是否双方都确认了交付时间和标准？

常见坑：只做纵向对齐，忽略横向依赖，导致项目执行到一半才发现关键接口方根本没排期。

4. 关口四：KR拆解与里程碑设计

输入：已确认的项目目标、可用的资源、时间窗口。

PMO做什么：引导团队把目标拆成3到5个关键结果，再把每个KR挂到具体的里程碑上。这里的关键是保持“结果→里程碑→任务”三层结构的清晰，不要让任务混进KR层。

输出：KR清单、里程碑计划、负责人矩阵。

检查问题：每个KR是否可量化、有期限、有唯一负责人？里程碑是否覆盖了KR的关键验证点？

常见坑：KR数量过多，一个项目写十几个，导致注意力分散，最后哪个都没做好。

5. 关口五：执行跟踪与节奏管理

输入：KR清单、里程碑计划、实际执行数据。

PMO做什么：设计分层的跟踪节奏。战略级项目走月度评审加里程碑复盘，重点级项目走双周会，常规项目走自助更新加异常上报。不是所有项目都需要高频汇报。

输出：KR进度看板、偏差预警、会议纪要及行动项。

检查问题：当前跟踪节奏和项目复杂度匹配吗？偏差预警是否在变成事故前发出？

常见坑：一刀切要求所有项目每周汇报，导致小项目负担过重，大项目的关键风险反而被淹没在噪音里。

6. 关口六：风险、变更与依赖管理

输入：执行过程中的风险事件、变更请求、依赖状态变化。

PMO做什么：维护风险登记册和变更记录，建立依赖升级机制。当依赖方无法按时交付时，要有明确的升级路径，而不是让项目经理自己去“求人”。

输出：风险登记册、变更影响评估、依赖升级记录。

检查问题：每个高风险是否有人负责、有应对方案、有触发条件？变更是否评估了对目标和KR的影响？

常见坑：风险登记册变成摆设，登记了就没人跟进，直到风险真的爆发。

7. 关口七：验收与收益复盘

输入：交付物、验收标准、当初设定的目标与KR。

PMO做什么：组织交付验收和两层复盘，一层看交付是否达标，一层看收益是否达成。这两层不能混，交付达标不等于目标达成。

输出：验收报告、目标达成度评估、收益分析。

检查问题：当初设定的KR是否被逐条对照？未达成的原因是否被记录？

常见坑：只验收交付物，不复盘目标达成情况，导致组织永远学不会“什么样的目标能实现”。

8. 关口八：知识沉淀与流程迭代

输入：各项目的复盘结论、流程执行中的问题、模板使用反馈。

PMO做什么：把复盘结论提炼成可复用的模板、检查表和案例库，并定期迭代PMO自身的流程规则。这一步是让PMO从“项目管家”升级为“组织能力建设者”的关键。

输出：更新后的模板库、案例库、流程规则版本。

检查问题：这次复盘产生的教训，下次项目能直接用上吗？流程规则多久没更新了？

常见坑：复盘结论停留在会议纪要里，从来没有变成模板或规则，导致同类问题在不同项目里反复发生。

五、PMO流程优化的四个抓手：减负、分级、自动化、度量

讲完八个关口，很多人会问：这套流程怎么落地才不至于把团队压垮？我的答案浓缩成四个词：减负、分级、自动化、度量。这四个词背后都是我在项目里吃过亏之后总结的。

1. 流程分级：不是所有项目都配得上同样的治理强度

我服务过的组织里，最普遍的流程病是“一视同仁”。一个几十人天的内部工具开发，走的是和千万级核心业务系统一样的审批流程，结果小项目怨声载道，大项目的关键决策反而被稀释。

我建议用三个维度做分级：战略影响度、投资规模、技术或合规复杂度。分级之后，不同级别配不同的审批层级、汇报频率、文档要求。

2. 模板瘦身：一页纸能说清的事情，不要写十页

我做过一次统计，一个典型的项目立项文档，如果按公司标准模板填写，平均需要4到6小时；但真正被后续参考的信息，集中在不到一页纸里。剩下那几页，写的人痛苦，看的人也不看。

我推行的一页纸工具包含四张表：一页立项（目标、范围、负责人、预算）、一页KR（3到5条关键结果）、一页风险（主要风险及应对）、一页复盘（达成度、原因、改进项）。四张纸跑完一个项目全周期，团队接受度非常高。

3. 自动化与工具集成：数据一次录入，多处可分场景使用

PMO最消耗时间的从来不是思考，而是搬运数据。同一个项目进度，要更新到不同的表格、周报、看板，稍不留神版本就乱了。这也是为什么我强烈主张打通工具链。数据一次录入、多处分场景使用，能把PMO从数据搬运工里解放出来，去做真正有价值的治理工作。

我在2023年参与的一个国产化替代项目，能很好地说明这一点。客户是一家年营收三十亿左右的装备制造企业，集团IT部门明确要求项目管理平台支持私有化部署，理由是研发数据涉及核心工艺，不能出内网。同时，他们原来的研发团队长期使用Jira，历史项目的issue、工作流、字段映射积累了五六年，骤然切换会让团队一边学新平台、一边开双系统维护老数据，成本很高。

我们评估了几家平台，最后选定PingCode，关键原因有两个：一是它支持私有化部署，满足集团的数据合规要求；二是它支持从Jira平滑迁移，历史项目的字段映射和工作流可以批量导入，团队不需要重头搭一遍体系。PingCode本身主要服务中大型企业及100人以上组织，这家客户研发体系有四百多人，规模上是匹配的。

项目上线后，我们把KR进度、里程碑状态、风险登记、变更记录全部收敛到同一平台，PMO每周的数据整理工作从原来跨七个表格手工汇总，变成系统自动生成看板。

4. 度量：六张指标卡，先定义口径再使用

我反对一上来就搞几十个指标的“数据大屏”，那只会让人视觉疲劳。真正有用的度量，六张卡就够：目标达成率、KR进度、里程碑偏差、风险关闭率、变更率、复盘完成率。

但有件事必须提前说清楚：这六个指标必须先定义口径，才能用。比如“里程碑偏差”是按计划日期还是承诺日期算？“风险关闭率”的分母是本周期新增风险还是累计未关闭风险？口径不统一，同一个指标在不同项目里含义完全不同，数据就没法比。

六、案例与数据观察：一家三百人制造企业的十二个月

这一章我尽量讲得具体些，包括做错了什么、怎么调整的、观察到了什么变化。以下数据来自我的项目记录，涉及企业名称做了脱敏处理，属于咨询过程中的真实观察。

1. 起点：做得都对，但没有一条对得上

这家企业做精密零部件，营收规模在两个多亿，研发和生产加起来三百多人。合作开始时，他们的PMO刚成立半年，只有两个人，负责管全公司二十八个在跑的项目。

他们的流程文档写得很规范，问题出在三个地方：立项审批要过十一个节点，一个小项目从提交到批复平均要十四天；项目目标写在立项书里，执行中没有任何对照机制；所有项目不管大小，都要求每周更新进度表，PMO两个人有六成时间在汇总数据。

2. 做了什么

我们分三个阶段做调整。第一阶段做流程分级，把二十八个项目按战略影响度、投资规模分成S、A、B三级，审批节点从十一个压缩到五个，小项目走简化通道。

第二阶段做目标校准，重新梳理所有在跑项目的KR，把任务型KR改成结果型KR，平均每个项目保留了三条核心KR。

第三阶段做工具收敛，把项目管理平台和他们的周报、里程碑看板打通，数据一次录入多处分场景使用，PMO不再手工汇总。

3. 十二个月后观察到的数据变化

这组数据里我最看重的是最后一行。复盘完成率本身不是业务指标，但它决定了组织能不能积累经验。一个不复盘的组织，每次遇到的都是新问题；一个认真复盘的组织，重复踩的坑会越来越少。

4. 一个意料之外的发现

项目和目标相关的调整做完之后，我原本预期看到的主要是流程效率的提升。但真正让客户管理层意外的是，业务方对PMO的态度变了。

最开始业务方见PMO是绕道走的，因为他们只会催数据。调整三个月后，有项目经理主动来找PMO问“这个依赖我搞不定，能不能帮我升级一下”。当PMO开始解决真实问题而不是收集数据时，它的地位自然就立住了。

这家企业的PMO人数后来从两个人增加到三个人，不是因为流程变复杂了，恰恰相反，是因为业务方开始依赖PMO做跨部门协调和目标跟踪，工作量从“记录”转向了“治理”。

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

同样一套全流程，放在不同规模、不同成熟度的组织里，落地方式差别很大。这一章按组织规模和行业特征给建议，你把最接近自己的那一类拿去用就行。

1. 二十人以下团队：不要上PMO，先立规矩

这个规模的组织，上专职PMO是浪费。你需要的是三条轻量规则：项目启动时口头明确目标并记录一段话、每周固定一次半小时的对齐、每个项目结束时花一小时做口头复盘并把结论写进文档。

工具用一个看板加一个文档库就够，别急着买平台。这个阶段最重要的不是流程完备性，而是让团队养成“目标，执行，回顾”的习惯。

2. 二十到一百人组织：设立兼职PMO，重点做分级和对齐

这个规模通常有一到两个兼职或半专职的PMO角色，可能是项目经理兼任。我建议重点抓两件事：一是把项目按重要性分级，避免用同一套流程折磨所有项目；二是建立跨部门对齐机制，因为这个阶段最容易出现的病是部门墙。

工具层面开始需要平台支撑，重点看它能不能把项目目标、KR、里程碑、风险放在同一个数据模型里，避免多系统数据打架。

3. 一百人以上、多项目并行组织：需要完整PMO，重心是治理和数据

这个阶段PMO的存在价值就非常明确了。重心应该从“管项目”转向“管组合”：项目组合的健康度、跨项目资源调配、流程规则迭代、组织级知识沉淀。

工具选型上要考虑三件事：能不能支撑多层级的目标分解、能不能做跨项目的资源视图、数据安全和部署方式满不满足合规要求。这几点在看平台时比功能列表更值得花时间。

对研发数据敏感的行业，比如装备制造、医疗器械、金融科技，私有化部署往往是硬门槛。同时，如果团队此前用过其他主流平台、历史数据量大，迁移成本必须提前算进决策里，一套能平滑迁移的方案，实际价值往往比多几个功能点更高。我们在此前那个装备制造客户的选型里，正是把“能不能把历史项目平滑迁过来”放到了和功能同等重要的位置，最终选定的PingCode在这两点上都符合预期。

4. 强监管行业：流程留痕优先，但别做成形式主义

金融、医药、航空这类行业，监管要求项目过程必须留痕，这直接决定了流程不能太轻。我的建议是把留痕做在流程里，而不是做在流程外。变更记录、风险登记、验收记录都应该是流程运转的自然产物，而不是事后补的材料。

如果留痕靠事后补，团队一定会抵触，而且补出来的材料真实性存疑。把留痕嵌到系统里，让PMO在系统中审核、留痕，既满足合规，又不额外增加负担。

八、不同情况下的取舍：这几个矛盾你绕不过去

做PMO流程优化，最难的从来不是方法，而是取舍。以下四组矛盾，我在每个项目里都会遇到，也提醒每个PMO负责人提前想清楚自己的立场。

1. 规范与灵活：流程越规范，个体灵活度越低

这是一组无法消除的矛盾。流程的每一次细化都在减少个体的自由裁量权，而某些创新性项目恰恰需要自由裁量空间。

我的判断是：用分级来解决，而不是用一套流程去平衡。把强规范性要求给到战略级和高合规要求的项目，把灵活度留给探索型和试验型项目。“一刀切”追求“既规范又灵活”的结果，通常是两边都不满意。

2. 自建与采购：自建可控但慢，采购快但有边界

有些组织倾向于自建工具链，觉得可控。我的经验是，除非你有稳定的内部研发团队专职维护，否则自建的成本会在第二、第三年快速显现：功能迭代跟不上、数据模型改不动、新人上手慢。

采购平台的好处是快、功能成熟、有人持续维护；代价是标准化，某些个性化需求要靠配置而不是改代码来实现。关键在于先把自己的核心需求想清楚，再决定哪些能让步、哪些不能让步。

3. 统一与差异：总部统一流程，业务单元抱怨不适用

集团型组织最容易遇到这个问题。总部统一流程的初衷是可比性和合规，但业务单元的差异性又实实在在摆在那里。

我的建议是统一数据模型和核心指标口径，差异化审批流程和汇报频率。口径统一意味着数据可比，频率差异化意味着业务单元不被过度打扰。这个组合在实操里可行性最高。

4. 透明与隐私：数据越透明，填报压力越大

一个组织越强调数据透明，团队成员就越会感受到被审视的压力，填报行为就越可能变形。我见过最极端的案例，团队为了让进度图好看，把“进行中”改成“已完成”再把后续工作另立一个项目，数据表面漂亮，治理基本失控。

破解的关键是把度量和考核解耦。指标用于发现问题和改善流程，不直接挂个人绩效。当团队知道数据是用来帮忙而不是用来打分的，填报的真实性会明显提升。

5. 我的取舍原则

面对这四组矛盾，我有一条通用原则：先保住目标达成，再优化流程体验。如果一套流程让目标更清晰、结果更可验证，那它可以适当重一些；如果它只是为了流程本身好看，再轻也应该砍掉。

九、结语：目标不是写出来的，是被流程跑出来的

写到这里，我想把整篇文章压缩成几句话。

第一，项目目标和关键结果的全流程，核心是八个关口，而不是八张表格。关口的意义在于每一个都需要有人做出判断，表格的意义只是记录判断的结果。

第二，PMO真正的价值，在于把战略意图翻译成可执行的规则，把执行数据翻译成可决策的信息。只会收集数据和催进度的PMO，早晚会被替代。

第三，流程优化不是加法，是取舍。减负、分级、自动化、度量，四个抓手背后都是同一个判断：不是所有项目都需要同样强度的治理。

如果你读到这里还在思考“我下一步该做什么”，我给你一个可以直接落地的行动清单，不需要任何预算：

• 今天：打开你们当前在跑的项目列表，随机挑三个，把目标原文和最近一次实际进度放在一张纸上，看它们能不能对上。
• 本周：把你手上所有项目的KR读一遍，把动词是“完成、参加、开展”的都标记出来，这些大概率是需要改写的结果型KR。
• 本月：尝试给项目做一次简单分级，分出战略级和常规级，先给常规级项目减一次流程负担，看看业务方的反应。
• 本季度：选一个项目做完整的八个关口走一遍，把遇到的问题记录下来，作为你迭代PMO流程的第一批真实素材。

我最后想说的是，这篇文章里所有的流程、指标和案例，都不是为了让PMO变复杂，恰恰相反，是为了让PMO从“做了很多动作但不产生结果”里走出来。一个健康的PMO，应该让组织里的每个人都能回答三个问题：我的项目为什么存在、做到什么程度算成功、现在离成功还有多远。如果这三个问题还答不上来，那说明流程还有一段路要走，但也说明你手里的事情非常有价值。