简介该资源为一份可直接套用的软件项目立项书模板doc格式面向项目经理、开发团队及项目投资方用于在项目启动阶段系统梳理目标、范围、进度、预算与风险统一各方认知。文档按标准立项书结构组织依次给出引言、项目概述、项目目标、规定与约束、项目工作范围、应交付成果、项目验收方式、项目团队组织等完整章节并细分了项目背景、定义、参考资料、性能/质量/时间指标、技术/财务/时间约束、WBS工作分解、Deliverables与验收程序等编写要点同时包含版本号、拟制/审核/批准日期、修订历史A添加/M修改/D删除等规范化表格便于使用者按模板快速填写实际项目信息。包体仅含1个doc文件整体大小83KB轻量实用。该资源已获得1576次浏览学习适合需要规范化撰写立项书、开展项目评审或准备项目启动汇报的读者直接参考借鉴。1. 软件项目立项书一份让评审无从挑剔的模板先存下来再说软件项目立项书说穿了就是给项目上的一道保险。我见过太多项目合同签了、团队搭了、需求过了两轮评审最后写立项书时直接把“目的”一栏填成了项目目标——等中期检查被追问“这个项目的验收标准到底是什么”才发现整份文档根本没写清楚“做到什么程度算成”。这份模板的稀缺之处是它几乎在每个章节底下都留了填写提示哪里容易混淆、哪里必须写时间点、哪些限制属于绕不开的约束。适合正要立项的项目经理、刚被指定带项目的技术负责人也适合常年被业主评审追着补文档的乙方研发。按这份模板的章节走一遍立项答辩时被反复追问“为什么”的概率能低很多。2. 引言与项目概述先把“目的”和“项目目标”分清再动笔立项书前两章是评审最先翻的也是翻车高发区。引言和项目概述看着都是套话实际每一小节都在回答一个具体问题这份文档是干什么用的、项目从哪来、做到什么程度算成功、受哪些限制、最后拿什么验收。2.1 引言五块每一块都对应一个坑引言章节包含五个部分。第一部分“目的”模板里第一句话就在警告这里的目的不是项目目标。它指本文档的目的与作用项目目标要到 2.1 里另写。所以 1.1 的“目的”要写的是“为什么要有这份立项书”不是“要做这个项目”。模板给的参考说法可以直接抄项目成员以及项目干系人之间的共识与约定项目生命周期所有活动的行动基础以便项目团队根据本计划书开展和检查项目工作。我一般会在后面补一句“本计划书经批准后作为需求变更、进度调整和验收判定的基准”评审看到“基准”两个字立刻知道这份文档的分量。第二块“背景”模板要求写清楚项目名称、委托单位、用户单位、主要承担部门、建设背景。建设背景要从行业环境和业务环境入手讲明白项目的大环境和来龙去脉。背景部分最忌讳写成一页纸的行业分析报告三四段把“谁要建、为什么现在建、谁出钱、谁来做”说清就够了。写背景的真实目的是让新加入的成员快速理解“这个项目为什么存在”不需要再去问前人。第三块“定义”列出为正确理解本计划书所用到的专门术语、外文缩写词的原词及中文解释。这一节有个重要提醒尽量不要对业界通用术语重新定义避免它的含义和通用术语的惯用含义不一致。很多人喜欢把“上线”重新定义为“完成部署并通过验收”结果项目组内沟通时概念全是黑的反而扯皮。第四块“参考资料”列出本计划书所引用的及相关的文件资料和标准写作者、标题、编号、发表日期和出版单位必要时说明获取途径。常用资料包括本项目的合同、标书、上级部门或集团下发的有关通知、经过审批的项目任务书以及本文档各处引用的文件资料。第五块“标准、条约和约定”则要列出必须遵守的标准和条约也就是相应的技术规范。提示把参考资料和标准条约混在一节写是评审最容易挑出来的硬伤。参考的不一定是必须遵守的两者在文档里的作用完全不同。2.2 项目概述五块目标要能拆成时间点项目概述是立项书的核心。先看“项目目标”模板给出的拆法有两种横向分解按功能或按建设单位的不同业务要求分解成第一目标、第二目标纵向分解按阶段拆成第一阶段目标、第二阶段目标或近期目标、中期目标、远期目标。阶段目标必须写明较为明确的时间。模板里那个句式可以直接套“为实现项目的总目标必须实现以下三个阶段目标”。评审判断目标写得好不好只看一条能不能从目标里找出“什么时间、交付什么、达到什么指标”。如果某个目标读下来没有可验证的指标那它停留在愿景层面还不是目标。再看不那么容易分清的一对概念“规定”和“约束”。规定是通过努力可以直接解决的问题而且必须解决才能保证项目按计划完成比如“必须在 3 天内到位”“必须在 8 月 8 日前确定对需求文档进行确认”。约束则是难以绕过的问题只能通过其他途径回避、弥补或取舍比如人力资源有限那就必须牺牲进度或质量。注意一个容易写错的地方如果问题出现具有不确定性不要写进规定或约束应该写进风险评估章节分析概率、影响和应对措施。把不确定的事当成确定约束写后面计划一调整这一整章都得返工。“项目工作范围”要说明为按时保质实现目标需要进行哪些工作。我习惯在范围里单独列一小段“不在本次范围的工作”立项书把边界画清楚后续需求蔓延时这就是后悔药。填需求变更申请时翻出这一页甲乙方都好说话。接下来是“应交付成果”模板把它分成了四类下面用一个表格梳理交付类型内容要点填写提醒需完成的项目建设项目建设内容清单逐项写避免“系统建设”一句话带过需提交用户的文档需求规格说明书、操作手册等写文档名称和内容要点别只写“相关文档”须提交内部的文档项目变更申请、项目进度报告等内部交付物关乎管理流程别漏应当提供的服务培训、安装、维护和运行支持合同里有培训约定时可另编培训计划最后是“项目验收方式”说明内部验收和用户验收的方式及验收依据。这一节的颗粒度要到“按什么标准、由谁签字确认”。立项书里不写“系统运行稳定”这种话要写“连续 7 天试运行期间无等级事故”这类可以判定的表述。验收依据若写得模糊验收阶段必有一方觉得自己被坑了。3. 团队组织与实施计划把“谁来做”和“做到什么程度”钉死在纸面上合同签完、项目启动会开完立项书里被翻得最多的就是第三章和第四章。团队组织讲分工实施计划讲节奏和风险。这两章写得好项目过程管理就有抓手写得虚计划评审都会被怼回来。3.1 项目团队组织角色、分工与沟通三条线团队组织这一章有三块内容。首先是组织结构模板要求从所需角色和项目成员两个方面描述。所需角色要列出为完成项目需要哪些人比如项目总负责人、项目经理、运维工程师、业务接口人、客服、产品等等同时说明团队成员来自哪个部门。除了组织结构图还要用文字说明每个角色应有的技术水平。评审经常问“测试谁来做、什么水平”组织章节答不上来说明团队配置就没想清楚。其次是人员分工用列表方式说明每个成员属于组织结构中的什么角色、技术水平如何、项目里的分工与配置。我习惯在人员分工表里加一列“可替代人”写明谁不在时谁接手。关键岗位没有备份项目进行到一半核心人员休假进度立刻崩。第三块是协作与沟通。内容分成三条线项目团队内部协作说明协作模式和沟通方式、频次、沟通成果记录办法项目接口人员要写清负责与用户接口、与公司内部接口、与支持方接口三类人员的职责和联系方式项目团队外部沟通与协作模式明确最终用户和直接用户所在的部门名称与联系电话协作开发的部门名称、经理姓名、承担的工作内容合作单位的名称、负责人和联系电话。沟通方式模板里列了会议、电话、QQ、内部邮件、外部邮件、聊天室等协作模式则要写明出现什么状况时哪个角色应当主动采取什么措施。3.2 实施计划风险、流程、进度与控制实施计划是全文档信息量最大的一节。先看“风险评估及对策”。模板要求识别内在风险与外在风险内在风险是项目组能控制和影响的如人事任免、成本估计外在风险超出项目组控制力如市场转向。对策分三类避免靠排除危险起源来排除特定威胁减缓减少风险事件的预期资金投入来降低发生概率和风险系数吸纳接受后果可以是积极的制定预防性计划防备风险事件也可以是消极的某些费用超支就接受低于预期的利润。软件开发项目的常见风险模板给了四类验收不能顺利完成或延迟技术风险比如用新开发技术、新设备、新应用组合没有经验或新行业新业务没有经验性能要求太严用户方面的问题比如功能多次变更、与用户分担开发导致拖延、用户承担的工作延误其它没有列到但推测存在的风险。写风险对策最忌笼统每条风险都该有触发条件、概率、影响范围和负责人落成表格更清晰风险类别触发条件示例概率影响对策负责人进度风险阶段成果提交评审后返工超过两周中里程碑顺延减缓评审前置关键节点设置双重检查项目经理技术风险首次引入消息中间件团队无运维经验高联调周期不可控避免先做技术验证验证通过再进架构设计技术负责人用户风险需求确认后仍高频变更高范围蔓延吸纳变更走申请流程预算和工期同步调整业务接口人接下来是工作流程。模板要求画出工作流程图并配文字说明。我一般不用画图工具而是用表格列出每个阶段的输入、活动、输出和负责人比纯图形更容易归档评审问起来也能指着某一行说清楚。再往下是“总体进度计划”要依据确定的项目规模列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果。覆盖的阶段包括项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收。每项工作任务写预定开始日期、完成日期、所需资源、先后顺序以及表征完成的标志性事件。提示里程碑千万不要写“需求完成”要写“需求规格说明书通过用户签字确认”。评审只看可验证的交付物。最后是项目控制计划三块内容各司其职。质量保证计划说明产品质量、建设质量、服务质量如何保证明确质量活动的记录要保存的期限和方法。进度控制计划由项目过程控制部门统一监控保留日常检查记录。预算监控计划说明怎么检查预算使用情况。这三块是给管理和审计看的但也是项目组自我保护的工具——被问“为什么延期”时日常检查记录就是最好的证据。4. 避坑五个最容易翻车的填写误区填立项书这项工作看着是模板套话实际全是细节里的玄学。以下五个坑每条都是项目真实评审中反复出现的问题按“现象 → 原因 → 解决”写照着自查能省一轮答辩。4.1 “目的”栏填成了“项目目标”现象1.1 的“目的”写的是“开发一个 XX 系统实现 XX 功能”翻到后面 2.1 项目目标内容差不多两节重复。原因没读模板里的提醒。“目的”说的是本文档的目的与作用项目目标在 2.1 里单独说明两件事。解决1.1 直接套用模板那句“项目成员以及项目干系人之间的共识与约定项目生命周期所有活动的行动基础以便项目团队根据本计划书开展和检查项目工作”再补一句文档作为变更和验收基准的话。项目目标则写可测量的成功标准两者自然区分开。4.2 修订历史不维护AMD 标记形同虚设现象项目进行到第三个月立项书已经改了六版。评审会上被问“这一版对上一版改了什么”整个会议室安静了三秒没人答得上来。原因改文档直接把旧文件覆盖了修订历史记录表从来没填过。模板里那张记录表版本、日期、修订者、说明四列说明里要用 A 表示添加、M 表示修改、D 表示删除大多项目组嫌麻烦跳过了。解决每次改动用一行记录版本号、日期、修订者、说明一项不漏。说明以 A/M/D 开头比如“M2.1 阶段目标时间点由 6 月 30 日调整为 7 月 15 日”。对外发版前自查一遍凡是没见过修订记录的版本一律不发。这个习惯能在评审时省下大量解释成本。4.3 规定和约束分不清现象立项书里“规定与约束”一节写的是“项目组只有 3 个人因此进度排到明年”“人手不足无法保证质量”评审直接质疑这个项目组成员配置为什么不能增加问题出在哪原因把“规定”和“约束”混为一谈。规定是通过努力能直接解决的问题必须解决才能保证项目按计划完成约束则是绕不过去的限制只能回避、弥补、取舍。人手不足这类问题属于资源配置的取舍不是靠“规定”能解决的。解决规定栏写通过努力能解决且必须解决的事项比如“必须在 8 月 8 日前确定对需求文档进行确认”约束栏写客观限制比如人力资源有限因此需要牺牲部分非核心功能或调整进度同时写明取舍策略。如果某个问题出现与否不确定直接移到风险评估章节按概率和影响分析。4.4 参考资料和标准条约混在一节写现象验收阶段翻立项书找合同编号发现参考资料和必须遵守的标准条约堆在一个列表里编号、日期都不全验收依据无从追溯。原因没理解两者的区别。参考资料具有“物质”特性要说明参照了什么、在哪里能获得标准、条约和约定具有“精神”特性是必须遵守的内容不说明在哪里获得。参考的不一定是必须遵守的必须遵守的也不一定要列在参考资料里。解决分节写。参考资料列合同、标书、任务书、已发表文件、引用的软件开发标准每条带作者、标题、编号、发表日期、出版单位和获取途径标准条约列必须遵守的技术规范和验收标准不写获取途径。两者内容允许有交集但角色不同不能混在一堆。4.5 风险对策写成“加强沟通、注意安全”现象风险评估整页看下来全是“加强沟通”“注意进度”“保证质量”这类口号没有任何一条写了概率、影响和应对动作。评审问“需求变更了怎么办”答不上来。原因把风险评估当成形式清单没有对具体项目算账。风险段模板给了四类常见风险但很多人只抄了类别名称没写对策组合——避免、减缓、吸纳。解决每条风险写四要素触发条件、概率分级、影响范围、对策动作。以“需求频繁变更”为例触发条件是业务方在需求确认后仍提出新功能要求概率高影响是开发返工、里程碑顺延 10% 到 20%对策是减缓两周一次变更评审、重要变更走变更申请流程负责人写项目经理。写完后自查一遍任何一条风险如果删掉后不影响任何后续计划说明它还是口号不是风险。5. 预算与支持条件三张表把人、财、物写明白预算章节在立项书里看着最像财务的事实际最考验对项目的理解。模板把预算拆成人员成本、设备成本、其它经费预算三块再加一项合计。人员成本要列出项目团队每一个人的预计工作月数以及完成本项目所需劳务的人数和时间。设备成本包含三部分原材料费、设备购置及使用费拟购置设备的配置和经费拟购置软件及其版本和经费。很多项目组在这里漏掉“现有设备使用时间”这一项结果现有资源的使用成本没进预算财务评审必然追问。其它经费预算模板列得很细差旅费含旅费、出租和补贴资料费含图书、资料、复印、出版通信费含市话长途、移动通信、上网和邮资会议费含鉴定、评审、研讨、外事办公费含办公用品协作费含业务协作招待和加班伙食培训费含资料编写、印刷、场地和设备另外还有检测、维修、消耗品等其它费用。这个分类的好处是每一项都有明确出处不容易发生“钱花哪了”的纠纷。支持条件章节则分内部支持、客户支持、外部支持三条内部支持逐项列出每阶段的支持需求包括人员、设备、软件、培训的时间要求和用途客户支持写明需由客户承担的工作、完成期限和验收标准包括需客户提供的条件和时间外部支持列出外部支持方承担的工作和完成时间。提示客户支持最容易写成一团模糊的“配合调研”。我后来强制写明“客户需在 X 月 X 日前确认需求文档延迟 X 个工作日则里程碑顺延”需求确认阶段互相甩锅的事少了很多。最后说一个我每次填预算都要做的验证动作反推。把预算合计金额除以总的投入人月数看单人月成本是否落在合理区间如果高过同类型项目一大截多半是某项预算重复计了再把每笔设备购置费和其它经费对着工作范围逐条找依据找不到出处的一律删掉。模板最后的“关键问题”章节也不要跳过逐项列出影响项目成败的技术难点和风险指出对项目成败的影响这一页就是评审答辩的底稿。从那以后我每次填完立项书都会强制把预算反推一遍确认每一项支出都能在工作计划里找到出处再提交评审。希望帮到你。本文还有配套的精品资源点击获取
简介该资源为一份可直接套用的软件项目立项书模板doc格式面向项目经理、开发团队及项目投资方用于在项目启动阶段系统梳理目标、范围、进度、预算与风险统一各方认知。文档按标准立项书结构组织依次给出引言、项目概述、项目目标、规定与约束、项目工作范围、应交付成果、项目验收方式、项目团队组织等完整章节并细分了项目背景、定义、参考资料、性能/质量/时间指标、技术/财务/时间约束、WBS工作分解、Deliverables与验收程序等编写要点同时包含版本号、拟制/审核/批准日期、修订历史A添加/M修改/D删除等规范化表格便于使用者按模板快速填写实际项目信息。包体仅含1个doc文件整体大小83KB轻量实用。该资源已获得1576次浏览学习适合需要规范化撰写立项书、开展项目评审或准备项目启动汇报的读者直接参考借鉴。1. 软件项目立项书一份让评审无从挑剔的模板先存下来再说软件项目立项书说穿了就是给项目上的一道保险。我见过太多项目合同签了、团队搭了、需求过了两轮评审最后写立项书时直接把“目的”一栏填成了项目目标——等中期检查被追问“这个项目的验收标准到底是什么”才发现整份文档根本没写清楚“做到什么程度算成”。这份模板的稀缺之处是它几乎在每个章节底下都留了填写提示哪里容易混淆、哪里必须写时间点、哪些限制属于绕不开的约束。适合正要立项的项目经理、刚被指定带项目的技术负责人也适合常年被业主评审追着补文档的乙方研发。按这份模板的章节走一遍立项答辩时被反复追问“为什么”的概率能低很多。2. 引言与项目概述先把“目的”和“项目目标”分清再动笔立项书前两章是评审最先翻的也是翻车高发区。引言和项目概述看着都是套话实际每一小节都在回答一个具体问题这份文档是干什么用的、项目从哪来、做到什么程度算成功、受哪些限制、最后拿什么验收。2.1 引言五块每一块都对应一个坑引言章节包含五个部分。第一部分“目的”模板里第一句话就在警告这里的目的不是项目目标。它指本文档的目的与作用项目目标要到 2.1 里另写。所以 1.1 的“目的”要写的是“为什么要有这份立项书”不是“要做这个项目”。模板给的参考说法可以直接抄项目成员以及项目干系人之间的共识与约定项目生命周期所有活动的行动基础以便项目团队根据本计划书开展和检查项目工作。我一般会在后面补一句“本计划书经批准后作为需求变更、进度调整和验收判定的基准”评审看到“基准”两个字立刻知道这份文档的分量。第二块“背景”模板要求写清楚项目名称、委托单位、用户单位、主要承担部门、建设背景。建设背景要从行业环境和业务环境入手讲明白项目的大环境和来龙去脉。背景部分最忌讳写成一页纸的行业分析报告三四段把“谁要建、为什么现在建、谁出钱、谁来做”说清就够了。写背景的真实目的是让新加入的成员快速理解“这个项目为什么存在”不需要再去问前人。第三块“定义”列出为正确理解本计划书所用到的专门术语、外文缩写词的原词及中文解释。这一节有个重要提醒尽量不要对业界通用术语重新定义避免它的含义和通用术语的惯用含义不一致。很多人喜欢把“上线”重新定义为“完成部署并通过验收”结果项目组内沟通时概念全是黑的反而扯皮。第四块“参考资料”列出本计划书所引用的及相关的文件资料和标准写作者、标题、编号、发表日期和出版单位必要时说明获取途径。常用资料包括本项目的合同、标书、上级部门或集团下发的有关通知、经过审批的项目任务书以及本文档各处引用的文件资料。第五块“标准、条约和约定”则要列出必须遵守的标准和条约也就是相应的技术规范。提示把参考资料和标准条约混在一节写是评审最容易挑出来的硬伤。参考的不一定是必须遵守的两者在文档里的作用完全不同。2.2 项目概述五块目标要能拆成时间点项目概述是立项书的核心。先看“项目目标”模板给出的拆法有两种横向分解按功能或按建设单位的不同业务要求分解成第一目标、第二目标纵向分解按阶段拆成第一阶段目标、第二阶段目标或近期目标、中期目标、远期目标。阶段目标必须写明较为明确的时间。模板里那个句式可以直接套“为实现项目的总目标必须实现以下三个阶段目标”。评审判断目标写得好不好只看一条能不能从目标里找出“什么时间、交付什么、达到什么指标”。如果某个目标读下来没有可验证的指标那它停留在愿景层面还不是目标。再看不那么容易分清的一对概念“规定”和“约束”。规定是通过努力可以直接解决的问题而且必须解决才能保证项目按计划完成比如“必须在 3 天内到位”“必须在 8 月 8 日前确定对需求文档进行确认”。约束则是难以绕过的问题只能通过其他途径回避、弥补或取舍比如人力资源有限那就必须牺牲进度或质量。注意一个容易写错的地方如果问题出现具有不确定性不要写进规定或约束应该写进风险评估章节分析概率、影响和应对措施。把不确定的事当成确定约束写后面计划一调整这一整章都得返工。“项目工作范围”要说明为按时保质实现目标需要进行哪些工作。我习惯在范围里单独列一小段“不在本次范围的工作”立项书把边界画清楚后续需求蔓延时这就是后悔药。填需求变更申请时翻出这一页甲乙方都好说话。接下来是“应交付成果”模板把它分成了四类下面用一个表格梳理交付类型内容要点填写提醒需完成的项目建设项目建设内容清单逐项写避免“系统建设”一句话带过需提交用户的文档需求规格说明书、操作手册等写文档名称和内容要点别只写“相关文档”须提交内部的文档项目变更申请、项目进度报告等内部交付物关乎管理流程别漏应当提供的服务培训、安装、维护和运行支持合同里有培训约定时可另编培训计划最后是“项目验收方式”说明内部验收和用户验收的方式及验收依据。这一节的颗粒度要到“按什么标准、由谁签字确认”。立项书里不写“系统运行稳定”这种话要写“连续 7 天试运行期间无等级事故”这类可以判定的表述。验收依据若写得模糊验收阶段必有一方觉得自己被坑了。3. 团队组织与实施计划把“谁来做”和“做到什么程度”钉死在纸面上合同签完、项目启动会开完立项书里被翻得最多的就是第三章和第四章。团队组织讲分工实施计划讲节奏和风险。这两章写得好项目过程管理就有抓手写得虚计划评审都会被怼回来。3.1 项目团队组织角色、分工与沟通三条线团队组织这一章有三块内容。首先是组织结构模板要求从所需角色和项目成员两个方面描述。所需角色要列出为完成项目需要哪些人比如项目总负责人、项目经理、运维工程师、业务接口人、客服、产品等等同时说明团队成员来自哪个部门。除了组织结构图还要用文字说明每个角色应有的技术水平。评审经常问“测试谁来做、什么水平”组织章节答不上来说明团队配置就没想清楚。其次是人员分工用列表方式说明每个成员属于组织结构中的什么角色、技术水平如何、项目里的分工与配置。我习惯在人员分工表里加一列“可替代人”写明谁不在时谁接手。关键岗位没有备份项目进行到一半核心人员休假进度立刻崩。第三块是协作与沟通。内容分成三条线项目团队内部协作说明协作模式和沟通方式、频次、沟通成果记录办法项目接口人员要写清负责与用户接口、与公司内部接口、与支持方接口三类人员的职责和联系方式项目团队外部沟通与协作模式明确最终用户和直接用户所在的部门名称与联系电话协作开发的部门名称、经理姓名、承担的工作内容合作单位的名称、负责人和联系电话。沟通方式模板里列了会议、电话、QQ、内部邮件、外部邮件、聊天室等协作模式则要写明出现什么状况时哪个角色应当主动采取什么措施。3.2 实施计划风险、流程、进度与控制实施计划是全文档信息量最大的一节。先看“风险评估及对策”。模板要求识别内在风险与外在风险内在风险是项目组能控制和影响的如人事任免、成本估计外在风险超出项目组控制力如市场转向。对策分三类避免靠排除危险起源来排除特定威胁减缓减少风险事件的预期资金投入来降低发生概率和风险系数吸纳接受后果可以是积极的制定预防性计划防备风险事件也可以是消极的某些费用超支就接受低于预期的利润。软件开发项目的常见风险模板给了四类验收不能顺利完成或延迟技术风险比如用新开发技术、新设备、新应用组合没有经验或新行业新业务没有经验性能要求太严用户方面的问题比如功能多次变更、与用户分担开发导致拖延、用户承担的工作延误其它没有列到但推测存在的风险。写风险对策最忌笼统每条风险都该有触发条件、概率、影响范围和负责人落成表格更清晰风险类别触发条件示例概率影响对策负责人进度风险阶段成果提交评审后返工超过两周中里程碑顺延减缓评审前置关键节点设置双重检查项目经理技术风险首次引入消息中间件团队无运维经验高联调周期不可控避免先做技术验证验证通过再进架构设计技术负责人用户风险需求确认后仍高频变更高范围蔓延吸纳变更走申请流程预算和工期同步调整业务接口人接下来是工作流程。模板要求画出工作流程图并配文字说明。我一般不用画图工具而是用表格列出每个阶段的输入、活动、输出和负责人比纯图形更容易归档评审问起来也能指着某一行说清楚。再往下是“总体进度计划”要依据确定的项目规模列表项目阶段划分、阶段进度安排及每阶段应提交的阶段成果。覆盖的阶段包括项目计划、项目准备、需求调研、需求分析、构架设计或概要设计、编码实现、测试、移交、内部培训、用户培训、安装部署、试运行、验收。每项工作任务写预定开始日期、完成日期、所需资源、先后顺序以及表征完成的标志性事件。提示里程碑千万不要写“需求完成”要写“需求规格说明书通过用户签字确认”。评审只看可验证的交付物。最后是项目控制计划三块内容各司其职。质量保证计划说明产品质量、建设质量、服务质量如何保证明确质量活动的记录要保存的期限和方法。进度控制计划由项目过程控制部门统一监控保留日常检查记录。预算监控计划说明怎么检查预算使用情况。这三块是给管理和审计看的但也是项目组自我保护的工具——被问“为什么延期”时日常检查记录就是最好的证据。4. 避坑五个最容易翻车的填写误区填立项书这项工作看着是模板套话实际全是细节里的玄学。以下五个坑每条都是项目真实评审中反复出现的问题按“现象 → 原因 → 解决”写照着自查能省一轮答辩。4.1 “目的”栏填成了“项目目标”现象1.1 的“目的”写的是“开发一个 XX 系统实现 XX 功能”翻到后面 2.1 项目目标内容差不多两节重复。原因没读模板里的提醒。“目的”说的是本文档的目的与作用项目目标在 2.1 里单独说明两件事。解决1.1 直接套用模板那句“项目成员以及项目干系人之间的共识与约定项目生命周期所有活动的行动基础以便项目团队根据本计划书开展和检查项目工作”再补一句文档作为变更和验收基准的话。项目目标则写可测量的成功标准两者自然区分开。4.2 修订历史不维护AMD 标记形同虚设现象项目进行到第三个月立项书已经改了六版。评审会上被问“这一版对上一版改了什么”整个会议室安静了三秒没人答得上来。原因改文档直接把旧文件覆盖了修订历史记录表从来没填过。模板里那张记录表版本、日期、修订者、说明四列说明里要用 A 表示添加、M 表示修改、D 表示删除大多项目组嫌麻烦跳过了。解决每次改动用一行记录版本号、日期、修订者、说明一项不漏。说明以 A/M/D 开头比如“M2.1 阶段目标时间点由 6 月 30 日调整为 7 月 15 日”。对外发版前自查一遍凡是没见过修订记录的版本一律不发。这个习惯能在评审时省下大量解释成本。4.3 规定和约束分不清现象立项书里“规定与约束”一节写的是“项目组只有 3 个人因此进度排到明年”“人手不足无法保证质量”评审直接质疑这个项目组成员配置为什么不能增加问题出在哪原因把“规定”和“约束”混为一谈。规定是通过努力能直接解决的问题必须解决才能保证项目按计划完成约束则是绕不过去的限制只能回避、弥补、取舍。人手不足这类问题属于资源配置的取舍不是靠“规定”能解决的。解决规定栏写通过努力能解决且必须解决的事项比如“必须在 8 月 8 日前确定对需求文档进行确认”约束栏写客观限制比如人力资源有限因此需要牺牲部分非核心功能或调整进度同时写明取舍策略。如果某个问题出现与否不确定直接移到风险评估章节按概率和影响分析。4.4 参考资料和标准条约混在一节写现象验收阶段翻立项书找合同编号发现参考资料和必须遵守的标准条约堆在一个列表里编号、日期都不全验收依据无从追溯。原因没理解两者的区别。参考资料具有“物质”特性要说明参照了什么、在哪里能获得标准、条约和约定具有“精神”特性是必须遵守的内容不说明在哪里获得。参考的不一定是必须遵守的必须遵守的也不一定要列在参考资料里。解决分节写。参考资料列合同、标书、任务书、已发表文件、引用的软件开发标准每条带作者、标题、编号、发表日期、出版单位和获取途径标准条约列必须遵守的技术规范和验收标准不写获取途径。两者内容允许有交集但角色不同不能混在一堆。4.5 风险对策写成“加强沟通、注意安全”现象风险评估整页看下来全是“加强沟通”“注意进度”“保证质量”这类口号没有任何一条写了概率、影响和应对动作。评审问“需求变更了怎么办”答不上来。原因把风险评估当成形式清单没有对具体项目算账。风险段模板给了四类常见风险但很多人只抄了类别名称没写对策组合——避免、减缓、吸纳。解决每条风险写四要素触发条件、概率分级、影响范围、对策动作。以“需求频繁变更”为例触发条件是业务方在需求确认后仍提出新功能要求概率高影响是开发返工、里程碑顺延 10% 到 20%对策是减缓两周一次变更评审、重要变更走变更申请流程负责人写项目经理。写完后自查一遍任何一条风险如果删掉后不影响任何后续计划说明它还是口号不是风险。5. 预算与支持条件三张表把人、财、物写明白预算章节在立项书里看着最像财务的事实际最考验对项目的理解。模板把预算拆成人员成本、设备成本、其它经费预算三块再加一项合计。人员成本要列出项目团队每一个人的预计工作月数以及完成本项目所需劳务的人数和时间。设备成本包含三部分原材料费、设备购置及使用费拟购置设备的配置和经费拟购置软件及其版本和经费。很多项目组在这里漏掉“现有设备使用时间”这一项结果现有资源的使用成本没进预算财务评审必然追问。其它经费预算模板列得很细差旅费含旅费、出租和补贴资料费含图书、资料、复印、出版通信费含市话长途、移动通信、上网和邮资会议费含鉴定、评审、研讨、外事办公费含办公用品协作费含业务协作招待和加班伙食培训费含资料编写、印刷、场地和设备另外还有检测、维修、消耗品等其它费用。这个分类的好处是每一项都有明确出处不容易发生“钱花哪了”的纠纷。支持条件章节则分内部支持、客户支持、外部支持三条内部支持逐项列出每阶段的支持需求包括人员、设备、软件、培训的时间要求和用途客户支持写明需由客户承担的工作、完成期限和验收标准包括需客户提供的条件和时间外部支持列出外部支持方承担的工作和完成时间。提示客户支持最容易写成一团模糊的“配合调研”。我后来强制写明“客户需在 X 月 X 日前确认需求文档延迟 X 个工作日则里程碑顺延”需求确认阶段互相甩锅的事少了很多。最后说一个我每次填预算都要做的验证动作反推。把预算合计金额除以总的投入人月数看单人月成本是否落在合理区间如果高过同类型项目一大截多半是某项预算重复计了再把每笔设备购置费和其它经费对着工作范围逐条找依据找不到出处的一律删掉。模板最后的“关键问题”章节也不要跳过逐项列出影响项目成败的技术难点和风险指出对项目成败的影响这一页就是评审答辩的底稿。从那以后我每次填完立项书都会强制把预算反推一遍确认每一项支出都能在工作计划里找到出处再提交评审。希望帮到你。本文还有配套的精品资源点击获取
