我见过最离谱的一份立项背景，正文第一页写的是公司成立于哪一年、有多少员工、通过了哪些认证，翻到第三页才出现”本项目”三个字。而它第五章”风险与应对”里只有一句话：“项目成员经验不足，需加强培训。” 半年后项目延期 11 周，复盘时大家发现，真正卡住进度的不是”经验不足”，而是核心结算模块只有一名开发能改，而他在第 7 周被抽调到另一个”更紧急”的项目上。这个信息在立项阶段所有人都知道，只是没有人把它写进背景里。
这篇文章想回答的问题很具体：立项背景到底该写什么、写到什么颗粒度，才能让项目成员风险在开工之前就暴露出来，而不是在延期之后才被追认。我会给你一套可以照着填的七要素模型、一张成员风险四象限表、六步操作步骤，以及我在多家中大型企业评审现场观察到的真实数据与踩坑记录。
一、核心结论：立项背景的第一读者不是领导，而是半年后的你自己
1. 立项背景的本质是”决策留痕”，不是”项目简介”
绝大多数人把立项背景当成一份向上汇报材料，所以写法天然偏向”讲得漂亮”：行业趋势、公司战略、领导指示、技术先进性。但项目执行到第 12 周，当你需要判断”这个需求该不该接”时，能救你的不是行业趋势，而是背景里那句”本项目只覆盖华东区直营门店，加盟店不在范围内”。
我的判断是：立项背景的唯一有效标准是，它能不能在未来被当成一份判断依据来使用。一份合格的背景，应该让一个完全没参与立项的人，在 15 分钟内回答出三个问题：为什么现在做、不做的代价是什么、哪些条件变了就必须重开立项。
如果背景做不到这一点，它就不是背景，是宣传稿。
2. 三个我在评审现场反复验证过的结论
过去几年我作为外部评审参与过 200 多场立项评审会，其中有完整复盘数据的样本大约 37 个。基于这批样本，有三个结论非常稳定。
- 结论一：背景要素低于 3 项的项目，几乎必然在中后期发生范围争议。争议点往往不是”要不要加需求”，而是”这个需求本来就在范围内吗”，而这个问题只能靠背景回答。
- 结论二：成员风险写得越模糊，项目中期的人力冲突越激烈。写成”经验不足”的，冲突发生在执行层；写成”模块 X 只有 1 人可维护，且其在 Y 项目上已占用 60% 工时”的，冲突会提前到排期阶段解决。
- 结论三：背景写得好不好，和是否使用项目管理工具没有必然关系，但和”背景是否被结构化存储”强相关。存在文档里、靠搜索找的，半年后基本没人再打开。
下面这组对比来自我跟踪的 37 个样本，按”立项背景要素齐全度”分组后的项目结果差异非常明显。这组数据是样本推演，不是行业统计，但它和我后来在其他企业看到的情况高度一致。
3. 成员风险不是”风险登记册”的事，是”背景”的事
这是我必须强调的一个反常识观点：大部分团队把成员风险放进风险登记册，是放错了地方。风险登记册是执行期的动态台账，更新频率高、关注度低、容易被当成形式主义。而成员风险是立项决策的输入条件，如果这个项目需要的能力公司现有人力覆盖不了，那这个项目现在就不该立，要么改范围，要么先招人。
把它写在背景里，它就会在立项会上被讨论；写在风险登记册里，它只会在复盘会上被引用。
二、真实场景：为什么大量立项背景最后写成了”公司简介”
1. 一次典型的立项评审现场
我印象最深的一次评审，是一家年营收 30 多亿的制造企业做 MES 替换立项。材料 28 页，前 9 页讲行业趋势和智能制造政策，第 10 页讲公司信息化现状，第 14 页才出现本次项目的范围和预算。
评审到第 40 分钟，一位生产副总问了一个问题：”现在这套系统到底哪里不能用？”全场安静了大概 10 秒，因为材料里没有一条量化的现状基线，只有”效率偏低””协同不畅”这类形容词。
最后这个立项被退回重写，退回意见只有一句话：“请补充三条可测量的现状问题，以及不做这个项目的具体代价。”
2. 立项背景写歪的三个结构性原因
写歪不是态度问题，是结构问题。我看到的原因基本集中在三点。
- 原因一：模板本身是错的。很多企业的立项模板沿用十年前的”项目概况”结构，天然要求先讲宏观、再讲微观，写出来的东西必然是公司简介开头。
- 原因二：写背景的人不是承担后果的人。文档常由 PMO 或技术骨干代笔，他们对业务痛点只有二手信息，只能写宏观。
- 原因三：没人要求背景”可证伪”。没有量化基线、没有触发条件、没有失效时间，写什么都无法被验证，自然怎么写都行。
3. 返工成本的真实分布
我把这 37 个项目在立项阶段发生的”返工”做了归因，结果和我预期有出入：排第一的居然不是”预算口径”，而是”业务目标未量化”。
注意，前四项里有两项是关于人的。这意味着只要在背景阶段把”谁来做、他有没有空、他走了怎么办”写清楚，大约 38% 的立项返工可以被消灭。
三、拆解常见误区：五句话毁掉一份立项背景
1. 误区一：把背景写成行业趋势
典型句式是”随着数字化转型的深入，行业竞争日趋激烈”。这句话放在任何一家公司、任何一个项目里都成立，因此它对决策没有任何信息量。
判断标准很简单：把这句话里的项目名换成另一个项目，如果依然成立，这句话就该删。背景里的每一句话都应该具备”只对本项目成立”的排他性。
2. 误区二：把成员能力当成成员风险
“团队缺乏经验””需要加强培训”，这是能力描述，不是风险描述。风险必须具备三要素：发生可能性、影响程度、可观测的触发信号。
“缺乏经验”没有触发信号，所以它无法被监控。而”结算模块仅 1 人具备修改能力，该人员 9 月起被 X 项目占用 60% 工时”具备完整三要素：可能性高、影响是进度阻塞、触发信号是工时占用超过 50%。
3. 误区三：背景只写给审批人看
审批人只关心”该不该批”，执行人关心”我具体要做什么”。如果背景只服务前者，执行人就必须自己去猜，猜错就是返工。
我的做法是：背景写完，先给一个完全不了解这个项目的同事看 15 分钟，然后让他复述项目要解决什么、范围和边界在哪。复述不出来，就重写。
4. 误区四：立项即冻结，背景不再更新
背景确实应该在评审通过后冻结为基线版本，但”冻结”不等于”永不更新”。正确做法是基线冻结 + 变更留痕：任何对目标、范围、关键成员的修改，都以变更单形式追加，原始基线不动。
这样一年后回头看，你能清楚看到项目是怎么从 A 目标漂移到 B 目标的。没有这条轨迹，所有偏差都会被归因成”执行不力”。
5. 误区五：项目管理工具只用来排进度
这是我见过最普遍的浪费。很多企业买了项目管理平台，只用了甘特图和任务看板，立项背景仍然存在共享盘里。结果就是背景和任务割裂，任务变更时没人回头改背景。
成员风险尤其如此。人员占用情况、技能矩阵、替补人选，如果不能和任务排期联动，那它就是一份静态表格，三个月后必然过期。
四、专业判断逻辑：背景七要素 + 成员风险四象限
1. 立项背景七要素模型
我把一份可用的立项背景拆成七个要素，缺任何一项都会在后期产生特定的麻烦。这个模型是我在多个中大型企业的立项模板基础上反复删减后定型的。
| 要素 | 必须回答的问题 | 合格标准 | 常见不合格写法 |
|---|---|---|---|
| 业务问题 | 现在到底哪里痛？ | 可被业务方原话复述，且不含解决方案 | “系统老旧，需要升级” |
| 现状基线 | 痛到什么程度？ | 至少 3 个带单位和统计口径的指标 | “效率较低””投诉较多” |
| 触发事件 | 为什么是现在？ | 具体到时间点或事件 | “顺应数字化转型趋势” |
| 不做的代价 | 如果今年不做会怎样？ | 可量化的损失或不可逆的机会成本 | “将影响公司竞争力” |
| 成功标准 | 怎么算做成了？ | 验收时能被第三方独立判定 | “用户满意度提升” |
| 边界与约束 | 明确不做什么？ | 列出至少 3 条排除项 | 只写”范围待细化” |
| 关键干系人与成员风险 | 谁影响成败？谁可能掉链子？ | 含决策人、执行人、可用性与替补方案 | “团队经验不足需培训” |
这七项里，前六项是常规做法，第七项才是真正拉开差距的地方。而第七项恰恰是绝大多数立项背景写得最敷衍的。
2. 成员风险四象限
我把项目成员风险按两个维度切分：横轴是”该成员能力在本项目中的不可替代性”，纵轴是”该成员在本项目周期内的可用性波动”。两个维度交叉后，得到四类需要不同处置方式的风险。
| 象限 | 不可替代性 | 可用性波动 | 典型表现 | 处置策略 |
|---|---|---|---|---|
| 高危区 | 高 | 高 | 唯一能改核心模块的人，同时被 2 个以上项目争抢 | 立项阶段就必须锁定工时，写入背景作为约束条件；同时启动备份人培养，排进项目计划 |
| 隐性区 | 高 | 低 | 核心人稳定但无备份，一旦离职或病假直接断档 | 在背景中标注”单点依赖”，并设定知识转移里程碑 |
| 浪费区 | 低 | 高 | 参与人可替换，但频繁换人导致上下文丢失 | 降低其决策权，改为任务执行；交接文档标准化 |
| 可控区 | 低 | 低 | 常规资源，可随时增减 | 按正常资源管理，无需写入背景 |
关键判断原则是：高危区和隐性区的成员，必须写进立项背景，并且在立项评审会上被显式讨论。不是放在风险登记册里等以后再说。
3. 从背景反推”立项必须回答的五个问题”
如果你时间极其有限，只来得及做一件事，那就把这五个问题问完并记录答案。
- 这个项目不做，公司在未来 12 个月会损失什么？由谁承担这个损失？
- 现状的三个量化基线数字是多少？谁提供的？什么时候的数据？
- 这个项目明确不包含什么？说三条。
- 哪些人具备不可替代性？他们在项目周期内的可用工时是多少？谁确认的？
- 如果第 4 条里的关键人明天离职，项目会怎样？有没有已启动的应对动作？
这五个问题问完，一份立项背景的骨架就立起来了。剩下的都是格式和表达问题。
五、操作步骤：从零产出一份可评审的立项背景
1. 第一步：锁定业务发起人，拿到一句话问题陈述
立项背景的第一句话不该由 IT 或 PMO 写，必须由业务发起人说。你要做的是追问，不是代笔。
追问的话术可以固定下来：”如果这个项目最后只解决一个问题，你希望是哪个？”把对方的回答原封不动记下来，作为背景第一段。业务方的原始表述往往比润色后的更有信息量，因为它包含了真实的痛感来源。
2. 第二步：量化现状基线，至少三个指标
基线指标必须满足三个条件：有单位、有统计口径、有取数时间。比如”订单人工录入平均耗时 8.5 分钟/单（2024 年 6 月，华东区 12 家门店抽样 480 单）”。
如果业务方给不出数字，说明他们对问题的理解还停留在感受层。这时候不要替他们编，而是把”基线数据缺失”本身作为立项的前置任务写入背景。
3. 第三步：成员盘点与风险建档
这一步是最容易被跳过的，也是最值钱的。具体做法是给每个将在项目中投入超过 20% 工时的人建立一行记录，包含六列。
成员风险建档模板（建议字段）
——————————–
姓名 / 角色 : 张伟 / 核心开发
项目投入工时占比 : 60%
不可替代性等级 : 高（结算模块唯一可维护人）
周期内可用性波动 : 高（9月起被 X 项目占用至 60%）
单点依赖风险 : 是，无备份人
应对动作与截止时间 : 10月底前完成结算模块知识转移，备份人：李芳
确认人 / 确认时间 : 研发经理 王强 / 2024-08-20
归档位置 : 项目管理系统「立项-成员风险」工作项类型，字段级权限：项目组可见
这六列写完，一个成员风险就从”感觉”变成了”可跟踪项”。它有时间、有责任人、有验证方式。
4. 第四步：把背景拆成可追踪的立项要素
背景写完之后，不要让它停留在文档形态。要把七要素拆成七个可被追踪的对象，尤其是”成功标准””边界与约束””成员风险应对动作”这三项，它们必须在项目执行期持续被引用。
我通常的做法是：成功标准对应到项目级验收清单，边界与约束对应到需求准入规则，成员风险应对动作对应到带日期的任务。这样背景就活了。
5. 第五步：用项目管理系统固化，而不是存在共享盘里
这是把背景从”一次性文档”变成”持续资产”的关键一步。以 PingCode 为例，中大型企业常见的一种落地方式是这样组织的。
把”立项申请”做成一个独立的工作项类型，七要素分别对应自定义字段，其中”现状基线”用数值字段+”取数时间”日期字段，”边界与约束”用多行文本+”排除项”标签，”成员风险”直接关联到成员台账工作项。评审状态走状态流转，每一次驳回和修改都留痕。
对于从 Jira 迁移过来的团队，历史项目的立项数据可以在迁移时一并保留，这样新老项目在同一套体系里可检索、可对比。PingCode 支持 Jira 平滑迁移，也支持私有化部署，这两点对 100 人以上、有数据合规要求的中大型组织尤其重要，立项背景里往往包含组织架构、人员占用、预算口径这些不适合放在公有云上的信息。
6. 第六步：评审、冻结、建立变更通道
评审会不应该从头讲一遍背景，而应该只讨论三件事：基线数字对不对、成员风险处置动作够不够、边界排除项有没有遗漏。
评审通过后，把当前版本标记为基线版本并冻结。此后任何修改走变更流程，记录”谁提出、为什么、影响哪些要素”。一年后你会有两份东西：原始基线，和一条完整的漂移轨迹。
六、具体案例与数据观察
1. 一个失败案例：把人名写进背景，但没写可用性
某 1200 人规模的装备制造企业，2023 年启动供应链协同平台项目。他们的立项背景写得其实不差：有业务问题、有三条量化基线（采购对账平均 6.5 人天/月、异常订单占比 11%、供应商响应平均 42 小时）、有明确的范围排除项。成员部分也写了人名和角色。
问题是，他们只写了”核心开发：3 人”，没写这 3 人的工时占比和同期占用情况。项目启动第 5 周，其中 2 人被集团另一个合规项目抽走，每周可投入时间从 5 天降到 1.5 天，项目直接停滞 3 周。
复盘的结论很扎心：这个风险在立项时完全可见，因为在评审会上那位研发经理确实提过一句”这两个人下半年可能忙”，但这句话没有被写进背景，因此没有进入决策。
2. 改进后的做法
这家企业在 2024 年重新立项时做了三件事：立项模板新增”成员可用性”必填字段；成员风险必须包含应对动作和截止时间；所有立项材料统一在项目管理系统中提交与评审。
他们选择了 PingCode 作为承载平台，主要考虑三点：一是支持私有化部署，立项材料涉及人员占用和预算，不适合外发；二是支持 Jira 平滑迁移，可以把历史 60 多个项目的立项记录迁过来做对比；三是工作项字段可以按立项模板自定义，不需要为了适配工具而扭曲模板。
下面是改进前后 6 个月的对比观察，数据来自该企业 PMO 提供的内部统计，我做了脱敏处理。
3. 一个反直觉的观察：立项周期变短了
很多人担心”把成员风险前置会拖慢立项”。这家企业的数据给出了相反的答案：立项到开工的平均天数从 26 天降到 14 天。
原因不复杂。过去的时间不是花在决策上，是花在来回补材料上。一旦背景一次性写到位，评审会只需要 40 分钟，不需要开第二次。
七、不同情况下的行动建议
1. 100 人以下的团队：只做三件事
小团队不需要七要素全套文档，那会变成负担。只做三件事就够：一句话问题陈述、三个基线数字、一份成员可用性清单。
成员可用性清单可以用最轻的方式维护，一个表格，四列：姓名、在本项目投入比例、同期其他项目、替代人选。每周更新一次，比任何工具都有效。
2. 100 到 500 人的组织：把成员风险做成字段，不要做成附件
这个规模是分水岭，项目数量上来了，靠人记已经记不住。核心动作是把立项背景结构化：七要素变成七个字段，成员风险变成独立工作项并和排期关联。
这个阶段最值得投入的是工具选型。要确认工具支持自定义工作项类型和字段级权限，否则你的立项模板会被工具倒逼变形。
3. 500 人以上或多事业部：必须做立项基线与变更留痕
这个规模的组织，最大的风险不是某个项目做砸，而是同类项目在不同事业部重复踩同一个坑。所以立项背景的价值一半在于本项目，一半在于跨项目复用。
建议建立立项档案库，按业务域、技术栈、风险类型打标签。新项目立项时先检索历史同类项目的背景与成员风险记录，能省掉大量重复调研。
4. 强合规行业：把背景纳入受控文档体系
金融、医疗、军工等行业的立项背景通常需要审计留痕。这类场景下，私有化部署几乎是必选项，因为立项材料里包含组织架构、人员工时、预算口径等敏感信息。
同时要注意版本控制：基线版本、变更版本、审批记录必须可追溯到具体人和具体时间。这一点在选型时要明确验证，不要等到审计时才发现日志不全。
八、不同情况下的取舍
1. 速度与严谨的取舍
如果项目窗口期极短（比如要赶一个政策节点或大促节点），不要试图做完整七要素。我的建议是保三舍四：保业务问题、保成功标准、保成员风险，其余四项可以后置补录。
原因是这三项直接决定项目会不会跑偏；而现状基线、触发事件、不做的代价，可以在开工后两周内补齐，不影响执行。
2. 全员透明与隐私保护的取舍
成员风险评估天然涉及个人工作负荷和绩效信息，全员公开会引发抵触。我的做法是分层：项目组内可见”谁在哪个模块不可替代、替代人是谁”，但”个人工时占比、同期项目占用”只对项目经理和其直属主管可见。
这个分层能不能实现，取决于工具是否支持字段级权限。不支持的话，最后要么全公开（伤士气），要么全隐藏（失去意义）。
3. 自研立项系统与采购平台的取舍
我见过两家企业自研立项模块，最后都变成了”电子表单 + 审批流”，因为没有任务管理能力，背景和排期始终是两张皮。自研的隐性成本往往被低估。
除非你有非常特殊的合规要求，否则我倾向于用成熟平台承载立项背景，把自研精力留给真正的业务系统。
4. 私有化部署与 SaaS 的取舍
取舍标准不是安全偏好，而是数据敏感度。如果立项背景里包含组织架构、人员工时、预算明细、客户名称，那么私有化部署基本是刚需。
反过来，如果只是纯技术项目、不涉及人员与财务信息，SaaS 的迭代速度和运维成本优势更明显。这里没有标准答案，只有和你的数据分级制度是否一致。
九、常见问题与快速答疑
1. 立项背景一般写多长合适？
我的经验区间是 1200 到 2000 字，加上一到两张表格。低于 800 字通常说明要素不全，超过 3000 字通常说明混入了不该放在这里的内容，比如详细技术方案、完整排期、预算明细。这些应该各自独立成章节，不要塞进背景。
2. 如果业务方坚持不给量化基线怎么办？
不要替他编数字。把”补齐三条基线指标”作为立项前置任务写入背景，并设定截止时间和责任人。这本身就是一种诚实的立项状态说明，评审会通常也会认可。
3. 成员风险要不要写具体人名？
必须写。不写人名的风险无法被验证，也无法被跟踪。如果担心敏感，可以通过权限控制访问范围，但不能用”核心开发岗位”这种模糊表述替代。
4. 小团队也要建成员风险档案吗？
要，但可以极简。10 人团队就一张四列表格，每周更新。它的价值不在于文档本身，而在于逼你每周想一次”这个人下周还在吗”。
5. 立项背景评审通过后还能改吗？
可以改，但要留痕。正确姿势是基线冻结 + 变更单追加。原始基线永远保留，这样一年后你能看到目标是怎么漂移的，而不是只剩一个”执行不力”的结论。
6. 怎么判断一份立项背景写得好不好？
用一个简单的测试：找一个没参与立项的同事，给他 15 分钟阅读，然后让他回答”这个项目不做什么”和”谁最可能拖后腿”。答不出来，就是没写好。
十、总结与下一步行动
回到最初的问题：立项背景写得好不好，不取决于文笔，取决于它能不能在未来被当成判断依据使用。业务问题、现状基线、成功标准、边界约束、成员风险，这五项决定了项目会不会跑偏；而成员风险是其中投入产出比最高、却最常被敷衍的一项。
我特别想强调一个容易被忽略的判断：把成员风险从”风险登记册”挪到”立项背景”，不是流程上的位置调整，而是决策时点的前移。写在背景里，它会被讨论、被确认、被写成约束条件；写在登记册里，它只会在复盘时被当作解释。
如果你打算下周就动手改，我建议按这个顺序走：
- 先改立项模板，把”成员可用性”设为必填字段，这一条改动成本最低、收益最快。
- 再做一次成员风险试盘点，挑一个正在进行中的项目，把参与人按四象限分类，看看有多少落在高危区和隐性区。
- 然后解决载体问题。如果立项背景还躺在共享盘里，先把它结构化，字段化的背景才能被检索、被联动、被追溯。对 100 人以上、有数据合规要求的组织，选择支持私有化部署的平台会更稳妥。
- 最后建立一条最小可行的变更通道：谁提出、为什么改、影响哪些要素。不用复杂，能留痕就行。
这四步做完，大概需要两三周。但从下一个项目开始，你会明显感觉到评审会变短、返工变少、延期时的争论从”谁的责任”变成”哪个假设失效了”。这才是立项背景真正该起的作用。
常见问题解答（FAQ）
1. 项目背景怎么写才不像套话，有没有可直接套用的结构？
我第一次写立项书的时候，背景那段被领导批“全是形容词”，什么“提升效率、赋能业务”写了一大段，但没人知道到底为什么要做。后来我发现问题不在文笔，而在于我没把业务现状讲成一个有数字、有触发点的故事。现在每次立项我都想找一套不靠灵感的结构。
用“现状数据，触发事件，不做的代价，目标与边界”四段式写，每段至少落一个可核验的数字。第一段现状：写清当前流程和基线，例如“客服工单平均处理时长 4.2 分钟，口径为近 3 个月 12,000 条工单的系统导出值”，必须标明数据来源和时间窗口，否则评审时一被追问就站不住。
第二段触发：写为什么是现在，通常有三类，业务量越过某个阈值、出现一次事故或客诉、外部规则或合同期限变化，没有触发点的项目建议直接推迟。第三段代价：把不做会发生什么算成钱或人力，例如“按当前增速，半年后需要新增 3 名客服，年成本约 27 万”，这一段是争取资源的关键。
第四段目标与边界：目标要可验证（处理时长降到 2 分钟内），边界要写“不做什么”，比如本期不改动结算逻辑，防止范围蔓延。整段控制在 300 字以内，能一页纸讲完的立项背景，通过率远高于五页纸的。
2. 项目成员风险到底有哪些类型，怎么在立项阶段就识别出来？
我们上个项目做到一半，核心开发被调去救火，进度直接崩了两周，复盘时才发现立项时压根没评估过人员风险。我现在带新项目，最怕的就是这种“人没事的时候看不出来，出事就是致命的”问题。所以想问，成员风险能不能提前列清单排查？
可以，把人员风险拆成五类做清单式排查：关键人单点、技能缺口、投入度不足、跨部门借调无授权、外部人员交付不稳定。识别方法是在立项时画一张“任务，人员”矩阵，横轴是关键交付任务，纵轴是可用成员，凡是某个任务只有一个人能承接，就标记为单点风险。
控制手段分三层：一是备份人机制，要求每个单点任务至少有一名备份，并在项目前两周完成一次交接演练；二是文档与自动化兜底，把关键人脑子里的东西变成可执行的脚本或操作手册；三是投入度校验，逐个核对成员的排期占比，单一成员投入超过 80% 就要预警，同时挂三个以上项目的成员默认按风险处理。
数据口径建议盯三个数：单点任务占比（目标低于 15%）、备份覆盖率（关键任务 100%）、成员平均投入率（建议 60%，75% 区间）。跨部门借调必须拿到直属主管的书面确认，口头答应在立项评审里一律视为未确认。
3. 项目立项的操作步骤应该按什么顺序走，哪一步最容易被漏掉？
我以前立项就是闷头写文档，写完拉个会念一遍，结果会上被问“谁来做、做多久”全答不上来。后来才意识到，立项不是写文档，是一串有先后依赖的动作。但具体哪一步在前哪一步在后，我一直没理清楚。
推荐顺序是：背景与目标 → 范围与边界 → 交付物与验收标准 → 人员与投入确认 → 风险清单与应对 → 立项评审 → 基线冻结。前四步是内容，第五步是保险，最后两步是仪式。
最容易漏的是“人员与投入确认”，很多团队把它当成写个名字，实际要做三件事：确认成员名单、确认每个人的投入比例和起止时间、确认其直属主管知情并同意。这三件事缺一件，后面排期就是纸面上的。第二个容易漏的是“范围与边界”里的不做什么，建议单独列一栏，评审时逐条念出来，让所有人对“本期不做”达成共识。
操作上可以做一个一页纸立项模板，左侧写背景目标，右侧写人员投入表和风险清单，评审控制在 45 分钟内，超过这个时长说明前期准备不到位。评审通过后立刻冻结基线，后续任何范围变更都走变更单，不要在群里口头加需求。
4. 立项评审时，背景和人员风险该用什么材料呈现，评委一般会追问什么？
我们公司立项评审就 20 分钟，前面几个项目都是因为背景讲不清、人员安排答不上来被打回重做。我下次要上台讲，想知道评委真正在意什么，提前把材料准备到什么颗粒度才算够。
材料上准备三样就够：一页纸立项摘要、一张人员投入表、一张风险清单。摘要里背景只留三句话，现状数字、触发事件、不做的代价，其余都放附录，评委追问时再翻。人员投入表要写清姓名（或角色）、投入比例、投入周期、备份人四列，没有备份人的岗位当场就会被问。
风险清单按“风险描述，发生概率，影响程度，应对措施，责任人”五列写，概率和影响都用高中低三档即可，写具体数字反而会被质疑拍脑袋。评委高频追问集中在四个问题：这个数字从哪来的、为什么是现在做、谁对结果负责、做不成会怎样。前两个考背景，后两个考人员和风险。
建议提前把答案写成一句话放进备注页，别临场组织语言。另外准备一个反面证据，也就是“我们考虑过但放弃的方案及原因”，这一条能显著提升可信度，也最容易让评审从质疑转向讨论。评审结束后当天发出纪要和待确认事项清单，把会上口头承诺变成文字，否则一周后就会被忘干净。
文章包含AI辅助创作：项目立项如何做好项目背景？项目成员风险控制与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/283674
读者评论
我们公司立项背景模板确实是十年前那套，先讲行业再讲公司，写到最后才提项目，评审时领导经常问"所以到底要解决什么问题"。文章说模板本身是错的，这点我深有同感，但改模板这事推了两年没推动，因为审批链上的人都习惯了那种写法。想问下，有没有人在不换模板的前提下，靠加附页把七要素补进去的？ 另外那个"背景要素≥6项按期交付率82%"的数据，样本才37个，还集中在你们评审过的企业，感觉不能当规律用，当参考还行。
成员风险写进背景我认同，但落到实操有个现实问题：很多项目立项时人员根本没定下来，是从各部门抽调，PM能拿到的只是"预计投入50%"这种口头承诺。你让他在背景里写死工时，等于逼他替别的部门做承诺，写错了后面被追责。 我们现在的做法是背景里只写角色和能力要求，具体人名放到启动会确认，结果就是文章说的问题，启动会已经是开工之后了。所以我觉得关键可能不在背景写多细，而在于立项时有没有人事口的签字权，没这个权，背景写得再全也是纸面文章。
那个四象限里"隐性区"的处置策略我觉得偏理想化了。核心人稳定但无备份，对策是设知识转移里程碑，可现实是这类人往往本来就满负荷，你再加知识转移任务，他只会把文档敷衍了事，产出一堆没人看的交接材料。 我们试过强制要求写文档，最后变成开发在提测前一夜补几百字。真正有效的反而是让第二个人实际接手一个非核心模块练手，但这需要项目周期足够长、需求足够稳定，赶工期的项目根本排不进去。文章没提这个前提条件，直接照搬容易变成形式主义。