医疗IT事业部PM课程系列项目范围管理ppt课件.pptx

项目经理专项培养系列课程之四项目范围管理PMP2014 02 27 项目范围管理 项目范围管理旨在保证项目做且只做完成项目所需的全部工作 它关注的焦点是 什么是包括在项目之内的 什么是不包括在项目之内的 即为项目工作明确划定边界 项目范围最常见的问题是发生范围蔓延 镀金 钓鱼 范围蔓延 该做的没做 不该做的又做了 项目范围在推进过程中不知不觉发生了偏离 镀金 未经批准私自增加产品功能 服务内容 质量要求等 做了项目本身不该干的工作 钓鱼 未经批准私自先做后谈钱 或者为了 钓 别的项目 前言 关于学习项目管理知识 国内项目经理的现状是责大权小 一个项目 自始至终 项目经理都需要为需求乱变担心 为领导改主意而闹心 为团队成员不高兴而操心 为回款困难而累心 有时候还要怕家里人嫌自己加班太多而烦心 凡此种种 不一而足 然而 项目经理这个工作也有其独特的魅力 项目实施过程中与团队一起胼 pian 手胝 zhi 足结下的兄弟情义 成功结案后来自客户由衷的赞扬与认可 以及自己心中油然而生的成就感与自豪感 这些都足以让项目经理在放过几天大假之后 再次振奋精神 迎接新的战役 项目管理修炼之道 郑柯 前言 关于学习项目管理知识 经验主要体现在一个一个的点上 而知识强调系统思维 强调原理 整体 结构 综合 强调各个点之间的综合关系 项目管理知识也可以理解为项目管理方法 要想将方法用得更好 我们需要了解其原理 结构以及各部分之间的关系 知识是从经验中提炼出来的 知识指导工作远比经验指导工作要好 我们在关注案例 场景 故事的同时 更应该关注知识 不断学习 思考 创新 前言 关于学习项目管理知识 经验 实际 优点 收获和教训体现比较明显 易学易用 拿来主义缺点 始终只是局限在别的项目 别的情况下 在你这儿就不一定适合任何一个项目无论大小 都能做出自己独特的地方 知识 理论 优点 系统思维 全面 易于激发创造性 对工作指导更大缺点 需要思考 理解并应用 费心 费力 费时间 学习枯燥 乏味 我们的培训尽可能的以理论知识为主线和基础 力求理论联系实际 力求内容丰富而生动 只是力求 更多需要大家自己去理解 项目经理的成长和培养更多是由内及外 从心而生 由心而发 前言 推荐四本书 PMBOK 纯理论 系统 全面 词句用语非常严谨 特别注重道德 项目管理核心 讲述项目管理核心思想 注重思想层面 从中西方文化差异分析我们怎么向西方学习项目管理 汪博士解读PMP考试 帮助你理解PMBOK 项目管理修炼之道 敏捷项目管理 以场景和案例为主 就像讲故事一样 出版项目管理书籍的人很多 讲项目管理课程的人也很多 内容 形式多种多样 大同小异 目的只有一个 带大家进入学习 应用的状态 前言 项目管理知识的应用 坚持 正确的方向 本文主要以PMI的项目管理知识体系指南PMBOK第五版 东软公司医疗质量体系OSSP等知识为基础和依据 结合项目管理实际工作经验进行展开 以理解项目范围管理方法及其应用 内容提要 PMI 美国项目管理协会ProjectManagementInstitutePMBOK 美国项目管理协会推出的项目管理知识体系指南ProjectManagementBodyOfKnowledge东软OSSP Organization sSetofStandardProcess组织标准过程集 OSSP的目的是在公司的各项目中建立起公共过程 支持过程的度量 持续性 并进行持续性的改进 方法的应用 应用方法不是照搬 而结合项目实际情况加以裁剪 有目的的 有选择的加以引用 服务于项目目标的实现 在方法的应用过程中不断的创新 目录 范围的重要性规划范围管理收集需求定义范围编制WBS确认范围控制范围 项目范围管理的几个过程 1 范围的重要性 项目的最终目标是为了成功 项目成功的标准是什么 项目的最终目标是为了成功 医院信息化项目成功的标准是 在计划内完工 并创造价值 项目为什么会做不完 做不好 传统三重制约 范围 时间 成本新的三重制约 范围 时间 成本 质量 风险 干系人 也可理解为六重制约主要制约因素的变化体现了质量 风险 干系人对项目成功的重要性各因素相互制约 相互影响 项目范围和时间是项目管理的关键的 重要的组成部分范围是 龙头 时间 进度 是 表象 很多项目一开始就失败了 因为没找到问题的 龙头 根 项目范围管理犹如HIS中医生站的医嘱一样 龙头没管理好 后续都会出问题 项目为什么会做不完 做不好 战略性项目 注重干系人满意度 注重质量 牺牲范围 时间 成本利润性项目 注重利润 注重范围 时间 成本 牺牲质量 干系人满意度项目目标的定位是管理层 包括客户管理层 决策的 而不是项目经理 定位决定打法 项目立项时的定位决定了项目经理对多重制约因素管理的侧重点 很多项目一开始就失败了 因为定位就不明确 项目为什么会做不完 做不好 项目管理决策 通常由项目经理负责 受限于管理层的决策组织管理决策 通常由一个组织的管理层负责 受限于市场环境因素的影响和限制 在项目管理生命周期内 组织管理决策并不是一成不变的项目经理及项目团队通常需要明白 理解项目管理过程中有些决定不是自己所能左右的 在组织管理决策下 做好自己应该做好的事 项目为什么会做不完 做不好 项目范围 合同及项目该做的事产品范围 一款产品该做的事产品的功能可能很多 但该项目中有些功能不一定必须做 约瑟夫 M 朱兰 JosephM Juran 强调质量是适合使用 提出了质量与等级的概念 菲利浦 B 克劳士比 PhilipB Crosby 强调质量是符合要求 提出零缺陷 重在预防 产品质量 同样的HIS 可以卖50 500万 项目质量 不光注重结果 更注重过程产品质量 产品特性 宁愿低等级高高质量 而不愿高等级 低质量 项目为什么会做不完 做不好 项目时间管理 确保合同 项目在规定的时间内完成 如果不能达成 则在其它几个主要方面要 开锁 范围 缩小范围以确保达成质量 降低质量以确保达成成本 提高投入以确保达成 我们医疗项目的成本主要包含人力成本和时间成本 项目之所以会亏 就是因为范围与质量不容易开锁 项目时间 进度 管理就是在做各方面的平衡和博弈 项目管理计划是综合性的计划 是整合一系列分项管理计划和其他内容的结果 用于指导项目的执行 监控和收尾工作 包括一系列的管理计划和项目基准 项目管理计划必须是科学的 现实可行的 被批准的 正式的计划 项目管理计划 1 规划范围管理 规划范围管理目的是向项目干系人说明 如何将招标 投标 合同等文件中约定的内容进一步细化 以确保清晰 详尽 可交付 特别是假设条件和制约因素的说明及对项目验收的影响 并形成书面的文档 各方签字确认 如何根据确认后的范围文档形成需要执行的工作任务树WBS 各任务有明确 可测量的可交付成果 包括假设条件和制约因素 如何变更和维护项目范围说明和WBS 如何验收WBS及项目范围说明中的可交付成果 可以是阶段验收 也可以是项目终验 项目范围说明书 WBS及相应的变更记录将做可交付成果验收的依据 它们与招标 投标 合同等文件的关系要说明清楚 由于我们这个行业的大多数客户对自己想要的产品或服务并不一定是清晰 明确的 或者说希望得到的产品或服务在将来一段时间内允许存在不确定的变化 大多数客户更愿意以招投文件及合同文件来验收 而不愿意根据 需求规格说明书 进行验收 将项目风险转移 最为关键的是客户不知道合理的变更是允许的 生怕签字后以后会有麻烦 规划范围管理过程 这样的CDR 300万你做不做 规划范围管理过程 输入 项目管理计划 在项目初期可能会有一个初步的 大概的计划项目章程 章程内容来源于招标文件 投标文件 合同文本 在OSSP中叫 项目任务书 组织过程资产 公司积累的知识资产 对规划项目范围有帮助的文件 表格 方法等输出 范围管理计划 描述如何定义 制定 监督 控制和确认项目范围 为创建项目范围说明书 创建WBS 明确可交付成果提供依据和输入 需求管理计划 描述在整个项目生命周期内如何进行需求的收集 汇总 分析 记录 评审和批准等 定义需求收集 需求分析模板 定义需求评审流程等 我们OSSP标准中的项目章程 销售或领导的口头承诺要重视 范围管理 需求管理 需求调研计划 范围管理计划 需求管理计划 需求调研计划的区别 范围管理计划 描述应如何定义 制定和核实项目范围 如何创建和定义工作分解结构 并指导项目管理团队如何管理和控制项目范围的一份文件 OSSP标准中的 需求规格说明书 只是定义 制定好的项目范围 还需要描述如何创建WBS 如何对项目范围进行核实 项目阶段验收或总体验收 如何控制范围蔓延或镀金 需要对这些进行描述和约定 范围管理计划可以是正式的 也可以是非正式的文件 OSSP中将此列为非正式的文件 所以OSSP中找不到 需求管理计划 描述在整个项目生命周期内如何进行需求的收集 汇总 分析 记录 评审和批准等 定义需求收集 需求分析模板 定义需求评审流程等 需求调研计划 描述在什么时间表 在什么地点 有哪些人参与 各种需求调研活动的责任人和可交付物 是为进度计划 需求管理计划 需求管理计划与需求调研计划的区别 需求管理计划 描述在整个项目生命周期内如何进行需求的收集 汇总 分析 记录 评审和批准等 定义需求收集 需求分析模板 定义需求评审流程等 需求调研计划 描述在什么时间表 在什么地点 有哪些人参与 各种需求调研活动的责任人和可交付物 是为进度计划 需求调研计划 2 收集需求 收集需求过程 输入 干系人登记册 记录识别干系人姓名 职位 项目角色 主要需求期望 对项目潜在影响等信息 区分支持者 反对者 中立者等 识别其对项目阶段的影响 干系人管理计划 描述为有效调动干系人积极参与 推动项目而制定的相关策略和办法 输出 需求文件 描述各种单一需求将如何满足与项目相关的需求 包括业务目标及流程 产品功能及特性 干系人需求 采用的技术标准 人员培训 项目质量 项目报告 项目绩效等需求跟踪矩阵 把需求从其来源连接到能满足需求的可交付成果的一种表格 主要实现需求实现过程的跟踪 结果的确认 需求要有始有终 这也是提高干系人满意度的重要内容 OSSP中的 需求差异跟踪矩阵 更侧重于产品 关注的软件需求实现过程 收集需求 干系人 识别干系人 范围是项目管理的龙头 而干系人则是范围的龙头 尽可能不要漏网 因为我们项目付出的代价几乎都是干系人带来的 很多干系人决定不了好事 但从中使坏是很容易的 干系人分类 关键的 非关键的 支持 潜在 的 反对 潜在 的 中立的 你喜欢的 不喜欢的 喜欢你的 不喜欢你的 即使是一头狼 你仍得与狼共舞 因为你是为了项目 分析并管理干系人 干系人需求和期望无法100 能得到满足 我们项目经理要做的就是平衡这些干系人的期望 积极调动他们 尽可能让他们发挥对项目积极的 有利的影响 收集需求 工具和技术 访谈 正式 非正式 一对一 一对多等方式交流获取需求信息焦点会议 某一个主题的互动讨论 让比较懂的人主讲 如演示 引导式研讨会 召集干系人充分参与 解决跨职能和差异性需求 如定医院流程群体创新技术 头脑风暴 投票排列 概念思维导图等 内部用 外部别用群体决策技术 一致同意 大多数同意 半数同意 独裁原型法 通过原型产品获取反馈 并进行迭代问卷调查 写好提纲 内容 通过书面远程收集需求 建议少用观察 把自己当成医生 护士实地考察 考察竞争对手情况 建议多用标杆对照 与标杆项目比较对照 获取需求 比如与盛京对照 系统交互图 将业务及产品可视化描述 侧重于技术实现细节 文件分析 卫生政策 法规 医院政策 规定等 建议多用这些我们平时可能都在用 最重要的是形成习惯 别忘了书面确认 收集需求 注意事项 由上而下 客户需求首先要体现客户想要实现的管理目标 所以需求首先是从高级管理层分解到各部门及使用人员的 我们收集需求时 要自上而下 逐层沟通 方能及时了解到正确的需求 最麻烦的上面不懂 下面懂的又决策不了 对客户说不 对于不在项目范围内的有策略的坚持说NO 对于有争议部分别着急说NO 根据项目目标 定位等实际情况评估然后上报公司决策 这不在项目经理决策范围内 特别是战略性项目 调研方法 要根据干系人期望 特点的不同而选择不同的方法 有的人喜欢听专家讲解卫生政策 标准 有的人关注解决方案思想 架构等 有的人喜欢直接看产品功能 而有的人可能什么都不看 喜欢跟你聊天 深入实际 要想充分了解干系人真正的需求 最好深入干系人的实际工作中去观察 体会 这才容易与干系人产生共鸣 才能沟通到一块儿去 要想将药品会计所关注的内容做到位 最好的办法是你将自己当成药品会计去记帐做报表 收集需求 OSSP文件 3 定义范围 项目范围说明书 是对项目范围 项目除外责任 主要可交付成果 假设条件和制约因素的描述 包括项目范围和产品范围 特别要注意可交付成果和验收标准的描述 假设条件和制约因素应尽可能的明确和详细 如静配中心系统必须在静配药房建成 相关管理制度落实后才可能实施 银医一卡通受制于银行自助设备及软件接口 因医院软件系统功能授权管理制度问题导致有可能有人统计药品处方问题而引发信息安全责任问题 不是东软的责任 项目文件更新 项目管理知识中特别强调滚动式规划 渐进明细的思想 类似于 敏捷项目管理 中的思想 前期初步规划的计划和文件在后期会得到持续的完善和更新 对其中所列优先级也是动态调整 规划并不是一成不变的 是与项目推进的实际情况相适应的 OSSP中的 项目计划 有项目范围的说明和要求 需求规格说明书 类似于PMBOK中提出的 项目范围说明书 只是更侧重于软件产品本身 同时其变更履历也体现了项目文件更新 项目渐进明细的敏捷思想 定义范围过程 定义范围 工具和技术 专家判断 理论上讲 项目范围定义人员越专业越好 特别是业务应用软件 如果对业务 产品了解不够 这样的范围会有很大问题 项目经理切记不要自己拍脑袋 不只咨询一个专家 更好的是整合多个专家的意见 产品分析 对于行业应用软件产品来说 没有标准的 固定的特性和范围 又特别是我们HIS 应用软件产品是为业务服务的 是服务于业务核心 独特竞争力的 不应放大客户对产品范围的要求 结合自身产品特点去寻求一致性 定义出一个自己当前产品不能满足的 或者将来无法做到的 那这项目就废了 备选方案 定义范围是一个谈判的过程 既然是谈判就要有备选方案 即使达成一致 也要考虑将来出现不一致的可能 引导式研讨会 我们最大的问题出总是纠缠在需求控制 项目验收的问题上 而忽略前期需求的定义 而范围 需求定义的问题更多的是缺乏引导 引导容易让人想到一块去 这是一个思路的问题 引导取决于你的实力 定义范围 注意事项 模糊与明确 理论上 大多数情况下 范围定义越明确越好 模糊化和明确化都可能给我们带来风险 所以不能教条 需要灵活把握 原则是甲乙双方均可接受 注意留下弹性的空间 概略与详细 对于范围 需求的定义 并不是越细越好 定义需要成本 执行也是需要成本的 应尽量避免定义得很好 可惜执行不下去 比如你的日程计划 关注专家意见 OSSP是标准 方法 但不是专家知识库 没有绝对的路径 套路 遵循 因为路径 套路 不可能穷尽所有的项目影响因素 多参考专家的经验和意见 在这个项目中去创造适合这个项目特点的套路 关注干系人 范围的定义要得到干系人的参与和认可 不光是客户 还包括我们团队成员 可以归结为执行工作任务的责任人 为什么要经常开会沟通 其目的是需要达成一致 4 创建WBS WBS 工作分解结构WorkBreakdownStructure 对实现项目目标 实现项目可交付成果所需的全部工作进行一种层级分解 项目的工作分解结构WBS是一个树结构 树的叶子称为最小工作包 意即不可再分的工作内容 叶子要有明确的交付成果 这颗树的枝 叶不能过多 也不能太少 过多管理成本越高 过少则不容易监控 叶子的工作量最好控制在5个工作日左右 并且有唯一的责任人 如个人日程表分解到几件事情及大概时间点较为容易 到时 分级难于执行 WBS词典 工作内容层级分解后 其相应的假设条件 制约因素 与其他工作包的关联也要附带 详尽的也可列人员 成本估算等信息 控制帐户 在这颗树的层级结点上 设一个可核算绩效的点 以使项目整体绩效能分解下去 同理 控制帐户过细 管理核算难度就会很大 成本更高 OSSP中的WBS分解直接裁剪到 项目计划 需求调研计划 开发进度计划 测试计划 实施日程计划 等各分项计划中去了 创建WBS过程 创建WBS 范围基准 创建WBS的输出范围基准 包括项目范围说明书的更新及签字确认 范围基准将做为验收的输入 依据 后续范围基准的每一项变更都需要得到签字确认 客户在验收时往往只关注招 投标及合同文件 而不关注签字的范围及变更 创建WBS 分解 创建WBS 分解 创建WBS 控制帐户 5 确认范围 确认范围过程 输入 项目管理计划 在包含了项目范围管理计划 项目范围基准 项目范围说明书需求文件 可以理解为原始需求 因为客户的需求是变化的 特别是对于大型项目需求跟踪矩阵 主要是体现干系人需求的跟踪 落实核实的可交付成果 即正确的 满足要求的可交付成果工作绩效数据 能包括可交付物与需求的偏差 及整改过程的相关数据输出 验收的可交付成果 可以理解为阶段验收 初步验收 也可以将验收的可交付成果做为最终验收 最终产品及服务移交 变更请求 范围确认后有可能还存在一些偏差需要继续改进 完善 形成变更请求以进行整改 确认范围 变更不可怕 可怕的是无序 未经批准的变更 批准一词包含了需要增加 减少预算 置换交易等 要管理好变更 6 控制范围 控制范围 关键点 主要目的 是监督项目范围和产品范围的状态 管理基准变更