文章目录9.1管理基础9.2项目范围管理过程9.2.1过程概述9.2.2裁剪考虑因素9.2.3敏捷与适应力法9.3规划范围管理9.3.1输入9.3.2工具与技术9.3.3输出1、范围管理计划2、需求管理计划9.4收集需求9.4.1输入9.4.2工具与技术1、专家判断2、数据收集头脑风暴、焦点小组3、数据分析4、决策5、数据表现6、人际关系与团队技能名义小组7、系统交互图8、原型法9.4.3输出1、需求文件2、需求跟踪矩阵9.5定义范围9.5.1输入9.5.2工具与技术9.5.3输出1、项目范围说明书9.6 创建WBS9.6.1输入9.6.2工具与技术9.6.3输出1、范围基准9.7确认范围9.7.1输入9.7.2工具与技术9.7.3输出1、验收的可交付成果2、变更请求3、工作绩效信息9.8控制范围9.8.1输入9.8.2工具与技术9.8.3输出1、工作绩效信息2、变更请求项目范围管理包括确保项目做且只做所需的全部工作以成功完成项目。项目范围管理主要在于定义和控制哪些工作应该包括在项目内哪些不应该包含在项目内。9.1管理基础9.1.1产品范围和项目范围产品范围指某项产品、服务或成果所具有的特征和功能。产品范围的完成情况是根据产品需求来衡量的。“需求”是指根据特定协议或其他强制性规范产品、服务或成果必须具备的条件或能力。项目范围包括产品范围是为交付具有规定特性与功能的产品、服务或成果而必须完成的工作。项目范围的完成情况是根据项目管理计划来衡量的。9.1.2 管理新实践项目范围管理的新趋势和新兴实践更加注重与商业分析师一起合作以便确定问题并识别商业需要识别并推荐能够满足需要的可行解决方案收集、记录并管理干系人需求满足商业和项目目标推动项目集或项目产品、服务或最终成果成功应用。9.2项目范围管理过程9.2.1过程概述项目范围管理过程包括1、规划范围管理为了记录如何定义、确认和控制项目范围及产品范围创建范围管理计划。2、收集需求为了实现项目目标确定、记录并管理干系人的需要和需求。3、定义范围制定项目和产品详细描述。4、创建WBS将项目可交付成果和项目工作分解为较小的、更易于管理的组件。5、确认范围正式验收已完成的项目可交付成果。6、控制范围监督项目和产品的范围状态管理范围基准的变更。在项目实际进展中以上各过程会相互交叠和相互作用。表9-1概括了项目范围管理的各个过程。9.2.2裁剪考虑因素因为每个项目都是独特的所以项目经理可能根据需要裁剪项目范围管理过程。裁剪考虑的因素包括知识和需求管理项目经理应建立哪些指南?为了在未来项目中重复使用需求组织是否拥有正式或非正式的知识和需求管理体系?确认和控制组织是否有正式或非正式的与确认和控制相关政策、程序和指南?开发方法组织是否采用敏捷方法管理项目?开发方法属于迭代型还是增量型?是否采用预测型方法?混合型方法是否有效?需求的稳定性项目中是否存在需求不稳定的领域?是否有必要采用精益、敏捷或其他适应型技术来处理不稳定的需求直至需求稳定且定义明确?治理组织是否拥有正式或非正式的审计和治理政策、程序和指南?9.2.3敏捷与适应力法对于需求不断变化、风险大或不确定性高的项目在项目开始时通常无法明确项目的范围而需要在项目期间逐渐明确。敏捷或适应型方法特意在项目早期缩短定义和协商范围的时间为后续细化范围、明确范围争取更多的时间。在许多情况下不断涌现的需求往往导致真实的业务需求与最初所述的业务需求之间存在差异。因此敏捷方法有目的地构建和审查原型并通过多次发布版本来明确需求范围会在整个项目期间被定义和再定义。采用敏捷或适应型生命周期通过多次迭代来开发可交付成果并在每次迭代开始时定义和批准详细的范围。在一个迭代开始时团队将努力确定产品未完成项中哪些优先级高的未完成项需要在下一次迭代中交付。在每次迭代中都会重复开展三个过程收集需求定义范围创建WBS。发起人和客户代表应该持续参与项目并对迭代交付的可交付成果提供反馈意见确保产品未完成项真实地反映了他们的当前需求。在每次迭代中都会重复开展两个过程确认范围控制范围。在预测型项目中经过批准的项目范围说明书、工作分解结构(WBS)和相应的WBS词典构成项目范围基准。只有通过正式变更控制程序才能进行基准变更。在开展确认范围、控制范围及其他控制过程时基准被用作比较的基础。而采用适应型生命周期的项目则使用未完成项反映当前需求。确认范围是正式验收已完成的项目可交付成果的过程。从控制质量过程输出的核实的可交付成果是确认范围过程的输入而验收的可交付成果是确认范围过程的输出之一由获得授权的干系人正式签字批准。因此干系人需要在规划阶段早期介入(有时需要在启动阶段就介入)对可交付成果的质量提出意见以便控制质量过程能够据此评估绩效并提出必要的变更建议。9.3规划范围管理规划范围管理是为了记录如何定义、确认和控制项目范围及产品范围而创建范围管理计划的过程。本过程的主要作用是在整个项目期间对如何管理范围提供指南和方向。本过程仅开展一次或仅在项目的预定义点开展。规划范围管理过程的数据流向如图9-1所示。范围管理计划是项目或项目集管理计划的组成部分描述将如何定义、制定、监督、控制和确认项目范围。制订范围管理计划和细化项目范围始于对下列信息的分析项目章程中的信息、项目管理计划中已批准的子计划、组织过程资产中的历史信息和相关事业环境因素。9.3.1输入1、项目章程项目章程记录项目目的、项目概述、假设条件、制约因素以及项目想要实现的高层级的需求。2、项目管理计划质量管理计划在项目中实施组织质量政策、方法和标准的方式会影响管理项目和产品范围方式。项目生命周期描述定义了项目从开始到完成所经历的一系列阶段。·开发方法开发方法定义了项目是采用预测型、适应型还是混合型开发方法。3、事业环境因素组织文化、基础设施、人事管理制度和市场条件等。4、组织过程资产政策和程序、历史信息和经验教训知识库等。9.3.2工具与技术1、专家判断规划范围管理过程中应征求具备如下领域相关专业知识或接受过相关培训的个人或小组的意见涉及的领域包括以往类似项目特定行业、学科和应用领域的信息等。2、数据分析适用于本过程的数据分析技术是备选方案分析。备选方案分析技术用于评估、收集需求详述项目和产品范围创造产品确认范围和控制范围的各种方法。3、会议项目团队可参加项目会议来制订范围管理计划。参会者包括项目经理、项目发起人、选定的项目团队成员、选定的干系人、范围管理各过程的负责人以及其他必要人员。9.3.3输出1、范围管理计划范围管理计划是项目管理计划的组成部分描述将如何定义、制定、监督、控制和确认项目范围。范围管理计划用于指导如下过程和相关工作①制定项目范围说明书②根据详细项目范围说明书创建 WBS③确定如何审批和维护范围基准④正式验收已完成的项目可交付成果。根据项目需要范围管理计划可以是正式或非正式的非常详细或高度概括的。2、需求管理计划需求管理计划是项目管理计划的组成部分描述如何分析、记录和管理需求。需求管理计划的主要内容包括①如何规划、跟踪和报告各种需求活动②配置管理活动例如如何启动变更如何分析其影响如何进行追溯、跟踪和报告以及变更审批权限③需求优先级排序过程④测量指标及使用这些指标的理由⑤反映哪些需求属性将被列入跟踪矩阵等。9.4收集需求收集需求是为实现目标而确定记录并管理干系人的需要和需求的过程。本过程的主要作用是为定义产品范围和项目范围奠定基础。本过程仅开展一次或仅在项目的预定义点开展。让干系人积极参与需求的探索和分解工作(分解成项目和产品需求)并仔细确定、记录和管理对产品、服务或成果的需求。需求是指根据特定协议或其他强制性规范产品、服务或成果必须具备的条件或能力。需求将作为后续工作分解结构(WBS)的基础也将作为成本、进度、质量和采购规划的基础。9.4.1输入1、立项管理文件会影响收集需求过程的立项管理文件是商业论证产生的文件它描述了为满足业务需要而应该达到的必要、期望及可选标准。2、项目章程项目章程记录了项目概述以及将用于制定详细需求的高层级需求。3、项目管理计划收集需求中使用的项目管理计划组件包括范围管理计划包含如何定义和制定项目范围的信息。需求管理计划包含如何收集、分析和记录项目需求的信息。干系人参与计划从该计划中了解干系人的沟通需求和参与程度以便评估并适应干系人对需求活动的参与程度。4、项目文件可作为收集需求过程输入的项目文件主要包括假设日志识别了有关产品、项目、环境、干系人以及会影响需求的其他因素的假设条件。干系人登记册用于了解哪些干系人能够提供需求方面的信息记录干系人对项目的需求和期望。经验教训登记册提供了有效的需求收集技术尤其针对使用敏捷或适应型产品开发方法的项目。5、协议协议会包含项目和产品需求。6、事业环境因素组织文化、基础设施、人事管理制度、市场条件等。7、组织过程资产政策和程序包含以往项目信息的历史信息和经验教训知识库等。9.4.2工具与技术1、专家判断收集需求过程中应征求具备如下领域相关专业知识或接受过相关培训的个人或小组的意见涉及的领域包括可行性研究与评估需求获取需求分析需求文件以往类似项目的项目需求图解技术引导冲突管理等。2、数据收集头脑风暴、焦点小组可用于收集需求过程的数据收集技术主要包括1头脑风暴是一种用来产生和收集对项目需求与产品需求的多种创意的技术。2访谈是通过与干系人直接交谈来获取信息的正式或非正式的方法。访谈的典型做法是向被访者提出预设和即兴的问题并记录他们的回答。访谈经常是一个访谈者和一个被访者之间的“一对一谈话但也可包括多个访谈者或多个被访者。访谈有经验的项目参与者、发起人和其他高管及主题专家有助于识别和定义所需产品可交付成果的特征和功能。访谈也可用于获取机密信息。3焦点小组是召集预定的干系人和主题专家了解他们对所讨论的产品、服务或成果的期望和态度。由一位受过训练的主待人引导大家进行互动式讨论。焦点小组往往比“一对一”的访谈更热烈。4问卷调查是指设计一系列书面问题向众多受访者快速收集信息。问卷调查方法非常适用于受众多样化需要快速完成调查受访者地理位置分散并且适合开展统计分析的情况。5标杆对照将实际或计划的产品、过程和实践与其他可比组织的实践进行比较以便识别最佳实践形成改进意见并为绩效考核提供依据。标杆对照所采用的可比组织可以是内部的也可以是外部的。3、数据分析可用于收集需求过程的数据分析技术是文件分析。文件分析指审核和评估任何相关的文件信息。在此过程中文件分析用于通过分析现有文件识别与需求相关的信息来获取需求可供分析并有助于获取需求的文件包括协议商业计划业务流程或接口文档业务规则库现行流程市场文献问题日志政策和程序、法规文件如法律、准则、法令等建议邀请书用例等。4、决策适用于收集需求过程的决策技术主要包括1投票是一种为达成某种期望结果而对未来多个行动方案进行评估的决策技术和过程。本技术用于生成、归类和排序产品需求。2独裁型决策制定采用这种方法将由一个人负责为整个集体制定决策。3多标准决策分析该技术借助决策矩阵用系统分析方法建立诸如风险水平、不确定性和价值收益等多种标准以对众多创意进行评估和排序。5、数据表现可用于收集需求过程的数据表现技术主要包括1亲和图用来对大量创意进行分组的技术以便进一步审查和分析。2思维导图把从头脑风暴中获得的创意整合成一张图用以反映创意之间的共性与差异激发新创意。6、人际关系与团队技能名义小组可用于收集需求过程的人际关系与团队技能主要包括1名义小组技术是用于促进头脑风暴的一种技术通过投票排列最有用的创意以便进一步开展头脑风暴或优先排序。名义小组技术是一种结构化的头脑风暴形式由四个步骤组成向集体提出一个问题或难题每个人在沉思后写出自己的想法主待人在活动挂图上记录所有人的想法集体讨论各个想法直到全体成员达成一个明确的共识个人私下投票决出各种想法的优先排序通常采用5分制1分最低5分最高。为减少想法数量、集中关注想法可进行数轮投票。每轮投票后都将清点选票得分最高者被选出。2观察和交谈是指直接察看个人在各自的环境中如何执行工作(或任务)和实施流程。当产品使用者难以或不愿清晰说明他们的需求时特别需要通过观察来了解他们的工作细节。观察也称为“工作跟随通常由旁站观察者观察业务专家如何执行工作但也可以由“参与观察者”来观察通过实际执行一个流程或程序来体验该流程或程序是如何实施的以便挖掘隐藏的需求。3引导引导与主题研讨会结合使用把主要干系人召集在一起定义产品需求。研讨会可用于快速定义跨职能需求并协调干系人的需求差异。因为具有群体互动的特点有效引导的研讨会有助于参与者之间建立信任、改进关系、改善沟通从而有利于干系人达成一致意见。此外与分别召开会议相比研讨会能够更早发现并解决问题。7、系统交互图系统交互图是对产品范围的可视化描绘可以直观显示业务系统(过程、设备、计算机系统等)及其与人和其他系统(行动者)之间的交互方式。8、原型法原型法是指在实际制造预期产品之前先造出该产品的模型并据此征求对需求的早期反馈。原型包括微缩产品、计算机生成的二维和三维模型、实体模型或模拟。因为原型是有形的实物它使得干系人可以体验最终产品的模型而不是仅限于讨论抽象的需求描述。原型法支持渐进明细的理念需要经历从模型创建、用户体验、反馈收集到原型修改的反复循环过程。在经过足够的反馈循环之后就可以通过原型获得足够的需求信息从而进入设计或制造阶段。故事板是一种原型技术通过一系列的图像或图示来展示顺序或导航路径。故事板用于各种行业的各种项目中如电影、广告、教学设计以及敏捷和其他软件开发项目。在软件开发中故事板使用实体模型来展示网页、屏幕或其他用户界面的导航路径。9.4.3输出1、需求文件需求文件描述各种单一需求将如何满足项目相关的业务需求。一开始可能只有高层级的需求然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的且主要干系人愿意认可的需求才能作为基准。需求文件的格式多种多样既可以是一份按干系人和优先级分类列出全部需求的简单文件也可以是一份包括内容提要、细节描述和附件等的详细文件。许多组织把需求分为不同的种类如业务解决方案和技术解决方案。前者是干系人的需要后者是指如何实现这些干系人需要的方案。把需求分成不同的类别有利于对需求进行进一步完善和细化。需求的类别一般包括1业务需求整个组织的高层级需要例如解决业务问题或抓住业务机会以及实施项目的原因。2干系人需求干系人的需要。3解决方案需求为满足业务需求和干系人需求产品、服务或成果必须具备的特性、功能和特征。解决方案需求又进一步分为功能需求和非功能需求功能需求描述产品应具备的功能例如产品应该执行的行动、流程、数据和交互非功能需求是对功能需求的补充是产品正常运行所需的环境条件或质量要求例如可靠性、保密性、性能、安全性、4过渡和就绪需求如数据转换和培训需求。这些需求描述了从“当前状态“过渡到“将来状态”所需的临时能力。5项目需求项目需要满足的行动、过程或其他条件例如里程碑日期、合同责任、制约因素等。6质量需求用于确认项目可交付成果的成功完成或其他项目需求的实现的任何条件或标准例如测试、认证、确认等。2、需求跟踪矩阵需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵把每个需求与业务目标或项目目标联系起来有助于确保每个需求都具有业务价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法有助于确保需求文件中被批准的每项需求在项目结束的时候都能实现并交付。最后需求跟踪矩阵还为管理产品范围变更提供了框架。跟踪需求的内容包括①业务需要、机会、目的和目标②项目目标③项目范围和WBS可交付成果④产品设计⑤产品开发⑥测试策略和测试场景⑦高层级需求到详细需求等。应在需求跟踪矩阵中记录每个需求的相关属性这些属性有助于明确每个需求的关键信息。需求踪矩阵中记录的典型属性包括唯一标识、需求的文字描述、收录该需求的理由、所有者、来源、优先级别、版本、当前状态和状态日期。为确保干系人满意可能需要增加一些补充属性如稳定性、复杂性和验收标准。9.5定义范围定义范围是制定项目和产品详细描述的过程。本过程的主要作用是描述产品、服务或成果的边界和验收标准。本过程需要在整个项目期间多次反复开展。由于在收集需求过程中识别出的所有需求未必都包含在项目中所以定义范围过程需要从需求文件(收集需求过程的输出)中选取最终的项目需求然后制定出关于项目及其产品、服务或成果的详细描述。准备好详细项目范围说明书对项目成功至关重要。应根据项目启动过程中记载的主要可交付成果、假设条件和制约因素来编制详细的项目范围说明书。在项目规划过程中随着对项目信息了解的逐渐深入应该更加详细、具体地定义和描述项目范围。此外还需要分析现有风险、假设条件和制约因素的完整性并做必要的增补或更新。9.5.1输入1、项目章程项目章程中包含对项目的高层级描述、产品特征和审批要求。2、项目管理计划定义范围中使用的项目管理计划组件是范围管理计划其中记录了如何定义、确认和控制项目范围。3、项目文件可作为定义范围过程输入的项目文件主要包括假设日志识别有关产品、项目、环境、干系人以及会影响项目和产品范围的假设条件和制约因素。需求文件识别了应纳入范围的需求。风险登记册可能影响项目范围的应对策略例如缩小或改变项目和产品范围以规避或缓解风险。4、事业环境因素组织文化、基础设施、人事管理制度、市场条件等。5、组织过程资产用于制定项目范围说明书的政策、程序和模板以往项目的项目档案以往阶段或项目的经验教训等。9.5.2工具与技术1、专家判断定义范围过程中应征求具备类似项目的知识或经验的个人或小组的意见。2、数据分析可用于定义范围过程的数据分析技术是备选方案分析。备选方案分析可用于评估实现项目章程中所述的需求和目标的各种方法。3、决策可用于定义范围过程的决策技术是多标准决策分析。多标准决策分析是一种借助决策矩阵来使用系统分析方法的技术目的是建立诸如需求、进度、预算和资源等多种标准来完善项目和产品范围。4、人际关系与团队技能人际关系与团队技能的一个典型示例是引导。在研讨会和座谈会中使用引导技能来协调具有不同期望或不同专业知识的关键干系人使他们就项目可交付成果以及项目和产品边界达成跨职能的共识。5、产品分析产品分析可用于定义产品和服务包括针对产品或服务提问并回答以描述要交付产品的用途、特征及其他方面。每个应用领域都有一种或几种普遍公认的方法用以把高层级的产品或服务描述转变为有意义的可交付成果。首先获取高层级的需求然后将其细化到最终产品设计所需的详细程度。产品分析技术主要包括产品分解、需求分析、系统分析、系统工程、价值分析、价值工程等。9.5.3输出1、项目范围说明书项目范围说明书是对项目范围、主要可交付成果、假设条件和制约因素的描述。它记录了整个范围包括项目和产品范围详细描述了项目的可交付成果代表项目干系人之间就项目范围所达成的共识。为便于管理干系人的期望项目范围说明书可明确指出哪些工作不属于本项目范围。项目范围说明书帮助项目团队进行更详细的规划在执行过程中指导项目团队工作并为评价变更请求或额外工作是否超过项目边界提供基准。项目范围说明书描述要做和不要做的工作的详细程度决定着项目管理团队控制整个项目范围的有效程度。详细的项目范围说明书包括内容有(直接列出或参引其他文件)产品范围描述逐步细化在项目章程和需求文件中所述的产品、服务或成果特征。可交付成果为完成某一过程、阶段或项目而必须产出的任何独特并可核实的产品、成果或服务能力可交付成果也包括各种辅助成果如项目管理报告和文件。对可交付成果的描述可略可详。验收标准可交付成果通过验收前必须满足的一系列条件。项目的除外责任识别排除在项目之外的内容。明确说明哪些内容不属于项目范围有助于管理干系人的期望及减少范围蔓延。虽然项目章程和项目范围说明书的内容存在一定程度的重叠但它们的详细程度完全不同。项目章程包含高层级的信息而项目范围说明书则是对范围组成部分的详细描述需要在项目过程中渐进明细。2、项目文件(更新)可在定义范围过程更新的项目文件包括假设日志随同本过程识别出更多的假设条件或制约因素从而更新假设日志。需求文件可以通过增加或修改需求而更新需求文件。需求跟踪矩阵应该随同需求文件的更新而更新需求跟踪矩阵。干系人登记册在定义范围过程中收集到了现有或新干系人的更多信息。9.6 创建WBS创建工作分解结构(WBS)是把项目可交付成果和项目工作分解成较小、更易于管理的组件的过程。本过程的主要作用是为所要交付的内容提供架构。它仅开展一次或仅在项目的预定义点开展。WBS是对项目团队为实现项目目标创建所需可交付成果而需要实施的全部工作范围的层级分解。WBS组织并定义了项目的总范围代表经批准的当前项目范围说明书中规定的工作。WBS最低层称为工作包其中包括计划的工作。工作包对相关活动进行归类以便对工作安排进度进行估算开展监督与控制。9.6.1输入1、项目管理计划范围管理计划范围管理计划定义了如何根据项目范围说明书创建WBS。2、项目文件需求文件详细描述了各种单一需求如何满足项目的业务需要。项目范围说明书描述了需要实施的工作以及不包含在项目中的工作。3、事业环境因素会影响创建WBS过程的事业环境因素包括项目所在行业的WBS标准这些标准可以作为创建WBS的外部参考资料。4、组织过程资产用于创建WBS的政策、程序和模板以往项目的项目档案以往项目的经验教训等。9.6.2工具与技术1、专家判断创建WBS过程中应征求具备类似项目知识或经验的个人或小组的意见。2、分解分解是一种把项目范围和项目可交付成果逐步划分为更小、更便于管理的组成部分的技术。工作包是WBS最低层的工作可对其成本和持续时间进行估算和管理。创建WBS的方法多种多样常用的方法包括自上而下的方法、使用组织特定的指南和使用WBS模板。自下而上的方法可用于归并较低层次的组件。1分解活动要把整个项目工作分解为工作包通常需要开展如下活动①识别和分析可交付成果及相关工作②确定 WBS的结构和编排方法③自上而下逐层细化分解④为 WBS 组成部分制定和分配标识编码⑤核实可交付成果分解的程度是否恰当。2WBS结构WBS的结构可以采用多种形式以项目生命周期的各阶段作为分解的第二层把产品和项目可交付成果放在第三层。以主要可交付成果作为分解的第二层。纳入由项目团队以外的组织开发的各种较低层次组件(如外包工作)。随后作为外包工作的一部分卖方须制定相应的合同WBS。对WBS较高层组件进行分解就是要把每个可交付成果或组件分解为最基本的组成部分即可核实的产品、服务或成果。WBS可以采用提纲式、组织结构图或能说明层级结构的其他形式。确认WBS较低层组件是完成上层相应可交付成果的必要且充分的工作以此来核实分解的正确性。不同的可交付成果可以分解到不同的层次。要在未来远期才完成的可交付成果或组件当前可能无法分解。项目管理团队因而通常需要等待对该可交付成果或组成部分达成一致意见才能够制定出WBS中的相应细节。这种技术又称为滚动式规划。3注意事项在分解的过程中应该注意以下8个方面。WBS必须是面向可交付成果的项目的目标是提供产品或服务WBS中的各项工作是为提供可交付的成果服务的。WBS并没有明确地要求重复循环的工作但为了达到里程碑有些工作可能要进行多次。最明显的例子是软件测试软件必须经过多次测试后才能作为可交付成果。WBS必须符合项目的范围WBS必须包括也仅包括为了完成项目的可交付成果的活动。100%原则(包含原则)认为在WBS中所有下一级的元素之和必须100%代表上一级的元素。WBS的底层应该支待计划和控制WBS是项目管理计划和项目范围之间的桥梁WBS的底层不但要支待项目管理计划而且要让管理层能够监视和控制项目的进度和预算。WBS中的元素必须有人负责而且只有一个人负责。WBS和责任人可以使用工作责任矩阵来描述。WBS应控制在4~6层如果项目规模比较大以至于WBS要超过6层可使用项目分解结构将大项目分解成子项目然后针对子项目来做WBS。每个级别的WBS将上一级的一个元素分为4~7个新元素同一级元素的大小应该相似。一个工作单元只能从属于某个上层单元避免交叉从属。WBS应包括项目管理工作(因为管理是项目具体工作的一部分)也要包括分包出去的工作。WBS的编制需要所有(主要)项目干系人的参与各项目干系人站在自己的立场上对同一个项目可能编制出差别较大的WBS。项目经理应该组织他们进行讨论以便编制出一份大家都能接受的WBS。WBS并非是一成不变的在完成了WBS之后的工作中仍然有可能需要对WBS进行修改。如果没有合理的范围控制仅仅依靠WBS会使得后面的工作僵化。9.6.3输出1、范围基准范围基准是经过批准的范围说明书、WBS和相应的WBS词典只有通过正式的变更控制程序才能进行变更它被用作比较的基础。范围基准是项目管理计划的组成部分。项目范围说明书 项目范围说明书包括对项目范围、主要可交付成果、假设条件和制约因素的描述。WBS WBS是对项目团队为实现项目目标、创建所需可交付成果而需要实施的全部工作范围的层级分解。工作分解结构每向下分解一层代表对项目工作更详细的定义。工作包 WBS的最低层是带有独特标识号的工作包。这些标识号为成本、进度和资源信息的逐层汇总提供了层级结构即账户编码。每个工作包都是控制账户的一部分而控制账户则是一个管理控制点。在该控制点上把范围、预算和进度加以整合并与挣值相比较来测量绩效。控制账户包含两个或更多工作包每个工作包只与一个控制账户关联。规划包 规划包是一种低于控制账户而高于工作包的工作分解结构组件工作内容已知但详细的进度活动未知一个控制账户可以包含一个或多个规划包。WBS字典WBS字典是针对WBS中的每个组件详细描述可交付成果、活动和进度信息的文件。WBS字典对WBS提供支待其中大部分信息由其他过程创建然后在后期添加到字典中。WBS字典中的内容一般包括账户编码标识、工作描述、假设条件和制约因素、负责的组织、进度里程碑、相关的进度活动、所需资源、成本估算、质量要求、验收标准、技术参考文献、协议信息等。2、项目文件(更新)可在创建WBS过程更新的项目文件主要包括假设日志随着创建WBS过程识别出更多假设条件或制约因素而更新。需求文件可以更新需求文件以反映在创建WBS过程提出并已被批准的变更。9.7确认范围确认范围是正式验收已完成的项目可交付成果的过程。本过程的主要作用也使验收过程具有客观性通过确认每个可交付成果来提高最终产品、服务或成果获得验收的可能性。确认范围过程应根据需要在整个项目期间定期开展。由主要干系人尤其是客户或发起人审查从控制质量过程输出的核实的可交付成果确认这些可交付成果已圆满完成并通过正式验收。确认范围过程依据从项目范围管理知识领域的相应过程获得的输出(如需求文件或范围基准)以及从其他知识领域的执行过程获得的工作绩效数据对可交付成果的确认和最终验收。1、确认范围的步骤确认范围应该贯穿项目的始终。如果是在项目的各个阶段对项目的范围进行确认工作则还要考虑如何通过项目协调来降低项目范围改变的频率以保证项目范围的改变是有效率和适时的。确认范围的一般步骤包括确定需要进行范围确认的时间识别范围确认需要哪些投入确定范围正式被接受的标准和要素也确定范围确认会议的组织步骤组织范围确认会议。通常情况下在确认范围前项目团队需要先进行质量控制工作例如在确认软件项目的范围之前需要进行系统测试等工作以确保确认工作的顺利完成。确认范围过程与控制质量过程的不同之处在于前者关注可交付成果的验收而后者关注可交付成果的正确性及是否满足质量要求。控制质量过程通常先于确认范围过程但二者也可同时进行。2、需要检查的问题项目干系人进行范围确认时一般需要检查以下6个方面的问题可交付成果是否是确定的、可确认的。每个可交付成果是否有明确的里程碑里程碑是否有明确的、可辨别的事件例如客户的书面认可。是否有明确的质量标准可交付成果的交付不但要有明确的标准标志而且要有是否按照要求完成的标准可交付成果和其标准之间是否有明确联系。审核和承诺是否有清晰的表达项目发起人必须正式同意项目的边界项目完成的产品或者服务以及项目相关的可交付成果。项目团队必须清楚地了解可交付成果是什么。所有的这些表达必须清晰并取得一致的同意。项目范围是否覆盖了需要完成的产品或服务的所有活动有没有遗漏或错误。·项目范围的风险是否太高管理层是否能够降低风险发生时对项目的影响。3、干系人关注点的不同确认范围主要是项目干系人(例如客户、发起入等)对项目的范围进行确认和接受的工作每个人对项目范围所关注的方面是不同的管理层主要关注项目范围是指范围对项目的进度、资金和资源的影响这些因素是否超过了组织承受范围是否在投入产出上具有合理性。客户主要关注产品范围关心项目的可交付成果是否足够完成产品或服务。项目管理人员主要关注项目制约因素关心项目可交付成果是否足够和必须完成时间、资金和资源是否足够主要的潜在风险和预备解决的方法。项目团队成员主要关注项目范围中自己参与的元素和负责的元素通过定义范围中的时间检查自己的工作时间是否足够自己在项目范围中是否有多项工作而这些工作是否有冲突的地方。9.7.1输入1、项目管理计划确认范围中使用的项目管理计划组件主要包括范围管理计划定义了如何正式验收已经完成的可交付成果。需求管理计划描述了如何确认项目需求。范围基准用范围基准与实际结果比较以决定是否有必要进行变更、采取纠正措施或预防措施。2、项目文件可作为确认范围过程输入的项目文件主要包括需求文件将需求与实际结果比较以决定是否有必要进行变更采取纠正措施或预防措施。需求跟踪矩阵含有与需求相关的信息包括如何确认需求。质量报告该报告内容可包括由团队管理或需上报的全部质量保证事项、改进建议以及在控制质量过程中发现的清况的概述。在验收产品之前需要查看所有这些内容。经验教训登记册在项目早期获得的经验教训可以运用到后期阶段。3、工作绩效数据可能包括符合需求的程度、不一致的数量、不一致的严重性或在某时间段内开展确认的次数。4、核实的可交付成果核实的可交付成果是指已经完成并被控制质量过程检查为正确的可交付成果。9.7.2工具与技术1、检查检查是指开展测量、审查与确认等活动来判断工作和可交付成果是否符合需求和产品验收标准。检查有时也被称为审查、产品审查和巡检等。2、决策可用于确认范围过程的决策技术是投票当由项目团队和其他干系人进行验收时使用投票形成结论。9.7.3输出1、验收的可交付成果符合验收标准的可交付成果应该由客户或发起人正式签字批准。应该从客户或发起人那里获得正式文件证明干系人对项目可交付成果的正式验收。这些文件将提交给结束项目或阶段过程。2、变更请求对已经完成但未通过正式验收的可交付成果及原因应该记录在案。可能需要针对这些可交付成果提出变更请求开展相应的缺陷补救工作。变更请求应该由实施整体变更控制过程进行审查与处理。3、工作绩效信息工作绩效信息包括项目进展信息例如哪些可交付成果已经被验收哪些未通过验收以及原因。这些信息应该被记录下来并传递给干系人。4、项目文件(更新)可在确认范围过程更新的项目文件主要包括需求文件记录实际的验收结果更新需求文件。需要特别注意实际结果比原定需求更好的情况或者原定需求已经被放弃的情况。需求跟踪矩阵根据验收结果更新需求跟踪矩阵包括所采用的验收方法及其使用结果。经验教训登记册记录所遇到的挑战、避免该挑战的方法以及良好的可交付成果验收的方法。9.8控制范围控制范围是监督项目和产品的范围状态管理范围基准变更的过程。本过程的主要作用是在整个项目期间保持对范围基准的维护。本过程需要在整个项目期间开展。控制项目范围确保所有变更请求、推荐的纠正措施或预防措施都通过实施整体变更控制过程进行处理。在变更实际发生时也需要采用控制范围过程来管理这些变更。控制范围过程应该与其他控制过程协调开展。未经控制的产品或项目范围的扩大(未对时间、成本和资源做相应调整)被称为范围蔓延。9.8.1输入1、项目管理计划控制范围中使用的项目管理计划组件主要包括范围管理计划记录了如何控制项目和产品范围。需求管理计划记录了如何管理项目需求。变更管理计划定义了管理项目变更的过程。配置管理计划定义了哪些是配置项哪些配置项需要正式变更控制以及针对这些配置项的变更控制过程。范围基准用范围基准与实际结果比较以决定是否有必要进行变更、采取纠正措施或预防措施。绩效测量基准使用挣值分析时将绩效测量基准与实际结果比较以决定是否有必要进行变更、采取纠正措施或预防措施。2、项目文件可作为控制范围过程输入的项目文件主要包括需求文件用于发现任何对商定的项目或产品范围的偏离。需求跟踪矩阵有助于探查任何变更或对范围基准的任何偏离对项目目标的影响它还可以提供受控需求的状态。经验教训登记册项目早期的经验教训可以运用到后期阶段以改进范围控制。3、工作绩效数据工作绩效数据可能包括收到的变更请求的数量接受的变更请求的数量或者核实、确认和完成的可交付成果的数量。4、组织过程资产能够影响控制范围过程的组织过程资产主要包括现有的、正式的和非正式的与范围控制相关的政策、程序和指南可用的监督和报告的方法与模板等。9.8.2工具与技术数据分析可用于控制范围过程的数据分析技术主要包括偏差分析用于将基准与实际结果进行比较以确定偏差是否处于临界值区间内或是否有必要采取纠正或预防措施。趋势分析旨在审查项目绩效随时间的变化情况以判断绩效是正在改善还是正在恶化。确定偏离范围基准的原因和程度并决定是否需要采取纠正或预防措施是项目范围控制的重要工作。9.8.3输出1、工作绩效信息控制范围过程产生的工作绩效信息是有关项目和产品范围实施情况(对照范围基准)的相互关联且与各种背景相结合的信息包括收到的变更的分类、识别的范围偏差和原因、偏差对进度和成本的影响以及对将来范围绩效的预测。2、变更请求分析项目绩效后可能会就范围基准和进度基准或项目管理计划的其他组成部分提出变更请求。变更请求需要经过实施整体变更控制过程的审查和处理。3、项目管理计划(更新)项目管理计划的任何变更都以变更请求的形式提出且通过组织的变更控制过程进行处理。可能需要变更请求的项目管理计划组成部分包括范围管理计划更新范围管理计划以反映范围管理方式的变更。范围基准在针对范围、范围说明书、、WBS或WBS词典的变更获得批准后需对范围基准做出相应变更。有时范围偏差太过严重以至于需要修订范围基准以为绩效测量提供现实可行的依据。进度基准在针对范围、资源或进度估算的变更获得批准后需要对进度基准做出相应的变更。有时进度偏差太过严重以至于需要修订进度基准以便为绩效测量提供现实可行的依据。成本基准在针对范围、资源或成本估算的变更获得批准后需要对成本基准做出相应的变更。有时成本偏差太过严重以至于需要修订成本基准以便为绩效测量提供现实可行的依据。绩效测量基准在针对范围、进度绩效或成本估算的变更获得批准后需要对绩效测量基准做出相应的变更。有时绩效偏差太过严重需要提出变更请求来修订绩效测量基准。4、项目文件(更新)可在控制范围过程更新的项目文件主要包括需求文件可以通过增加或修改需求而更新需求文件。需求跟踪矩阵应该随同需求文件的更新而更新需求跟踪矩阵。经验教训登记册更新经验教训登记册以记录控制范围的有效技术以及造成偏差的原因和选择的纠正措施。9.9本章练习1选择题在____生命周期中项目开始时就对项目可交付成果进行定义对任何范围变化都要进行变更管理。 A预测型B适应型C敏捷型D.迭代型 参考答案A不是规划范围管理过程的输入。 A项目章程B项目管理计划C质量管理计划D需求管理计划 参考答案D关于需求的理解不正确的是。 A让干系人积极参与需求的探索和分解工作并仔细确定、记录和管理对产品、服务或成果的需求能直接促进项目成功 B为更好地对项目进行了解收集需求的过程应在整个项目期间定期开展 C需求是指根据特定协议或其他强制性规范产品、服务或成果必须具备的条件或能力 D需求包括发起人、客户和其他干系人的已量化且书面记录的需要和期望 参考答案B数据收集技术中将实际或计划的产品、过程和实践与其他可比组织的实践进行比较以便识别最佳实践形成改进意见并为绩效考核提供依据。 A.头脑风暴B焦点小组C.亲和图D标杆对照 参考答案D是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。 A系统交互图B决策矩阵C需求跟踪矩阵D.UC矩阵 参考答案C应根据来编制详细的项目范围说明书。 1.可交付成果2.假设条件3.制约因素4.WBS A.123 参考答案A关于项目范围说明书的理解不正确的是。 A项目范围说明书可明确指出哪些工作不属于本项目范围 B项目范围说明书使项目团队能进行更详细的规划并为评价变更请求或额外工作是否超过项目边界提供基准 C项目范围说明书描述要做和不要做的工作的详细程度决定着项目管理团队控制整个项目范围的有效程度 D项目范围说明书不能代表项目干系人之间就项目范围所达成的共识 参考答案D范围基准包括1.经过批准的范围说明书2.项目章程3.WBS词典4.WBS项目5.管理计划C.134参考答案C2简答题请简述确认范围过程与控制质量过程的不同之处。