如何进行项目范围定义和项目变更管理？

1、项目范围定义

产品所具有的功能其实都是为了满足客户的某种需要，这种需要最终左右了项目应该做什么和不做什么。我们把这种需要称为需求。需求表述了客户打算利用项目成果来做什么，而项目的产品范围则定义了什么样的产品可以实现客户的需要。

客户需求是“因”，产品范围是“果”，需求和范围之间存在着一个转化过程，两者之间是有区别的。客户不是仅仅为了拥有而购买产品，而是通过产品来实现某种目的。 “需求”是“范围”之源。不同行业，需求和范围在项目管理之中有不同的侧重。

在某些传统的行业中，促使项目建立的客户需求是相当明确的。 例如，建一栋楼的目的是满足客户居住的要求，这是千百年来都不变化的需求。而用户更关心的是造什么样的房子，这就是范围的概念。 在另外一些新兴的行业中，特别是一些IT或者软件类型的项目，项目的需求都是解决一个新的问题，或者是创造出一种新的需要。这个时候连解决什么问题都说不清楚，又怎么能准确把握交付什么样的产品就能解决问题呢?前者就是我们说的“需求”，后者就是所谓的“范围”。 这类项目有一个共同的特征：项目是在需求还只是一个概念的情况下开始的，需求是很不清晰、很不准确的。项目的第一个活动就是搞清楚用户需求，然后在正确需求的基础上确定项目的产品范围及工作范围，并作为后续项目活动的基准。

这个活动看起来虽然简单，但却有几个重要的环节需要注意： 首先，要明确需求收集活动的目的是什么。很多人会误以为需求收集就是搞清楚用户要的是什么产品。定义产品就是确定产品范围，它是在确定需求之后的活动。

我们应该在这个阶段集中力量搞清楚以下问题：

1）用户为什么需要这个产品?
2）用户打算拿这个产品解决什么问题?
3）这个产品给用户带来了什么价值?

整个需求活动都是围绕着用户来进行的。 其次，当我们搞清楚了用户的需求后，就需要确定创建什么样的产品来满足用户需求。这就是需求分析活动的目的，其结果就是定义产品的规格说明书。事实上，很多成熟行业的项目都是从相对详细而准确的产品规格开始的，产品规格定义了产品范围。在IT或者软件行业中，其第一个活动则早于产品规格而是从收集需求开始的，由需求确定规格，也就是产品范围。

范围是项目其他活动的源头和基础，所以需要采取措施控制好这个源头。在某些项目中，存在比“范围”还要提前的“需求”活动，则更需要控制好“需求”。“需求”控制好了，由它衍生出的“范围”也就控制好了。但有的时候项目需求变化了，项目范围可能变化也可能不变化。

最后，需要特别注意的是：获取项目需求和定义产品规格(范围)所要求的技能是不同的。获取项目需求的人员必须对要解决的问题，也就是业务领域很熟悉，而定义产品所要求的技能则是技术能力。很少有人在两个领域都是专家。如果只具备一种技能的人做了两个要求不同的事情，很可能某一件事达不到要求。一个懂技术但不懂业务的人员去收集客户需求，容易导致需求质量不高，这一问题在现实中经常出现。

了解项目需求、确定项目范围确实有一定的先后关系。很多项目在明确需求之前就签订了项目的实施合同，这个时候项目就承担了一定的风险，因为如果识别的需求和当初估计差距较大，就会导致项目产品和工作范围超出预期。 有些大型项目会把需求定义工作和需求实现工作两部分活动分开。在第一阶段，请专门的咨询公司进行需求定义，然后利用定义好的需求进行第二阶段招标，选择合适的需求实现伙伴。这种做法无疑能够保证两部分不同要求的工作都可以达到相应的要求。项目管理者联盟

2、项目变更管理

项目的不确定性因素导致了项目的进展未必能按计划进行，而当这种不确定性变得明确的时候，就会导致项目出现变更。项目目标是项目所有活动的最终判断准则。那些可能会引起项目目标变化的因素包括：内部因素和外部因素。

1）内部因素是指由于项目的实际实施绩效偏离原有计划要求，导致无法实现原定项目目标，不得不变更项目计划。

2）外部因素是指干系人本身对项目目标发生了变化，从而引起计划的变更。

项目变更，无论是外部请求变更还是内部的偏差变更，都有可能是来源于或导致项目的四个目标因素发生变化。但在实践中，外部请求变更大多只由范围因素变更所引起，而内部偏差引起的变更则可能由于范围、时标正确性的判断必须引入客户参与。 变更的最终效果是引起项目基准计划产生变化。

由于项目基准计划是项目各项活动开展的基础，为了不引起混乱，它的变化必须是一个严格而受控的过程。大多数的变更控制过程都是相似的。

一般的变更过程始于正式提出变更申请。变更申请的英文为：Change Request或Modification Request，所以也经常简称为CR或MR。在变更申请中，需要详细地描述变更的来源，主要是反映项目目标变化。例如：

1）客户对项目范围产生了变化，范围变更。
2）客户需求发生了变化，引起了产品的需求变更。
3）实施效率偏差导致了基准计划的修订，例如进度和成本目标的变化。
4）通过质量检验，发现交付产品没有达到质量目标，必须对产品实施返工从而引起的产品变更。 收到了变更请求后，会有专门的人员先做一个初步的分析，主要是评估变更的来源、变更的理由、变更产生的影响、变更的代价。某些变更会在这个阶段作出一个初步的处理。例如：描述不清楚的变更请求，或被要求提出者重新补充信息。删除那些明显错误的变更请求。一些简单且影响小的变更可以直接由分配人员处理。

5）余下的变更请求会被提交到变更控制委员会进行评审。 变更控制委员会评审是整个变更控制过程的核心。一般来说，变更控制委员会是一个项目主要的管理机构，由项目重要的干系人代表、各个相关组织的代表、主要的技术人员等组成。变更控制委员会评审就是评估那些被提交上来的变更请求，针对这些变更的目的、要求和影响作出如下决策：同意实施一项变更请求，并且在会议上安排相关的变更实施责任人和相关联的协作组织。拒绝某一项变更请求，并给出拒绝的理由。 变更控制委员会评审一般以会议的形式进行，有关各方都会参加，可以定期召开，也可以针对某一项重要变更临时召集。 如果变更请求得到批准，则变更被实施。变更实施的过程中要特别关注那些可能会产生广泛影响的变更，避免在变更实施过程中出现不一致。完成变更后，需要对变更的实施结果进行验证，以确保被批准的变更得到了正确实施。