开发管理 CheckLists(8) -控制项目的范围

注： 开发管理 CheckLists-系列文章是从本人   Iteye博客中移植过来.后续会直接在此更新     开发管理 CheckLists   专栏

接着上篇项目利益相关者责任，确定了项目的利益相关者之后，先别急着进入开发阶段，我们接下来要做的是先控制项目的范围,项目的范围控制好了才能保证后续的开发不会因为项目范围变更而做大量无用功,看下面介绍

项目范围是指为了实现项目目标所必须完成的项目工作。在需求日益变化，客户普遍声称需求变化时合理的、是其应有权利的年代，控制项目的范围将面临跟多的挑战和需要更多的创意。

一、确定项目不做什么

          实践经验告诉我们，在进行项目范围变更时，或者说在划分项目边界时，确定项目不做什么比确定项目做什么更为重要.

          项目的工期、费用等无不与项目范围的大小有关，因此，包含在项目范围内的工作必须是即必要又充分的。同样的项目目标可以通过不同的工作方式来实现，也就是说，对于项目的项目成果特性与特性而言，有不同的项目范围。然而，在管理项目的实践过程中，经常遇到要么将项目目标混同于项目范围、要么将达到项目目标的一种凡事等同于达到项目目标唯一方式的情况发生.- 不知道还有其他的方式来达成项目的目标.

    

          根据Standish Group在2000年的调查，"最小化的项目范围"对客户的成功很重要，它对项目的影响度排在"经理层的支持"、"客户参与"、"有经验的项目经理"、"清晰的商业目的"之后，未居第五位，影响度为10%。

          项目范围管理中存在的问题通常有以下几种.

          1、项目方案设计问题

               项目达成目标的总体策略、方式上存在着不合理性对项目范围的影响极大，这种不合理性一般不是项目可行与不可性的问题，而是项目实施效率高和低的决定性问题。对于达成项目目标的方案设计是决定项目范围合理是否的关键。

          2、项目范围蔓延问题

               由于各种各样的原因，项目利益相关者会在项目实施过程中加入很多"细小的"计划外工作，项目范围就会像爬山虎异样悄悄蔓延。项目管理者并不一定意识到其对项目的致命性破坏.，直到有一天这些蔓延由量变引起质变彻底摧毁项目为止。

              客户在项目过程中，一般会提出一小小的、略增加一些工作量就能够实现的工作。这些工作虽然与项目成果的特征和特性无太大的关系，但会使客户跟愉快、更满意。然而，这些微小的变化积累起来就会形成对项目的拖延、费用的超支，而到了那时候不仅是项目发起人对项目不满意，客户同样对项目不满意。客户不会因为对项目组在项目过程中所做的额外工作的满意而抵消对整个项目延期的不满。更有甚者，尽管项目的延期可能由于客户带来项目范围的蔓延引起的，然如果对这些范围蔓延不加以记录和确认，还可能会造成一些法律纠纷。

              为了避免客户造成项目范围的蔓延，记住这一条原则是十分有用的：“决不让步、除非交换”。变化时客户的权利，但任何项目范围的改变都需要通过商业谈判完成(尽管它可能是不正规的)，必须在项目工期、费用或质量基准方面做出相应的、正规的改变。

       因此，不仅清晰的定义项目的需求和目标十分重要，定义清楚项目的边界，即决定哪些活动不属于项目范围同样是十分重要的.

 

 二、把握项目的细节

          对细节的把握程度反映了一个企业、一个项目经理的管理水平。“魔鬼藏在细节中”，如果不能将藏在细节中含糊的、不确定的、不合理的成分展示出来，我们永远不能尝到管理的饿乐趣，永远不能摆脱想当然带来的内心不安.

          工作分解结构(WBS)是帮助人们揭示项目细节的有效工具，也是界定项目范围、进行项目预算和沟通等有效工具.

          WBS是为了完成下你过目产品的所有工作的等级表示，是一个项目产品的系谱层级图，途中所有的内容均为实现喜爱那个木最终目标所需做的工作。

          有情趣的朋友可以关注一下这个链接了解WBS详细信息 http://baike.baidu.com/view/530736.htm

          WBS作为项目管理的重要工具，八五它的编制规模是非常重要的。如果WBS过分复杂、庞大，就会成为管理层的管理负担。正常情况下，应当根据工作范围各元素的风险水平来编制WBS并分解个元素。

 

三、管理范围变更。

          如果在实施过程中，项目范围还是发生了变化，我们就应该进行管理范围的变更了.

          为规范化项目变更管理，需要制定明确的变更管理流程，其主要内容是识别并管理项目内外引起超出或缩小项目范围所有因素。它包括三个主要过程：

 

         1、对引起工作范围变更的因素进行识别

         2、确定确实需要发生变更并施加影响以保证变更时有益的

         3、管理那些实际发生的变更.

         对于发生的变更问题,  项目范围变更申请及审批表如下

 

                   项目需求变更申请表

 

项目名称	xxxxxx		申请人		申请日期	2xxx.XX.XX
更改类型 （客户填写）	（ ）合同变更；（ ）结项时间变更；（ ）成本变更；（ ）人员变更； （ ）验收标准变更；（ü）需求变更；（ ）进度变更；（ ）其它：
原相关内容 （客户填写）
变更后内容 （客户填写）
更改原因	实际工作需要
更改影响分析 需求： 进度（单位：工作日）： 成本（单位：人天）： 合同： 其它：
最终审批意见:
同   意（   ）                    不同意（   ）
不同意的原因

 

       

<开发管理 CheckLists> by dyllove98 @开发管理 CheckLists