项目立项书
一页说清项目为什么做、做到什么算成功、谁负责、何时交付。
可整段复制 占位符用双大括号标出,替换成你的内容即可
# 项目立项书|{{项目名称}}
## 一、一句话说明
{{用一句话说清这个项目解决什么问题、给谁带来什么价值}}
## 二、背景与问题
- 现状:{{目前的做法与数据}}
- 问题:{{谁在什么场景遇到什么困难}}
- 代价:{{不解决的损失}}
- 已有尝试:{{做过什么、效果如何}}
## 三、目标与成功标准
| 目标 | 衡量指标 | 当前值 | 目标值 | 验收时间 |
| --- | --- | --- | --- | --- |
| {{目标一}} | {{指标}} | {{基线}} | {{目标}} | {{日期}} |
- 不做什么:{{明确排除的范围}}
## 四、范围与产出
- 交付物:{{文档/系统/活动}}
- 覆盖对象:{{用户/部门/地区}}
- 不在范围:{{排除项}}
## 五、角色与分工
| 角色 | 负责人 | 职责 | 决策权限 |
| --- | --- | --- | --- |
| 发起人 | {{姓名}} | {{提供资源与目标}} | {{最终拍板}} |
| 项目经理 | {{姓名}} | {{排期与推进}} | {{范围内调整}} |
| 执行成员 | {{姓名}} | {{具体任务}} | {{无}} |
## 六、里程碑
| 阶段 | 时间 | 产出 | 检查点 |
| --- | --- | --- | --- |
| 启动 | {{日期}} | {{立项书}} | {{资源到位}} |
| 中期 | {{日期}} | {{可用版本}} | {{核心功能跑通}} |
| 上线 | {{日期}} | {{正式版本}} | {{验收通过}} |
## 七、资源与预算
- 人力:{{人天}}
- 预算:{{金额与科目}}
- 外部依赖:{{供应商/合作方}}
## 八、主要风险
- {{风险一}}:{{概率与影响}},应对 {{措施}}
- {{风险二}}:{{概率与影响}},应对 {{措施}}
## 九、审批
- 发起人:{{签名/日期}}
- 部门负责人:{{签名/日期}}
- 资源审批:{{签名/日期}}
复制与下载都在浏览器本地完成,不会上传内容,也不需要登录。
怎么用
- 立项书不是走流程的表格,而是让自己想清楚为什么做、做到什么程度算成功。
- 目标与成功标准必须可量化,否则项目中期无法判断是否偏航。
- 「不做什么」要写具体,避免项目后期被不断加需求拖垮。
为什么这么写
- 一句话说明迫使发起人把价值讲清楚,而不是只描述要做什么功能。
- 基线值与目标值让验收有依据,减少上线后「算不算成功」的争论。
- 角色与决策权限提前明确,能减少跨部门推进时的反复请示。
- 风险与资源写在立项阶段,比执行中才发现缺人缺钱更可控。
常见错误
- 目标写成「提升用户体验」这类无法验收的表述。
- 只列交付物,不写排除范围,项目边界不断膨胀。
- 立项后不再更新,实际情况与文档脱节。