如何解决项目的范围管理问题

这个案例所反映的问题在信息系统实施中是比较普遍的。在开始实施时a、b公司所碰到的表面上的种种分歧，归结起来本质上主要是项目的范围管理问题。

　　定义项目范围可能是定义一个项目过程中最重要的部分。事实上，如果你不确定你在进行的是什么，以及你所进行的项目的边界在哪里，你就根本不可能成功。管理项目范围是项目管理中最重要的一部分。但是，如果你没有很好地定义项目范围，那么你的项目将不可避免地面临失败的危险。

　　糟糕的范围管理是导致项目失败的致命伤，通常在实施PDM项目时会遇到下列问题：

　　◆ 咨询公司或系统集成商往往有一种“never say no”的气魄。的确，一个实力雄厚的咨询公司是可以通过二次开发和客户化，提出适应客户个性化需求的解决方案。但是，客户化开发需要做的工作，客户往往并不清楚——工作量有多大，由谁来进行，费用是多少，如何配合整体实施进度？不过，如果销售人员对这类问题谈得过深过细，很有可能影响签单。因此，在许多情况下，这些问题被有意回避，成为双方合作和实施中的定时炸弹。
　　遗憾的是，不少软件公司的销售人员并不十分了解PDM系统的原理与概念，甚至不了解本公司产品的功能，至于对行业存在问题的了解就更难说了；他们主要的特长是“关系学”。在接触客户甚至签单的过程中，销售人员往往会过度承诺（over-promise），他们关心的是“签单”，也就是“成交”，而售后服务顾问关心的是“客户满意”，也就是“成功”。
　　“成交”和“成功”虽然仅有一字之差，但是公司对两类人员有不同的考核指标，对前者的考核是完成多少销售额，对后者的考核是完成多少服务天数。这种公司内部销售和技术支持部门之间的矛盾，对公司和用户都非常不利。

　　◆ 一旦项目开始进行了，在进一步讨论项目实施的范围时，客户与软件公司就会发生这样那样的分歧，一种可能是，客户不停地要求软件公司完成超出原来商定范围的工作，或者和原来商定范围不同的工作；还有一种可能就是，软件公司以超出合同范围为由拒绝提供实际上应该要做的工作。

　　◆ 范围蔓延：很多项目经理能够意识到大的范围改变，但是对于小的改变却没有那么敏感了。现在有一种趋势，就是不断地进行项目，不断添加额外的工作而并不经过仔细的考虑。范围蔓延指的是当项目接受了太多小的变化之后所出现的情况。当所有这些小的变化结合在一起，项目小组才意识到需要做的额外工作太多，以至于要超出预算，延误工期。

　　◆ 没有发起人的同意：有时软件供应方项目经理会从最终用户，或者客户经理那里收到变更请求。由于这些人都是客户公司内部的，他们认为这些请求都应该被接受。很多项目陷入麻烦是因为他们认为他们获得了进行范围修改的批准，但是后来却发现有权决定这种变更的人—发起人，并没有同意这样做。

　　◆ 项目小组的责任：由于项目小组成员和客户有很多联系，他们是最经常会遇到范围更改请求的人。因此，整个项目小组必须理解范围变化管理的重要性。他们必须在范围变化发生的时候立即发现它，并且及时把它反馈给项目经理。如果他们自己答应进行一些额外的工作，他们的这种行为就很有可能导致他们不能够按时完成自己的工作，从而危及整个项目的进行。

　　科学的范围管理是项目成功的第一步，它的基础是一个科学的范围管理流程，其中包括范围规划、范围定义、范围确认和范围变更。

　　我们在实施PDM项目时必须意识到范围变化本身并没有什么不对。也就是说在项目进行过程中修改范围并不是什么坏主意。事实上，很多时候，这是一件好事。首先，客户和软件供应方通常都不能确定最终解决方案所需要的所有的需求和功能。其次，就算他们可以，商业环境是随着时间不断变化的，因此项目的需求也会发生变化。如果你不能够容纳变化，最终的解决方案就会达不到应有的价值，或者它甚至有可能是无用的。

　　定义范围变化管理流程最好的时机是在项目开始之前（作为项目管理程序的一部分）。但是，如果你确实没有建立一个好的流程，任何时候开始都不算太迟。项目管理必须安排一个暂停的时间，由实施双方一起来鉴定并满足范围变更的请求。然后每个人都要学习新的流程。

　　为了解决a、b公司目前在实施PDM时所遇到的问题，我建议双方的项目经理要尽快坐到一起，对于在合同框架体系下承诺的内容要清晰地表达出来，澄清模棱两可的描述。

　　对于在合同外的需求或者变更需求，需要通过范围管理的变更流程来控制。对要实现的系统功能有个优先级排序，哪些是至关重要的，哪些是重要的，哪些是需要的，哪些是锦上添花的。这对后面的资源安排很有帮助，当然重要程度需要双方共同讨论加以确认。在此基础上，必须形成一份完整的需求规格书。双方充分沟通讨论，形成统一意见，交由项目指导委员会审批。批准后，就成为项目范围的基准线(baseline)，以后的变更就要更改该文件。

　　其次，还要定义一个实际可行的范围管理流程，这个流程应该包括确定变化，评估变化的商业价值，评估对于项目的影响，一些小的变化，项目经理可以适当调整项目进程，但是一些比较大的变更需要将这些信息提交给项目发起人进行评估。发起人然后可以决定是否同意该变化。如果同意，发起人还应该理解它对于项目的影响，然后为它追加费用，延长项目时间。

2005.10.8 来自：赛迪网-中国计算机用户

--------------------------------------------------------------
项目经理如何做好范围管理？ 2005.10.8

范围管理保证项目包含了所有要做的工作而且只包含要求的工作，它主要涉及定义并控制哪些是项目范畴内的，哪些不是。范围管理的基本内容包括：项目启动、范围计划编制、范围核实、范围变更控制等等。以下所讨论的是其中比较重要的部分。

1．编制范围计划

“公欲善其事，必先利其器”。一个项目经理要想真正管理好项目范围，没有必要的技术和方法是肯定不行的。国外曾经有人对项目失败原因进行调查，其中计划被放到了首位，可见它在项目管理中的重要性。

我们这里首先强调的就是周密地做好范围计划编制。范围计划编制是将产生项目产品所需进行的项目工作（项目范围）渐进明细和归档的过程。做范围计划编制工作是需要参考很多信息的，比如产品描述，首先要清楚最终产品的定义才能规划要做的工作，项目章程（典型的例子是合同）也是非常主要的依据，通常它对项目范围已经有了粗线条的约定，范围计划在此基础上进一步深入和细化。 　　范围计划中究竟应该包含哪些内容呢？不同的计划详尽程度自然不一样，其中范围说明和范围管理计划必须包含在内。

范围说明在项目参与人之间确认或建立了一个项目范围的共识，作为未来项目决策的文档基准。范围说明中至少要说明项目论证、项目产品、项目可交付成果和项目目标。项目论证是商家的既定目标，要为估算未来的得失提供基础；项目产品是产品说明的简要概况；项目可交付成果一般要列一个子产品级别概括表，如：为一个软件开发项目设置的主要可交付成果可能包括程序代码、工作手册、人机交互学习程序等。任何没有明确要求的结果，都意味着它在项目可交付成果之外；项目目标是要考虑到项目的成功性，至少要包括成本、进度表和质量检测。项目目标应该有标志（如：成本、单位）和绝对的或相对的价值（如：少于150万美元等）。不可量化的目标（如：“客户的满意程度”）要承担很高的风险。

范围管理计划是描述项目范围如何进行管理，项目范围怎样变化才能与项目要求相一致等问题的。它也应该包括一个对项目范围预期的稳定而进行的评估（比如：怎样变化、变化频率如何及变化了多少）。范围管理计划也应该包括对变化范围怎样确定，变化应归为哪一类（当产品特征仍在被详细描述的时候，做到这点特别困难，但绝对必要）等问题的清楚描述。

2．范围分解

计划明确了，然而该做哪些事情似乎还是一把抓，因为完成项目本身是一个复杂的过程，必须采取分解的手段把主要的可交付成果分成更容易管理的单元才能一目了然，最终得出项目的工作分解结构（WBS）。恰当的范围定义对项目成功十分关键，当范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利的后果。

比较常用的方式是以项目进度为依据划分WBS，第一层是大的项目成果框架，每层下面再把工作分解，这种方式的优点是结合进度划分直观，时间感强，评审中容易发现遗漏或多出的部分，也更容易被大多数人理解。Microsoft的项目管理工具Project就可以自动为各个层次的任务编码。

3．范围变更

一个项目的范围计划可能制订的非常好，但是想不出现任何改变几乎是不可能的。因此对变更的管理是项目经理必备的素质之一。变并不糟糕，糟糕的是缺乏规范的变更管理过程。范围变更的原因是多方面的，比如用户要求增加产品功能、环保问题导致设计方案修改而增加施工内容。项目经理在管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。我们强烈建议企业的项目管理体系中包含一套严格、高效、实用的变更程序，它对管好项目至关重要。