项目立项启动管理教程：审批单到基线冻结五步走

「这个项目当时到底是谁拍的板、范围怎么定的、预算批了多少，谁能给我说清楚？」一家装备制造企业的新任项目总监，上任第一周翻三个在建项目，问出的第一句话就是这句。三个项目，一个有立项邮件没有预算数，一个有预算数没有范围说明，一个只有一句「本月启动」。再往下看，三个项目的需求变更分别记了 17 次、23 次、9 次，没有一次有基线可比对——改到哪算完，谁也说不清。病根不在执行，在开头。这篇教程就讲立项启动这一个阶段：五步，从一张审批单到一次基线冻结，把项目的「出生证明」办齐。

一、先想清楚：立项到底在立什么

很多团队的立项等于发一封「项目启动邮件」，抄送一堆人，然后开干。两周后问题就来了：目标各人理解不一样，范围今天加一点明天减一点，预算没批就先花了，出了问题找不到拍板的人。立项阶段要立住的其实是四样东西，缺一样后面都要还债：

• 目标：这个项目做成了是什么样，验收标准是什么；
• 范围：做什么、明确不做什么，边界写进纸面；
• 预算：总盘子多少、分几期、超了找谁批；
• 负责人：项目经理是谁、权限到哪、出问题谁兜。

这四样东西,在系统里就是一张立项审批单。下面五步，每一步都是把口头共识变成系统记录的过程。

二、第一步：立项审批单，四要素一次写清

立项审批单是整个项目的第一张单据，也是后面一切争议的原始依据。填单时四个字段一个都不能含糊：

1. 目标怎么写

不写「提升客户满意度」这种没法验收的话，写「交付新版工单系统并在 3 家分公司上线，客服单均处理时长下降 20%」。有对象、有时点、有数字，验收时才不会各说各话。经验上，目标里带不出数字的，说明还没想清楚，退回重想。

2. 范围怎么划

除了写做什么，更重要的是写不做什么：「本期不含移动端」「不改造老系统数据」——这两句写在纸面上，能挡掉后面一大半「顺手也做了吧」。范围字段宁可写得啰嗦，也不要写得体面。

3. 预算怎么分

总额之外写清分期：一期多少、二期多少、预留多少机动。没有分期的总预算，等于每次花钱都重新吵一遍。预算科目按人力、采购、外协粗分即可，立项阶段不必太细。

4. 负责人怎么定

项目经理写具体姓名，不写部门；同时写清授权范围——多少金额以内他可以自己批，超出走变更审批。项目经理有责无权，是项目失控最常见的起点。

单子提交后走在线审批，各审批人的意见留在单据上。日后翻旧账，「当时为什么这么批」有处可查——这张单据在项目管理系统里就是「出生证明」，后面启动会、WBS、基线全部挂在它下面。

三、第二步：启动会，材料备齐再开会

启动会最忌讳开成「宣布会」：领导讲两句，大家鼓个掌，散会。开成工作会的前提是材料先备齐，清单如下：

• 立项审批单终稿（含审批意见）；
• 项目目标与验收标准一页纸；
• 范围说明书，含明确的「不做清单」；
• 干系人清单：谁是发起人、谁是验收人、谁必须被通知；
• 里程碑计划草案：三到五个关键节点即可；
• 沟通机制：例会频率、汇报模板、问题升级路径。

这六份材料在系统里挂到项目空间下，会后形成会议纪要，任务、决议、待办各归各位。启动会开好的标志不是气氛热烈，而是散会时每个人都清楚三件事：目标是什么、我负责什么、有问题找谁。某制造企业 PMO 的统计口径：启动会材料齐全的项目，执行期范围争议比材料不全的少约六成——开会前多花的两天，后面省回来几十天。

四、第三步：WBS 任务分解，拆到能检查的颗粒

WBS 不是把活列出来，是把活拆到「能检查、能验收」的颗粒。常用判断标准是 8~80 小时：一个任务的工作量小于 8 小时，拆得太碎管不过来；大于 80 小时，说明还没拆开，进度没法汇报——「开发中」三个月的任务和「开发中」一周的任务，在进度表上长得一模一样。

1. 按交付物拆，不按部门拆

交付物导向是 WBS 的第一原则：需求规格书、原型、测试报告、上线部署包——每个节点是一份可验收的产物。按部门拆（设计组一批、开发组一批）是最常见的错误，拆出来的是组织架构，不是工作分解。

2. 每个任务自带三要素

在系统里录入任务时写全：负责人（具体到人）、工期估算、交付物或完成标准。三缺一的任务先不录入——没有负责人的任务等于没人做，没有完成标准的任务永远做不完。

3. 分层拆到第二、三层

项目拆里程碑，里程碑拆任务，任务可再拆子任务，但不必无限拆下去。立项启动阶段拆到第二、三层，覆盖前两个里程碑即可，后面边执行边补——一次性拆半年后的细节，多半是无效功。

五、第四步：责任分配，一个任务只能有一个负责人

任务拆完做责任分配，推荐用简化的 RACI 思路：每个任务标明谁负责干（R）、谁审批验收（A）、被咨询谁（C）、被通知谁（I）。落地时抓最要紧的一条：R 只能有一个人。「两人共同负责」的任务，就是两人都不负责——这句话在多家公司的项目复盘中反复应验。

在系统里，责任分配直接做在任务卡上：负责人、协同人、验收人分栏填写，任务到期提醒发给 R，超期升级抄送 A。矩阵不必单独画表，导出任务清单按人筛选，每个人的活一目了然。启动阶段把责任分干净，比执行期开十次协调会都值。

六、第五步：基线冻结，给项目立一根准绳

前四步做完，范围、进度、预算三项都有了成型的东西，这时做立项启动阶段最后一个动作：基线冻结。在系统里把当前版本的范围说明书、里程碑计划、预算分配存为基线——从此项目有了「原点」。

基线的价值不在冻结本身，在变更有了比对物：需求又变了？和基线比，新增了多少工作量、影响哪个里程碑、预算缺口多大，变更单一拉数字就出来，而不是凭感觉争。该企业三个问题项目补做基线后，变更评审的平均时长从一次会吵两三个小时，降到半小时内出结论——因为争的不再是「当初是不是这样」，而是「和基线比变了什么、值不值」。

七、五步之外，两个容易踩的坑

第一个坑：立项仪式化。审批单走了，四要素全是模板话——目标写「如期高质量交付」，范围抄合同目录，负责人挂部门名。这样的单据形同虚设，基线冻了个寂寞。填单时拿「验收时这句话能不能当标准用」自问一遍，就能滤掉八成空话。

第二个坑：启动会拉错人。该来的验收人没来，不该来的领导来了一屋子。会后执行层按自己的理解推进，验收人第一次看成果就是验收当天——不通过，返工。干系人清单在启动会前过一遍，发起人、验收人、资金审批人一个都不能少，这是启动会材料的第三项之所以存在的理由。

五步走完，立项启动阶段就有了完整的系统记录：一张审批单、一套启动材料、一棵 WBS、一张责任分配、一条冻结基线。此后项目怎么走都会有争议，但争议都有参照物——这根准绳，就是「开个好头」的全部含义。