计划
计划实践的目的是通过定义要交付的产品(“什么”)和交付方法(“谁”、“如何”、“在哪里”以及对”何时”和”多少”的估算)来促进沟通和控制,从而满足项目商业论证(“为什么”)。
定义:计划 概述整个项目(或其活动的子集)的内容、地点、时间、方式和人员的提案。在 PRINCE2 中,有以下类型的计划:项目计划、阶段计划、小组计划,以及例外计划。
7.1 计划的双重作用
促进了解和沟通
计划集成了三个视角:
- 用户对要交付的产品和要实现的收益的期望
- 项目管理团队对满足这些期望的最有效方法的评估
- 项目的业务支持,包括资金、人员和资源的承诺
计划的开发使项目管理团队能够评估和了解:
- 为什么:用户的驱动需求以及他们期望实现的收益
- 什么:要交付的产品及其相关的验收准则和质量规格
- 如何:交付方法和任何约束
- 何时:交付活动的顺序和估算持续时间
- 在哪里:交付和验收所涉及的地点和设施
- 谁:项目团队所需的技能和职责以及人员的组织方式
- 多少:协定产品以及相关交付和管理活动的估算成本
促成控制
定义:范围 由已批准的计划及其产品描述和工作包描述表示的产品、交付和管理活动的总和。
已批准且已设定基线的项目计划代表协定的项目范围。明确了解已获批项目范围内与范围外的内容,对于避免不受控变更(通常称为范围蔓延)至关重要。
7.2 对有效计划的指导
7.2.1 规划周期
计划始终基于估算。PRINCE2 原则”按阶段管理”满足了将计划保持在合理规划周期内的需求。因此,PRINCE2 项目具有:
- 项目计划:对如何及何时实现项目目标的概括性描述,显示主要产品、活动以及所需的人员和资源
- 阶段计划:当前阶段的详细文件,基于在规划周期内可实现的更精确估算
7.2.2 计划层级
| 计划类型 | 定义 |
|---|---|
| 项目计划 | 一项说明项目的主要产品及其交付日期、交付方式和相应成本的高层次计划 |
| 阶段计划 | 一个详细的计划,用作整个阶段中项目管理控制的基础 |
| 小组计划 | 在执行工作包时,用作组织和控制小组工作的基础的计划(在 PRINCE2 中是可选的) |
| 例外计划 | 一种计划,它遵循例外报告,并说明项目将如何响应阶段内的例外 |
计划层级关系:
项目任务书/业务计划 → 项目计划 → 后续阶段计划 → 小组计划
↘ 启动阶段计划
↘ 例外计划(如需要)

7.2.3 阶段
确定如何将项目划分为多个阶段需要权衡:
- 交付方法(迭代-增量或线性-顺序)
- 交付活动的顺序
- 涉及的人员和资源类型
- 关键决策点的数量和时间
- 项目可以管理的风险量
- 在项目中提前多少对于计划来说是合理的
阶段数量:阶段数量越多,控制程度越高,但每个阶段边界都需要尽力管理
阶段长度决定因素:
- 复杂性:交付活动之间依赖关系多则宜用较短阶段
- 风险级别:高风险项目可在关键点插入阶段中断
- 规划周期:不确定性高则宜用较短阶段
- 适当的决策点:阶段边界与关键决策保持一致
- 与项目群活动保持一致:项目群可能要求阶段与项目群里程碑一致
PRINCE2 阶段不重叠,通过引入交替运作的决策点来划分项目,使项目管理团队和项目管理委员会能够审查进展,并评估项目是否具有持续业务理由。
7.2.4 计划中的容许偏差
PRINCE2 包括对收益、时间、成本、质量、范围、风险和可持续性的容许偏差:
| 容许偏差类型 | 定义 |
|---|---|
| 时间容许偏差 | 计划时间的容许偏差,一旦超出时间容许偏差,则需上报到更高一级管理层 |
| 成本容许偏差 | 计划成本的容许偏差,一旦超出成本容许偏差,则需上报到更高一级管理层 |
| 范围容许偏差 | 计划范围的容许偏差,一旦超出范围容许偏差,则需上报到更高一级管理层 |
7.2.5 基于产品的规划
定义:基于产品的规划 一种 PRINCE2 技术,可基于所需产品的创建和交付来生成计划。
关注产品是 PRINCE2 的一项原则。优点:
- 避免对所需产出没有实质性贡献的活动
- 帮助项目经理知道从哪里开始
- 降低遗漏或忽略的范围方面的风险
- 帮助例外计划专注于解决例外,同时将对成本和进度表的影响降到最小
7.3 PRINCE2 规划技术
7.3.1 规划技术步骤(六步骤)
| 步骤 | 说明 |
|---|---|
| 1. 定义和分析产品 | 编写项目产品描述 → 创建产品分解结构 → 编写产品描述 → 创建产品流程图 |
| 2. 组织工作包 | 识别工作包并确定依赖关系 |
| 3. 准备估算 | 估算人员、资源、活动持续时间、成本、收益和风险 |
| 4. 准备进度表 | 工作包及相关任务的顺序、相互关系和持续时间 |
| 5. 编制预算 | 计算计划的成本,包括风险预算和变更预算 |
| 6. 将计划记录成文 | 分析风险,形成叙述性文件说明计划 |
定义和分析产品详解
项目产品描述
项目主要产品或成果的描述,包括用户的质量期望,以及项目的验收准则和验收方法。
产品分解结构
计划期间生产的所有产品的层级。
将每个产品以层方式划分为组件元素,并收集对这些元素的需求。
产品流程图
产品流程图中呈现了产品分解结构中列出的产品的生产顺序及相互依赖关系的图表。
依赖关系
依赖关系意味着一种产品依赖于另一种产品。
- 内部依赖关系:项目的两个产品之间的依赖,项目团队可以控制
- 外部依赖关系:项目产品与项目范围外产品或活动之间的依赖,项目团队无法完全控制
7.3.2 支持技术
优先级排序方法:
- 将标准分类为必须具有、应该具有、可以具有或不会具有
- 产品待办事项方法(了解向用户提供特征的顺序)
- Kano 模型(令人愉悦的特征、绩效特征和基本特征)
- Eisenhower 矩阵(从重要性与紧迫性或价值与实施简易性两个对比维度评估标准)
进度表编制工具:
- 甘特图:任务持续时间相对于时间进展的图形化呈现
- 电子表格:列出工作包和任务及相应时间线
- 产品核查清单:计划中主要产品及其关键交付日期的清单
- 活动流程板:显示每个产品或产品组件在开发或交付工作中的进展(看板)
估算技术:
- 自上而下:假设主要产品和工作包的成本、持续时间和工作量可估算到高水平的置信度
- 自下而上:在单个产品、组件、活动或任务的最低定义层面上制定估算
- 比较:基于类似项目或公开可用的市场信息进行估算
- 参数化:使用项目中的值(如结构数量、单位或大小)进行估算
- 数据分析:描述性分析和预测性分析
- 主题专业知识:Delphi 和计划扑克等基于共识的技术
7.4 应用实践
7.4.1 组织情境
- 项目计划通常受组织情境的影响,包括政策、程序和支持
- 项目群管理团队可能扮演主要支持角色,甚至领导其项目的计划
- 项目群可能定义一套标准的阶段,项目群中的项目必须统一执行
7.4.2 商务情境
- 对于商务情境下的项目,供应商的角色是一个重要的考虑因素
- 建议确保协议要求供应商的计划对用户项目计划的适用元素提供清晰的可追溯性
- 协议应说明如何编制这些计划,以及用户有哪些检查和审计权利
7.4.3 交付方法
- 线性-顺序项目:大多数计划工作都是在项目准备和项目启动流程中提前进行的,类似项目有助于以高置信度估算持续时间、工作量和成本
- 迭代-增量项目:侧重于在固定时间段(例如冲刺或时间盒)内可以生产多少,目标是快速交付初始产品,并迭代完善和改进它
7.5 管理产品
计划的 PRINCE2 管理产品包括:
- 项目产品描述:仅用于项目计划,在项目准备流程中创建
- 产品描述:在项目启动流程中以更多细节描述所需产品,包括验收准则和质量规格
- 工作包描述:项目经理和负责工作包的小组经理之间的协议,记录所有依赖关系
- 进度表和预算:可在单独的系统或文件中维护
- 叙述性文件:概括解释计划,并识别依赖关系、建议的容许偏差、监视和控制需求等
喜欢的话,留下你的评论吧~