批准小组由一级部门负责人组成，项目Owner通常是一级部门核心经理。b级：第二部门项目。一般来说，这是一个可以通过影响一级部门重点目标落地、一级部门内协作来完成的项目。批准小组由第一部门负责人组成，项目Owner通常对第二部门持否定态度。

C级：

其他项目

举个例子说明一下，比如我们在S级项目的立项评审会上，发现一个项目是有价值的，但并不符合S级的要求，那么会将该项目定为A级，由相关一级部门自己负责项目实施跟进和结项流程；

再比如，在A级项目的立项评审会议上，发现需要更高层级的资源调动和协同，则可升级至S级项目评审。

• 审批意见

就项目组提出的项目目标、评价标准、实施路径、项目负责人等信息给予审批意见和调整建议，作为项目规划的输入。

通常为结果1和结果2的项目，通过项目目标、评价标准、投入资源等的调整和确认进行资源平衡。

前面我们明确了立项报告完需要达到的目的，那么报告主体需要紧密围绕着这个目的来设计，2页即可。

第一页希望能够提供足够的信息，从而筛选出结果3和结果4的项目。

主体部分 Page 1

稍微解读一下。

项目名称：不解释。

项目负责人 & 项目经理：前文解释过了。

起始日期，结束日期，项目工期，贡献部门：从时间和项目协作的角度大致判断一下项目规模和复杂度。

项目背景：用简短的几句话描述项目想解决什么问题。借鉴敏捷对于用户故事的要求，尽量对应到某个业务问题：即便是技术改造类的项目，也需要关联具体的业务目标，比如为了支持后续的业务目标等。

如果已经引入了“OKR”，可以对应的引述一下对应的“O”。

ROI：评估项目的投入和收益。希望能够尽量具体和量化。

项目目标：这里推荐大家使用一下“电梯演讲”。据说是来自麦肯锡公司。

当时事情的经过是这样的，这样的，这样的......

麦肯锡公司曾经给一家极其重要的大客户做咨询服务。过程中某一次，麦肯锡的项目负责人在电梯间里，偶遇到了客户公司的董事长。于是董事长就问麦肯锡的项目负责人：“你能不能说一下项目究竟是做什么的？”由于该项目负责人没有充分准备，无法在电梯到达1层时这极其有限的时间内把结果说清楚。最终，麦肯锡失去了这个重要客户。

经过这次惨痛教训，于是麦肯锡公司要求他的每一个业务人员，都必须要有在30秒的时间，可以清晰有效地向客户介绍方案的能力，被称之为“电梯演讲”或者“电梯陈述”。

与敏捷中的“用户故事”描述类似，我们也要求尽量用最简短的描述说清楚“项目价值”。

这并非苛求，笔者固执的认为，通常3分钟你说不清楚的事情，给你30分钟同样说不清楚。你品，你细品......

评价标准：对应项目目标描述如何验收项目。

以上就是第一页的大致内容。

如果通过这一页基本认定是结果3和结果4的项目，后面的PPT就可以不用看了。

惊不惊喜？刺不刺激？

从这个意义上来说，这也有可能是史上最快“挂”的项目。

但如果做了一个压根就不该开始的项目，岂不是比不通过立项要糟糕的多？

第二页希望针对于结果1和结果2的项目进行更加深入的了解。

进入到这个阶段的项目通常是结果1和结果2的项目，则需要对于项目目标达成的路径做更多的了解。从而判断项目前期的输出是否有盲点和需要调整的地方，进而判断是否需要调整ROI，项目周期乃至于项目目标。

主体部分 Page2

关键时间节点：里程碑信息，即项目的阶段性达成目标。

项目假设与约束条件：举个例子，比如项目是举行一个集会活动，如果目前的方案是安排在室外，那么关键的假定就是活动当天天气良好。如果非常倒霉碰上恶劣天气，那与之相关的成本、流程、效果等都会与正常天气大相径庭。如果这个基本假设不成立，则需要有调整项目方案，比如是否方便改期，是否需要预备雨衣等。

项目主要利益干系人：项目是人去做的，对于关键干系人的识别则体现出项目方案对于"人"这个重要因素的考虑。如果某个角色缺失，则可能遇到意外的困难或者错失项目可以求助的方向。

报告的主体就是这2页啦，如果还需要补充一些项目背景信息，可以增补几页PPT。

补充材料部分（4~5页PPT）

可以罗列其他的项目背景的信息，如市场环境，竞对分析，用户调研，产品策略，技术方案等，尽可能浓缩重要的信息辅助决策。

市场环境：行业现状，市场调研，市场分析，政策信息等。

简单说来，前面两页是论点，后面的补充材料是论据。竞对分析：竞品产品功能优缺点，竞品渠道信息，竞品市场规模现状，竞品目标用户数据等。

用户调研：目标用户群体及特征，用户使用场景分析，用户需求分析（痛点、刚需、高频、客单价）等。

产品策略：运营策略，产品功能及规划，产品里程碑（Roadmap），风险点等。

技术方案：系统架构，业务架构，上下游链路，核心功能等。

综上，报告主体+ 补充材料 + 评审结论，就是整个立项报告的全部。前面两页是论点，后面的补充材料是论据。

完了？

完了！

笔者给大家晒的立项报告并非完美，甚至可能有些人觉得有些简陋，但为什么我这么“敢秀”呢？其实我真正想跟大家分享的是模板背后的设计逻辑和理念：

• Less is More ( 少就是多 )，聚焦价值

笔者在过往工作中看过非常多的立项报告，大多数都长篇累牍。为了确保项目被批准立项，能加上的信息恨不得都加上，反而去了焦点。

笔者认为，决策的过程其实是一个“由少至多，再由多至少”的过程：在决策前，尽量收集更多的信息，从多角度多维度去尽量接近事实的真相；在决策时，却应该抓住最主要的信息，排除其他信息的干扰。

从这个意义上来说，立项报告需要把无用的信息剔除，保持最重要的项目价值，ROI，基本实现路径等就可以了。

可能你会比较焦虑，内容这么少如果做了一个压根就不该开始的项目，岂不是比项目通过立项要糟糕的多？

• 从用户的角度思考，如何节约用户时间

立项报告的阅读者/聆听者应该是可以拿到必要的信息，随时可以离开。

如果已经判断是不值得投入或者低级别的项目，完全后面部分就可以不用看了，一下个立项申请走起；项目必要性基本没问题的前提下，再看可行性、实现路径是否需要调整。

项目经理从某种意义上来说是信息工作者，如何提供足够、有用的信息，不多也不少，是一个项目管理者永远需要修炼的基本功。

班门弄斧，权当抛砖引玉吧！希望大家都能够设计出符合自己实际需要的“最容易通过的立项申请报告”，即便很快被“毙了”也能够及时去复盘和调整，把立项这个项目本身收好尾。Good Luck！

本文作者：bignose ， 哈啰出行PMO， PMO前沿特约作者，转自知乎作者已授权，转载请联系作者；