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

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

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

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

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

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

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

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

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

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

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

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

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