高项 第九/十/十一章项目范围/进度/成本的理解一、范围管理需求管理计划需求管理计划完整现实例子子计划写流程规则不写具体功能 本计划用来规定本项目全部需求如何收集、记录、跟踪、变更、验证。 收集需求的方法 对接产品、商户、普通用户做访谈开展需求研讨会输出交互原型所有需求必须由干系人正式提出开发不接收微信口头提需求。 需求如何编写成【需求文件】 每一条需求分配唯一编号 R 开头区分业务需求、用户需求、非功能需求每条需求必须写可验证的验收标准模糊的描述不能进需求文件。 需求跟踪矩阵管理规则 项目启动就建立跟踪矩阵。 跟踪链条业务需求 → 用户需求 → WBS 工作包 → 可交付成果 → 测试用例。 只要需求变更经过 CCB 批准之后立刻更新跟踪矩阵保证双向追溯。没有批准不许改动矩阵。 需求优先级规则 使用 MoSCoW必须做、应该做、可以做、暂时不做。迭代优先开发 “必须做” 需求。 需求变更流程 任何新增、修改需求口头无效必须提交变更请求走实施整体变更控制。 CCB 批准后项目经理更新需求文件、更新需求跟踪矩阵拒绝私自改需求、私自开发防止范围蔓延。 需求验证 模块开发完成产品对照需求文件做确认所有测试用例必须能够在跟踪矩阵找到对应的需求不允许出现无来源的测试用例。需求文件业务需求人事部门希望系统实现员工打卡考勤统计减少手工统计。 用户需求 R‑001员工可以在小程序打卡定位打卡。 R‑002人事管理员可以导出月度考勤Excel报表。 R‑003系统要支持请假申请、审批流程。 非功能需求 1. 小程序页面响应时间≤2秒。 2. 数据每天自动备份。 验收标准导出报表可以直接导入Excel日期、打卡记录无错乱。需求跟踪矩阵需求编号需求描述业务目标WBS 工作包可交付成果测试用例 ID状态R‑001小程序定位打卡员工考勤WBS‑1.1.1打卡小程序模块TC‑01已完成R‑002导出月度考勤报表人事统计WBS‑1.2.3后台报表功能TC‑02开发中R‑003请假审批流程人事流程WBS‑1.3.2审批模块TC‑03未开始问为什么要做需求优先级排序举现实流程 需求管理计划提前写死规则 使用 MoSCoW 做优先级排序 由产品经理 业务代表共同确定优先级 每次新增 / 变更需求批准后必须重新评估优先级 优先级结果记录在需求文件中。 项目会收集一大堆需求 用户要优惠券、 商户要对账、 用户要夜间模式、 要分享红包、 要会员体系。 但是工期、钱、人力有限不可能一次性全部做完。 区分先后解决资源不够的矛盾 通过优先级分出哪些第一期必须做哪些二期再做。 MoSCoW 例子 ✅必须做 (M)浏览商家、购物车、微信支付一期一定要上线 ⭕应该做 (S)优惠券一期尽量做时间不够就挪二期 可以做 (C)夜间模式有空余资源再做 ❌暂不做 (W)会员体系本版本放弃以后再说 迭代 / 版本规划的依据 敏捷、增量项目尤其重要。一期只做高优先级需求保证核心功能先上线。 出现变更的时候重新评估优先级 客户新增需求 “拼单功能”。 按照需求管理计划提前定好的规则 新增需求来了由产品 业务干系人重新评估优先级再放进迭代。 不是开发想做哪个就做哪个也不是客户说啥就先做啥。 应对范围蔓延 客户不断加需求资源不变。 靠优先级做取舍新增一个高优先级需求就要把现有某个低优先级需求移出本期版本。范围平衡问为啥定义范围的输入有风险登记册写范围说明书的时候要把风险考虑进范围边界、假设、约束里面。风险登记册记录已经识别出来的风险用来辅助定范围。举例子开发外卖小程序风险登记册里面记录几条已识别风险风险 R1第三方支付接口不稳定对接失败风险。风险 R2工期紧张如果做会员模块大概率延期。风险 R3商户对账功能开发复杂度高人力不足。执行【定义范围】编写项目范围说明书看到风险 R2做会员模块容易延期 →范围说明书就把会员模块排除在本版本范围之外本版本不做会员规避该风险。看到风险 R3对账复杂度高 → 范围说明书写明商户对账只做简易版本完整对账放到二期降低风险。看到风险 R1支付接口存在不稳定风险 → 在范围说明书的假设条件写上假设第三方支付接口能正常提供服务一旦接口变更需要走变更流程。也就是说已识别的风险会影响我们怎么划定项目范围哪些功能放进范围哪些排除出去设置哪些假设约束。所以定义范围要读风险登记册。范围基准范围基准 项目范围说明书 WBS WBS 词典三者打包在一起经过批准只有走变更流程才能修改。①项目范围说明书口诀产、可、验、除、制、假 产品范围描述细化产品 / 服务具备什么功能、特性 可交付成果要交出的全部成果含产品、文档、报告等辅助成果 验收标准可交付成果要满足哪些条件才算验收通过 项目的除外责任明确哪些不做防止范围蔓延 制约因素限制项目的条件如预算、工期、技术约束 假设条件规划时假定成立的前提不一定真实产品范围描述开发外卖点餐小程序 V1.0实现用户浏览商家、购物车、下单支付、订单查询功能。项目可交付成果用户端小程序前端后端业务服务接口部署文档、操作手册项目除外责任做什么 / 不做什么包含商家列表、购物车、微信支付、订单查询。不包含会员体系、拼单、商户完整对账、夜间模式放到二期实现。假设条件微信开放平台提供正常支付接口业务人员可以按时提供需求确认。制约因素总工期 3 个月预算 28 万。② WBS工作分解结构范围基准第二部分分解到可管理的工作包WBS 分解的是可交付成果不是活动1.0 外卖点餐小程序V1.0 1.1 用户端小程序 1.1.1 商家浏览模块 1.1.2 购物车模块 1.1.3 下单订单查询模块 1.2 后端服务 1.2.1 商家数据接口 1.2.2 订单支付接口 1.3 文档交付物 1.3.1 部署文档 1.3.2 用户操作手册③ WBS 词典范围基准第三部分对每个 WBS 条目详细解释WBS 编号名称工作描述责任人预算工期1.1.1商家浏览模块实现商家列表展示、商家详情页面开发张工4.5 万12 天1.1.2购物车模块菜品加入购物车、修改数量、删除菜品李工4 万10 天1.2.2订单支付接口对接微信支付完成下单支付回调处理王工6 万15 天WBS 词典写清楚每个工作包内容、负责人、成本时间避免大家理解不一样。上面三步骤的过程先记住两个核心过程定义范围 → 产出范围说明书、WBS、WBS 词典范围基准这个阶段只拆工作包只定义 “要产出什么东西”此时还没有精确工期、精确预算。我上例写的工期、预算是为举例方便直接填上的现实中这里只是预留位置数值来自后面过程。估算活动持续时间 估算成本才算工期、算钱。下面是具体流程顺序1定义范围拆出 WBS 工作包只写清楚这个工作包是做【商家浏览模块】此时不知道要花多少钱、做几天→WBS 词典先占位写名称、描述、责任人预算、工期这里是空的。2创建 WBS 之后进入 定义活动把每个工作包再拆成一个个要干的活动。 拆成页面原型、前端开发、接口联调、单元测试。3估算活动持续时间估算每个活动要几天。4估算成本估算每个活动要花多少钱。5制定进度计划 → 得到项目总工期6制定预算 → 得到项目总预算 28 万然后再回填到 WBS 词典里面把汇总后的每个工作包的工期、预算填进去。WBS 词典里面每个工作包的预算、工期来源是估算成本、估算活动持续时间不是拍脑袋写的。7项目总工期、总预算写进项目范围说明书的【制约因素】。范围说明书里的 “总工期 3 个月预算 28 万”是制约条件我们这个项目受限于最多 3 个月、最多花 28 万是上层给的约束。二、进度管理进度管理计划项目背景企业 OA 系统升级项目总工期 6 个月2026‑09‑012027‑02‑28总预算 120 万。下面是《进度管理计划》主要章节 实例内容。1. 进度管理方法采用敏捷 瀑布混合模式需求分析、设计阶段用瀑布开发迭代采用 2 周一个 Sprint。工具Project 编制甘特图Jira 跟踪任务每周输出进度报告。进度网络技术关键路径法 CPM识别关键路径重点管控关键活动。计量单位工作日每日 8 小时周末节假日不计入。2. 进度准确度与精度进度估算精度±10%汇报精度周级别每周五输出进度状态里程碑到天。3. 工期估算方法主要使用三点估算部分成熟模块采用类比估算。示例OA 登录模块开发乐观 8 天悲观 16 天最可能 10 天 (t_e(84×1016)/6 10.67)工作日。4. 进度里程碑例子表格里程碑完成时间交付物M1 需求规格确认2026‑09‑30需求规格说明书签字确认M2 概要设计完成2026‑10‑25系统概要设计文档评审通过M3 开发完成2026‑12‑31全部功能开发完成单元测试通过M4 系统测试结束2027‑01‑31系统测试报告bug 闭环M5 上线交付2027‑02‑28OA 系统上线验收报告5. 活动持续时间、资源日历开发人员 5 人测试 2 人工作日上班法定节假日不排班。关键活动不安排节假日加班确需加班走变更流程。6. 进度基准将批准后的 WBS 活动、工期、逻辑关系、里程碑、甘特图作为进度基准。只有通过整体变更控制流程审批后才能修改进度基准不能直接改计划。7. 控制临界值偏差阈值用来判断要不要采取纠偏措施工期偏差10%必须提交进度偏差分析报告里程碑滞后单个里程碑滞后超过 3 个工作日启动风险处置关键路径活动一旦延期立刻触发干预不等待阈值。8. 绩效测量规则使用挣值管理 EVM测量进度绩效SPIEV/PVSPI0.9进度落后分析原因提交纠偏方案SPI1.1评估是否可以适度调整资源避免后期返工风险。9. 报告格式每周进度报告包含当前 PV/EV/SPI任务完成情况滞后任务风险下周计划。里程碑节点输出里程碑专项报告。10. 进度更新、变更流程实际进度每周录入 Project对比进度基准识别偏差。出现进度偏差先分析原因资源不足 / 需求变更 / 技术难点选择赶工、快速跟进、增加资源等纠偏。如果纠偏无法挽回工期提交变更请求CCB 审批审批通过更新进度基准活动清单举例收集业务部门需求编制需求规格说明书组织需求评审修改需求文档编写系统概要设计概要设计评审登录模块编码开发审批流模块编码开发单元测试集成测试系统测试用户验收测试系统部署上线活动属性活动 ID活动名称紧前活动负责人预估工期资源约束A01收集业务部门需求无产品经理8 工作日产品 1 人9.1 开始A02编制需求规格说明书A01产品经理5 工作日产品 1 人A03组织需求评审A02项目经理2 工作日全体干系人必须甲方参会A04修改需求文档A03产品经理3 工作日产品 1 人评审问题闭环进度基准过程梳理定义活动 → 排列活动顺序 → 估算活动持续时间 →制定进度计划排列活动顺序输出项目进度网络图只有活动 逻辑关系FS/FF/SS/SF没有工期、没有日期只是一张逻辑图不能当计划用。估算活动持续时间输出持续时间估算只有每个活动大概要干几天没有开始结束日期没有资源没有整体时间表只是一堆孤立的工期数字。网络图知道谁先谁后持续时间知道每个活干多久但是不知道几号开始、几号结束、总工期多久。制定进度计划把前面所有输入揉在一起算时间输入包括 活动清单、活动属性、项目进度网络图、持续时间估算、资源日历、风险登记册、假设条件等等。用工具关键路径、资源平衡、假设情景分析、赶工、快速跟进。 经过反复演算、调整、优化出来两个东西① 项目进度计划进度模型包含各活动开始 / 结束日期、甘特图、里程碑、关键路径、总工期。这是草稿版本、可修改的工作版本还没审批。② 进度基准项目进度计划经过 CCB 审批批准之后就成为进度基准。基准用来做对比测量的标尺正常情况不能随便改变更必须走整体变更控制。实际执行时拿「实际进度」和「进度基准」对比算 SPI、判断偏差。进度基准举例**活动 ID活动名称紧前活动计划工期 (工作日)计划开始计划结束总时差自由时差是否关键活动里程碑标记资源需求规划类型A01收集业务部门需求无82026‑09‑012026‑09‑1000✅是业务分析师 1 名A02编制需求规格说明书A0152026‑09‑112026‑09‑1700✅是需求工程师 1 名A03组织需求评审A0222026‑09‑182026‑09‑1922❌否需求评审通过评审专家组A04修改需求文档A0342026‑09‑222026‑09‑2622❌否需求工程师 1 名A05编写系统概要设计A0482026‑09‑292026‑10‑1000✅是架构师 1 名A06概要设计评审A0522026‑10‑132026‑10‑1400✅是概要设计基线技术评审组基准里的里程碑内嵌在进度基准M1 需求规格说明书评审确认2026‑09‑19 M2 概要设计评审完成2026‑10‑14 M3 开发工作全部完成2026‑11‑04 M4 系统测试完成2026‑12‑12 M5 系统上线验收交付2026‑12‑31三、成本管理规划成本管理输出成本管理计划### 1. 计量单位 - 货币单位人民币万元人力按人天统计。 ### 2. 精确度、准确度 - 估算精确度保留 2 位小数 - 估算准确度±10%项目早期允许 ±15%。 ### 3. 控制临界值偏差阈值 - 成本偏差 CV成本绩效指数 CPI 作为监控指标 - **CPI0.9**或成本偏差超过总预算 10%必须提交成本偏差分析报告 - 单个里程碑成本超支8%启动审查。 ### 4. 绩效测量规则挣值 EVM 规则 1. 采用挣值管理 EVM 开展成本绩效测量 2. PV、EV、AC 按周统计 3. EV 测量规则活动 100% 完成计全部 EV部分完成按完成百分比计算 EV 4. 管理储备**8 万元**用于应对未知未知风险不经审批不得动用 5. 应急储备**10 万元**应对已知未知风险项目经理可在授权范围内使用。 总预算 项目成本基准 管理储备 成本基准 各活动估算 应急储备 112 万总预算 1128120 万 ### 5. 估算方法 - 主要采用**参数估算、三点估算**历史模块使用类比估算。 ### 6. 报告格式 - 每周项目报告包含 AC、PV、EV、CPI、CV成本超支 / 节约原因分析 - 每个里程碑输出专项成本报告。 ### 7. 成本更新与变更流程 1. 定期更新项目成本计划对比成本基准识别偏差 2. 出现成本偏差优先分析原因采取控制措施削减范围、优化资源、替换方案等 3. 若需要修改**成本基准**必须提交变更请求CCB 审批通过后更新成本基准 4. 管理储备动用提交申请高层审批批准后才纳入成本基准。 ### 8. 资金筹措 资金按阶段拨付需求阶段拨付 25%开发阶段拨付 45%测试上线拨付 30%。 ### 9. 审批权限 - 单次支出≤5 万项目经理审批 - 单次支出5 万上报公司财务 项目发起人审批。估算成本输出成本估算、估算依据成本估算成本估算收集业务部门需求 4.20 万编制需求规格说明书 2.80 万组织需求评审 1.50 万修改需求文档 2.10 万编写系统概要设计 5.00 万概要设计评审 1.80 万登录模块编码开发 8.60 万审批流模块编码开发 10.20 万单元测试 4.50 万集成测试 5.80 万系统测试 6.30 万用户验收测试 3.20 万系统部署上线 4.00 万成本合计60 万应急储备 10.00 万项目总估算 70.00 万元。估算依据含义成本估算的支持细节说明这个数是怎么算出来的文档化用来追溯。估算依据包含内容实例估算使用的方法部分活动类比估算开发模块采用三点估算人力成本采用参数估算人天 × 人力单价。估算的假设条件团队人员稳定外部服务器租赁价格不变没有重大需求变更工作日按 8 小时计。估算的约束条件项目不能超公司内部人力单价标准部分工作不允许外包预算上限约束。估算的资源依据人员数量、人天、物料、服务器、外包费用人力单价开发 1200 元 / 人天测试 900 元 / 人天。估算的置信区间 / 误差范围本项目成本估算准确度 ±10%。应急储备计算说明基于风险登记册识别的已知‑未知风险按活动总成本约 16.7% 计提应急储备 10 万元。哪些部分做了估算哪些没有估算本估算不含管理储备管理储备在预算阶段单独设置。成本预算输出成本基准、项目资金需求成本基准阶段时间阶段预算万元备注需求阶段2026‑0912.00需求相关全部活动 对应应急储备设计阶段2026‑1014.00概要设计 评审 对应应急储备开发阶段2026‑10~1126.00模块编码、单元测试 对应应急储备测试阶段2026‑11~1212.00集成、系统、UAT 测试 对应应急储备上线部署2026‑126.00部署上线 对应应急储备合计成本基准70.00含应急储备 10 万不含管理储备项目资金需求时间节点需要资金万元说明项目启动2026‑09 初18.00覆盖需求、设计阶段预留少量缓冲开发启动2026‑10 中32.00覆盖开发 部分测试对应成本基准对应时段测试上线2026‑11 底20.00覆盖测试、上线包含成本基准剩余部分项目总资金需求78.00成本基准 70 万 管理储备 8 万检查点 2026‑09 月底 成本基准计划到 9 月底预算 PV12 万实际 AC13.5 万EV10 万。 CPIEV/AC10/13.5≈0.74成本超支。拿实际 AC 和成本基准做对比分析偏差可以调整方案、优化资源但不能直接修改成本基准如果确实需要上调成本基准提交变更请求CCB 审批通过后更新成本基准。如果遇到特大未知未知风险需要动用 8 万管理储备提交高层审批批准后把对应金额划入成本基准同时更新项目资金需求。 高项 第九/十/十一章项目范围/进度/成本的理解
高项 第九/十/十一章项目范围/进度/成本的理解一、范围管理需求管理计划需求管理计划完整现实例子子计划写流程规则不写具体功能 本计划用来规定本项目全部需求如何收集、记录、跟踪、变更、验证。 收集需求的方法 对接产品、商户、普通用户做访谈开展需求研讨会输出交互原型所有需求必须由干系人正式提出开发不接收微信口头提需求。 需求如何编写成【需求文件】 每一条需求分配唯一编号 R 开头区分业务需求、用户需求、非功能需求每条需求必须写可验证的验收标准模糊的描述不能进需求文件。 需求跟踪矩阵管理规则 项目启动就建立跟踪矩阵。 跟踪链条业务需求 → 用户需求 → WBS 工作包 → 可交付成果 → 测试用例。 只要需求变更经过 CCB 批准之后立刻更新跟踪矩阵保证双向追溯。没有批准不许改动矩阵。 需求优先级规则 使用 MoSCoW必须做、应该做、可以做、暂时不做。迭代优先开发 “必须做” 需求。 需求变更流程 任何新增、修改需求口头无效必须提交变更请求走实施整体变更控制。 CCB 批准后项目经理更新需求文件、更新需求跟踪矩阵拒绝私自改需求、私自开发防止范围蔓延。 需求验证 模块开发完成产品对照需求文件做确认所有测试用例必须能够在跟踪矩阵找到对应的需求不允许出现无来源的测试用例。需求文件业务需求人事部门希望系统实现员工打卡考勤统计减少手工统计。 用户需求 R‑001员工可以在小程序打卡定位打卡。 R‑002人事管理员可以导出月度考勤Excel报表。 R‑003系统要支持请假申请、审批流程。 非功能需求 1. 小程序页面响应时间≤2秒。 2. 数据每天自动备份。 验收标准导出报表可以直接导入Excel日期、打卡记录无错乱。需求跟踪矩阵需求编号需求描述业务目标WBS 工作包可交付成果测试用例 ID状态R‑001小程序定位打卡员工考勤WBS‑1.1.1打卡小程序模块TC‑01已完成R‑002导出月度考勤报表人事统计WBS‑1.2.3后台报表功能TC‑02开发中R‑003请假审批流程人事流程WBS‑1.3.2审批模块TC‑03未开始问为什么要做需求优先级排序举现实流程 需求管理计划提前写死规则 使用 MoSCoW 做优先级排序 由产品经理 业务代表共同确定优先级 每次新增 / 变更需求批准后必须重新评估优先级 优先级结果记录在需求文件中。 项目会收集一大堆需求 用户要优惠券、 商户要对账、 用户要夜间模式、 要分享红包、 要会员体系。 但是工期、钱、人力有限不可能一次性全部做完。 区分先后解决资源不够的矛盾 通过优先级分出哪些第一期必须做哪些二期再做。 MoSCoW 例子 ✅必须做 (M)浏览商家、购物车、微信支付一期一定要上线 ⭕应该做 (S)优惠券一期尽量做时间不够就挪二期 可以做 (C)夜间模式有空余资源再做 ❌暂不做 (W)会员体系本版本放弃以后再说 迭代 / 版本规划的依据 敏捷、增量项目尤其重要。一期只做高优先级需求保证核心功能先上线。 出现变更的时候重新评估优先级 客户新增需求 “拼单功能”。 按照需求管理计划提前定好的规则 新增需求来了由产品 业务干系人重新评估优先级再放进迭代。 不是开发想做哪个就做哪个也不是客户说啥就先做啥。 应对范围蔓延 客户不断加需求资源不变。 靠优先级做取舍新增一个高优先级需求就要把现有某个低优先级需求移出本期版本。范围平衡问为啥定义范围的输入有风险登记册写范围说明书的时候要把风险考虑进范围边界、假设、约束里面。风险登记册记录已经识别出来的风险用来辅助定范围。举例子开发外卖小程序风险登记册里面记录几条已识别风险风险 R1第三方支付接口不稳定对接失败风险。风险 R2工期紧张如果做会员模块大概率延期。风险 R3商户对账功能开发复杂度高人力不足。执行【定义范围】编写项目范围说明书看到风险 R2做会员模块容易延期 →范围说明书就把会员模块排除在本版本范围之外本版本不做会员规避该风险。看到风险 R3对账复杂度高 → 范围说明书写明商户对账只做简易版本完整对账放到二期降低风险。看到风险 R1支付接口存在不稳定风险 → 在范围说明书的假设条件写上假设第三方支付接口能正常提供服务一旦接口变更需要走变更流程。也就是说已识别的风险会影响我们怎么划定项目范围哪些功能放进范围哪些排除出去设置哪些假设约束。所以定义范围要读风险登记册。范围基准范围基准 项目范围说明书 WBS WBS 词典三者打包在一起经过批准只有走变更流程才能修改。①项目范围说明书口诀产、可、验、除、制、假 产品范围描述细化产品 / 服务具备什么功能、特性 可交付成果要交出的全部成果含产品、文档、报告等辅助成果 验收标准可交付成果要满足哪些条件才算验收通过 项目的除外责任明确哪些不做防止范围蔓延 制约因素限制项目的条件如预算、工期、技术约束 假设条件规划时假定成立的前提不一定真实产品范围描述开发外卖点餐小程序 V1.0实现用户浏览商家、购物车、下单支付、订单查询功能。项目可交付成果用户端小程序前端后端业务服务接口部署文档、操作手册项目除外责任做什么 / 不做什么包含商家列表、购物车、微信支付、订单查询。不包含会员体系、拼单、商户完整对账、夜间模式放到二期实现。假设条件微信开放平台提供正常支付接口业务人员可以按时提供需求确认。制约因素总工期 3 个月预算 28 万。② WBS工作分解结构范围基准第二部分分解到可管理的工作包WBS 分解的是可交付成果不是活动1.0 外卖点餐小程序V1.0 1.1 用户端小程序 1.1.1 商家浏览模块 1.1.2 购物车模块 1.1.3 下单订单查询模块 1.2 后端服务 1.2.1 商家数据接口 1.2.2 订单支付接口 1.3 文档交付物 1.3.1 部署文档 1.3.2 用户操作手册③ WBS 词典范围基准第三部分对每个 WBS 条目详细解释WBS 编号名称工作描述责任人预算工期1.1.1商家浏览模块实现商家列表展示、商家详情页面开发张工4.5 万12 天1.1.2购物车模块菜品加入购物车、修改数量、删除菜品李工4 万10 天1.2.2订单支付接口对接微信支付完成下单支付回调处理王工6 万15 天WBS 词典写清楚每个工作包内容、负责人、成本时间避免大家理解不一样。上面三步骤的过程先记住两个核心过程定义范围 → 产出范围说明书、WBS、WBS 词典范围基准这个阶段只拆工作包只定义 “要产出什么东西”此时还没有精确工期、精确预算。我上例写的工期、预算是为举例方便直接填上的现实中这里只是预留位置数值来自后面过程。估算活动持续时间 估算成本才算工期、算钱。下面是具体流程顺序1定义范围拆出 WBS 工作包只写清楚这个工作包是做【商家浏览模块】此时不知道要花多少钱、做几天→WBS 词典先占位写名称、描述、责任人预算、工期这里是空的。2创建 WBS 之后进入 定义活动把每个工作包再拆成一个个要干的活动。 拆成页面原型、前端开发、接口联调、单元测试。3估算活动持续时间估算每个活动要几天。4估算成本估算每个活动要花多少钱。5制定进度计划 → 得到项目总工期6制定预算 → 得到项目总预算 28 万然后再回填到 WBS 词典里面把汇总后的每个工作包的工期、预算填进去。WBS 词典里面每个工作包的预算、工期来源是估算成本、估算活动持续时间不是拍脑袋写的。7项目总工期、总预算写进项目范围说明书的【制约因素】。范围说明书里的 “总工期 3 个月预算 28 万”是制约条件我们这个项目受限于最多 3 个月、最多花 28 万是上层给的约束。二、进度管理进度管理计划项目背景企业 OA 系统升级项目总工期 6 个月2026‑09‑012027‑02‑28总预算 120 万。下面是《进度管理计划》主要章节 实例内容。1. 进度管理方法采用敏捷 瀑布混合模式需求分析、设计阶段用瀑布开发迭代采用 2 周一个 Sprint。工具Project 编制甘特图Jira 跟踪任务每周输出进度报告。进度网络技术关键路径法 CPM识别关键路径重点管控关键活动。计量单位工作日每日 8 小时周末节假日不计入。2. 进度准确度与精度进度估算精度±10%汇报精度周级别每周五输出进度状态里程碑到天。3. 工期估算方法主要使用三点估算部分成熟模块采用类比估算。示例OA 登录模块开发乐观 8 天悲观 16 天最可能 10 天 (t_e(84×1016)/6 10.67)工作日。4. 进度里程碑例子表格里程碑完成时间交付物M1 需求规格确认2026‑09‑30需求规格说明书签字确认M2 概要设计完成2026‑10‑25系统概要设计文档评审通过M3 开发完成2026‑12‑31全部功能开发完成单元测试通过M4 系统测试结束2027‑01‑31系统测试报告bug 闭环M5 上线交付2027‑02‑28OA 系统上线验收报告5. 活动持续时间、资源日历开发人员 5 人测试 2 人工作日上班法定节假日不排班。关键活动不安排节假日加班确需加班走变更流程。6. 进度基准将批准后的 WBS 活动、工期、逻辑关系、里程碑、甘特图作为进度基准。只有通过整体变更控制流程审批后才能修改进度基准不能直接改计划。7. 控制临界值偏差阈值用来判断要不要采取纠偏措施工期偏差10%必须提交进度偏差分析报告里程碑滞后单个里程碑滞后超过 3 个工作日启动风险处置关键路径活动一旦延期立刻触发干预不等待阈值。8. 绩效测量规则使用挣值管理 EVM测量进度绩效SPIEV/PVSPI0.9进度落后分析原因提交纠偏方案SPI1.1评估是否可以适度调整资源避免后期返工风险。9. 报告格式每周进度报告包含当前 PV/EV/SPI任务完成情况滞后任务风险下周计划。里程碑节点输出里程碑专项报告。10. 进度更新、变更流程实际进度每周录入 Project对比进度基准识别偏差。出现进度偏差先分析原因资源不足 / 需求变更 / 技术难点选择赶工、快速跟进、增加资源等纠偏。如果纠偏无法挽回工期提交变更请求CCB 审批审批通过更新进度基准活动清单举例收集业务部门需求编制需求规格说明书组织需求评审修改需求文档编写系统概要设计概要设计评审登录模块编码开发审批流模块编码开发单元测试集成测试系统测试用户验收测试系统部署上线活动属性活动 ID活动名称紧前活动负责人预估工期资源约束A01收集业务部门需求无产品经理8 工作日产品 1 人9.1 开始A02编制需求规格说明书A01产品经理5 工作日产品 1 人A03组织需求评审A02项目经理2 工作日全体干系人必须甲方参会A04修改需求文档A03产品经理3 工作日产品 1 人评审问题闭环进度基准过程梳理定义活动 → 排列活动顺序 → 估算活动持续时间 →制定进度计划排列活动顺序输出项目进度网络图只有活动 逻辑关系FS/FF/SS/SF没有工期、没有日期只是一张逻辑图不能当计划用。估算活动持续时间输出持续时间估算只有每个活动大概要干几天没有开始结束日期没有资源没有整体时间表只是一堆孤立的工期数字。网络图知道谁先谁后持续时间知道每个活干多久但是不知道几号开始、几号结束、总工期多久。制定进度计划把前面所有输入揉在一起算时间输入包括 活动清单、活动属性、项目进度网络图、持续时间估算、资源日历、风险登记册、假设条件等等。用工具关键路径、资源平衡、假设情景分析、赶工、快速跟进。 经过反复演算、调整、优化出来两个东西① 项目进度计划进度模型包含各活动开始 / 结束日期、甘特图、里程碑、关键路径、总工期。这是草稿版本、可修改的工作版本还没审批。② 进度基准项目进度计划经过 CCB 审批批准之后就成为进度基准。基准用来做对比测量的标尺正常情况不能随便改变更必须走整体变更控制。实际执行时拿「实际进度」和「进度基准」对比算 SPI、判断偏差。进度基准举例**活动 ID活动名称紧前活动计划工期 (工作日)计划开始计划结束总时差自由时差是否关键活动里程碑标记资源需求规划类型A01收集业务部门需求无82026‑09‑012026‑09‑1000✅是业务分析师 1 名A02编制需求规格说明书A0152026‑09‑112026‑09‑1700✅是需求工程师 1 名A03组织需求评审A0222026‑09‑182026‑09‑1922❌否需求评审通过评审专家组A04修改需求文档A0342026‑09‑222026‑09‑2622❌否需求工程师 1 名A05编写系统概要设计A0482026‑09‑292026‑10‑1000✅是架构师 1 名A06概要设计评审A0522026‑10‑132026‑10‑1400✅是概要设计基线技术评审组基准里的里程碑内嵌在进度基准M1 需求规格说明书评审确认2026‑09‑19 M2 概要设计评审完成2026‑10‑14 M3 开发工作全部完成2026‑11‑04 M4 系统测试完成2026‑12‑12 M5 系统上线验收交付2026‑12‑31三、成本管理规划成本管理输出成本管理计划### 1. 计量单位 - 货币单位人民币万元人力按人天统计。 ### 2. 精确度、准确度 - 估算精确度保留 2 位小数 - 估算准确度±10%项目早期允许 ±15%。 ### 3. 控制临界值偏差阈值 - 成本偏差 CV成本绩效指数 CPI 作为监控指标 - **CPI0.9**或成本偏差超过总预算 10%必须提交成本偏差分析报告 - 单个里程碑成本超支8%启动审查。 ### 4. 绩效测量规则挣值 EVM 规则 1. 采用挣值管理 EVM 开展成本绩效测量 2. PV、EV、AC 按周统计 3. EV 测量规则活动 100% 完成计全部 EV部分完成按完成百分比计算 EV 4. 管理储备**8 万元**用于应对未知未知风险不经审批不得动用 5. 应急储备**10 万元**应对已知未知风险项目经理可在授权范围内使用。 总预算 项目成本基准 管理储备 成本基准 各活动估算 应急储备 112 万总预算 1128120 万 ### 5. 估算方法 - 主要采用**参数估算、三点估算**历史模块使用类比估算。 ### 6. 报告格式 - 每周项目报告包含 AC、PV、EV、CPI、CV成本超支 / 节约原因分析 - 每个里程碑输出专项成本报告。 ### 7. 成本更新与变更流程 1. 定期更新项目成本计划对比成本基准识别偏差 2. 出现成本偏差优先分析原因采取控制措施削减范围、优化资源、替换方案等 3. 若需要修改**成本基准**必须提交变更请求CCB 审批通过后更新成本基准 4. 管理储备动用提交申请高层审批批准后才纳入成本基准。 ### 8. 资金筹措 资金按阶段拨付需求阶段拨付 25%开发阶段拨付 45%测试上线拨付 30%。 ### 9. 审批权限 - 单次支出≤5 万项目经理审批 - 单次支出5 万上报公司财务 项目发起人审批。估算成本输出成本估算、估算依据成本估算成本估算收集业务部门需求 4.20 万编制需求规格说明书 2.80 万组织需求评审 1.50 万修改需求文档 2.10 万编写系统概要设计 5.00 万概要设计评审 1.80 万登录模块编码开发 8.60 万审批流模块编码开发 10.20 万单元测试 4.50 万集成测试 5.80 万系统测试 6.30 万用户验收测试 3.20 万系统部署上线 4.00 万成本合计60 万应急储备 10.00 万项目总估算 70.00 万元。估算依据含义成本估算的支持细节说明这个数是怎么算出来的文档化用来追溯。估算依据包含内容实例估算使用的方法部分活动类比估算开发模块采用三点估算人力成本采用参数估算人天 × 人力单价。估算的假设条件团队人员稳定外部服务器租赁价格不变没有重大需求变更工作日按 8 小时计。估算的约束条件项目不能超公司内部人力单价标准部分工作不允许外包预算上限约束。估算的资源依据人员数量、人天、物料、服务器、外包费用人力单价开发 1200 元 / 人天测试 900 元 / 人天。估算的置信区间 / 误差范围本项目成本估算准确度 ±10%。应急储备计算说明基于风险登记册识别的已知‑未知风险按活动总成本约 16.7% 计提应急储备 10 万元。哪些部分做了估算哪些没有估算本估算不含管理储备管理储备在预算阶段单独设置。成本预算输出成本基准、项目资金需求成本基准阶段时间阶段预算万元备注需求阶段2026‑0912.00需求相关全部活动 对应应急储备设计阶段2026‑1014.00概要设计 评审 对应应急储备开发阶段2026‑10~1126.00模块编码、单元测试 对应应急储备测试阶段2026‑11~1212.00集成、系统、UAT 测试 对应应急储备上线部署2026‑126.00部署上线 对应应急储备合计成本基准70.00含应急储备 10 万不含管理储备项目资金需求时间节点需要资金万元说明项目启动2026‑09 初18.00覆盖需求、设计阶段预留少量缓冲开发启动2026‑10 中32.00覆盖开发 部分测试对应成本基准对应时段测试上线2026‑11 底20.00覆盖测试、上线包含成本基准剩余部分项目总资金需求78.00成本基准 70 万 管理储备 8 万检查点 2026‑09 月底 成本基准计划到 9 月底预算 PV12 万实际 AC13.5 万EV10 万。 CPIEV/AC10/13.5≈0.74成本超支。拿实际 AC 和成本基准做对比分析偏差可以调整方案、优化资源但不能直接修改成本基准如果确实需要上调成本基准提交变更请求CCB 审批通过后更新成本基准。如果遇到特大未知未知风险需要动用 8 万管理储备提交高层审批批准后把对应金额划入成本基准同时更新项目资金需求。