如何避免项目范围蔓延

Posted 2020-10-30 好人good

如何避免项目范围蔓延

为什么范围蔓延经常发生？该做些什么事情才能管理好范围？

你是否曾在边界扩大了的项目里工作过？

或者更为重要是，你是否曾在范围没有扩大的项目里工作过？

范围蔓延通常被定义为：计划之外的项目规模扩大。我们如何避免它？是否可以既有效率又有效果地控制和管理我们的业务流程改进项目？答案是，完全可以！几乎每个参与过项目工作中的人都遇到过项目范围蔓延的问题。这就像压缩海绵，当它掉入水中时会发生膨胀，变成原来尺寸的10-20倍，这是因为它的边界（塑料胶囊）被溶解了。同样，项目边界的消失也会导致项目范围蔓延。为了防止范围蔓延，我们有必要正确地去定义问题根源。

如果我们分析范围蔓延的根本原因，可以发现以下主要问题：

错误地定义了流程以及没有认识到所有流程都是相互连接的。

错误的人在定义范围。

与项目相关的术语没有被定义。

没有定义流程之间的高层次界面。

忽略了对这些分界面的“体检”工作。

 没有意识到这样一个问题：项目的某些方面会使项目规模变得很大以至于无法管理。

1、 错误地定义了流程以及没有认识到所有流程都是相互连接的。

这些问题不是与我们做过的工作有关，而是与没做过的有关。所有问题皆始于组织如何定义业务流程。当问及业务流程如何定义时，我经常得到这样一些回答：它是使输入变成生产结果的一组业务活动。流程有两个特点很少被提到：第一，几乎所有的流程都是跨职能的。第二，几乎所有流程都是相互连接的。如果你项目中的一个“流程”只包含了一个职能部门，那么极有可能是：你原始的项目范围只包含了流程的一部分，到最后，项目范围将包含整个流程。

比如一个公司希望改进应付账款“流程”，这做得到么？应付账款确实是使输入变成生产结果的一组业务活动。但是，我们必须要问：为什么非要一个输入？当每月信用卡账单寄来的时候，我也不得不问同样的问题。我有账单，因为购买了物品。因此，在一个公司里，如果我们想改进应付账款，就必须检查在采购这个环节上发生了什么。然后，如果我们购买了物品，接下来发生了什么？我们接收了这项物品。现在，我们也应该把接收包含在内，因为我们不愿意为那些没有接收到的物品付钱。当我们接收到物品后，如不直接使用的话，它们就会入库。那么我们就要同库存人员沟通，以确保不出现库存问题。在使应付账款“流程”确实有效之前，我们必须确保充分利用了所有协商好的折扣条款。这些条款是通过合法协商而得到的，这样的话，就需要法务部参与到项目中。最后一个问题：谁来选择供应商？有供应商筛选流程么？我们可以暂且认为筛选流程发生在市场部。我们还可以列出更多的情况，但在这里只是举个简单的例子。项目的范围变化了多少？从一个职能部门内的应付账款开始，拓展到采购、接收、库存控制、法务、市场。现在，我们的项目与一开始相比大了5倍。

另一方面，我们可以仅仅改进应付账款，毕竟包含其他类别的话会让项目更加复杂，那意味着有人不得不去协调跨职能所需的资源。在这种情况下，我们要对应付账款“流程”进行重新设计以便产生更有效率的付帐单。然而，我们从来没有充分利用折扣，我们从十个供应商那里购买办公用品，为我们从来没有接收到的物品付款，或者为我们接收了但漏到了不合适的组织部门里的物品付款。有人会产生疑问：为什么没有从应付账款改进项目中获得商业利益？

 

2、错误的人在定义范围。

引起流程改进项目范围蔓延的第二个原因是：我们并不经常有正确的成员来定义流程。成员们必须是相关职能部门的高级经理，他对业务及存在的问题有非常全面的认知。定义流程的边界是这些成员的职责。比如，确定流程从哪里开始哪里结束。这些团队成员还必须具备调动资源的权利。以防项目边界被界定了，但是项目所需的资源却找不到的情况发生。

让我们再来看看订单管理流程改进项目。这个流程是否开始于电话铃响？或者开始于签订单？还是开始于信用被认可，产品的有效性被确认？这个流程在什么时候结束？它是否结束于“已发运”？还是结束于产品送达或产品验收完毕？我们定义项目边界所采用的方式会一次又一次地影响项目本身。这会影响到我们从什么人那里得到输入，我们的核心团队应该包含哪些人，我们要衡量什么，我们如何设立我们的愿景，当我们重新设计流程或者改进流程时，哪些范围的变化应该被列入。

当由正确的团队来定义范围时，这个团队也可以保证资源的获得。不要让任何其他人来做你的工作，这会给范围蔓延以可乘之机。

 

3、与项目相关的术语没有被定义。

我们必须要讨论与项目相关的术语，以便让所有项目参与者及流程当事人对术语的含义达成共识。大多数时候，我们“假定”每个人对流程的理解保持一致，这是流程项目过程中的众多“假定”之一，这些假定通常都不准确。我们虽然假定每个人对流程及流程中用到的术语都有一个清晰的认识，但不幸之处在于，这些假定仅仅是假定，并非事实。只有当我们深入项目并开始质问、反思时，我们才能精确地定义出这些术语。通常，术语的定义也会使项目定义发生改变。举个例子，提到美国的批萨，我们脑海中就会形成一个非常明确的画面。但是，假如你在意大利、匈牙利或者其他国家点一份批萨时，送来的很可能是非常新奇的类似于矩形的批萨，有些批萨上面还有有煎蛋和玉米。这表明，我们不能假定所有人都理解项目中所使用的术语。比如对于会计人员，Fasby应该是FASB（美国财务会计准则委员会），但你如果不是会计人员，就不会明白这个双关语，可能会以为这只是一只狗的名字。

 

4、没有定义流程间的高层次界面。

流程间的高层次界面必须定义，为此必须要知道项目所考虑的流程是什么，该流程与其他流程的分界面是什么。换句话说，哪些流程影响了该流程，或者被该流程影响了，是什么产生了界面，或者是什么在流程及其他利益相关者之间流动。我们把这些界面定义为IGOEs（输入、支配、输出、使能）。通常，一个组织很难定义这些界面，因为他们连流程本身都还没有定义清楚。因此，如果一个组织没有定义它的流程，那如何能确定项目的范围？典型的情况是，项目中涉及很多的组织职能模块，这说明我们从一开始就意识到范围会蔓延（缺乏准确的流程定义）。因此，我们需要定义一些高层次流程界面。

那么，需要花多长时间来定义高层次流程？我们的项目时间有限，而且不能在与项目无直接关联的事情上投入太多时间。通过经验可得，如果有正确的人在会议室内，这项工作在半天内就可以轻松完成。从一开始就投入时间来定义高层次流程是值得的，这能确保你知道流程改进项目在这个大流程图中处在哪个位置。大流程图的真正价值在于我们能不断地用到这张图，当我们知道所有的流程界面时，就完成了所说的范围分析。

 

5、忽略了对这些分界面的“体检”工作。

我们需要对所有界面进行分析，以确定每个界面都是完好的。这样做的目的是把我们的精力集中在真正重要的地方，切实地知道能影响什么不能影响什么。为此我们必须问一些问题：哪些运作得好，哪些不好？哪些不可能改变？哪些会在给定的资源和时间限制内耗费我们大量的时间？这种新认识的结果就是范围变更。这意味着，所有包含在边界里的东西都有可能以某种方式发生改变。这就是我们的项目范围定义。

 

6、没有意识到这样一个问题：项目的某些方面会使项目变得很大以至于无法管理。

我们必须把现实情况考虑在项目范围中。比如，如果项目范围是一个大型金融机构的支付流程，我们需要考虑，是检查所有的支付类别，还是只检查少数几种主要的（对组织的风险和期望酬金有最大影响）支付类别。

总之，项目范围可以管理得更好吗？当然可以！流程改进项目的挫败通常是不知道怎么处理项目范围问题所造成的。你现在已经有知识、有能力既有效率又有效果地去控制你的项目了！