项目范围管理:什么是项目范围管理?
每个项目都有一个范围。它定义了要生产什么。它是由客户在业务用例文档中，在需求的正式声明中作为项目，客户和项目团队之间商定的章程，作为一个工作计划，规定了项目的时间和成本项目团队准备的项目计划的交付。
项目管理最近，范围的复杂性有所增加。数字工具支持项目管理通过各种不同的通信媒体。没有对各种输入和输出的管理，项目范围就会脱离控制。因此需要一个有效的范围管理系统．改变项目范围，项目成本和时间表也会改变。最终的交付成果也会受到影响。
有些项目在项目文件中有正式的范围说明，而其他项目则使用项目计划的工作分解结构(WBS)。无论哪种方式，范围声明中包含的任务都在范围内。其他一切都超出了范围。
对于较大的项目，PMBok已经制定了一个多步骤的过程。较小的项目也将使用这种方法，将一些步骤合并在一起。
的创建有效的范围管理所涉及的步骤项目将包括:
内容
1.创建正式范围管理计划．
实际上，这是一个三步过程:
a.范围规划
这流程建立范围管理环境，并根据项目文档开发，并与项目涉众达成一致。与变更管理，范围管理将直接与变更管理计划联系起来。
b.需求收集
需求收集是与所有人的详细交互利益相关者了解他们的需求和期望是什么。这是一个迭代的过程。输出文档还应该为管理他们的期望而制定。
c.范围定义
当您计划了范围并定义了项目可交付成果时，您现在就可以精确地记录什么在范围内，什么不在范围内。这个声明将成为项目圣经，贯穿整个项目以确定活动是否在范围内。
2.创建工作分解结构(WBS)
在这个阶段，WBS现在可以处理交付可交付成果所需的任务、资源和成本。经同意并签署的WBS将有效地确定项目范围。
3.项目验证
在定义项目可交付成果，项目范围，以及如何在整个生命周期中管理项目，现在是时候验证这些陈述和假设了。
两个步骤:
- 让项目文件得到涉众的批准和签字。这将修复范围并防止以后的任何恢复。WBS可能需要修订。
2.我同意审批程序。完成的任务就这样结束了。涉众需要签署里程碑。如果要根据交付情况向外部承包商支付报酬，这一点就尤为重要。
4.变更控制
对范围的更改不可避免地会跟随需求的更改。这将是总体范围的一部分管理环境，并从项目文档和利益相关者的输入开发。
让涉众参与这项工作是至关重要的，只要让他们理解一旦定义和签署，项目范围就不能在正式程序之外更改。如果他们确实需要更改，他们将了解如何请求更改，以及提交请求后会发生什么。
范围的变化
然而，就像企业的年度报告一样，定义的项目范围是项目最初达成一致时所需内容的快照。生活在继续，项目的基础也会改变。变化会发生，有意的和无意的。他们改变了项目范围，这就是范围管理出现的原因。
变更可以来自涉众，以响应不断变化的业务需求。有时，当他们看到项目的实际实施时，他们会改变主意。在一个IT项目中，他们可能想要更改用户屏幕上的布局和文本，尽管在早期阶段已经同意了。
变化可能来自外部来源。例如，在我们的建筑示例中，健康和安全法规的更改可能会强制更改任务的执行方式。
通常在项目中，个人对项目应用小的增量范围外的变更，每个变更对项目关键路径的影响很小或没有影响。尽管如此，他们可能会这样做，一个任务的变化可能会对另一个任务产生意想不到的影响。
未经授权的变更的实现产生了一个大多数pm都熟悉的术语——范围蠕变，它是首要的范围管理功能限制范围蠕变。
范围蠕变有以下几个影响:
1.该项目没有达到最初的设计目标。用一个古老的比喻，最初被设计成马的东西变成了骆驼。
2.目标时间表和预算没有实现。
3.随着项目的进行，客户对交付的产品并不满意，并且会拒绝任何进一步的时间或金钱要求。
那意味着需要管理项目范围。您需要理解范围管理是一种黑色艺术，因为没有权威的方法来做它。这需要外交、实用主义和对大局的全面理解。
有三个基本的a范围管理和范围渐变的方法:
1.不允许对范围进行任何更改。
2.允许变更，但必须经过变更控制的批准。
3.允许所有未经授权和授权的更改。
1.没有变化
这是理想的，但很少能实现。
不可更改意味着项目文档中列出的项目范围是项目的圣经，不会被更改。提交给PM的任何超出范围的更改要么被丢弃，要么在项目完成后放入待处理文件中进行考虑。
没有变更控制，因为没有预期或接受范围变更。
这里的困难通常是项目管理客户的团队和管理。
当客户直接向团队成员询问时，一些小的变更往往会被忽略。他们的借口是，这只是一个很小的改变，不会花费额外的时间和成本。团队成员实现所请求的更改以使客户满意。危险在于意外后果法则。
如果不考虑小更改的影响，它可能会影响项目中的另一个任务，而累积的更改可能会影响项目本身。这个小变化可能与另一个小变化冲突。
无论哪种方式，项目质量都会受到影响，而且可能一些项目预算被花在了未经授权的活动上。
在不允许任何更改的环境中，必须让项目团队成员和客户都清楚，不允许任何更改。无论如何要将它们保存在待处理文件中，它们将在稍后阶段得到考虑。
没有办法逃避，未经授权的改动会被发现。根据项目范围来衡量可交付成果的质量审计将突出微小的变化。
然而，这种方法通常被认为太不灵活，而且有时紧急或强制的业务需求会导致必须实现的项目变更。
2.变更控制
正如我们已经讨论过的，范围更改有时是必要的，需要一种机制来管理它们。变更控制机制是控制范围蠕变的第一步。
简单地说，变更被请求，然后由适当的机构(通常是变更控制委员会)进行考虑，然后被授权、拒绝或等待。
委员会可能要求提供进一步的资料和分析，以帮助作出决定。他们需要知道对时间表和预算的影响，也许还需要知道与执行变更相关的外围问题。
以这种方式管理范围渐变将从技术练习转变为人员管理。一些客户工作人员希望他们的请求得到毫无疑问的执行，如果这些请求被变更控制委员会拒绝或搁置，他们将不会感到非常高兴。
一个精明的PM会知道什么时候考虑到更大的项目蓝图是最好的让步，即使在其他情况下请求会被搁置或拒绝。
变更控制委员会的使用将为PM提供一些保护，但是可以预期不时会有一些激怒的羽毛。
3.实施的所有更改
公平地说，不受控制的变更应用是PM的噩梦和灾难的配方。对于小型项目来说，这可能并不完全正确，但是项目景观中到处都是失败项目的骨架，其中范围渐变没有得到控制。
至少，项目的时间表和预算将无法满足，并且PM将在证明项目延迟和额外成本方面走一条艰难的道路。你会有一个不可控的项目，很可能不可控。
客户和团队成员会对工作计划和可交付成果的频繁变化感到失望和不满。
项目的交付成果可能不像最初设想的那样，客户会不满意。项目很可能会进入一个永远不会完成的状态。
总之，这不是我们该呆的地方。
