去年我接手一个 400 人规模研发组织的 PMO 诊断，进场第一天我让项目助理把"当前所有在跑项目的进度"拉一张表给我。她花了两天，交上来一份 31 行的 Excel，其中 9 个项目状态写着"正常"。我随机抽了 3 个去问负责人，得到的回答分别是"其实已经延了两周""正常，但要靠加班顶""我不确定，得问下开发"。三句话，三种口径，没有一句能和那张表对上。这不是个例，在后来的大半年里我又看了十几家企业的进度管理现状，反复撞上同一个结论：绝大多数团队的进度失控，不是发生在执行阶段，而是发生在"进度"这两个字根本还没有被定义的时候。
这篇文章我把进度管理从 0 到 1 的全过程拆开讲，先给结论，再讲我实际踩过的坑和看到的数据，最后落到不同规模团队该怎么动、该怎么取舍。
一、先给结论：进度管理从 0 到 1，第一步不是选工具
如果只能记住一句话，我希望是这句：进度管理的第一步是定义"进度的定义权"，第二步是让进度数据可信，第三步才是上工具。顺序颠倒，投入越大，幻觉越深。
1. 进度不是"完成百分比"，而是"可验证的剩余工作量"
"这个需求做了 80%"，这是我听过最多、也最没有信息量的一句话。80% 是什么？代码写完算 80%，还是自测通过算 80%，还是联调通过算 80%？同一个 80%，在三个人嘴里可能是三周和三天的差别。
我在实际项目里推的做法是：把进度表达从"完成百分比"换成"剩余工作量的可验证状态"。具体就是每个任务只允许落在五个状态里，未开始、进行中、待验证、已验证、已关闭，并且"待验证"必须挂一个明确的验证人和验证方式。这样做的好处是，进度汇报不再是主观感受，而是一组可以被追问的事实。
2. PMO 的第一职责不是催进度，而是让进度数据可信
很多 PMO 新人上任后的第一个动作是建制度、发模板、开周会。我见过最夸张的一家，PMO 成立三个月发了 17 份流程文件，但项目经理填进度表的动力为零，因为填了也没人看，填错了也没人管。
真正有效的 PMO，第一件事是把"数据可信度"当成 KPI 来管。我会明确三条底线：进度状态只能由任务负责人本人更新；任何状态变更必须留时间和变更人；超过约定周期没更新的任务，自动标为"数据过期"而不是"正常"。这三条落地之后，进度数据的可信度通常能从五六成提升到九成以上，PMO 后面的所有分析才有意义。
3. 0 到 1 阶段只做三件事
从零开始搭进度管理，我不建议一次上全套。只做三件事就够启动：
- 单一数据源：一个项目只有一张进度表，谁都不许另开小账本。
- 固定节奏：明确谁在什么时间更新什么字段，频率不超过每周一次，也不低于每两周一次。
- 异常上报：只定义"什么算异常"和"异常往哪报"，其余细节先不写。
这三件事撑起来，进度管理就已经能跑。剩下的甘特图、挣值、燃尽图，都是加法。
4. 工具是第四步，不是第一步
这句话经常被误解成"工具不重要"。恰恰相反，当你的团队超过 100 人、项目超过 15 个时，靠 Excel 和微信群维护进度，成本会指数级上升。但工具的作用是承载已经跑通的规则，不是替你发明规则。先有定义、再有数据、再有节奏，最后用工具固化，这个顺序不能动。
二、真实场景：我见过进度失控的三种典型形态
把过去几年我诊断过的组织按规模分一下，进度失控基本收敛到三种形态，每种形态的病灶完全不同，用错药只会更糟。
1. 形态一：Excel 进度表 + 周会口头汇报（100 人以下最常见）
典型特征：项目进度表由项目助理或 PM 手动维护，数据来源是周会上大家的嘴。周会开完，助理花半天更新表格，表格发到群里，没人打开。
这种形态最致命的不是"不准"，而是"延迟"。周会周三开，表格周四发，等它到决策者手上，已经是一周前的快照。我见过一个硬件+软件混合项目，因为进度表滞后 9 天，导致样机采购晚下单两周，直接撞上供应商春节停产。
2. 形态二：工具里有一套流程，线下跑另一套（100-500 人最常见）
这是最普遍、也最浪费的形态。组织已经采购了项目管理平台，工具里有任务、有里程碑、有看板，但实际排期、变更、风险跟踪全在飞书文档和微信群里。原因通常是：工具是自上而下推的，字段设计没有参与感，一线觉得"填了是给领导看的"。
我做过一次抽样：某个 260 人的研发中心，平台上任务总数 4800 条，其中超过 30 天没有状态变更的占 61%。这意味着工具里的数据只能当"历史档案"看，不能当"决策依据"用。而这家公司每年在工具和培训上的投入接近七位数。
3. 形态三：数据很全，但没人看（500 人以上常见）
大组织反而容易出现"数据过载"。仪表盘做得花团锦簇，燃尽图、累积流图、缺陷趋势应有尽有，但项目集层面的决策者只看两件事：这个季度能不能交付、哪几个项目要爆。仪表盘回答不了这两个问题，于是被绕过。
这类组织的优化重点不是"补数据"，而是"做减法"，把 30 个指标砍到 5 个，每个指标绑定一个明确动作。
三、常见误区拆解：为什么"做了进度管理"还是延期
下面这五个误区，我在至少十个组织里见过，而且它们往往同时存在。
1. 误区一：把"计划完成率 90%"当成健康指标
计划完成率是进度管理里最会骗人的数字。原因很简单：分母是可以被调整的。这个月做不完，把任务挪到下个月，完成率立刻回到 95%。我见过一个团队连续六个月计划完成率在 92% 以上，同期项目平均延期 6 周，两者并不矛盾，因为计划本身一直在往后退。
我的替代指标是计划稳定度：统计一周内被改期的任务数占总任务数的比例。健康值一般在 10% 以下，超过 25% 说明计划形同虚设。
2. 误区二：用工期倒排代替工作量估算
"12 月 15 号上线，所以 12 月 10 号必须提测"，这是倒排，不是计划。倒排本身没错，错在倒排之后没有回到工作量维度做校验。
我要求团队在倒排之后必须补一步：把每个里程碑前的任务拆到不超过 3 人天的粒度，然后让执行人自己认领。这一步能拦掉大部分明显不靠谱的计划。真实情况是，很多排期在被拆解之后，团队自己就发现时间不够，而不是等到第三周才被迫上报。
3. 误区三：把里程碑做成"检查点"而不是"决策点"
检查点的作用是"看看走到哪了"，决策点的作用是"决定继续还是调整"。大部分团队的里程碑只承担了前者。
我推的做法是：每个里程碑必须绑定一个决策问题。比如"需求冻结"这个里程碑，决策问题是"需求范围是否锁定，后续变更是否走变更流程"；"提测"这个里程碑，决策问题是"质量门槛是否达标，不达标是否推迟发布"。没有决策问题的里程碑，本质上只是一次汇报。
4. 误区四：用会议频率代替信息密度
进度出问题的团队往往第一反应是"加会"：日站会、周例会、双周复盘、月度汇报。结果是会议时长翻倍，信息量没变。
我的判断标准很直接：如果一个会议上的信息 100% 能从系统里看到，这个会议就应该被取消或压缩到 15 分钟以内。会议的价值在于解决系统里看不到的部分，分歧、风险、依赖、承诺。
5. 误区五：先做 PMO 制度，再考虑数据可得性
这是最典型的"先设计理想国"错误。制度里写着"每周五 17:00 前完成进度更新"，但没人考虑：一线周五下午通常在处理联调问题，根本没时间开系统。制度落地第一天就破功，破功三次之后，制度就死了。
正确的顺序是反过来：先看数据在什么时间点自然产生，再把更新动作挂在那个时间点旁边。比如代码提交自动带出任务状态，测试报告自动回写验证结果，能自动采集的绝不要求手填，必须手填的必须给出理由。
四、专业判断逻辑：进度管理从 0 到 1 的四层结构
把前面所有问题收拢，我给客户讲进度管理时只用一张四层图。每一层都有明确的输入和输出，跳层是绝大多数失败的根源。
1. 第一层：任务颗粒度与验收标准
这一层决定进度能不能被度量。我的经验阈值是：单个任务的预估工作量不超过 3 人天，最长不超过 5 个工作日。超过这个粒度，任务本身就变成了一个黑盒，进度更新只能是"还在做"。
与之配套的是验收标准。一个任务必须能回答"做到什么程度算完成"。我见过一个团队把所有任务都叫"开发完成"，结果发现测试同学等着的是"提测版本"，而开发理解的"完成"是"代码合并"。这类错位在小团队里靠吼能解决，超过 50 人就必然出问题。
（1）一个可直接复用的任务定义示例
下面是我在某中大型企业落地时用的任务模板，字段不多，但每个字段都有明确用途：
task:
title: "订单中心-优惠券叠加校验接口"
owner: "张三" # 唯一责任人，不允许写"前端组"
estimate: "2.5 人天" # 超过 3 人天强制拆分
start: "2024-03-04"
due: "2024-03-06"
acceptance: # 验收标准，必须可验证
"接口返回 200 且覆盖 4 类叠加场景"
"单元测试覆盖率 ≥ 80%"
"联调环境验证通过并附截图"
verifier: "李四" # 验证人，与责任人不同
status: "待验证" # 未开始/进行中/待验证/已验证/已关闭
blocked_by: ["订单中心-券模板接口"] # 显式依赖，避免口头对齐
last_update: "2024-03-05 18:20"
这个模板的关键不在字段多，而在每个字段都能被机器校验：没写 verifier 的任务不能进入"待验证"，estimate 超过 3 人天的任务会被自动标黄，last_update 超过 5 天的任务会被标为"数据过期"。
2. 第二层：进度信号与更新频率
很多人把"更新频率"理解成一个管理动作，其实它应该由任务的时长决定。我用的一套基准是这样的：
| 任务时长 | 状态更新频率 | 更新责任人 | 异常判定阈值 |
|---|---|---|---|
| ≤ 2 人天 | 每日自动采集（提交/构建记录） | 责任人 | 超过预计完成时间 1 天 |
| 3-5 人天 | 每 2 个工作日 | 责任人 | 超过预计完成时间 2 天 |
| 6-15 人天（已拆分场景） | 每周一次 | 子任务责任人汇总 | 剩余工作量未下降 |
| 跨团队依赖任务 | 每周一次 + 变更即时通知 | 依赖双方责任人 | 依赖方未确认接受 |
这套频率的意义在于：更新成本必须低于管理收益。如果更新一次要花 10 分钟，一个 3 人天的任务更新五次就是 50 分钟，接近任务本身的 20%，没人会坚持。
3. 第三层：偏差识别与升级路径
这是 PMO 真正产生价值的一层。核心不是"发现延期"，而是定义什么算异常，以及异常在多长时间内往哪一级升级。
我用的一套升级规则参考如下，可以根据组织调整：
- 任务级偏差：超过预计完成时间 1 天，责任人自己更新状态并说明原因，不需要上报。
- 里程碑级偏差：关键路径上的任务偏差累计超过 3 天，项目经理在 24 小时内评估影响并给出调整方案。
- 项目级偏差：关键里程碑预计延期超过 5 个工作日，或范围变更超过原计划 10%，自动升级到项目集层。
- 组合级偏差：同时有 3 个以上项目触发项目级偏差，或有项目影响季度交付承诺，升级到 PMO 与业务负责人。
这套规则的价值是把"该不该上报"从人的判断变成一个明确的阈值。我发现一个规律：凡是需要项目经理"凭经验判断要不要上报"的组织，延期暴露的时间平均晚 11 天。
4. 第四层：复盘与估算校准
前三层解决"现在怎么样"，第四层解决"下次准不准"。没有第四层，进度管理永远在原地打转，每次延期都是新问题，每次估算都靠拍脑袋。
我推的复盘只问三个问题：估算和实际的偏差是多少？偏差主要来自哪一类原因（需求不清、技术不确定、依赖等待、资源冲突）？下一次同类任务的估算要不要加系数？
积累三到五个迭代之后，你会得到团队自己的"估算校准系数"。我见过的一个后端团队，经过四轮校准后，把历史偏差系数 1.35 写进了排期规则，计划准确率从 58% 提到 84%。
五、案例与数据观察：某中大型企业 PMO 的 90 天进度改造
下面这个案例是我实际参与的一个项目，客户是一家 900 人规模的制造+软件混合型企业，研发中心约 320 人，同时在跑 28 个项目。改造前的情况是：项目平均延期 5.5 周，PMO 6 个人，每周花在汇总进度上的时间约 40 人时。
1. 第 1-30 天：只做一件事，建立单一数据源
这 30 天我们没动任何流程，只做数据收口。具体动作是：把散落在 6 份 Excel、3 个飞书多维表格、2 个老系统里的项目进度全部合并到一个平台，并设定规则，从第 31 天起，平台之外不再有"官方进度"。
这一步最大的阻力不是技术，是习惯。有三个项目经理明确表示"我的项目太复杂，平台表达不了"。我们的处理方式是：先按他们的口径在平台上搭一遍，如果确实表达不了，再补字段。最后三个项目里有两个被说服，一个补了两个自定义字段。
30 天结束时，28 个项目全部在一个数据源里，任务总数 7200 条，其中有效的（有责任人、有验收标准、有到期日）占 68%。
2. 第 31-60 天：把更新频率和颗粒度定下来
这一阶段我们做了三件事：把超过 5 人天的任务强制拆分，共拆出 1400 余条子任务；给每类任务绑定更新频率；上线自动采集规则，让代码提交、构建结果、测试报告自动回写任务状态。
结果是手填工作量下降明显。改造前每人每周花在更新进度上的时间约 42 分钟，改造后降到 17 分钟，其中约 60% 由系统自动完成。
这一阶段还发生了一件让我印象深刻的事：拆分之后，团队自己发现了 11 个此前没人注意到的隐藏依赖。其中一条是"固件烧录工具依赖第三方 SDK 升级"，这条依赖此前只在某次聊天记录里出现过一次，没有任何人跟踪。它在第 47 天被识别出来时，距离原定提测还有 3 周，如果再晚两周发现，整个样机验证会推迟一个月。
3. 第 61-90 天：建立偏差升级和复盘机制
这一阶段我们把前面提到的四层升级规则正式落地，并上线了一个每周自动生成的"偏差清单"：所有超过阈值未更新的任务、关键路径上偏差超过 3 天的任务、依赖未确认的任务，自动进入清单并推送给对应层级。
同时启动迭代复盘，每次复盘只输出一个数字：本迭代的估算偏差系数。前三轮分别是 1.42、1.31、1.24，第四轮开始稳定在 1.15 附近，团队把它直接写进了排期公式。
90 天结束时，项目平均延期从 5.5 周降到 2.4 周，PMO 每周花在汇总进度上的时间从 40 人时降到 9 人时。更重要的是，PMO 的角色从"催进度的"变成了"看偏差、做决策的"。
4. 工具选择的判断：为什么中大型组织更倾向私有化部署与平滑迁移
这个案例里有一个绕不开的环节：工具。当组织超过 100 人、项目超过 15 个、且涉及跨部门数据时，Excel 和文档工具会迅速触顶。我们在选型阶段评估了四类方案：轻量看板工具、通用协作平台、专业研发管理平台、自研系统。
最终这家企业选择了 PingCode。原因有三个，我觉得对同规模组织有参考价值：
- 适配中大型企业及 100 人以上组织的协同结构：项目集、项目、迭代、任务、测试、知识库在同一套模型里，不需要靠外部表格拼接。
- 支持私有化部署：这家企业有涉密研发内容，数据不能出内网，私有化部署直接解决了合规评审的时间成本。
- 支持从 Jira 平滑迁移：他们此前有 4 年的 Jira 使用历史，200 多个项目、近 10 万条工作项。迁移方案保留了历史数据与字段映射，避免了"历史数据断档"这个常见坑。
我想强调的是，工具选型不是"哪个功能多"，而是哪个工具能承接你已经跑通的规则，并且不强迫你为迁就工具改规则。私有化部署能力和平滑迁移能力，对有历史包袱的中大型组织来说，权重远高于界面美观度。
六、不同情况的行动建议
同样的方法论，落到不同规模的组织，起手动作完全不同。下面按规模给出我的具体建议。
1. 50 人以下团队：别建 PMO，先建"一张表 + 一条规则"
这个规模建 PMO 是浪费。你需要的是：一张所有项目共用的任务表，一条"任务不超过 3 人天"的拆解规则，和一个每两周一次的 30 分钟对表会。
工具上，轻量的看板或表格工具完全够用。这个阶段的重点是把拆解习惯养起来，而不是追求数据实时性。50 人以下最大的风险不是进度不准，而是没有估算意识。
2. 50-200 人团队：把"更新频率"和"异常阈值"写死
到这个规模，口头同步开始失效，必须把规则写下来。我建议的动作是：
- 定义 5 个任务状态，禁止自定义。
- 按任务时长绑定更新频率（参考前文的表格）。
- 设定一条异常线：关键路径偏差超过 3 天必须上报。
- 引入自动采集，先接通代码仓库和测试系统。
这个阶段最值得投入的是自动采集。它决定了你后面所有的数据是否可信，而且投入一次长期受益。
3. 200-1000 人组织：先做数据收口，再做流程统一
这个规模的组织通常已经有多套工具、多个事业部的不同流程。我的建议是先统一数据，再统一流程，因为流程统一的阻力远大于数据统一。
具体路径：先让所有项目在同一个平台上至少记录"任务、责任人、到期日、状态"四个字段，允许各事业部保留自己的看板视图和阶段命名。等数据收口完成、大家习惯了同一个数据源，再逐步统一阶段定义和门禁规则。
工具选择上，这个规模应当优先考虑支持私有化部署和项目集管理的专业平台，比如前文提到的 PingCode 这类面向中大型企业的研发管理平台，避免用通用协作工具硬撑。同时要评估历史数据迁移成本，尤其是从既有平台迁移时字段映射的完整性。
4. 1000 人以上 / 多项目集：把 PMO 变成"数据与决策"部门
这个规模的组织，PMO 如果还在做汇总和催办，是严重的人力浪费。我认为 PMO 应该承担三件事：
- 定义数据标准：统一字段、状态、口径，并维护校验规则。
- 做组合级决策支持：回答"这个季度能交付几个项目""哪三个项目需要干预"。
- 做能力建设：培训项目经理的估算与偏差分析能力。
汇总、跟催、催填这些动作，应该由系统自动完成，而不是由人承担。
七、不同情况下的取舍
进度管理从 0 到 1 的过程，本质上是一连串取舍。下面四组是我被问得最多、也最容易走极端的。
1. 颗粒度 vs 维护成本
颗粒度越细，偏差看得越早，但维护成本越高。我的经验分界线是 3 人天：超过 3 人天的任务必须拆，低于 0.5 人天的任务不要再往下拆，否则会陷入"填任务比做任务还累"的境地。
另一个容易被忽略的成本是心理成本。当一个人的任务列表里有 40 条待办时，他会本能地抗拒更新。控制单人在手任务数在 8 条以内，比强制每天更新更有效。
2. 实时性 vs 真实性
实时更新听起来很美，但在研发场景里，真实进度往往要在事情做完之后才清楚。强迫每天更新，只会得到一堆敷衍的状态。
我的取舍是：状态更新可以滞后，但到期日不能悄悄改。状态每两天更新一次可以接受，改期必须留下变更记录和原因。这样既保证真实性，又保证可追溯。
3. 标准化 vs 适配业务
标准化能带来跨项目可比性，但会牺牲业务适配度。我的建议是分层：数据层强制标准，视图层允许差异。也就是说，所有人都必须用同一套字段和状态，但硬件团队可以看阶段视图，软件团队可以看迭代看板，销售交付团队可以看里程碑视图。
这样做的好处是，底层数据可以汇总比较，上层体验又不至于让一线反感。我见过失败最惨的推进方式，是连视图都强制统一，结果所有人都在抱怨"这个工具不适合我们"。
4. 自建 vs 采购
这是中大型组织绕不开的问题。我的判断依据是三条：
| 判断维度 | 倾向自建 | 倾向采购 |
|---|---|---|
| 业务独特性 | 进度口径与行业标准差异极大 | 研发流程属于通用实践 |
| 合规要求 | 需要完全自主可控且具备长期维护团队 | 供应商支持私有化部署即可满足 |
| 维护能力 | 有稳定的平台工程团队（≥5 人长期投入） | 研发重心在业务，IT 资源有限 |
| 历史数据 | 历史数据结构特殊，迁移成本高于重建 | 供应商提供成熟的迁移方案与字段映射 |
实话讲，我见过的大多数自建进度系统，最终都退化成了一个内部 Excel 的 Web 版，因为自建的成本不只是开发，还有长期的字段维护、报表迭代、权限治理。除非你有长期稳定的平台团队，否则采购成熟平台 + 少量定制通常是更划算的选择。
八、下一步：30 天最小可行动作清单
如果你读完想做点什么，我给一份我实际用过很多次的 30 天清单。它不追求完整，只追求启动。
1. 第 1 周：盘点和定义
- 把所有项目进度表收集起来，数一数一共有几份，口径差在哪。
- 和 3-5 位一线执行人聊 30 分钟，问一个问题："你怎么判断一个任务做完了？"
- 写出你的 5 个任务状态定义，每个定义配一句可验证的描述。
2. 第 2 周：收口和拆解
- 选定一个数据源，把当前在跑的项目全部录进去，只录 6 个必填字段。
- 挑一个项目做试点，把所有超过 3 人天的任务拆到 3 人天以内。
- 记录拆分过程中暴露出的隐藏依赖，这几乎一定会出现。
3. 第 3 周：接入和验证
- 接通代码仓库或测试系统，让至少一类状态可以自动更新。
- 定义一条异常线和一个升级路径，越简单越好。
- 跑一次手工的"偏差清单"，看能不能真的找出问题。
4. 第 4 周：复盘和校准
- 对比试点项目这一周的估算和实际，算出偏差系数。
- 开一次 60 分钟复盘，只讨论偏差原因，不追责。
- 决定下一步：是扩大试点范围，还是先补工具能力。
九、总结：进度管理从 0 到 1，本质上是一场"定义权"的争夺
回到开头那个场景。那个项目助理花两天做出来的 Excel，问题不在她不努力，而在于整个组织从来没有规定过"进度"这两个字由谁来定义、按什么标准定义。
我做了这么多年 PMO，最深的体会是：进度管理的成败，取决于组织愿不愿意把"我觉得快做完了"换成"这个任务在什么条件下算完成"。前者是感受，后者是事实。所有工具、流程、报表，都是为了把这两者之间的距离缩短。
如果你现在正准备从 0 到 1 搭进度管理，我的建议是按这个顺序走：先定义任务完成的验收标准，再定更新频率和异常阈值，再收口数据源，最后才考虑工具和可视化。任何一步跳过去，后面都要返工。
至于工具，不要被功能清单牵着走。对 100 人以上的组织来说，真正决定成败的是三件事：能不能承接你已经跑通的规则、能不能保证数据不出内网、能不能让你过去几年积累的历史数据不丢。私有化部署能力、平滑迁移能力、项目集管理能力，这三项的权重远高于界面好不好看。
最后一句给到要动手的人：明天就做一件事，挑一个正在进行、且你觉得"差不多快完了"的任务，去问负责人"做到什么程度算完成，谁验证"。如果这个问题问下去对方答不上来，你就已经找到了第一个要修的地方。
常见问题解答（FAQ）
1. 项目进度管理从0到1，PMO第一步该先搭什么，而不是先上工具？
我刚接手公司PMO的时候，第一反应是赶紧找一款工具把进度管起来，结果大家填了两周数据就没人维护了。后来才发现，真正卡住的不是工具，而是进度这件事本身没有统一口径，同一个任务，有人觉得算完成一半，有人觉得才算刚开始。
第一步是先定义进度的口径，再谈流程和工具。具体做法是把项目拆到可交付物层级，每个交付物必须能回答三件事：产出物是什么、由谁验收、验收标准是什么；然后把进度状态收敛成三档，未开始、进行中、已完成（已交付并通过验收），取消主观百分比。
经验上，一个3到6个月、跨3个以上部门的中等规模项目，拆出30到80个可交付物比较合适，太少会掩盖风险，太多维护成本超过收益。口径定完再定两个固定动作：每周固定时间点更新一次状态，每两周做一次里程碑偏差复盘。工具放到最后选，因为口径不清时，工具只会把混乱放大，还留下看起来很规范的假象。
判断0到1是否真的完成，看一个指标：随机抽三个项目，分别问项目经理、开发负责人和测试负责人同一个交付物完成了没有，三人的回答与系统状态是否一致。一致率能稳定在90%以上，说明地基打好了。
2. 团队上报的进度总是虚高，PMO怎么判断真实进度？
我做过一次项目审计，系统里显示整体完成75%，但离交付只剩两周，关键模块的接口文档还没评审。我去问开发，他说代码写完就算完成；测试说没提测就不算，两个人差了30个百分点。这种事在PMO日常里太常见了，光看百分比根本管不住。
不要问完成了百分之多少，改问哪个可交付物已经通过验收。可执行的做法是把进度口径从主观百分比换成两种客观算法之一：一是0/100法，交付物只有未完成和已完成两种状态，进度等于已完成交付物数除以总交付物数，按交付物权重加权；二是里程碑法，只统计已通过验收评审的里程碑占总里程碑的比例。
两种口径都必须挂证据，比如评审记录、测试报告、上线记录、客户确认邮件，没有证据的状态变更不允许提交。经验数据上，用客观口径算出来的进度通常比主观百分比低15到25个百分点，这个差值本身就是最有价值的信息，它代表团队对完成的理解比PMO宽松。
另外要把计划进度和实际进度分成两条线：计划进度按基线日期算，实际进度按已验收交付物算，两者差值超过10%要求提交偏差说明，超过20%升级到项目发起人。
3. PMO的进度例会和周报怎么做才不流于形式？
我们之前的周报是十几个项目各写一段，我每周一上午花两小时看完，还是不知道哪个项目真的要出事。例会也是轮流念进度，念完就散会，没人被推动。后来我把周报砍到一页，会议只讨论偏差，才慢慢有点用。
核心原则是报告看偏差、会议解阻塞。周报模板压到一页，只保留四块内容：本周计划完成但未完成的交付物及原因、下周必须完成的关键交付物、需要跨部门决策或资源支持的事项、当前红黄灯状态。红黄灯要有客观定义，不能凭感觉：黄灯指关键路径上的交付物延期1到3个工作日，或存在一个未决的跨部门依赖；
红灯指关键路径延期超过3个工作日，或里程碑日期需要变更。例会把80%的时间花在黄灯和红灯项目上，绿灯项目只在会上确认一句无变化。会议控制在45分钟内，每个偏差项必须当场产出三件事：责任人、新的承诺日期、下一步动作。跨部门阻塞如果当场解决不了，24小时内升级到对应决策人，不要留到下周再讨论。
判断机制是否有效，看两个数：会议中无变化项目的占比是否超过60%，以及红灯项目从出现到有明确处置动作的平均时长是否缩短到3天以内。
4. 进度管理什么时候该从表格换成项目管理平台，怎么选才不踩坑？
我们一开始用共享表格管二十多个项目，版本满天飞，谁改了哪一行都说不清。后来上了平台，结果大家还是把表格导进去当附件用，流程一点没变。所以我现在判断要不要换工具，不看功能清单，先看三个数。
先看三个判断指标。第一，并行项目数，稳定超过10个且跨3个以上部门时，表格的版本管理和权限控制基本撑不住；第二，跨项目依赖数量，如果每周需要人工核对超过20条依赖关系，靠表格迟早出错；第三，变更频率，如果需求或排期每周变更超过2次，就需要有留痕的变更记录和影响范围提示。
三个里中两个以上，才值得上工具。选型时按顺序验证四件事：能不能按你已经定好的进度口径去配置状态和交付物，而不是被工具的固定字段带着走；依赖关系和关键路径能不能自动推导，还是仍要人工维护；权限粒度能不能做到项目成员只看自己项目、PMO看全局；能不能导出原始数据做二次分析，避免被单一平台锁死。
迁移不要一次性全量铺开，先选2到3个配合度高的项目试点运行一个季度，用一组对照数据判断效果，比如周报准备时间从几小时降到几小时、进度偏差的发现时间从平均几天提前到几天。试点数据不达标就继续调流程，别急着全员推广。
核心关键词
文章包含AI辅助创作：项目进度怎么做？PMO流程优化：进度管理从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/411600
读者评论
我们一百多人的团队正好卡在文章说的第二种形态，工具买了两年，真正在用的字段就一个任务名。想请教下，让一线愿意更新状态，除了把更新动作挂到代码提交这类自然节点上，还有别的实操办法吗？我们试过考核，结果变成下班前统一刷一遍状态。
计划完成率”那个误区太真实了。我们部门连续几个季度完成率都在95%左右，但项目实际交付一拖再拖，后来才发现大量任务被悄悄挪到了下个周期。不过我对换成计划稳定度有点疑问：需求本来就频繁变动的业务线，改期率高是不是反而正常？这个阈值可能得按业务类型分开看。