我经常说,确定范围是项目管理中最难的部分。所以对于一个正式的项目,你需要一个好的范围管理计划。它将帮助您导航范围过程,并充分利用您的所有努力工作。
但是范围管理计划只是项目管理的一小部分。在PMI的项目管理知识体系(PMBOK指南)第6版中,它是10个知识领域之一的六个过程之一的两个输出之一。那么,你可能会问,我为什么要为我们的一位大向导选择这个话题呢?
这里有一个故事。
在这篇文章中,我们将介绍:
在一开始就设定错误的范围将导致项目失败。另一个常见的失败来源是无法控制你的范围,导致范围蠕变进度和预算都超出了。而且,如果你在将产品移交给新的受益所有者之前未能正确验证产品,你将会遇到一大堆麻烦。
您的范围管理计划将列出保护您免受所有这些失败影响的流程和程序。
如果这还不够,一个具体的问题和一系列的问答促使我写这篇文章。目前,在我的网站上,观看次数最多的视频(约70k次)”PM Dictionary:什么是…”系列:项目范围是什么?
这是……
这段视频让一名观众提出了以下问题:
范围管理计划和项目管理计划的区别是什么?
换句话说,范围管理计划和项目管理计划孰先孰后?
我想用这篇文章来扩展我给出的答案。
如果您感兴趣,我在本文底部记录了这三个问题和答案。
以下是我的回答:
范围管理计划是关于你将如何:
- 确定并记录项目的范围
- 验证您交付的活动和产品是否符合规范
- 监视和控制你的范围,以确保范围的变化:
- 满足不断变化的需求,
- 得到一个可靠的签名,然后
- 正确执行
让我们把范围管理计划放在上下文中。我们将从两个角度来看待它。在…的范围内:
简单地说,范围管理计划是更广泛的项目管理计划的一部分。因此,对于较小的项目,它可能是较大文档中的一个部分。但是,对于一个大型项目,它可能是一套相互关联的文档中的一个。
这是PMI在其项目管理知识体系(PMBOK指南)第6版中如何表示它的示意图版本。
新出现的项目管理计划的要素是计划范围管理过程的输入,而范围管理计划是项目管理计划的输入。这听起来可能是令人担忧的循环。但是,就像衔尾蛇一样,这正是它应该有的样子。
计划你的项目,以及你将如何交付和控制它,是一个过程:
关于项目范围和项目计划的其他方面之间的关系,最重要的是一致性。每个部分必须与其他部分保持一致。
你的范围管理计划是更广泛的项目范围管理主过程的一部分,项目管理知识指南将其分为六个组成部分的过程,可以如下所示……
你是否为自己而学习CAPM或PMP,或者开发一个实用的方法来计划本月的新项目,您的范围管理方法将类似于图:
首先,需要明确的是,制定范围管理计划与定义项目范围是不一样的。你可以在我们的长文中了解更多:项目范围:你需要知道的。
您的第一个重大决定是如何与您的项目管理计划集成。
在可能性范围的一端是一个完全独立的范围管理计划。这必须与你的项目管理计划一致,但可以作为一个单独的文件存在,并重复任何重叠的部分。
另一个极端是在你的项目管理计划中包括范围管理。这是我的总体偏好。
无论哪种方式,你在项目管理计划上已经做的任何工作都将成为制定范围管理计划的输入。重叠和接口的具体例子包括:
你还需要考虑到:
在下一个主要部分中,我们将讨论范围管理计划的内容列表。但是你需要从可能的组件的长列表中抽取出你的项目所需的组件。
最重要的是解决问题如何你将管理你的范围:
这是您(项目经理)将领导的一个过程。但是你也要让你的项目团队参与进来。还要考虑让关键的涉众参与进来——特别是当你决定你的验证、接受和变更控制过程时。
您还需要项目发起人和治理层的参与。如果你是受阶段关口流程/关口审查例如,一个令人满意的范围管理计划可能是通过评审的必要标准。同样,您的项目委员会或指导小组可能需要在您的计划上签字。
顺便说一下,关于项目管理和与赞助商合作的更多信息,我建议:
最后一部分为范围管理计划列出了一长串可能的部分。你很少需要所有这些。还有一些你想要合并成更少的部分。
总之,我们将讨论的部分是:
但是,要清楚……
我并不是说你需要所有这些。但是,您需要从这些部分中选择适合项目范围管理计划的部分。
使用您的介绍来设置项目的上下文,并将范围管理的治理置于其中。还要记录范围管理计划与其他文档的关系。
这一部分是核心,必须涉及两个组成部分:
你也会想要回顾那些影响你思考的输入。
此部分将向外引用其他文件,如您的项目管理计划,其中包含相关信息。同样地,它可能会突出您已经选择包括在范围管理计划中的计划,其他项目流程将会调用这些计划。其中包括我们在下面列出的部分,比如:
通常,范围管理的成本是项目管理更广泛成本的一部分。当然,这不是记录整个项目预算的地方。但是,如果您预计活动范围的特定成本,请将其记录下来。例子包括:
在本节中,您将记录那些对范围或范围更改决策具有特殊影响的涉众。您可以选择在这里简单地识别它们,并将您的分析和计划参考您的利益相关者参与管理计划。或者你可以在这里创建一个范围涉众参与计划。
通常,范围确定过程将遵循需求识别步骤。因此,在这里,您将记录需求收集的结果,以及您计划如何将其保持在变更控制之下。
在需求识别期间,您将发现涉众需要什么。您将结合一对一和一对多会议,并使用远程通信和调查工具来实现这一点。大多数项目都有大量来自广泛的涉众群体的需求,因此找到一种方法来衡量优先级或每个需求,对每个涉众来说是很有价值的。一个很好的问题是“那又怎样?”“找出满足或不满足要求的后果。
让我们先忽略一件事。PMBOK指南(第6版,第5章,项目范围管理的关键概念部分)明确规定;
项目范围.的工作提供具有指定特性和功能的产品、服务或结果。
强调工作是我的,不是PMI的。所以,“范围”就是工作。除了PMBOK指南同样清楚地指出:
在WBS的上下文中,工作是指工作产品或可交付成果活动的结果而且而不是活动本身.
再说一次,这是我的重点,不是PMI。所以,范围看起来很混乱。这是我的经验(但我不能肯定它是否普遍正确):
然而,无论你采用哪种方法,选择一种,避免混合术语。对于任何一种情况,你都需要:
你可能还想包括:
范围声明是项目定义的核心部分。它建立并记录涉众的期望。因此,如果你做对了,它将降低项目过程中范围变更的风险。
的工作分解结构(WBS)是你们进行有效管理的主要工具,也是你们范围管理计划的一部分。一旦你建立了它,你就有了项目的平台:
这可能经常与……
WBS字典通过为每个工作项列出以下内容来支持你的工作分解结构:
要构建项目计划,您可以开始添加更多信息。例如,其他项目可能包括:
你的范围说明书和WBS可能经常涵盖项目的…
可交付产品或产品可以是你可以触摸和看到的物质。但它也可以是你可以经历的事情,比如培训课程、事件或流程改进。这些是你的赞助组织委托你制作的东西。因此,您需要将它们包括在范围管理计划中,以及它们必须满足的规范和标准。
使用本节讨论如何管理范围信息。例如,您可能会包含产品规格模板。你还需要所有项目文档的版本控制程序——包括你的范围管理计划!
范围确认是PMBOK指南中六大范围管理过程之一。说明你将如何验证你的交付成果符合你最初的范围和规格。
您的客户或赞助商也应该正式接受并签署您的交付成果,因此这可能经常与…
在新的受益所有人(项目发起人、客户、运营经理等)正式接受交付成果之前,交付成果还没有完成。这可能并不意味着他们已经收到了交付物:只是他们批准了交付。
您还可能有一个范围接受阶段,在这个阶段,新的受益所有人批准范围声明和规范集。这意味着,只要产品满足其验证标准,后续的验收是自动的。
这包括:
我们将在文章中介绍如何处理更改请求:项目变更控制在线课程指南。
在这里,您将记录谁拥有范围管理的权限和责任。这通常是你(项目经理)的责任。但是,项目发起人、团队成员和涉众也有自己的角色。
您还可以在这里覆盖治理安排——特别是如果您在变更控制部分没有这样做的话。这让我想起了一个特定的角色或一组角色:变更控制器,以及她或他可能拥有的任何团队。
团队领导和团队成员将各自扮演一个角色,因为范围的每个部分将位于工作流中,因此是整个项目团队的一部分的责任。
我建议您将姓名、角色和职责列成表格,如下面的例子所示。或者你可以用RACI图或线性责任图.
这可能需要你的项目管理计划的一部分。在一个更复杂的项目或计划中,产品、结果和利益之间的相互关系与每个产品的规格同样重要。因此,您将需要一个流程和计划来管理这些配置。
这可能需要你的项目管理计划的一部分。我们做项目是为了获得利益。福利管理计划是一种方法,通过它你将建立一个过程,以确保你提供这些福利。
如果你对这篇文章有任何想法或问题,请在下面的评论中告诉我们。我们会回复每一条评论。
范围管理计划和项目管理计划的区别是什么?
换句话说,范围管理计划和项目管理计划孰先孰后?
项目管理计划是一个更大的东西——我涵盖了项目的各个方面:范围、进度、资源、预算、质量、H&S……你的范围管理计划是其中的一个组成部分。它列出了:范围的初始声明,以及你打算如何处理范围的变化,以及监督和签字交付。
哪个先来?是鸡。不,是鸡蛋。
严肃地说,项目计划是一个迭代的过程,在这个过程中,各个方面被细化,并触发我们审查我们已经有临时声明的其他方面。我们的目标是完全自我一致性。
也就是说,定义范围是一个早期阶段的活动。在定义阶段,我们定义目标、目的和范围。然后,我们在规划阶段细化范围,使其更加精确。看看这个视频项目层次结构而且什么是莫斯科分析?我们使用MOSCOW分析在一开始就帮助定义范围。
非常感谢您的快速回复,但您认为我们已经通过了计划流程和启动阶段的开始,我认为我们还在开始阶段。
那么,为什么项目管理计划会作为范围管理计划的输入出现呢?我想这就像,我们还在计划的起步阶段,到目前为止我们还没有任何项目管理计划,我们还在定义范围的过程中,所以我们得到了项目管理计划,把它作为范围管理计划的输入。
*根据PMBOK
4.2.3.1项目管理计划
项目管理计划是描述项目将如何执行、监控和执行的文件
控制。它从规划过程中整合和巩固所有的子计划和基线。
我认为答案在于计划的迭代性质。从最初阶段开始,我们开始制定项目计划,同时制定范围声明和范围管理计划。两者相互促进。
如果我说我觉得两者之间的区别有点做作,我希望PMI不会不高兴。在现实世界中,它们通常是同一文档的一部分。
再次感谢您的兴趣和快速回复,
但是友好地说,我还是很困惑!!
撇开规划的迭代性质不谈,我们是平行规划还是波浪规划?
例如,我们可以在收集需求之前定义范围吗?我们可以在获得需求文档之前或同时拥有范围声明吗?
我认为有些规划可以并行进行,但有些则不能,总体规划或项目管理计划是所有规划过程的结果和集合,
这可能会让我们回到这个问题:建立项目管理计划的第一步是什么?是范围定义还是一组并行进行的计划过程?在这里,如果回答了两个问题中的一个或两个,项目管理计划仍然是一个结果和一个输出,我们不能在进行任何审查或改进之前,将其视为计划早期阶段的一个组成部分的输入。
你提出了很好的问题,揭示了这个话题的复杂性。我们有不同的方法来做计划,也有不同的方法来确定范围,这种格式不能公正地回答你的问题。
所以,我已经把你的问题添加到我的专题文章的主题列表中OnlinePMCourses.com.有时(但不是马上,因为专题文章是全面的,是提前计划好的)我会写一个1500 - 2500字的答案*.
与此同时,下面的文章可能太基础了,但它可能对你有帮助://www.worldclime.com/define-project-scope/
*实际上是3000。
Mike Clayton博士是英国最成功和最受欢迎的项目管理培训师之一。他是14本畅销书的作者,其中4本是关于项目管理的。他还是一个多产的博客作者,并为ProjectManager.com和项目管理协会期刊《项目》撰稿。在1990年至2002年期间,Mike是一名成功的项目经理,领导大型项目团队并交付复杂项目。2016年,Mike推出了在线课程。
会话过期
请重新登录。登录页面将在一个新选项卡中打开。登录后可关闭并返回本页。