导图社区 PMP:项目整体管理
本图内容为信息系统项目管理师十大管理之整体管理。做项目总是会涉及不同的人,需要调度多样的资源,如果这一切都非常充足倒是非常好办。可是更多时候是这些资源无法满足需要。这就需要进行协调,甚至需要在矛盾或者竞争是寻找平衡点。整合管理就是协调与统一,以努力满足项目各项目平衡。进而可以进行科学的取舍。整合管理的负责人必须是项目经理,项目经理必须通过整合管理对项目形成全局观。进而对后面的工作做到胸有成竹。
学习笔记分享!信息系统管理工程师需要学习的十大管理过程之整体管理。整体管理的流程又依次分为:制定项目章程、制定项目管理计划、指导与管理项目工作、监控项目工作、实施整体变更、结束项目或阶段六大模块。希望从事信息管理工作的伙伴记得学习收藏哦!
社区模板帮助中心,点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
范围管理
规划范围管理
编制范围管理计划,描述如何定义、确认和控制范围的过程
输入
项目章程
记录项目目的,目标及测量标准,项目概述,假设条件,制约因素,以及项目意图实现的高层次需求
项目管理计划
质量管理计划
在项目实施组织的质量政策,方法和标准的方式,会影响管理项目和产品的方式
项目生命周期描述
项目从开始到结束所经历的一系列阶段
开发方法
瀑布式
迭代式
适应型
敏捷型
混合型
事业环境因素
组织过程资产
工具和技术
专家判断
会议
输出
范围管理计划
描述如何定义、制定、监督、控制和确认项目范围
如何制定范围说明书
如何根据范围说明书创建WBS
如何维护批准WBS
如何确认和验收可交付成果
如何处理范围说明书变更
需求管理计划
描述如何分析、记录和管理项目和产品需求
如何规划、跟踪和汇报各种需求活动
需求管理需要使用的资源
培训计划
项目干系人参与需求管理的策略
判断项目范围与需求不一致的准则和纠正规程
需求跟踪结构,即哪些需求属性列入跟踪矩阵并可以在哪些文件中追踪到
配置管理活动
收集需求
为实现项目目标而确定、记录并管理干系人的需要和需求的过程
干系人管理计划
干系人登记册
访谈
焦点小组
主持人引导
引导式研讨会
跨职能需求、协调干系人
群体创新技术
头脑风暴法
庭外判决、各抒己见、追求数量、取长补短
名义小组技术
分组讨论、逐个询问、评审排序
德尔菲技术
优点
发挥专长、集思广益
表达分歧,扬长避短
最有效的判断预测法
防止个人观点被不正确的放大
缺点
碍于情面,不愿意发表不同意见
出于自尊,不愿意改正原来不全面的意见
过程复杂,花费时间长
概念/思维导图
将头脑风暴获得的创意,通过图片反映创意的共性与差异
亲和图
正对问题,充分收集资料,汇总归纳
多标准决策分析
借助决策矩阵,评估排序
群体决策技术
一致同意、大多数原则、相对多数原则、独裁
问卷调查
观察
原型法
标杆对照
系统交互图
对产品的可视化描述,显示系统与参与者的交互方式。
文件分析
需求文件
业务需求、干系人需求、解决方案需求、项目需求、过渡需求,相关的假设条件依赖关系制约因素
需求跟踪矩阵
将产品需求从来源连接到满足需求的可交付成果的一种表格
范围定义
制定项目和产品详细描述的过程
产品分析
备选方案生成
制定更多的潜在可选方案的技术,用于识别项目工作的不同方法
项目范围说明书
内容
产品范围描述
验收标准
可交付成果
项目的除外责任、制约因素、假设条件
作用
确定范围、沟通基础、规划和控制依据、变更基础、规划基础
项目文件更新
创建WBS
将项目可交付物和项目工作分解成较小的、易于管理的组建的过程
事业环境因素、组织过程资产
分解
活动
识别和分析可交成果及相关工作
确定WBS的结构和编排方法
自上而下逐层细化分解
为WBS组件制定分配标识编码
核实可交付物分解程度是恰当的
原则
在各个层次上保持项目完整性,避免遗漏必要的组成部分
一个工作单元只能从属于某个上层单元,避免交叉从属
相同层次的工作单元应该有相同性质
工作单元能分开不同的责任者和不同的工作内容
便于项目管理进行计划和控制的管理需要
最底层的工作应有可比性、可管理、可定量检查的
应包括项目管理工作,包括分包工作
功能或技术原则、组织结构、系统或者子系统。
最底层应该是工作包
注意事项
必须是面向可交付物
必须符合项目范围
WBS底层应该支持计划和控制
WBS元素有且只有一人负责
WBS应控制在4-6层,每个工作单元不能交叉从属
包括分包工作
所有干系人、项目成员参与
WBS不是一成不变的
分解方式
生命周期各阶段作为第二(一)层
主要可交付物作为第二(一)层
子项目作为第二(一)层
范围基准
范围确认
正式验收已完成的项目可交付物的过程
需求文件、需求跟踪矩阵
确认的可交付成果、工作绩效数据
检查
验收的可交付成果
变更请求
工作绩效信息、项目文件更新
步骤
确定需要进行范围确认的时间
识别确认范围需要的投入
确定范围正式被接受的标准和要素
确定范围确认会议的组织步骤
组织范围确认会议
意义
明确了项目的工作范围和工作内容,为提高成本、进度的估算准确度打下了基础
确定了项目进度测量和控制的基准
为进一步安排工作和任务打下了基础
范围控制
监督项目和产品的范围状态,管理范围基准变更的过程
需求管理计划、需求跟踪矩阵
工作绩效数据、组织过程资产
偏差分析
工作绩效信息
项目管理计划更新、项目文件更新、组织过程资产更新
相关知识
范围管理工作
含义
项目范围是指项目的“产品范围”(即项目业主/客户所要的项目产出物)和项目的“工作范围”(即项目组织为提交项目最终产品所必需完成的各项工作)的总和。项目范围管理是指对于项目“产品范围”和“工作范围”的全面管理,其中最为主要的是对于项目“工作范围”的管理。
明确项目边界:范围基准
经过批准的项目范围说明书
WBS
WBS字典
对项目进行监控:范围控制
防治项目范围发生蔓延
产品范围
产品或服务应包含的工作,是项目范围的基础,是产品要求的描述,是项目范围书的重要组成部分
项目范围
为了能够交付产品,所必须做的工作
项目范围的定义是项目管理计划的基础
需求分类
业务需求
干系人需求
过度需求
从当前状态过渡到将来状态需要的临时能力
质量需求
确认可交付成果的成功完成或其他项目需求的实现的任何条件或标准
工作包
位于WBS最底层的可交付成果获工作组成部分,符合8/80原则
控制账户
管理控制点。可包含一个或多个工作包,每个工作包仅属于一个控制账户。
规划包
控制账户之下,内容已知但尚缺详细活动的WBS要素,最终被分解为工作包及具体活动