在管理一个项目时，对其下定义及进行策划仅仅是让您迈出了成功的第一步。在您为此项目布署好计划后，您还得去履行它。您务必要确保您同意交付的此项工作是在规定的时间及预算范围内完成。另外，在制定计划的部分过程中您也要有所保留以备应付出现一些不可规避的问题，一旦项目启动，客户可能会无止境地要求您去做远多于或远不同于起初所协议的事宜。这时，您必须使用范围变更管理。如不然，您最终做的工作将远多于最初协议好的并且在预算上也得不到改善。换言之，您在自找麻烦。
范围管理始于范围定义
在对一个项目进行诠释之前，定义范围或许是最为要紧的部分。实际上，如果您不确定您要做什么，并对此项目的范畴一无所知，您将毫无成功可言。管理范围是管理一个项目至关重要的一面。然而，如果您未曾做好定义范围这一步，管理范围也几乎是行之无效的。
为范围下定义旨在清楚地描述您的项目的逻辑范畴并在此上达成的协议。范围综述被用来指出什么是此项目份内的事，什么是份外的事。若您对范围定义到的方面越多，您的项目将会被做得越好。以下信息类型可能有所帮助。
项目范围内和范围外的任务类型（业务需求，当前状态评估）
范围内和范围外的主要的生命周期过程（分析，设计，测试）
范围内和范围外的数据类型（财政，销售，雇佣）
范围内和范围外的数据来源（或数据库）（账单，总分类帐，工资表）
范围内和范围外的组织机构（人力资源，制造业，厂商）
范围内和范围外的主要职能（决策支持，数据登记项，管理报告）
在适当的时候有一个行之有效的范围变更过程
项目经理和项目组必须意识到范围变更不是什么坏事。也就是说，对一个起步阶段的项目进行范围变更绝非一个有害的提议。事实上，在一些情况下，这是件好事。首先，客户们通常都无法完全指出最终的解决方案所具备的全部条件和特征。其次，即便他们说得出来，事物也会随着时间有所改变，因此对项目的要求也相应要变。要知道，项目本身就是一个日臻完善的过程。
如果您不能接纳变更，最终所得到的解决方案会与理想中的相差甚远，或者它实际上会面目全非、一无是处。因此，您会希望客户能够在项目期间指出需要变更的地方。当项目经理未能在项目变更上做到先发制人，问题就会接踵而至。此过程应包括识别变更，鉴别变更的商业价值，判定对项目的冲击，并且将结果信息反馈给项目主办人以作评估之用。主办人能判定这个变更是否应该进行。如果变更需要进行，主办人也应当会知悉其对项目造成的冲击，并且针对此变更增拨资金和延长时间。
范围变更管理的常见问
项目组在进行范围变更管理时会遇到许多问题。
范围蠕变：一些项目经理认为执行大范围的变更不见得会有进行小范围变更做得那么仔细。盲目前进和增加工作量而不多花心思是一个趋势。范围蠕变是指当一个项目拟进行大量小的变更时所迸发的问题。即当所有的小变更综合在一起时，该项目组会发现它要背负太多的额外工作，预算再也无法控制，并且交付时间也会有所拖延。
未经主办人批准：很多时候，一个项目经理会收到来自于最终用户，股东，或客户经理们的变更请求。既然所有这些人都属于客户组织，项目组倾向于认为这些请求应该接受。这是大错特错的。最终用户会经常提出范围变更要求，但是他们没有能力去批准进行这些变更。甚至一个客户经理也不能批准范围变更的请求。唯一有权的人是主办人（除非主办人将其权力委托给了其他人）。一些项目之所以会陷入困境是因为项目组自以为他们得到了批准去进行范围变更，但是后来却发现真正有权的人，即主办人，并没有同意。
项目组的责任：既然项目组成员与客户之间有很多的交流机会，他们就是最常收到范围变更请求的人。因此，整个项目组必须知晓范围变更管理的重要性。所有的组员都必须察觉到出现的变更并将它们反映给项目经理。如果他们自己接纳了额外的工作，那么他们的任务很有可能要滞后完成，这会危害到整个项目。
亡羊补牢为时未晚
如果您发现您的项目就要超出预算且超过交付时间，要尽力去查找原因。一些情况下，您会发现您正在做的工作仅仅是超出最初协议范围的工作。为范围变更管理下一个定义的最好时机是在此项目开始前（作为项目管理过程的一部分）。然而，如果您没有在合适的时候做好这件事的话，亡羊补牢犹为时未晚。项目经理必须定下一个短期的暂停时间来和客户共同处理范围变更请求的审查和批准。然后每个人必须对新的变更有所认识。
如果这么做至少有一个好处的话，那就是该项目组和客户能直接看到：既然此项目已经陷入困境，那么不控制范围会出现怎样的后果。于是他们能更好地理解范围变更管理的目的，并且会更乐意去处理未来更严峻的问题。
|
|
|
|
|
|
|
您的位置：
