企业如何在信息化项目中进行项目范围管理

申请免费试用、咨询电话：400-8352-114

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

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

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

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

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

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

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

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

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

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

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

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

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

　　第三、 信息部门作为实施的关键部门，在协调业务部门和实施方之间的关系中起到重要的作用。

　　综合上述三点，信息部门应该能在业务和技术两者之间权衡一个平衡点，因此在判断项目范围的环节上能站在一个比较中立的立场上给出客观的判断。

　　三、项目范围控制要素分析：

　　1．项目范围定义的依据

　　1.1关键业务需求

　　企业在定义其项目实施范围时，要注意紧紧围绕着企业的战略目标以及核心业务，以内部价值链为主线，而非全部业务，一应俱全。实施信息系统的目的是提高企业的竞争力和内部管理效率，因此我们要定位在能够为企业的效益和效率产生最大价值的方面，而不是涵盖企业的全部业务。要避免出现主次不分，胡子眉毛一把抓的现象。

　　2．项目范围控制要素

　　一般来说，在启动项目初期，业主就应该提出一个比较稳定的项目范围，为项目的实施提供一个牢固的前提和框架，同时也是为后期的项目管理划出一个明晰的“圈”，所有项目活动的开展，包括项目成本、质量和时间的控制也应该在此范围内进行。但是，在实际的操作过程中，这个“圈”的边界有可能会出现模糊、扩大的现象，甚至这些扩大和模糊的部分给项目带来风险。我们从下图看：

　　如果项目范围即既定的的面积S不变，C、Q、T就可以在一个固定的S的边界限制下给出一个约束的关系模型。但是，如果S的值并不是固定，就如上图所示出现边界模糊或者向外扩展时， C、Q、T就失去可依赖的边界限制，其之间的约束关系就会变得复杂。因此，我们在对项目范围进行控制时，一是要保证项目初期的S是准确可靠的，尽量减少边界的模糊性；二是要保证项目实施过程中S的稳定，尽量避免扩大化，或是说让扩大化受到合理的控制。

　　2.1内部价值链

　　我们先看看以下一个企业的内部价值链示例：

　　项目预算——项目拆分及概算分摊——项目合同——订单——采购——库存——材料发放——合同支付——成本归集

　　可以看出价值链中的每个环节构成了企业内部的核心业务，因此，我们在定义项目范围的时候就可以贯穿着这个价值链，把价值链中的每个环节定义成具体的项目需求和范围，并且遵循一个闭环的原则来进行描述，如下述对项目预算范围定义中，从预算编制开始到预算回归分析，接着又进行预算编制，形成一个完整的闭环。

　　通过上述的定义，我们就可以为价值链定义出多个闭环，而每个闭环将构成一个整体的闭环，同时也构成项目范围的边界。

　　2.2内部管理成本

　　业主在实施项目过程中，对超出了原项目范围内定义的需求我们可以用以下的标准来作出判断。

　　2.2.1是否对关键业务构成关键的影响

　　项目实施中，在对业务部门进行详细需求调研的阶段，业务部门不可避免地会提出很多与其业务相关联的业务，或者是一些新的想法，当遇到这种情况的时候，业主方的信息部门要作出一个合适的判断，是否可以包含在项目范围内。

　　首先，这个业务需求是否在关键业务描述中已经涵盖，或者说这个需求是否对关键的业务构成足够的影响力。如果不是，建议可以不纳入项目的范围内，或者暂时不纳入本次的项目范围内，而作为日后一个扩展的功能。

　　其次，如果此需求对关键业务构成必要的影响，那么信息部门应该进一步作以下分析：

　　（1） 目前系统功能是否可以解决这个需求？如果可以，实现难度如何？
　　（2） 如果实现难度不大，可以纳入项目范围。如果实现难度大，那么进行成本分析。

　　2.2.2项目成本分析

　　（1） 内部资源是否足够应付新需求的实现？包括业务部门人员、技术人员、软硬件支撑。
　　（2） 在整体项目计划当中是否允许作这样的调整？能否在项目计划时间内完成？
　　（3） 是否能保证项目的质量？会不会对其他功能造成影响？

　　如果上述成本分析回答都是肯定的，那么就可以把需求纳入实施范围，如果全为否，建议就不把其纳入本项目范围。但是由于该项需求是一个关键业务需求，可以考虑把此项目作为扩展功能在以后实现，目前可以采用其他灵活的方式处理。如果上述的回答中有肯定也有否定的，那么我认为首先要以内部资源的问题作为重点，如果此条件不能满足，即使勉强把其纳入项目范围内也只会造成项目的延迟，还不如干脆等条件满足的情况下再实施，目前先采取其他灵活的方式处理，这样既保证当前项目在原既定范围内完成，新需求在新的项目中实现。如果内部资源条件满足，那就要判断是否对项目的计划和质量造成影响或者说造成多大的影响？这种影响能否被接受和控制等等。如果会失去控制，建议不纳入范围而采取其他方式解决。

　　四、在控制项目范围时要注意控制好实施双方之间的利益关系：

　　项目成本控制对项目实施双方来说，特别是对项目范围的理解上常会存在着利益冲突关系，因此业主方在控制项目范围时要注意切实把握好关键业务的范畴，把控住项目的成本，而且此成本不光是指实施一方消耗的成本，还要注意结合自身内部资源的问题，重点考虑好内部的管理成本。企业实施信息系统本身是一项高管理成本的项目，如果项目范围本身控制不当，很容易造成无形的内部管理成本的巨大消耗，而在实际的管理效益上获得的收益却不高，在这种低的效益/投资比下，无疑是一种不可取的项目管理方向，因此，企业进行信息化项目管理的时候，要站在中立、客观的立场上分析范围的“度”，采取适度则取，过度则收的原则。