首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

《PMP精讲视频》第5章 项目范围管理

第5章 项目范围管理

  • 49个过程占了6个过程

项目范围管理

目标

  1. 要做什么?
  2. 只做什么?

范围管理包括

  1. 产品范围:产品、服务或成果所具有的特性和功能,看得见摸得着的可交付成果
  2. 项目范围:为交付产品、服务或成果而必须完成的工作。为了实现这些可看得见摸得着的产品所做的管理工作,如要编制的计划、制定预算、控制偏差,做得变更的管理

范围管理过程

  • 确保:项目团队、项目发起和和项目相关方,对项目的可交付成果,以及对形成这些可交付成果所进行的工作达成共识

不同生命周期的范围管理对比


收集需求

范围与需求

  • 需求是客户希望你给他做到的
  • 范围管理:自己要做的工作

需求跟踪矩阵(记录需求的工具)

  • 需求管理计划的一个主要内容

项目团队要做的工作

  • 范围管理计划,要定义如何描述我们如何去做的工作,让团队成员有一个清晰一致的认识
  • 包含一些工具
  1. WBS工作分解结构
  2. 范围说明书
  3. WBS词典

需求是他想要的,范围就是我们要做的 项目经理流的泪就是需求分析脑子里进的水!

收集需求

  • 需求就像是冰山一角,下面还有很多坑(可能不懂专业说不出来、没法说、不敢说、不能说)

头脑风暴Brain Storming

  • 也叫诸葛亮会议,每个人都可以发表自己的看法,互相启发、互相激励,争取能够把大家的经验挖掘出来,帮助识别项目的需求

访谈Interview

  • 拿本子拿笔去谦虚的请教你需要了解他需求的这个人,希望这个项目做成什么样对你工作最好帮助

焦点小组Focus Group

  • 最重要的特点:必须非常聚集针对某一个主题

问卷调查Questionnaire

  • 特点:量大面广

标杆对照Benchmarking

  • 来自于美国的施乐公司,施乐公司老板买下竞争对手产品,拆开一个个零件对比,不断学习提升自己的能力

需求决策与表现

  • 决策:什么需求需要被满足,什么需求可能我们只能说服我们的客户,让他做出一定的取舍。不只一个人说了算,很多人发表意见,最后拿出最终的结论
  • 决策过程用到的工具

投票(最常用)

  • 奇数比偶数好,奇数当中质数最好
  • 分类
  1. 一致同意
  2. 大多数同意(超过50%)
  3. 相对多数同意

独裁

  • 在一个非常紧急情况下,没有办法充分发挥民主,需要快速果断做出决策

多标准决策Multi-criteria decision analysis(MCDA)

  • 公司要上ERP系统,请拿出一个选择方案?ERP厂商有很多。如价格、特点、行业、适配性等。在很多领域都会用到,如评标阶段

数据表现

亲和图 Affinity Diagram 川喜田二朗

  • 通过不同颜色区分不同的需求

思维导图Mind Map


人际关系与团队技能

  • 当我们识别出很多需求,哪些满足、哪些放弃,需要团队成员一起协商,共同商议这个结论,怎么组织这些人去协商这样的需求呢?

名义小组Nominal Group Technique NGT

  1. 小组成员先不通气,独立思考
  2. 各自写下备选方案和意见
  3. 轮流陈述自己的方案和意见
  4. 小组成员对全部备选方案投票
  5. 得票最多的备选方案入选
  6. 当然,管理者仍有权否决这一方案
  • 头脑风暴鼓励大家畅所欲言,名义小组刚好相反,实际上各自表达自己独立的见解,减少相互之间的影响

观察法Observation

  • 有些需求没法通过问卷调查、访谈去识别和发现,只能自己去看

如富士康跳楼事件,跳楼的人回答不了你,准备跳的人不会回答你

引导式研讨会Facilitated workshops

  • 把各种专业、各部门的人都叫在一起,针对项目需求做分析,结合大家的意见,特征:跨部门跨专业,必须有一个主持人,引导各专业各部门的人发言

需求的呈现

用户故事User Story

  • 敏捷项目当中非常常用的工具,有一个固定的语法

As a , I want to , so that . 作为一个<角色>,我想要<活动>,以便于<商业价值>

  • 如:作为一个微信用户,我希望有一个不限制人数的版本,以便于我只需要带一个手机
  • 已帮定的语法把用户的需求把它表述成统一的格式,以便于我们所有项目团队成员去识别,并且分析和执行它

系统交互图System interaction diagram

原型法Prototype

app原型设计

  • 非常有利于跟客户需求确认的一个方法

故事板Story Board

  • Visual Script:可视化剧本

需求文件与需求跟踪矩阵

需求跟踪矩阵Requirement-Trace Matrix

  • 把历史上发生过的需求识别、记载、变化都能踏实的把它记载下来,以便于我们去跟踪和管理

Scrum 敏捷开发框架

  • 都应该把每条翻译成用户故事,写到Backlog里

项目范围说明书

项目章程 vs. 项目范围说明书

可测量的项目目标和相关的成功标准——验收标准 高层级项目描述、边界定义以及主要可交付成果——项目可交付成果

  • 为什么会有两个一样的东西呢?因为这就是一个渐进明细的过程。在章程当中是粗略的要求,而到了范围说明书是具体详细的定义。在章程是有高层级三个字,高层级低层级这样的词汇经常出现,指的是都是WBS工作分解结构

工作分解结构Work Breakdown Structure

范围基准

  1. 项目范围说明书
  2. 工作分解结构WBS
  3. WBS词典
  • 这里容易出考题

以下哪一个不是范围基准组成的文件?

  1. 范围说明书
  2. 工作分解结构WBS
  3. WBS词典
  4. 需求文件
  • PMP如果有排比、并列的词汇,很容易出考题

工作分解结构WBS及WBS词典

  • 工作包:一起拆分到很清晰很容易描述多少时间和资源、成本的单元

工作分解结构WBS

  1. 子项目(Subproject)
  2. 控制账户(Control Account):一个项目在公司财务体系中,一定会给我们设置一个账,我们设置的预算,一个项目在财务那就一个账户,所有的预算都记在这一个账号里,混在一起其实不便于管理。如果一个账户拆分几十、上百个工作包,每个工作包都设置一个账户的话也太多了,需要取一个合适的度
  3. 工作包(Work Package):最低层次单元,在这个单元就可以很清晰评估资源、成本、时间,也是项目经理管理到的最低单元,也不是说就不能再分了,工作包再往下分就是活动。如支付系统的工作包,下面还有各种各样的活动
  4. 规划包(Planning Package):和工作包一个层次,在做分解时(在做计划阶段),这事迟早要做,但现在不用做或没法评估工作,就先把这个坑占上
  5. 活动(Activity):
  6. 任务(Task):活动再分就是任务

规则:工作包到项目经理,活动到执行团队,任务到个人

WBS词典

  • 分类
  1. 树状分解WBS
  2. 目录式分解WBS
  • 不管怎么分解,都会有一个唯一的编号

针对每个WBS组件,详细描述可交付成果活动和进度信息的文件

  • WBS词典信息
  1. 控制账户
  2. 工作包名称和编号
  3. 负责人
  4. 交付成果描述
  5. 验收标准
  6. 完成日期等
  • 有多少工作包就有多少词典,WBS词典就是配合WBS工作用的工具

RAM责任分配矩阵

  • 工作包和人两个维度建立起了关系。每一行有且只有一次黑色三角形,这个负责人必须是唯一的,

WBS工作分解结构的价值

  • 项目管理当中是最最重要的一项工具
  • 基准的来源 后面2个基准要根据范围基准来,范围基准最核心的是WBS,无论是进度计划、成本、风险、质量、沟通等等都要依赖WBS来制定
    1. 范围
    2. 进度
    3. 成本
  • 计划的基础
  • 工作的展现:清单没有层次,WBS结构化、层次化展示项目工作的全貌
  • 控制的依据
  • 团队的指南:把大型复杂的项目变成一个个可控的工作单元,对工作有个清晰和统一的认识

确认范围

  • 每完成一个可交付的成果都应该和甲方进行确认,确认这个工作是满足客户想要的要求。如果做的不是客户想的东西,还是请求一个变更,争取更多的时间和人手,改到满足客户的需求为止,客户认可了需要客户签字确认,这件事情就靠一段落了。这个动作一定要及时做,不能积攒,必须分期分批化整为零的及时把它解决掉

如何防止范围蔓延

范围蔓延

  • 镀金 vs. 爬行
  • 镀金:客户没要求,是自作多情,没事找事,画蛇添足的增加一个功能
  • 爬行:我们不想加功能,客户频繁提出需求,被迫加功能,工作量增加了,范围扩大了
  • 共同点:都是范围发生了改变,都没有经过变更整体控制程序。没有经过变更控制程序发生的改变,就要消耗相对应的资源,这些资源和时间是没有人认可你的。一次是可以,因为项目经理在预算当中也有一笔叫做不可预见费,两次也还勉强,一起这样下去,储备是很有限的,没办法覆盖所有的变更,导致整个项目延误和成本超支。在项目当中所谓的工期延误和成本超支很多原因都是范围失控造成的,做了一些本来不做或可做可不做的事
  • 镀金和爬行统称为范围蔓延。范围蔓延是指范围发生了改变,但是却没有整体变更控制程序而产生的这样的不良的影响

范围蔓延该怎么办?

  • 镀金产生的原因?
  1. 讨好客户
  2. 配置强迫症:有时对某些功能的升级,就会觉得其它的功能也会升级,导致做了很多无谓的工作,增加了很多的成本和资源
  3. 秀才艺

做任何超出范围的事情都有代价

  • 一个规范的变更控制流程是保护我们项目经理和项目团队的一道防火墙。我们应该促进我们公司项目管理走向规范化制度化信息化,这样才能在项目管理当中取得主动,防止项目范围的蔓延

范围管理学习要点

  1. 不同类型生命周期范围管理的区别
  2. 需求识别的工具与技术:识别它们之间细微的差别,了解每种工具和方法的特征和适用的场景
  3. WBS分解的原则和逻辑:出题非常密集,了解WBS当中有多少种元素,分别代表什么含义
  4. 确认范围的时间(不同生命周期类型):不同生命周期范围确认是不一样的,都有一个共同的规则,一定要及时确认、不能积累
  5. 范围蔓延(镀金、爬行)
下一篇
举报
领券