Prince2 (受控环境中的项目)方法论教材
2019-09-10 00:07:40 0 举报AI智能生成
Prince2 (受控环境中的项目)方法论教材
作者其他创作
大纲/内容
Prince 结构
原则
持续业务验证
吸取经验教训
明确定义的角色和职责
按阶段管理
例外管理
关注产品
根据项目环境剪裁
主题
商业论证
目的
建立一种机制来判断项目是否是（保持是）可取的、可交付的、可获得的，作为是否对这个项目继续投资的决策支持手段
定义
什么是商业论证
产出 成果 收益
商业论证的类型
必要做的项目
非盈利项目
进化中的项目
客户/供应商项目
涉及多个组织的项目
方法
开发
验证和维护
确认收益
商业论证的内容
理由
可选方案
预期收益
预期负收益
时间
投资评估
主要风险
职责
项目管理委员会
项目主管
高级供应商
项目经理
项目保证
项目支持
组织
项目
项目群
公司组织
角色和工作
三种项目利益
商业
用户
供应商
组织层次
公司或项目群管理层
指导-项目管理委员会
管理-项目经理
交付-小组经理
项目管理团队
项目管理团队结构
高级用户
变更管理组织
小组经理
处理项目管理团队变化
项目团队工作
项目、团队和个人的平衡
项目团队的培训需求
兼职团队
与公司组织协同工作
直线型管理/职能型管理
卓越中心
与利益相关方协同工作
利益相关方类型
利益相关方管理
识别利益相关方（谁？）
创建和分析利益相关方概况（什么？）
定义利益相关方管理战略（如何？）
编制利益相关方管理计划（什么时候？）
与项目利益相关方建立密切关系（做）
测量有效性（结果）
沟通管理战略
质量
范围
质量管理和质量管理体系
编制质量计划
质量控制
质量保证
区别:质量保证和项目保证
客户的质量期望
验收标准
项目产品描述
质量管理战略
产品描述
质量登记单
质量方法
质量记录
批准记录
验收记录
计划
什么是计划
什么是编制计划
计划的层次
项目层次
阶段层次
小组层次
项目计划
阶段计划
例外计划
原理
基于产品的规划
编制计划的前提-设计计划
定义和分析产品
编写项目的产品描述
创建产品分解结构
编写产品描述
创建产品流程图
识别活动与依赖关系
活动
依赖关系
准备估算
准备进度表
定义活动顺序
评估资源可获得性
分配资源
平衡资源的使用
批准控制点
定义里程碑
计算总体资源要求和成本
展示进度表
甘特图
关键路径图
电子数据表
产品核查清单
分析风险
记录计划
风险
什么是风险
哪些可能受到风险影响
什么是风险管理
风险管理原则
项目中的风险管理
风险管理战略
登记单
风险管理步骤
识别
识别环境
风险识别技术
评审经验教训
风险核查清单
风险提示清单
头脑风暴
风险分解结构
识别风险
风险专题研讨会
风险表达
『风险原因』触发『风险事件』带来『风险结果』的影响
造成『威胁』和 『机会』
评估
估算
评估与项目相关的威胁和机会的概率和影响
风险估算技术
概率树
预期价值
帕累托分析
概率影响网格图
评价
评估所有识别出来的威胁和机会集合对项目的净效果
风险评价技术
风险模型
预期货币价值
为已识别出的威胁和机会准备特定的管理应对策略
关键因素
平衡\"实施应对方案所投入的成本\"和\"风险发生造成的损失\"
应对策略
规避、降低、后备、转移、接受
利用、强化、拒绝
共享
实施
保证计划的风险应对策略能付诸实施，监督策略有效性，并及时纠正
角色职责
风险负责人
选定应对策略，对风险进行管理、监督、控制
风险执行人
在风险负责人指导下，完成风险策略
沟通
利益相关方充分交流
管理产品
检查点报告
要点报告
阶段竣工报告
经验教训报告
沟通方式
公告
布告栏
管理控制台
网络论坛
简报
风险预算
为已知和未知风险预留的资金
计算预算方法
风险模型-蒙特卡洛分析
变更
识别、评估、控制任何 潜在的变更 和 已批准的对基线的变更
问题和变更控制
步骤
前提: 建立恰当的配置管理系统（记录项目产品基线）
问题得到识别、评估
变更被批准、拒绝或推迟
贯穿项目生命周期
配置管理
问题
项目的任何时候，任何与利益相关的人，都可提出问题
问题类型
变更请求
不合格项
问题/关注
建立控制方法
配置管理战略
配置项记录
产品状态陈述
日志
问题登记单
问题报告
配置管理步骤
1.编制计划
2.识别
3.控制
4.状态陈述
5.检验和审计
问题和变更控制步骤
捕获
1.判断问题类型: 变更请求、不合格项、问题/关注
2.决定严重程度/优先排序：正式管理、非正式管理
3.记录到登记单：针对正式管理的问题，创建问题报告
检查（影响分析）
1.进行影响分析，应考虑
项目绩效目标、项目商业论证、项目总体风险
商业、用户、供应商
2.检查问题的严重程度和优先排序
3.更新『问题登记单』『问题报告』
4.重要事情征求管理委员会意见
提议（方案分析）
1.识别可选方案
2.评估可选方案
3.推荐可选方案
决定
1.确定职权能否处理
项目经理直接处理
上报委员会（或变更管理组织）
2.批准、拒绝、推迟方案
(放宽容许偏差)建议/例外报告请求
项目经理采取纠正性行动
更新『问题登记单』和『问题报告』
进展
建立监督和控制机制，使关键的持续可行性评估得以实施，保证商业论证的持续可行性
三原则
阶段管理
进展控制 是项目管理的核心
进展是什么
进展是一份计划的各个目标实现程度
进展控制是什么
项目管理团队的上一级对下一级的监督控制授权
例外和容许偏差
例外
例外是一种可预知的情形，项目偏差超出容许偏差范围
容许偏差
不必向上级管理者报告的允许偏差
容许偏差分配 遵循4层次
公司或项目群管理层、项目管理委员会、项目经理、小组经理
容许偏差控制 涉及6方面
项目时间、成本、质量、范围、收益、风险
不使用容许偏差 后果
遇任何偏差项目经理均上报，项目经理不作为
委员会负担变重，自然不满意
项目经理只监督工作，浪费
遇任何偏差项目经理直接纠偏，项目经理作为
委员会质疑项目经理为什么不上报，项目经理可能超职权范围，存在风险
项目经理出力不讨好
授权
管理的4个层次
控制对象
项目层次上进行总体控制
偏差权限
项目允许偏差
超出偏差应对
项目委员会将偏差提交给公司或项目群管理层
一个管理阶段
项目管理委员会规定的允许偏差内
项目经理将偏差提交给项目管理委员会
一个工作包
项目经理预先约定的工作包容许偏差内
小组经理将偏差提交给项目经理
项目管理委员会控制方法
授权启动、授权项目、授权阶段和最后项目收尾
收到『项目准备阶段流程』的启动授权请求，在『项目指导流程』授权启动
收到『项目启动阶段流程』的项目授权请求，在『项目指导流程』授权项目
收到『阶段边界管理流程』的评审阶段计划或例外计划批准请求，Yes 在『项目指导流程』则进行授权
收到『项目收尾流程』请求，Yes 则评审项目竣工报告，在『项目指导流程』授权收尾
进展更新
例外与变更
例外报告
项目经理控制方法
『阶段控制流程』待完善
小组经理/团队成员的检查点报告
项目登记单
记录单
用管理阶段来控制
阶段的数量
至少两个阶段，项目启动阶段+其他阶段
由 项目性质 和 项目持续时间 决定
阶段的长度
影响阶段长度的因素
任何时间点的规划周期
项目内的技术阶段
与项目群活动取得一致
风险水平
技术阶段
根据所应用的技术或者创建的产品来作为工作分类，比如：设计、建造、施工
技术阶段经常重叠
事件驱动控制方法、时间驱动控制方法
概念
时间驱动控制
事件驱动控制
两者管理产品
进展控制基线
来源
工作包
评审进展
风险登记单
进展评审技术
里程碑图
S曲线
挣值管理
向前看：有什么需要做、什么时间做、需要什么资源
向后看：计划和实际进展进行比较
捕获和报告经验教训
经验教训记录单
报告进展
(小组)检查点报告
小组经理 提交给 项目经理
(阶段)要点报告
项目经理 提交给 项目委员会
项目竣工报告
提出例外
工作包层次的例外
超级允许偏差，上报上一层次
阶段层次的例外
项目层次的例外
流程
P2 流程
项目前期
启动阶段
后续交付阶段
最后交付阶段
P2 流程模型
项目准备流程
做最少而有必要的事情，判断确保项目启动的先决条件是否已经具备？
防止不合理的项目启动
批准可行的项目启动
目标
确保
存在项目启动的业务验证
存在启动授权
不要浪费时间启动不正确假设为基础的项目
确定
评估『项目交付方式』，选择『项目方法』
信息充足以定义确定『项目范围』
任命『项目主管』和『项目管理团队』
编制项目启动所需『工作计划』
环境
『任务书』，项目的触发因素，由『公司或项目群管理组织』提供。在流程中进一步完善形成『项目概述文件』。
『项目概述文件』『概要商业论证』，需要项目经理、项目管理委员会、利益相关方经常/定期交流，明确需求。
活动可能需要 公司或项目群管理层、项目主管、项目经理共同承担
任命项目主管和项目经理
评审项目任务书，检查理解
任命项目主管，通常由公司或项目群管理层授权
任命项目经理，通常由项目主管任命
创建日志作为项目信息的资料库，目的: 保存没有记录在其他管理产品中的信息。
捕获以前的经验教训
形式
推荐：专题研讨会
参与人员：感兴趣的相关方，在以前类似项目中工作的人员
行动
创建『经验教训记录单』
评审 类似项目 的经验教训报告
评审 公司管理、项目群管理、外部组织 的经验教训
咨询 个人/团队 类似项目经验
把所有识别的经验教训记录到『经验教训记录单』
设计和任命项目管理团队
每人了解同意：谁对谁我为什么负责，谁负责什么，什么是报告和沟通路径
评审相关经验教训
设计项目管理团队
准备项目管理团队结构
项目委员会 角色描述
项目保证 角色描述（合适）
小组经理 角色描述（或 PM 兼任）
项目支持 角色描述（如果 PM 需要）
确认报告和沟通路径
任命项目管理团队
估算 角色 的所需时间和工作量
识别 角色 的候选人，提名合适人员
将已识别的任何风险加入日志中
准备概要商业论证
提出一个高层次的观点，说明为什么这个项目值得去做
项目主管，根据对项目的了解，(授权pm或自己)起草概要商业论证
项目经理，咨询高级用户、项目主管，定义项目交付什么，创建『项目产品描述』
评审记录在日志中的风险，总结影响项目可行性的 关键风险
选择项目方法和汇总项目概述文件
评估可能的交付解决方案，并决定合适的交付项目产品和完整概要商业论证的项目方法
内部开发 or 外包
对已有产品修改 or 从零开始
汇总项目概述文件
定义项目
整合概要商业论证
整合项目产品描述
整合项目方法
评审项目管理团队结构、角色描述，识别工作所需角色和技能
整合项目管理团队结构、角色描述
使用日志记录任何新的问题/风险
编制启动阶段计划
根据项目方法，决定合适的管理控制，以便项目启动
识别任何启动阶段事件和成本限制，编制『阶段计划』
评审记录的风险，评估对启动阶段计划的影响
识别到新风险则更新日志
请求启动授权
项目指导流程
进行 启动授权、项目授权
进行 项目产品交付授权
管理项目方向，进行控制，保证项目可行
『公司或项目群管理层』与『项目』之间界面接口
进行 项目收尾授权
管理和评审实现项目后 收益计划
项目委员会导向
授权启动
评审和批准『项目概述文件』
评审和批准『项目产品描述』
验证『概要商业论证』能够表明项目的可交付性
评审和批准启动阶段的『阶段计划』
通知『所有利益相关者』和现场项目正在启动，申请后勤支援
授权项目经理进入启动阶段
授权项目
评审和批准『项目启动文件』
评审和批准『收益评审计划』，确定他处理了所有的预期收益，满足公司和项目群管理的需要
通知『公司或项目群管理』其他感兴趣的相关方，已获得项目授权
授权项目经理开始实施项目，或指导提前结束项目
授权一个阶段/例外计划
解释
『项目委员会』评审当前阶段绩效，批准下一阶段阶段计划，授权下一管理阶段
如果阶段中发生意外，『项目经理』提交一份『例外计划』给『项目委员会』，等待批准，若例外被批准将成为阶段新基线
评审和批准『阶段竣工报告』
确定项目绩效，要求pm解释偏差，预测未来绩效
检查风险摘要，确保风险是可接受的
（如果有）处理产品的分期移交
评审项目经理请求批准的『阶段计划/例外计划』
评估可行性、可实现性
评审批准新的产品描述
确认(被更新的)项目启动文件足用以项目剩余部分
验证(被更新的)商业论证 可行性
评审和批准(被更新的)收益评审计划，确保下个阶段将取得收益的测量评审
制定决策
批准计划，授权pm按计划行驶
获得/承诺所需资源
设定批准计划的容许偏差
要求pm对不合格的计划进行修改，直到计划可接受
指导pm对项目提前收尾
与公司或项目群管理层沟通项目状态，使其他感兴趣的相关方保持对项目的了解
给予特别指导
应对『非正式建议和指导』的请求
如果必要，向『公司或项目群管理层』提出请求建议
根据需要协助pm，可能包括要求pm完成问题报告/例外报告
应对上报的『问题报告』
在职权范围内
要求例外计划/提供指导
批准
延迟
拒绝或要求更多信息
授予特权
应对『例外报告』
增加偏差范围
指示pm编制『例外计划』
指示pm提前结束项目
对例外的评估推迟一段固定时间
应对收到『要点报告』
评审要点报告以理解项目状况
确保项目始终保持商业论证的合理性
确保『阶段计划』按计划进展
确保『公司层和感兴趣的相关方』保持对项目进展的了解
采取必要的行动
应对来自公司或项目群管理层的『建议或决策』
确保『项目管理团队』保持对外部事件的了解
通知 pm 任何可能影响项目的变化，并确保采取适当行为
授权项目收尾
评审『项目启动文件』最初版本和当前版本
评审和批准『项目竣工报告』
确认『谁』收到后续实施建议，比如：运营维护部门
评审『经验教训报告』，分享
验证项目产品的移交符合『配置管理战略』
确保项目后收益评审是否有任何副作用
评审和批准更新的『收益评审计划』
确认更新到『商业论证』
按照沟通管理战略发布『项目收尾通知』
项目启动流程
使组织在承诺大笔投入前，能够了解为了交付项目产品需要完成的工作，为项目建立坚实的基础
开展项目的理由、预期收益、相关风险
工作的范围、交付的产品
项目产品将如何、何时、什么价格交付
谁将参与项目决策
如何达到要求的质量
如何建立和控制基线
如何识别、评估、控制风险问题和变化
如何监督和控制进展
谁需要信息，什么时间，什么格式
项目管理方法将如何根据项目进行剪裁
准备『风险管理战略』
描述
描述了应用风险管理的目标、使用的步骤、角色和职责、风险容许偏差、风险管理活动的时机、将要使用的工具和技术以及报告的要求。
评审『项目概要文件』了解公司层的风险管理相关的所有战略、标准、实践是否需要应用于项目
吸取有关风险管理的经验教训
评审日志中有关风险管理的所有问题和风险
定义风险管理战略
咨询项目保证，检查所提出的风险管理战略是否公司层满意
据风险管理战略创建『风险登记单』，将『日志』中的风险转录上去
请求项目委员会批准『风险管理战略』
准备『配置管理战略』
评审『项目概述文件』，以便了解公司层与之相关的战略、标准、实践
吸取有关的经验教训
评审『日志』『风险登记单』中相关问题的风险
定义配置管理战略
咨询项目保证，检查提出的战略是否满足公司层需求
创建初始的『配置项记录』
创建『问题登记单』考虑日志中已记录的问题是否需要正式管理
如果识别到新的风险/问题，更新『风险登记单』『问题登记单』
请求项目委员会批准『配置管理战略』
准备『质量管理战略』
任何项目成功的关键在于是否能够提供客户所期望并愿意接受的交付物
『质量管理战略』确保了这些商定的一致意见得到记录和维护
评审『项目产品描述』以理解客户质量期望，并检查『项目验收标准』是否被准确定义
评审『问题登记单』『风险登记单』中相关问题的风险
定义质量管理战略
创建『质量登记单』准备记录所有质量活动的细节
请求项目委员会批准『质量管理战略』
准备『沟通管理战略』
关注内部和外部两个方面的沟通，包含如何发送与接受信息的详细信息。
识别和评审『利益相关方』，并咨询他们的信息需求
识别期望的关系
澄清关键的沟通讯息
确定成功的沟通所产生的理想成果
建立与质量管理战略、风险管理战略、配置管理战略，相关的信息需求
定义『沟通管理战略』
请求项目委员会批准『沟通管理战略』
建立项目控制
评审『质量管理战略、配置管理战略、风险管理战略、沟通管理战略』，以便确定需要建立哪些控制
确认并记录提供适当水平的控制所要求的『管理阶段边界』
将项目所要求的各个层次的决策分配给最是当的项目管理层次
(合适的情况下)将『决策权和职责』更新『项目管理团队结构』『角色描述』
确认项目的『容许偏差』『上报流程』
在『项目启动文件』中简要说明项目控制
请求项目委员会批准『项目控制』
编制『项目计划』
pm 在用户们、供应商们紧密配合下共同完成
评审『项目概述文件』
确定项目计划的『格式』、『表现形式』，以便面向受众
识别项目将使用的『编制计划』『控制工具』
选择『估算项目计划的方法』
评审『质量管理战略、风险管理战略、配置管理战略、沟通管理战略』了解所需的资源、标准、方法、成本
创建主要产品 的 产品分解、产品流程图、产品描述。确定将产品移交至运营过程的安排。
更新『项目产品描述』
创建/更新要交付的每项产品的『配置项记录』
识别并确认所要求的资源，识别候选人
识别项目控制的活动、资源、时间安排，并包含在计划内
识别与计划相关的风险
编制项目计划文件
请求项目委员会批准『项目计划』
完善商业论证
概要商业论证：以反应时间、成本、风险、收益
根据获得的其他信息，创建详细的商业论证
项目计划中计算的成本和时间
影响项目可行性、可实现性的主要风险
将要取得的收益
每项收益的容许偏差
创建『收益评审计划』
评审商业论证、检查对项目期望的理解
确定如何测量所取得的每项收益，基线的测量方法
确定收益评审的时间安排
如果项目是项目群的一部分，该计划可能已经在项目群层次被创建维护
咨询项目保证，检查提出的是否满足公司层需求
请求项目委员会批准『商业论证』『收益评审计划』
汇总项目启动文件
汇总在项目启动文件内的信息，含有\"什么、为什么、谁、如何、哪里、什么时间、多少\"
保存授权的项目启动文件版本，作为被比较的手段，对项目『实际绩效』『最初批准基础』的比较
选用(修改)『项目概述文件』中的信息
项目定义
项目方法
包含/参考下列文件信息
项目管理团队结构、角色描述
包含/参考 项目控制，总结项目使如何剪裁
汇总『项目启动文件』
检查不同部分信息，确保内容协调性
准备下一个阶段（将触发阶段边界管理流程）
向项目管理委员会提出项目实施请求，以获得项目授权
阶段控制流程
分配需要完成的工作，监督这些工作处理问题
向项目管理委员会报告进展
采取纠正性行动来确保保持在容许偏差范围内
以交付阶段产品为重点，监督方向
『风险』『问题』保持在受控状态
『商业论证』持续评审
在商定的成本、工作量、时间内，按质量标准，交付阶段产品，取得收益
项目管理团队专注于(容许偏差范围内的)交付
项目经理视角，pm如何处理日常管理工作，适用于项目中的每一个交付阶段。(可适用于较长启动阶段的复杂项目)
日常控制由以下循环组成
对需要完成的工作进行授权
监督工作进展
评审状态，并出发新的工作包
报告要点
观察、评估、解决问题和风险
采取纠正性行动
最后一个阶段临近结束时，触发项目收尾流程
授权工作包
检查当前管理阶段的『阶段计划』，了解->
要生产的产品
预期消耗的成本和工作量
可获得的容许偏差
检查『项目启动文件』来了解
要求的项目控制(进度报告安排)
质量管理战略中定义的『质量标准』
定义每个将要授权的工作包
工作包产品描述、使用的技术、开发接口、运营维护接口、工作量、成本、时间、里程本、容许偏差、限制条件、配置管理要求
定义报告、问题处理、上报的安排
定义批准方法
提供相关参考
与小组经理一起评审工作包，确保小组经理接受工作包，授权小组经理开始工作
评审小组经理的『小组计划』，并更新『阶段计划』反应授权工作包的时间安排
更新『配置项记录』反应授权工作包的内容
根据计划的质量管理活动，更新『质量登记单』，咨询项目保证确认可接受
(如果必要)更新『风险登记单』『问题登记单』
评审工作包状态
1.从检查点报告中捕获并评审正在执行的工作包
评估未完成工作所需的时间和工作量评估
评审小组计划(与小组经理)，确定工作是否能按预算和时间完成
评审『质量登记单』的条目，了解质量活动现状
确认每个产品的『配置项记录』与他们的状态一致
2.更新如下
(有必要的话)风险登记单、问题登记单
『阶段计划』
接收已完成的工作包
确保小组经理完成(工作包内定义的)工作
检查质量登记单中，与已完成产品 相关的条目的 完整性
确认更新了每一个产品的『配置项记录』
更新『阶段计划』，显示工作包已完成
评审阶段状态
评审阶段进展
评审『检查点报告』
评审当前阶段的预测和实际情况
(向项目支持)申请一份『产品状态陈述』，以便识别项目进展、报告进展、实际进展之间的偏差
检查『质量登记单』中表明的质量问题
检查『风险登记单』中新的风险，评估对商业论证、阶段计划、项目计划的影响
检查『问题登记单』中的事件，评估对商业论证、阶段计划、项目计划的影响
检查纠正性行动状态
评估『资源使用情况』，保证剩余资源的可获得性
检查『收益评审计划』
根据上述分析，决定是否要采取任何行动，例如->
报告要点，按照『沟通管理战略』
捕获/检查 问题、风险
上报 问题、风险，如果超出容许范围
请求项目委员会的建议
记录已识别的经验教训
按计划继续进行
如果必要，修改风险登记单和问题登记单
如果评估改变了原有策略
更新『阶段计划』
阶段性移交中，如果任何产品的所有权将要转移给客户
为将移交的产品申请一份『产品状态描述』
产品获得批准(按产品描述)
产品符合所有质量标准(或获得特许)
运营/维护已经准备好承担 接收产品的责任
移交产品
如果临近阶段结束
为下一阶段准备
如果临近最后一个阶段结束
准备收尾项目
pm向项目委员会提供有关阶段和项目状态的简要报告
按照沟通管理战略中的沟通频率，向利益相关方分发信息
汇总该阶段重要更新
汇总该阶段采取的纠正行动清单
回顾以前的要点报告
完成当前要点报告
向人员(沟通管理战略内规定)发送要点报告
捕获并检查问题和风险
项目经理非正式管理的问题，去做，在日志中注解
需要正式管理的问题( 参加变更主题 )
对于风险( 参见 风险 主题）
上报问题和风险
提前通知项目管理委员会，预测例外情况以便有所准备
以『例外报告』形式支持信息
目的是为了在阶段/项目容许偏差范围内，选择并实施能够纠正偏差的行动
项目的变更和调整，即使看起来很容易管理，也需深思熟虑和合理的方式进行
产品交付管理流程
提出有关接收、执行、交付项目工作的正式要求
项目经理 和 小组经理联系
分配给小组的工作包经过授权和商定
小组经理、小组成员、供应商要清楚将要『生产什么、预期工作量、成本、时间是什么
产品将在容许偏差范围内交付
按照商定频率向pm汇报沟通
从小组经理的视角看待项目
接受工作包
评审工作包
获得参考文档
与pm澄清将要交付什么
代表小组和pm协商完成工作的限制条件
同意『容许偏差』
了解『报告需求』、产品如何从哪获得批准、产品交付方式
确认如何向pm报告工作包完成
编制『小组计划』，表明产品可以在限制条件下完成，并申请必要的批准
针对『小组计划』进行风险评审，通知pm任何风险变化(如有登记单权限则更新)
同意 交付的工作包
执行工作包
管理所要求产品的开发
通知pm 任何新的问题、风险、经验教训，由pm决定适当的应对行动，采取pm所要求的行动
为完成的产品 获得批准
评审，向pm报告工作包状态
交付工作包
评审『质量登记单』，验证所有质量活动已经完成
评审『批准记录』，验证所有产品已获得批准
更新『小组计划』表明工作包已完成
检查工作包，遵循交付已完成的工作包步骤。通知pm工作包已完成。
阶段边界管理流程
项目经理导向
编制下一阶段计划
编制计划不是一个孤立的活动。pm需咨询管理委员会、项目保证、小组经理、可能得利益相关方，编制一个可行的计划。
越多人参与编制计划，该计划越可行
评审『项目启动文件』的组成部分
编制下一个阶段的『阶段计划』
为下一阶段要生产的产品创建『配置项记录』
如果新问题/风险被识别，更新『问题登记单』『风险登记单』
为计划的质量管理活动更新质量登记单（包括产品的目标评审日期和批准日期）
更新项目计划
检查当前的阶段计划是否符合最新的实际进展
评审项目计划以反映当前实际情况和下阶段预测
更新商业论证
检查所涉及组织的『风险偏好』和『风险承受能力』是否有变化，『风险容许偏差』是否需要重新定义。
使用『风险登记单』评估项目的风险，以确定项目面临的总体风险，并识别目前商业论证的关键风险。
根据收益评审的结果，更新『收益评审计划』
修改『商业论证』，(如有必要)修改『收益评审计划』以获得项目委员会的批准
根据需要更新『风险登记单』『问题登记单』
报告阶段竣工
pm 向 委员会报告阶段结果，pm 给出项目能否持续满足项目计划和商业论证的意见，并评估总体风险状况
编制例外计划
例外计划是项目委员会 应对 例外报告时所要求的
项目收尾流程
提供一个固定点，来确认对项目产品的验收
核实用户验收了项目产品
确保项目团队解散时，项目现场组织能支持产品
根据基线，评审项目绩效
评审已实现的收益，更新剩余收益预测，并为这些尚未实现的收益编制『收益评审计划』
确保在后续行动建议中做好准备，处理尚未解决的问题和风险
A. 准备按计划收尾
在『建议项目收尾』之前，pm务必确保预期结果都已实现并交付并达到验收标准
请求批准，以便通知公司层，相关资源已经可以/即将释放
B. 准备提前收尾
在『项目收尾』之前，项目产品必须移交到『运营和维护环境』中。
咨询管理团队，为项目产品准备后续行动给出建议
某些收益直到项目产品在日常运营一段时间后才能测量，所以，检查确认『收益评审计划』中包含了测量这些收益的项目后活动
检查『配置管理战略』以确认产品如何移交给哪些在运营中的维护人员
评价项目
目标是评估项目如何成功，如何失败，从项目经验中学习。
建议项目收尾
一旦pm确认项目可以结束，就应该向项目管理委员会提出『项目收尾建议』
使用『沟通管理战略』识别需要知道项目收尾的组织/相关方
关闭『项目问题登记单』、风险登记单、质量登记单、日志和经验教训记录单
保存/归档所有项目信息，以便将来审计项目管理团队的决策、行动、绩效
准备发送『项目收尾通知初稿』，提交项目管理委员会评审，声明项目已结束
P2 流程章节结构
每个流程描述采用的结构和格式
指项目发生的环境，包括：项目内环境、项目外环境
流程由一组(顺序或并行的)活动组成
活动由(为获得特点结果而设计的)推荐行动组成
根据环境剪裁
0 条评论
回复 删除
下一页
