项目范围管理培训课程(PPT 45页).ppt

1、1,项目范围管理,2,3,主要内容,范围管理的概念 产品范围与项目范围 项目范围管理的内容 收集需求 定义范围 创建工作分解结构 核实范围 控制范围,相应的方法与工具 收集需求的方法 访谈、QFD、问卷调查等 集思广益的方法 名义小组技术 K J 分析 工作分解的方法 相应文件模板 项目范围说明书 WBS WBS词典,4,范围管理的概念 Scope Management,5,产品范围和项目范围,产品范围：刻画某项产品、服务或结果的特性（Features）和功能（Functions）。 项目范围：为交付某项具有特定特性和功能的产品、服务或结果所必须完成的工作。 以相应产品的范围定义为基础，但是又

2、不限于产品范围，如还包括了为实现这些产品所必要的管理工作。 如果一个项目只是完成一个（大型）产品的一部分，产品范围和项目范围是交叉关系。,6,范围管理,项目范围的确定和管理影响到项目的整体成功。 首先是要做正确的项目（What），其次才是要正确地做项目（How）。 项目管理，尤其是大型项目的管理，其最大挑战就是如何将所有要完成的工作合理分解成易于执行、易于监控的工作包。 范围管理回答以上问题。,7,项目范围管理内容 收集需求 Collect Requirements,8,收集和分析市场需求,产品的成功仰赖于对市场需求的准确理解 客户表述的需求有时不十分准确 不同市场段（Market Segme

3、nt）的需求不同 移动电话：商务用户、娱乐用户、一般用户；不同地区又有区别 市场需求的时限性，机会之窗稍纵即逝 由于资源的限制，必须选择最关键的功能和特性以满足客户需求和优化投资回报 需要一整套收集和分析市场需求的方法,9,聆听客户之声（VOC）,识别客户 关键的少数与次要的多数 帕累托定律：意大利经济学家帕累托在1906年的观察， 80%的财富在20%的人的手中 80%的销售额来自20%的客户 外部客户与内部客户 最终客户与中间客户 产品使用者与经销商、代理商 隐身客户 法规监管人、公众 分析、筛选、归纳客户需求 提炼成产品特性 也要听取和参考（潜在）分包商、供应商的意见 注意隐含的（没有直

4、白表述的）客户需求,10,需求收集技术,访谈 Interviews 使用选择矩阵确定访问人和被访人 有效利用访谈资源 足够的代表性：不同类型的客户、不同角色（管理人员、技术人员等） 焦点小组 Focused Groups 引导式研讨 Facilitated Workshops 例：质量功能部署 Quality Function Deployment (QFD) 问卷调查 Questionnaires & Surveys 更大的覆盖面 观察 Observations 包括工作跟踪与参与者观察 原形 Prototypes 使干系人有机会体验实物,11,集思广益的方法（群体创新技术）,头脑风暴 Br

5、ain Storming 德尔菲技术 Delphi Technique 名义小组技术 Nominal Group Technique K J 分析法 （亲和图 Affinity Diagram）,12,群体决策技术,一致同意 Unanimity 绝对多数 Majority 相对多数 Plurality 无人反对 Consensus 独断 Dictatorship,13,名义小组技术（NGT）,方法： 确定议题，确定主持人和参与人（6至8人）； 每人分别（背对背）写下他的意见，并由高至低依次排列； 主持人要求每人轮流读出他所列出的排名第一的意见，其他人不做评论；全部读完后再轮流读排名第二的，直到

6、所有人读完所有的意见； 主持人将结果公示，并听取与会者的评论； 无记名投票选出最终的意见清单。,14,K J 分析法,川喜田二郎（Kawakita Jiro）首先使用 又称亲和图（Affinity Diagram） 方法： 把写有原始信息的纸条贴在白板或墙上； 移动纸条，将同类信息聚在一起； 过大的组要不要拆分？过小的能不能合并？ 对归类有争议的可以将纸条复制； 当大家都没有争议了，为每组命名。 应用： 将归纳成组的市场需求作进一步的分析 区分NUD（新颍、独特、困难）和ECO（容易、一般、陈旧）的需求 NUD能使你的产品与众不同,15,亲和图示例,16,制定正确的项目需求的原则,识别所有的干

7、系人 正确地定义和描述需求 区分必须和希望 功能需求、性能需求和设计需求 建立需求跟踪矩阵 后向：链接每一条需求和它的来源（业务需要、机会、项目目标） 前向：链接每一条需求到项目范围（WBS中的可交付成果）、产品设计和开发（实现它的子系统、模块以及测试策略与案例），链接宏观需求到详细需求 定义并严格遵循变更控制 计划并执行正式的和非正式的需求检查与评审,17,需求定义常见的问题,关键干系人未参与制订需求或被咨询 需求描述不清晰（存在二义性） 需求不完整（暗藏未明确表述的假设） 需求过分（混淆希望与必须） 需求过细（混淆需求与设计） 需求自相矛盾 需求多变,18,需求检查清单,是否完整 是否清晰

8、 不需另加说明 是否合理 根据需求可开发出正是用户所需要的产品 有没有有性能指标 响应时间、吞吐量等 是否可行 是否稳定 是否可度量,是否可测试 有没有任何约束 可靠性、可在性指标是否现实 是否易于维护 维护人员参与制订需求 有没有安全性需求 有没有用户界面需求 外观、易于使用 有没有对规模的适当界定 是否过小、过大、过于复杂,19,收集需求的依据、工具与技术、成果,20,项目范围管理内容 定义范围 Define Scope,21,项目范围说明书,项目范围说明书详细描述项目的可交付成果及为制作这些成果所需的活动。项目范围说明书是项目干系人之间就项目范围所达成的共识。 内容 产品范围描述（对将提

9、交的产品、服务或成果的特性的详细描述） 将提交的产品、服务、成果的验收过程和标准 项目可交付成果 项目边界（哪些属于、哪些不属于项目范围） 项目制约因素（事先约定的预算、强制性日期、强制性里程碑等） 项目假设条件,22,项目范围说明书模板示例,23,定义范围的依据、工具与技术、成果,24,项目范围管理内容 创建工作分解结构 Create WBS （Work Breakdown Structure),25,工作分解结构（WBS）,WBS 是一个面向可交付成果的层次型结构 WBS把项目分解成较小、更便于管理的多项工作 每降一层意味着项目工作定义得更详尽 WBS定义了整个项目的范围，表示目前已批准的

10、项目范围说明书所规定的全部工作 未列入WBS的工作将排除在项目范围之外 在WBS最底层的单元叫“工作包”（Work Package）,26,制作WBS的好处,提高对成本、时间及资源估算的精确度 为绩效测量与控制定义一个基准 便于进行明确的职责分配,制作WBS,变更,工期拖延 成本上升 质量缺乏保证,27,WBS示例（一）,海南自助游,交通,活动,住宿,购物,订机票,乘机 （去）,乘机 （返）,预订 旅馆,入住,退房,活动 计划,南山,大东海,按功能分解,潜水,快艇,28,WBS示例（二）,海南自助游,准备,活动,出发,返回,乘机 （去）,乘机 （返）,预订 旅馆,入住,退房,活动 计划,南山,

11、大东海,按阶段分解,订机票,潜水,快艇,29,WBS的特征,面向可交付成果 每一个WBS项的工作内容是其下一级各项工作之和 每一个WBS项必须有准确描述（其核心词是个动词） 每项工作由一个人负责 可以有不同的分解方式 以生命期的阶段为第一层，可交付成果为第二层 以主要可交付成果为第一层 以子项目为第一层 可以有不同的分解层次 无论如何分解，同一项目最终分解出的工作包应大体相同 避免工作包过粗或过细 是否足够详细以编制成本和历时估算？ “80人时（2人周）原则” 项目组成员参与WBS 的制定过程,30,WBS编号,目的：便于提及 方法：用多点的数码反映WBS结构 注意： 一个号码一旦使用，永不重

12、用，即使原来的工作已经被删掉 编号大小与工作顺序无关,海南自助游例 7.1 交通 7.1.1 订机票 7.1.2 乘机（去） 7.1.3 乘机（返） 7.2 住宿 7.3 活动 7.3.1 南山 7.3.2 大东海 7.3.2.1 潜水 7.3.2.2 快艇 7.3.3 亚龙湾 ,31,WBS词典,不是名词术语的定义 而是为每一个工作包提供详尽的背景信息，如 编号 工作描述 负责人/部门 成本估算、工期、人员安排、需要的其他资源 质量要求、验收标准 该工作包的紧前与紧后工作包 其他信息,32,建立WBS的方法,遵循指导方针 美国国防部（DoD）的项目范围说明中明确指出项目的WBS 类比法 选取

13、相似项目的WBS作为参考 从上至下或从下至上方法,33,美国国防部项目WBS模板之一,34,类比法,以前项目的工作分解结构常常被用作新项目的模板 相同或类似的项目生命周期 每个阶段有相同或类似的可移交项,35,自上至下的分解方法,确定项目的各主要可交付成果，包括项目管理 可以阶段为第一层，可交付成果为第二层 每个可交付成果的详细程度是否已经达到了足以编制出恰当的成本和历时估算并分配给一个组织单元（部门或个人）？是-4， 否-3 识别可交付成果的组成部分，对每一组成部分重复2 每个组成部分应能以切实的、可校验的语言加以描述 对分解的正确性进行校验 下一层的元素是否对于完成上一层工作是必须的且足够

14、的？ 每一项元素是否都已被清楚且完整地定义？ 是-结束；否-增减或重新定义组成部分，重复2,36,创建工作分解结构的依据、工具与技术、成果,37,项目范围管理内容 核实范围 Verify Scope,38,核实范围,核实范围是项目干系人对已完成的项目范围及相应的可交付成果正式验收的过程。 核实范围的手段是检查，包括测量、测试、审查、审计、巡检等。 如果项目被提前中止，核实范围过程应当查明并记录所完成的水平和程度。 核实范围不同于控制质量： 核实范围主要关心对工作结果的“接受”； 控制质量主要关心工作结果的“正确性”。,39,核实范围的依据、工具与技术、成果,40,项目范围管理内容 控制范围 C

15、ontrol Scope,41,控制范围,控制范围是监督项目和产品的范围状态、管理范围基线变更的过程。 包括： 确保请求的变更、推荐的改正措施按照整体变更控制过程进行处理； 变更不可避免，须与其他控制过程（进度控制、成本控制、质量控制）结合起来； 对造成范围变更的因素施加影响，并控制这些变更造成的后果。,42,范围蔓延问题（Scope Creep）,范围变更失控导致范围蔓延 根据Standish公司的调查，IT 项目 成功的十大因素中，有三项与范围有关： User involvement Minimized scope Firm basic requirement 失控（ Challenged

16、 ）的十大因素中，前三项是： Lack of user input Incomplete requirements & specifications Changing requirements & specifications,43,控制范围蔓延问题的建议,促进用户参与 使用户易于获得项目有关信息如项目章程、范围说明书、工作分解结构等 让用户参与项目组织 举行例会，用户在例会上签收阶段性成果 让用户与开发人员相处，易于沟通 减少不完整的、易变的要求和说明 制定并遵循一个需求管理程序 使用原型制作、用例模型、合作应用设计等方法，透彻理解用户的要求 合作应用设计（JAD）：发起人、用户、分析员和程序员等项目干