第5章项目范围管理。 - 草稿 - 草稿

作者&投稿:博赖 (若有异议请与网页底部的电邮联系)
项目范围管理包括确保项目做截止的所需,全部工作已成功完成项目的各个过程项目管理范围,主要有待于定义和控制哪些工作?应该包括哪些项目?哪些不应该包括在项目内。项目范围管理过程包括。

5.1规划范围管理  为记录如何定义确认和控制项目范围及产品战略,而创建范围管理计划的过程。

5.2收集需求。为实现项目目标而确定记录并管理相关方的需要和需求的过程。

5.3定义范围 制定项目和产品详细描述的过程。

5.4创建WPS,将项目交付成果和项目分解为较小的,更易于管理的组件的过程。

5.5确认范围。正式验收已造成的项目和交付成果的过程。

5.6控制范围,监督项目和产品范围的动态管理范围基准变更的过程。

项目管理的核心概念。

产品范围。某项产品服务或成果所具有的特征和功能。项目范围有时也包括产品范围。

从预测型方法都是隐形方法或敏捷方法,下面这些可以处于连续区间内的任何位置,在原则性生命周期中,在项目开始时对对橡木可交付成果进行定义,对任何范围变化都要进行渐进管理,而在适应性或面解决生命周期中通过多次迭代来开发可交付成果,并在每次迭代开始时定义和批准详细的范围。

采用适应性生命周期指代对应,对大量变更需要相关方持续参与项目,因此应对适应性项目的整体范围分解为一系列,你实现需求合理执行工作,有在一个迭代开始时,团队将努力确定产品未完成项中,哪些最优先项下一代中交付,在每次迭代中都会重复开展三个过程收集需求定义范围和创建WPS相反,在预测性项目中,这些过程在项目开始时开展,并在必要时通过实施整体控制过程进行更新。

在预测型项目中,经过批准的项目范围说明书工作分解结构和相应的工作分解词典构成项目基准范围,只有通过正式变更控制程序才能进行基准变更,待开展确认范围,控制范围及其其他控制过程时,基准被用作比较的基础,而采用适应型生命周期项目的使用未完成项,包括用户需求和用户故事反映当前需求。

项目范围完成情况是根据项目管理计划来衡量产品范围完成情况,根据产品需求来衡量,在这里需求指特定协议或其他强制性规范产品服务或成果所必须的条件和能力。

确认范围是正式验收已完成的项目和交付成果的过程,从控制质量过程运出的核实可交付成果是确认范围,过程输入而验收可交付成果是确认范围过程输出之一,有获得授权的相关方正式签字批准。

项目范围管理的发展趋势和新兴实践。

组织开始认到如何用于商业分析通过定义管理和控制需求活动来提高竞争优势商业活动分析,可在项目启动和项目经理任命之前就开始根据需求管理实践指南,需求管理过程中需要评估而需要评估,有可能始于橡木组合规划项目及规划和单个项目。

需求管理过程结束于需求关闭,把产品服务和成果移交给接受方,以便长期测量监控实现维持利益。

项目经理与商业分析师之间应该是伙伴是合作关系。

对于需求不断变化,风险大或不确定性高的项目,在项目开始通常无法明确判断项目范围,而需要在项目期间逐渐明确明确方法,特意在项目早期拓展定义和协商范围时间并未持续探索和明确范围而延长,创建相应过程时间。

5.1规划范围管理。

规划范围管理是为记录如何定义确认和控制项目范围及产品范围,而创建范围管理计划的过程等过程的主要作用在项目期间如何管理范围提供指南和方向,本过程仅开展一次或仅在项目预定展点开展。

范围管理计划是项目或项目信息管理计划的组成部分,描述将如何定义,指定监督控制和确定项目范围。

5.1.1项目规划范围管理输入。

项目章程记录项目目的项目描述,假设条件制约因素以及项目意图实现的高层级需求。

5.1.2规划范围管理,工具技术。

5.1.2.2数据分析。

适用于本过程数据分析技术,包括备选方案分析,本技术用于评估收集需求,详细项目和产品范围,创造产品确认范围和控制范围的各种方法。

5.1.2.3会议。

项目团队可以参加项目会议来制定范围管理计划。

5.1.3规划范围管理。输出。

5.1.3.1范围管理计划。

范围管理计划是项目管理计划的组成部分,描述将如何定义,制定监督控制和确认项目范围。范围管理计划要对将用于下列工作的管理过程作出决定。

制定项目范围说明书。

确定如何审批和维护范围基准。

正式验收已完成的项目和交付成果。

5.1.3.2需求管理计划。

需求管理计划是项目管理计划的组成部分,描述将如何分析记录和管理项目和产品需求根据从业者商业分析实践指南。有一些组织称之为商业分析计划。

5.2收集需求。

收集需求是为了实现目标而确定记录并管理相关方的需要和需求的过程。本过程主要作用是为了定义产品范围和项目范围奠定基础,仅开展一次或近待项目预定点开展。

收集需求。

输入。1.项目章程,2.项目管理计划。范围管理计划,需求管理计划,相关方参与计划。三项目文件。假设日志,经验教训登记册,相关方登记册。4,商业文件 商业论证。5协议。6,事业环境因素。7组织过程资产。

5.1.3项目文件。

经验教训登记册。经验教训登记册提供了有效的需求收集技术,有提升,对使用迭代性和适应性产品开发方法的项目。

相关方登记册,相关方登记册,用于了解哪些相关方,能够提供需求方面信息及记录相关方对项目需求和期望。

5.2.1.4商业文件。商业文件会影响收集需求过程是商业论证,它描述了为满足业务需要而达到的必要期望和可选标准。

5.2.2.2数据收集。

头脑风暴。头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创新技术。

访谈是通过相关方直接交谈来获取正式或非正式的方法,访谈的典型做法是向被访者提出预设提醒的问题,并记录他们的回答,访谈是一个访谈者和被访谈者之间的1对1的谈话,但也可以包括多个访谈者和多个被访者。访谈有经验的项目参与者,发起人和其他高管以及主题专家,有助于识别和定义所需产品可交付成果特征和功能。访谈也可以用于获取机密信息。

焦点小组。焦点小组是召集预定相关方和主题专家,了解他们对所讨论的产品服务和或成果期望的态度,有一位。训练的主持人引导大家进行互动式讨论,焦点小组往往比1对1的访谈更热烈。

问卷调查。问卷调查是指涉及一系列书面问题,向众多受访者快速收集信息,问卷调查方法最适用于以下情况。受众多样化,需要快速完成调查。受访者地理位置分散,并且适合开展统计分析。

标杆对照。彪悍对照将是集合计划产品过程和时间与其他科比组织的时间进行比较,以辨识别对家时间形成改进意见,并为绩效考核提供依据,标杆对照所采用的可比组织,可以是内部,也可以是外部的。

数据分析。可用于本过程数据分析技术,包括文件分析文件分析,包括审核和评估任何相关文件的信息。

5.2.2.4决策。

投票。投票是一种未达成某种期望结果,而对多个未来行动方案进行评估,具体决策技术的过程,本技术用于生成归类和排序产品需求,投票示例包括。

一致同意  每个人都同意某个行动方案。

大多数同意 获得群体中超过50%人员的支持就能做出决策。把参与决策的小组人数作为基数,可防止因平局而无法达成决策。

相对多数同意。根据群体中相对多数人的意见,多数角色即便未能获得大多数人的知识,通常在候选项超过两个时使用。

独裁性决策制定。采用这种方法,将由一个人负责整个集体制定决策。

多标准决策分析。该技术接触决策矩阵,用系统分析方法建立诸如风险水平不确定性和价值收益的多种标准,你对中国创意进行评估和排序。

5.2.2.5数据表现。

亲和图 用来对大量创意进行分组技术,以便进一步审查和分析。

思维导图。把头脑风暴中获得了创意,整合成一张图,用于反映创意之间的共性与差异,激发新创意。

5.2.2.6人际关系团队技能。

名义小组技术。名义小组技术用于促进头脑风暴的一种技术动作,通过投票排列最有用的创意一遍,进一步开展头脑风暴或优先排序。

观察和访谈。观察和交谈是指直接查看个人在各自环境中如何执行工作或实施流程。当产品使用者难以或不愿清晰说明他们需求时,就特别需要通过观察来了解他们的工作细节,观察也称为工作跟随身边通常由膨胀观察员或者观察业务专家如何执行工作,但可以由参与观察者来观察,通过实际执行一个流程或程序来体验该流程或程序是如何实施的,以便挖掘隐藏的需求。

引导。引导与主题研讨会结合使用,把主要相关方召集在一起,定义产品需求研讨会,可用于快速定义跨职能需求,并协调相关方的需求差异,因为具有群体活动的特点,有效引导引导,会有助于参与者之间的建立,信任感情关系改善沟通从而有利于相关方达成一致意见。

联合应用设计或开发JAD。这一例会议是由于软件开发行业这种研讨会注重把业务主题专家和开发团队集中在一起,以收集需求和改进软件开发过程。

质量功能展开。制造业采用qfd这种引导技术来帮助客户确定新产品的关键特征,qfd从收集客户需求需要开始,然后客观对这些需要进行分类和排序,并为实现这些需要而设定目标。

用户故事。用户故事是对所需功能的简短的文字的描述,经常产生于需求研讨会,用户故事描述哪个相关方将从功能中收益它需要实现什么目标,以及他期望获得什么利益。

5.2.2.7系统交互图。

系统交互组织范围模型的一个例子,它是对产品范围的可视化描绘显示业务系统及其与人和其他系统之间的交互方式,系统交互方式显示了业务系统的输入,输入提供者,业务系统输出和输出接收者。

5.2.2.8原型法。

全球化知识渐渐明晰的理念,需要从经历从模型创建用户体验反馈收集到原型修改的反复循环的过程,在经过度过的反馈循环之后,就可以通过应用法获得足够的需求信息,从而进入设计或制造阶段

故事板是一种原型技术。通过一系列图像或图示来展示顺序或导航路径故事,本用于各种行业的各种项目注入,电影广告教学设计,以及敏捷和其他软件开发项目,在软件开发中估值来使用实体模型来展示网页屏幕或其他用户界面的导航路径。

5.2.3收集需求输出。

5.2.3.1需求文件。

需求文件描述各种单一需求将如何满足与项目相关业务需求,一开始可能只有高层企业需求,然后随着有关需求信息增加而逐步细化,只有明确的可跟踪的完整的相互协调,而主要相关方愿意认可需求,才能作为基准

需求文件的格式是多种多样,既可以是一份按照相关方和优先级分类列出全部需求的简单文件,也可以是一种包括内容提要,信息描述和附件等的详细文件。

业务需求,整个组织高峰期需要例如解决业务问题或抓住业务机会以及实施项目的原因。

质量需求用于确认项目和交付成果的,成功完成或其他项目需求的实现的任何条件或标准,例如测试认证确认的。

5.2.3.2需求跟踪矩阵。

需求跟踪矩阵,把产品需求从其来源连接到能满足需求和交付成果的一种表格式,使用需求跟踪理论,把每个需求与业务目标或项目目标联系起来,有助于确认每个需求都具有商业价值需求跟踪矩阵提供的,在整个项目生命周期中跟踪需求的一种方法,也可以确保需求文件中被批准的每一项需求在项目结束的时候都能交付,最后。需求跟踪矩阵还为管理产品范围变更提供的框架。

应在需求跟踪矩阵中记录每个需求的相关属性,这些属性这些属性有助于明确每个需求的关键信息,需求跟踪矩阵中进入典型的属性,包括唯一标识需求的文字描述,收入该需求的理由所有者来源优先,级别,版本,当前状态。为确保相关方满意,可能需要增加一些属性如稳定性复杂性验收标准。

~