立项书最该写细的一页，不是方案，是「前提和假设」

需求一直加，节点一直拖，多出来的时间和人力谁来担？这要在立项时写好：写进立项书里最不起眼的一章，前提和假设。

立项时没写清楚，到后面只能吵。业务说「这本来就该做」，项目组说「这不在范围里」，谁也说服不了谁。

这篇讲：立项要定死哪 8 样，最常漏的那一样怎么写，以及组织和交付件怎么写。

一、项目立项要定死 8 样

我们的立项建议书一共九章：概述、需求、目标与范围、前提和假设、方案建议、实施计划、组织结构、概算、交付件。拆开看，要定死的是这 8 样：

• 范围：写到哪个工厂、哪个车间、哪条产线；接哪些系统，比如 SAP、MES、SRM、QMS、WCS；做哪些功能。不在范围里的，也要写出来
• 目标：量化到指标，比如库存呆滞率降到多少、配送及时率达到多少，不写「提升效率」这种话
• 验收标准：前面几篇反复说过，验收的门槛在立项时定，不在验收时商量
• 里程碑：立项、蓝图、实现、上线准备、试运行、验收
• 组织、人力、交付件：谁拍板、谁干活、交什么，第三节细说
• 预算：按硬件、软件、集成实施、人天分别估，每一项都要有依据

功能范围里有一个细节很有用：功能清单的每一行，都标上「复用」还是「改造」。复用的是平台现成的，改造的要开发。哪些功能吃人天，一眼就看得出来，后面估工时、谈变更也有底。

二、立项最常漏的：变更和延期的成本没有具体约束

8 样都写了，照样会吵。最常漏的是：需求变更、需求增加、节点延期，会带来多少时间和人力成本，立项时没有具体约束。

没有约束，加一条需求就要吵一次：这条算不算变更？多出来的人天谁出？节点要不要顺延？

这些要写进前提和假设这一章。它的意思是：项目能按这个范围、这个工期、这些人做完，是有前提的；前提变了，计划就要变，成本就要有人担。

我们写进去的几类：

• 答复时限：项目组提交文档，业务方在几个工作日内答复，逾期视同确认
• 签字代表：业务方的签字代表是谁、授权人是谁。因为签字人不明确造成决策延误，项目延期不由项目组承担
• 数据责任：源数据的准备和准确由业务方负责。因数据不准导致上线不成功，再次上线的额外工作量由业务方承担
• 范围变更：范围外的增加、增强、修改，一律走变更控制流程
• 业务调整：业务方的组织结构或业务模式调整，影响到已确认的设计，额外费用由业务方承担
• 人员投入：关键用户必须参加培训，和项目组一起工作

这一章不是客气话，是事先说好：谁该为多出来的时间和人力买单。

三、立项书里的组织和交付件：谁拍板、谁干活、交什么

组织，先写清谁拍板、谁把关。 我们立项书里的组织是这几层：

• 指导委员会：定方向，重大问题最终决策，给项目管理办公室授权，确保相关部门全力参与
• 项目管理办公室：计划、资源、进度、风险、沟通协调，组织验收
• 项目监理：看合同权责是否清楚，审方案是否合理，预算、进度、变更替公司把关
• 关键业务组：指导和审核业务流程，对流程质量负责
• 数据组：历史数据清理和切换，容器、库存地数据整理，PFEP 维护
• 产品、开发：产品设计，开发资源、进度和质量

前一篇讲推不动要书面升级，升级给谁？立项时就写在这里。指导委员会写进去了，业务方没人做主的时候，才有地方去要人做主。

人力，按角色估人天。 每个角色写清做什么、估多少人天，实施和开发分开估。两边各占多少，看项目情况定，没有固定比例。还有一条规矩：概算里算钱的总人天，不能超过组织结构里报的总人天，两边要对得上。

交付件，按阶段列到责任人：

• 启动：项目实施计划、立项建议书
• 需求调研：调研计划、系统需求说明书
• 蓝图设计：业务蓝图、蓝图评审会议纪要
• 详细设计：系统详细设计说明书、接口设计说明书
• 上线准备：功能测试报告、用户操作手册
• 上线：系统试运行报告
• 验收：验收报告、程序清单及源代码

立项时列好、写上责任人，验收时就按这张清单交，不用临时补材料。

---

你们的立项书里，有没有写需求变更的人力和时间谁来担？