【落叶105】“老兵爱分享”之《项目范围和进度管理》
PPT 首页 为啥要做项目范围管理这是《落叶》文集里第 105 片落叶,希望你能喜欢,不为别的,只为这份坚持。
【Page 1】
案例:Y 公司在实施 ERP 项目的过程中,实施工程量比预计工程量大幅增加,除了导致工期延后了六个月,客户还要求赔偿一百万,在这个项目上,Y 公司非但没有赚到钱,还需要承受大额亏损。
缺少正确的项目需求、定义和范围核实是导致项目失败的主要原因。
目前IT项目最大的问题是项目需求与范围的不确定性和易动性。
做对的事情比把事情做好更重要!
【Page 2】
【Page 3】
项目范围的定义包括两个方面的含义:
项目产品范围——某项产品、服务或成果所具有的特性和功能。对项目产品范围完成的衡量标准根据客户需求来进行。
项目工作范围——为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。对项目工作范围完成的衡量标准根据项目范围管理计划来检验。
【Page 4】
为啥要做项目给工作分解项目范围管理包括确保项目做且只做成功完成项目所需的全部工作的各过程。项目范围管理主要在于定义和控制哪些工作应包括在项目内,哪些不应包括在项目内。
—— PMBOK
【Page 5】
【Page 6】
工作分解结构(WBS,Work Breakdown Structure)的涵义
工作分解结构是基于项目管理和控制的目的,将项目分解成易于管理部分的技术。它是通过直接对项目的目标或项目产出物逐层细分为更小、更易管理的子项目或项目要素,直到分解出具体的(项目产出物)工作包的系统方法。
【Page 7】
【Page 8】
创建WBS分解的方法
自上而下法: 从项目最大的单位开始,逐步将它们分解成下一级的多个子项。
自下而上法: 让项目组人员一开始就尽可能地确定项目有关的各项具体任务,然后再将各项具体任务进行整合,并归总到 WBS 的上一级内容当中。
【Page 9】
范围核实
要形成一份满足干系人需求的范围说明书和WBS是一件非常不容易的事情,而项目范围核实和范围变更控制则更具难度
由于IT项目的特点,范围蔓延的现象屡见不鲜,正是诸如范围蔓延等类似的问题,导致了许多项目的失败
【Page 10】
为啥要做进度管理范围变更
范围变更的表现形式多种多样,如客户改变对功能需求的想法,项目预算发生改变甚至项目环境发生变化等。
在IT项目中,范围变更可能来自服务商、供应商或者客户,也可能来自项目组织内部。产生变更可能有如下一些原因:
需求不明确
系统实施时间过长
用户业务需求改变
系统正常升级
【Page 11】
项目计划是指导项目实施和控制的一系列纲领性文件,是经高层管理批准的项目正式文档。
项目进度计划制定是根据项目的目标,在项目确定的范围内、依据确定的需求和质量标准、并在项目成本预算许可下,制定出一个周密的项目活动安排的过程。
项目时间管理是在项目的执行和实施过程中,经常检查实际进度是否按计划要求进行,若出现偏差,便要及时找出原因,采取必要的补救措施或调整、修改原计划,直至项目完成的过程
【Page 12】
【Page 13】
依赖性关系的四种类型:
FS:Finish to Start,需求分析-总体设计
SF:Start to Finish,系统上线-项目结项
FF:Finish to Finish,单元测试-编写集成测试用例
SS:Start to start,总体设计-编写系统测试用例
【Page 14】
资源需求
大多数活动所需时间由相关资源多少所决定。例如,二人一起工作完成某设计活动只需一半的时间(相对一个人单独工作所需时间);每日只能用半天进行工作的人通常至少需要二倍的时间完成某活动(相对一个人能整天工作的所需时间)。
资源质量
大多数活动所需时间与人和设备的能力(质量)有关,例如,对同一活动,设有两个人均全日能进行工作,一个高级程序员所需时间少于初级程序员所需时间。
【Page 15】
【Page 16】
项目进度计划(Schedule)是在工作分解的基础上对项目活动做出的一系列时间安排。
制定项目进度计划的目的就是控制时间和节约时间,安排项目各项活动的时间计划和人员安排
常见的项目进度计划方法有里程碑法和甘特图法
作者简介:14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵