企业官网建设流程全解析

简介：《Standish Group 2020混沌报告》项目成功速查卡片是一份面向项目经理、敏捷教练及PMO团队的经典参考资料，基于CHAOS 2020研究数据提炼项目成功的三大核心要素：赞助人、团队与工作环境，并给出各自对应的十条原则及成熟度与成功率对照。资源为单个PDF文档，压缩包约3.26MB，内容紧凑、图文结合，适合移动端随时查阅或打印使用。已有680人学习收藏。读者可从中获得关于“好赞助人”的决策延迟、愿景、影响力等原则，关于“好团队”的沟通、正念、解决冲突等实践，以及“好工作环境”的情绪成熟、用户参与等要点；同时附带按成熟度划分的项目成功率统计，便于组织对照自身成熟度水平制定改进策略，快速提升项目交付成功率。

1. 一份 2020 年的 CHAOS 报告 PDF，为什么到今天还在被引用

做项目管理的人，对 Standish Group 的 CHAOS 报告应该不陌生。它以大量真实项目样本为基础，给出“成功、受挑战、失败”三类项目占比，是很多组织制定项目治理政策时的参照物。project-success-qrc-standish-group-chaos-report-2020.pdf这个文件，正是 CHAOS 2020 报告中关于项目成功率评估的一份 PDF 文档，其中 QRC（Quantitative Risk Criteria）常被理解为“量化风险判定口径”，也就是用来界定一个项目到底算不算成功的那套硬性门槛。

这份资料的价值不在于那张好看的饼图，而在于它把“项目成功”从一个抽象口号拆解成可复核的指标。无论你是 PMO 负责人、项目经理还是敏捷教练，都需要回答同一个问题：凭什么说一个项目成功了？如果只看“上线了”或者“验收通过了”，很可能把延期和超支掩盖在灯笼下。CHAOS 报告里的 QRC 思路，恰好提供了一套可操作的判断框架。接下来，我们从判定模型、PDF 数据提取、到落地自己的指标体系，一层层拆开来讲。

2. Standish 的判定口径：CHAOS 报告里的“成功”到底怎么算

2.1 三类结果的划分方式

CHAOS 报告从 1994 年开始发布，长期把项目结果分成三类：成功（Successful）、受挑战（Challenged）和失败（Failed）。2020 年的 CHAOS Report 沿用了这套框架，只是对“成功”的定义更加严格。按常见做法，成功项目需要同时满足“按计划时间”“按预算”和“按预期功能范围”三个条件。只要延期、超支或范围缩水，就会被划到受挑战一类。而失败则指项目被取消或交付后完全无法使用。

QRC 在这里的作用，就是把这三个条件进一步量化。例如，“按预算”不是笼统说“没超出”，而是允许一个固定误差范围，超出若干个百分点就算失败。不同组织可以调整这个范围，但 CHAOS 报告给出了一个参考基线。理解这一点很重要：对外行来说，报告里的 31% 成功率是“所有项目中有多少完全达标”；对内行来说，更重要的是那 69% 的项目，到底在时间、预算、范围这三个维度上偏离了多少。

2.2 从 CHAOS 报告里我们能拿到哪些字段

一份规范的 CHAOS 报告 PDF，通常包含按行业、按项目规模、按组织年限分类的成功率数据。最常见的字段有：

这些字段分布在 PDF 的不同章节。有的表格是行业细分，有的表格是项目规模细分。拿到 PDF 后，第一件事不是看结论，而是确认表头里“成功”的判定条件是否与 QRC 一致。很多引用 CHAOS 报告的人，错把“上线”当“成功”，导致后续决策的数据基础就已经偏了。

2.3 为什么 QRC 比“上线率”更接近项目本质

“上线率”只看结果状态，而 QRC 看的是过程约束。一个项目即使上线了，但延期一年、预算翻倍，按 QRC 只能算受挑战。这种口径对开发团队更公平，因为它承认了工程不确定性；对管理层也更诚实，因为它暴露了计划质量。QRC 的另一个特点是可回溯：只要记录了计划时间、预算基线和验收范围，任何人拿同一份数据都能得出同样的分类。

如果你要在自己的组织里对标 CHAOS 报告，建议先照抄它们的口径跑一遍历史项目，再根据自身行业特点调整。不要一上来就发明新指标，否则你得到的数据和公开报告不可比，也就失去了“对标外部基准”的意义。

3. 把 CHAOS 2020 PDF 变成可分析的数据：表格提取实操

3.1 先判断 PDF 是扫描件还是文本型

很多网上流传的 CHAOS 报告是扫描版，看起来像 PDF，实际是图片。这种情况下，pdfplumber 的extract_tables可能什么都提取不到，因为根本没有文本层。我一般会先用pdfplumber.open打开文件，检查第一页是否有可提取字符。如果全是空白，就要先做 OCR，或者在 Python 里先跑一遍筛选，避免后面解析时踩坑。

下面的代码用pdfplumber打开你拿到的project-success-qrc-standish-group-chaos-report-2020.pdf，并统计每页表格数量：

import pdfplumber pdf_path = "project-success-qrc-standish-group-chaos-report-2020.pdf" with pdfplumber.open(pdf_path) as pdf: for i, page in enumerate(pdf.pages): text = page.extract_text() tables = page.extract_tables() if text or tables: print(f"第 {i} 页: 文本长度 {len(text or '')}, 表格 {len(tables)} 个")

这段代码的作用有三层。第一，pdfplumber.open以上下文管理器方式打开文件，结束后自动释放资源；第二，page.extract_text()返回当前页所有文字，如果返回None说明该页是纯扫描图像；第三，page.extract_tables()返回该页内的所有表格对象，每个表格是一个二维列表，方便后续转成 DataFrame。建议先跑这段看输出，根据页号缩小解析范围，避免把目录页的文字也混进数据。

3.2 提取核心表格并转成 DataFrame

确认 PDF 有文本层后，就可以精准提取。CHAOS 报告中的成功率汇总表通常出现在前几章，我一般会提取所有表格，再按表头关键词过滤。

import pdfplumber import pandas as pd rows = [] with pdfplumber.open("project-success-qrc-standish-group-chaos-report-2020.pdf") as pdf: for page in pdf.pages: for table in page.extract_tables(): for raw_row in table: # 去掉全空行 if any(cell is not None and str(cell).strip() for cell in raw_row): rows.append([str(cell).strip() if cell else "" for cell in raw_row]) df = pd.DataFrame(rows) # 查找包含“成功”和“样本”的行，作为表头所在位置 header_idx = df[df.apply(lambda r: r.astype(str).str.contains("成功").any(), axis=1)].index.tolist() print("潜在表头行:", header_idx) print(df.head(20))

这里的any()判断是核心。如果不加，大量空表单元格会被保留下来，导致 DataFrame 出现很多错位。另一个值得注意的地方是，CHAOS 报告里“成功”和“受挑战”可能是中文版报告的映射，也可能是原版英文 “Successful”、“Challenged”，过滤关键词时可以同时写多个词，比如成功|Successful。先用head(20)看前 20 行，确认表头位置，再手动指定列名，比自动识别更可靠。

3.3 数据清洗时最容易犯的三个错

表格提取出来只是第一步。CHAOS 报告这种多表合并的 PDF，转成 DataFrame 后会有三个明显问题：表头重复、百分比带%符号、年份是字符串区间。

# 清洗示例 df_clean = df.dropna(how="all") df_clean = df_clean[~df_clean.apply(lambda r: r.astype(str).str.contains("年份|项目规模|Success|Challenged").any(), axis=1)] # 把百分比列转成小数 for col in df_clean.columns: if df_clean[col].astype(str).str.contains("%", na=False).any(): df_clean[col] = df_clean[col].astype(str).str.replace("%", "").replace("", "0").astype(float) / 100 print(df_clean.head())

第一个问题，表头重复，因为 PDF 分页后每页重复了相同的表头，需要按内容过滤掉。第二个问题，百分比列是字符串，astype(float)会直接报错，所以先去掉百分号再转。第三个问题，年份列可能是"2013-2019"，这没问题，但如果要按年拆分，需要用split提取起始和结束年。完成清洗后，你可以按自己的口径重新计算成功率：

# 估算样本数的成功项目数量 df_clean["成功项目数"] = df_clean["样本数"] * df_clean["成功"] print(df_clean["成功项目数"].sum())

这里假设样本数列已经是数值类型。如果清洗不彻底，数值列可能还是对象类型，建议在转换后执行df_clean = df_clean.apply(pd.to_numeric, errors="ignore")，只转换可数值化的列。

4. 把 QRC 变成你自己的项目成功度量：三个必调参数

4.1 时间偏差阈值：容忍延期多久算失败

Standish 的原始口径很严格，一天延期就算 challenged。但在实际组织里，完全按这个口径推进会很痛苦，因为需求变更和外部依赖必然带来计划调整。我见过的做法是：把“延期”定义为一个相对基线计划的百分比，例如延期不超过 10% 算正常波动，超过 10% 但不超过 30% 算受挑战，超过 30% 算失败。

def classify_delay(actual_days, planned_days): delay_percent = (actual_days - planned_days) / planned_days if delay_percent <= 0.10: return "成功" elif delay_percent <= 0.30: return "受挑战" else: return "失败"

这个函数里的0.10和0.30就是你要调的参数。对招投标类项目，客户通常不允许延期超 15%，那就改成0.05和0.15。对内部工具类项目，可以给到0.20和0.50。注意，参数一旦定下来，就不要在一个统计周期内频繁改，否则历史数据不可比。

4.2 预算偏差阈值：拿到立项基线后再谈偏差

预算偏差比时间偏差更难算，因为很多组织把“预算”和“实际财务支出”定义得很含糊。QRC 语境下的预算偏差，应该以项目立项时批准的资金盘为基线，不包括后续追加的部分。追加预算如果走的是正常变更流程，那可以视为范围扩大；如果没有走流程，只是账目上补了一笔，那就应该算预算偏差。

def classify_cost(actual_cost, baseline_cost): cost_percent = (actual_cost - baseline_cost) / baseline_cost if cost_percent <= 0.10: return "成功" elif cost_percent <= 0.20: return "受挑战" else: return "失败"

这里的baseline_cost必须从立项文件里读取，而不是用项目组自行上报的数字。我看见过不少项目实际超支 50%，但上报的 baseline cost 也被同步调高了，导致算出来仍然在成功区间。为了堵住这个口子，最好把baseline_cost的来源字段和成本季度汇总表做交叉校验，确保不是同一个 Excel 单元格生产出的两个数字。

4.3 功能范围偏差：从“实现的功能数”转向“可用的业务价值”

CHAOS 报告的原始口径是看范围内功能是否全部交付，但 2020 年前后很多组织开始用价值流指标替换功能完成率。一个最简单的做法是维护一张功能清单，每个功能标上「计划交付」和「实际交付」的日期，以及对应的业务价值权重。

features = pd.DataFrame({ "feature": ["登录", "支付", "报表"], "planned": [1, 1, 1], "actual": [1, 1, 0.5], # 报表只做了部分 "value_weight": [10, 50, 40] }) features["value_delivered"] = features["actual"] / features["planned"] * features["value_weight"] total_value_ratio = features["value_delivered"].sum() / features["value_weight"].sum() print(f"业务价值实现率: {total_value_ratio:.2%}")

这个例子中，报表功能只交付了 50%，但因为业务价值权重占 40%，整体实现率只有(10 + 50 + 20) / 100 = 80%。如果按传统功能点算法，实现率是(1+1+0.5)/3 = 83.3%，两种口径差别不大；但如果把报表的价值权重调到 60%，差别就出来了。QRC 的意义不是规定权重怎么设，而是要求你必须显式定义并记录权重。不记录权重，那 20% 的功能缺失会被隐藏在总数里，下次复盘根本找不出是谁拖累了成功率。

5. 用历史报告做交叉验证：排查虚假成功率的三个技巧

当你把 2020 年的 CHAOS 报告 PDF 清洗成自己的数据表后，别急着做结论。先做一个动作：把你整理的「成功率」和公开可查的 CHAOS 报告历史趋势放在同一张图里。如果自己的数据和报告里的差异超过 5 个百分点，先不要怀疑报告，先去查自己的清洗逻辑。

第一个技巧，用「受挑战项目」的平均偏差反推样本分布。CHAOS 报告通常会公布平均预算偏差和时间偏差。你可以用这两列和成功率一起做一次敏感性回归，看看是不是存在某种系统性偏差。例如，如果报告显示平均预算偏差是 26%，而你自己算出来的所有成功项目的平均预算偏差是 8%，那很可能你把“预算”定义成了“最终清算金额”，而不是立项基线。这时回到 PDF 原文，找出 QRC 章节的注释，逐字比对后修正。

第二个技巧，检查重复统计。PDF 转表格时，经常出现同一张表在一个页码被提取两次的情况，合并后的 DataFrame 里“样本数”翻了一倍。跑一次df_clean["样本数"].sum()，和报告里给出的总样本数对比。不一致就把drop_duplicates()加在去重逻辑里，按年份和项目规模双主键去重。我处理过一份 2020 年的报告数据，原始提取有 4 个表格重复统计了“大型项目”子样本，去掉后成功率直接掉了 3 个百分点。

第三个技巧，用外部基准复核自己的 QRC 参数。你设的0.10延期阈值，放到你所在行业是否合理？查同行公开发表的项目复盘数据，如果大多数项目延期在 20% 左右，而你把阈值设成0.30，那么统计出来的“成功”其实夹带了很多水分。一个务实的做法是把阈值调低 5 个百分点，看成功率下降的幅度。如果变化超过 10%，说明你的项目群体处在阈值边界附近，这时候要敏感对待“打分规则改变结论”的风险。

最后，把你写好的清洗脚本和参数配置保存为可重复执行的 Python 文件，每次有新的项目月度数据时直接跑一遍，输出结果再和 CHAOS 2020 的基准并排展示。这才是 QRC 真正的落地点：它不是一次性的报告解读，而是一条反复校准项目成功标尺的流水线。

本文还有配套的精品资源，点击获取