我们在谈到很多项目管理方面经验的时候都提到如何进行项目的控制和管理，其中一个项目范围的问题，成为控制项目风险和成本的关键因素之一，也是项目管理四个要素当中(Q、C、T、S)范围(S)的问题。

　　对于这个项目范围，一般在项目启动初期，项目实施双方(业主方和实施方)会就这个问题进行详细的研究和探讨，并在项目目标的指导下，双方形成一致的项目范围的定义，并作为书面报告记录下来，为日后的项目实施提供纲要性的指导，也为项目成本的控制提供确定性的因素。

　　很多信息系统项目实施失败的原因，我自己认为是在项目实施过程当中，实施双方没有控制好项目范围的问题。实施信息系统项目的特点之一是实施的周期长、对业务的依赖性强，特别是一些跨业务的项目，要完全把企业的全业务流程稳定下来，并通过系统实现，是需要较长的时间来巩固的。因此在这么一个客观条件下，常常出现一些需求不稳定、需求变更，项目范围失控的现象，如果在此问题上没有一个“度”的控制，那么项目的范围将失去可控性，随之而来的是项目的风险和成本无法控制，更严重的是导致项目的滞后和失败。

　　一、业主方对项目范围定义的误区：

　　或许很多实施信息系统项目的人员都认为 “项目的管理和控制都应当是项目实施方的责任，业主方就可以无虑于范围的限制，无条件的提出自己的需求，需求提得越多对业主总有好处，不会吃亏”。我个人在参与信息系统实施的过程中，自己对项目范围的控制问题感觉到，要实现良好的项目管理，项目范围的控制是一个关键，而这个关键点的把控更多的是由业主方来控制，而并非“越多就越有利于业主”。

　　在很多项目管理的课题研究中提出，项目管理的四个关键要素彼此之间互相约束互相影响，并可以得出一个计算公式：C=f(Q,T,S)。从这个计算公式中可以看出，一般情况下，我们认为项目的范围一般在项目开始初期就已经是确定的，也就是说公式中的S是“固定”的，因此在后面的项目成本控制过程中主要关注的就是质量(Q)和时间(T)之间的权衡和约束关系。

　　这是一个比较理想的控制模型，但是，在实际的项目实施中，往往出现项目范围变动，而且一般是向外扩大的现象，在这种情况下，上述计算模型中成本的控制就失去了基本线的限制，C、Q、T、S之间就存在着难以计算的复杂关系，对项目的管理和控制难度就扩大，甚至失控。

　　对于项目范围的控制，我认为业主方比项目实施方占有更多的控制主动权，而且在项目范围的把控上更具有权威性和判别性。在这里，我要提醒各个实施业主方的人员注意，项目管理是实施双方共同努力的，而不单纯是实施方的责任，因为对于业主方本身而言，项目范围的失控同样会带来自身管理成本的浪费，项目的滞后等不良的影响。要走出“项目需求(范围)越多越好”的误区，实事求是把握住项目范围的“度”，才是实现良好项目控制的手段。

　　二、企业信息部门要注意好把握项目实施范围的“度”：

　　项目范围将如何定义才 “合适”呢?这个问题在项目实施双方衡量的标准是不一致的，或许我们暂且用“多”和“少”这两个相反的字眼来反映业主方和实施方对项目范围的衡量标准。当然了，在实际的项目管理当中，我们并不能那么简单就把这个因素用这两个简单而相反的字眼来概括，因为项目范围本身涉及到不同利益双方之间的关系，而且还涉及到业主本身复杂的业务逻辑，在项目开始时描述项目的需求范围时对项目范围边界的定义上就存在着一定的模糊性和不确定性，这些都将成为隐藏的风险。

　　一般来说，项目范围的定义是业主根据内部管理的需求提出来的一个框架性的条目，这个框架的定义一般会涉及到多块的业务，如财务管理、采购管理、库存管理、订单管理等等。而在这些范围的描述当中，一般以粗条目方式列出，并没有细化，细化的工作会在项目实施的过程中通过需求调研的方式来具体化。换而言之，这个需求包含的内容可能是“广泛”的，其深度和广度本质上来说是模糊的，因此在项目实施全过程当中，时刻都要注意对项目范围的控制，这样才能对项目的质量、时间和成本达到有效的控制。在这一点上，我认为业主责无旁贷要把握好这个关，不能让需求“泛滥”，同时也要满足业务的需要，保证项目的质量。那么，这个尺度该由谁去把握会比较合适呢?我认为企业内部的信息部门是最适当的人选。

　　第一、 信息部门对企业内部的业务比较熟悉，而且在项目需求提出的初期会参与全过程，对需求描述范围把握比较准确。

　　第二、 信息部门本身对技术有较深的认识，在把握技术实现难易程度时会给出专业的判断。

　　第三、 信息部门

[1] [2] [3]  下一页