本篇论文目录导航：
【题目】饭店网项目改造中项目范围管理的运用探究
【第一章】饭店计算机网络改造管理研究绪论
【第二章】项目范围管理与计算机网络项目相关理论概述
【3.1 - 3.3.1】饭店有线网络及网络安全改造方案
【3.3.2】饭店无线网络建设方案
【3.3.3 3.3.4】网络管理平台建设方案与达成效果
【第四章】范围管理下原改造设计中的问题与分析
【第五章】基于范围管理在原改造方案设计中的改进实施
【结论/参考文献】饭店网络项目改造中范围的控制结论与参考文献
第 4 章 基于范围管理在原改造方案设计中的问题与分析
本章以上章的原改造设计方案为基础，通过使用项目范围管理的方法和工具对其进行重新梳理，并针对存在的问题进行分析。
4.1 基于范围规划的问题与分析
4.1.1 相关概念和成果
项目范围规划是指逐步规划产生项目产品的项目工作，制定项目范围管理计划，以及规定如何定义、检验、控制范围以及如何定义工作分解结构，项目范围的规划将会直接影响到项目的整体成功。如图 4.1 所示，项目范围管理计划作为一种规划工具是范围规划阶段的主要输出，通过分析项目章程、项目管理计划、组织过程资产中的历史信息、以及有关的事业环境因素得出。
项目范围管理计划的内容组成具体包括：如何制定一个详细的项目范围说明书；如何基于项目范围说明书，从而细化创建出工作分解结构（WBS）；如何控制处理变更请求的处理流程；如何对已完成的阶段成果或整体成果进行规范的范围验证。
4.1.2 基于范围规划存在的问题
我们在使用专家判断工具来定义范围管理计划的时候，发现目前的项目团队中（目前的主要干系人表请见下方表 4.1）缺少饭店行业网络解决方案专家。现有团队中的产品经理虽然都是售前技术人员，对网络产品和典型组网方案设计都非常熟悉，但都对饭店行业信息化业务比较生疏，缺少大型饭店网络解决方案设计经验，这将可能导致会遗漏或误解饭店行业信息化业务对计算机网络的独特需求。如果方案真的存在设计上的技术错误而却在项目实施后期才被发现的话，势必要影响工期、甚至需要客户追加投资费用。这将会带来非常恶劣的影响，是谁都不希望看到的结果。
4.1.3 基于范围规划的问题分析
专家判断法是进行项目管理决策中常用的一种工具，是指利用在特定方面的专家个人或集体的知识、经验和判断能力，对目标做出预测的一种方法。
出现此问题的主要原因是在项目团队建立初期，仅凭经验的认为团队中只需要现场技术人员（产品经理）和销售人员（客户经理）即可，没有评估现场技术人员的能力是否能够胜任此次有行业特性的方案设计工作，所以并没有加入饭店行业信息化方面的专家，导致团队中所需的知识体系不够完整。所以在用专家判断法来制定项目范围说明书、工作分解结构以及项目范围管理计划等内容时，仅凭现有团队得出的结论会有一定的片面性和局限性，这势必会影响到范围管理的输出成果的质量，从而也就不能最大程度的体现通过范围管理进行项目方案设计的作用。
4.2 基于范围定义的问题与分析
4.2.1 相关概念和成果
项目范围定义是指制定项目目标和详细描述可交付物的过程，即制定项目范围管理计划。项目范围定义的目的在于明确项目目标、工作内容以及资源需求，制定绩效考核和控制准则，分配项目任务与责任。
项目范围定义包括产品范围和工作范围，产品范围（Product Scope）是指用户对最终产品或服务的所希望包含的典型特性与功能的总和。工作范围（Project Scope）是指为提供具有典型特性与功能的产品或服务所必须做的工作。项目范围管理计划是项目范围是否完成的确定标准，项目范围说明书是产品范围是否完成的确定标准，二者需要相辅相成才能保障项目目标的实现，两种范围的管理必须很好的结合，以确保项目工作所提交的是定义的可交付物。
如图 4.2 所示，作为范围定义阶段的主要的输出成果，项目范围说明书详细说明了项目可交付物和为这些可交付物所必须做的工作，阐述了项目的主要目标，让所有项目干系人对项目范围有共同的理解，为将来正确执行项目工作提供基础。
4.2.2 基于范围定义存在的问题
发现原有设计方案中存在“项目过界”的情况，和项目范围说明书中的“项目边界”中的要求不符。“项目边界”中要求只有有线、无线、以及网络管理是此次改造的内容，其中有线部分此次项目只负责连接在主楼和行政楼的所有信息点。而原有方案中还另外加入了为后期数字标牌终端连入网络所配置的专用网络交换机设备。这主要是基于原先 JX 饭店的要求，因为客户考虑到后续数字标牌系统还是要采购华为品牌，各显示终端需通过此次新改造的核心交换机连接到服务器区的服务器，那么用于连接各显示终端的接入交换机不如趁此次网络改造的机会一并采购。但是，目前数字标牌的摆放位置以及数量都没有最终确定，只有一个模糊的概念。如果后续规划设计的数字标牌方案和现在预估的出入较大，或者 JX 饭店选用了非华为的其他品牌产品，更甚至采用其他的更为先进产品替代数字标牌产品，那么势必造成现有网络整改以及设备的浪费或增加新的采购，间接地会对本项目造成一定的影响。
4.2.3 基于范围定义的问题分析
项目过界是指在项目中做了范围定义之外的工作。那么在几种情况下会导致项目过界发生，一是在项目规划时因为没有明确项目的范围边界，对项目的需求模糊不清，导致错误的判断以为某些过界的工作是在项目范围之内；二是虽然明知某些工作不应该在此次项目范围内，但还是或因客户方或因我方的考虑和要求被加入到此次项目中。但是不论是哪种情况导致的范围过界，都是要被尽可能的避免。
出现此范围过界问题的主要原因还是我方团队此前在没有制作项目范围说明书之时对项目范围的界定比较模糊，更没有认识到范围过界可能带来的不良影响。虽然此次网络改造项目设计中的过界工作是客户方提出的要求，是出于减少下次项目的预算及工作量的考虑而把下次项目中一些工作放在了此项目中来。但经过分析得知加入的这些超出范围的工作具有太多的不确定性，处理不当很可能会失去控制造成范围蔓延，从而对此次项目的质量、时间造成影响。
4.3 基于范围具体工作分解的问题与分析
4.3.1 相关概念和成果
范围工作分解是指把项目的主要可交付产品和服务划分为更小的、更易于执行的活动，即制作工作分解结构（Work Breakdown Structure, WBS）。
工作分解结构（WBS）的主要作用：把项目划分成具体的活动，定义项目的具体产品范围和工作范围，明确了原来看起来比较模糊的项目目标，清楚地表示出各活动之间的相互联系；提高成本、时间与所需资源估算的准确性，针对各活动，进行独立的时间、费用和资源需要量的估算，从而提高整体项目估算的准确性；便于提出明确的职责分派；为各活动独立的分派人员，规定这些人员的对应职责，使项目团队成员明确自己所承担的责任；定义了里程碑事件，通过对其中关键活动的进展跟踪，可作为项目状况的报告工具。
工作分解结构（WBS）设计的基本原则：在各级层次中保持项目内容的整体完整性，不漏掉任何必要的组成；分解出的活动有明确的可交付成果，是可管理的、可定量检查的、可分配任务的、并且是独立的；不同的活动应该是完全不同的工作内容；一个下级活动只能属于一个上层活动，不能交叉从属；相同层次的活动应具有类似的性质；应该根据项目的复杂程度以及大小在结构内构建合理的层次，层次太少会导致分工模糊，层次太多则不易于管理；整体结构应具有一定的灵活性，应能满足在有必要的情况下对项目的范围和内容进行扩展。
工作分解结构（WBS）的形式：树形图，基于可交付成果或基于工作内容来进行划分；优点：层次清晰，直观；缺点：不易修改，大项目的结构图太复杂。列表图，优点：可以反映项目全貌；缺点：不直观。
制定工作分解结构（WBS）的方法：自下而上法，是要求从项目规划开始就让项目所有成员尽可能的确定该项目中所要进行的所有底层活动；再将这些活动不断的向上汇总整理，最后形成一个总体的活动；这种方法的优点是让所有参与项目成员来首先汇总各自底层活动和所需资源，这使得最后的项目活动详细程度比管理者自己归纳的要高；但缺点是往往发生总所需资源或费用是管理者无法接受的情况。自上而下法，这是制作工作分解结构目前最常使用的方法；即从项目最大的上层活动开始，逐步向下分解成为多个子活动；然后不断地增加级数和细化子活动，直到认为最底层的子活动为合适大小的工作内容时为止；这种方法的优点是总所需资源或费用比较准确，一定程度的避免了项目风险；但缺点是给各子活动分配的资源未必能满足各项目成员的预期，可能会导致不必要团队争执和协商。
按照树形图以及自上而下的方式制作的 JX 饭店计算机网络改造项目方案设计的工作分解结构：
4.3.2 基于范围具体工作分解存在的问题
工作分解结构是组织管理工作的主要依据，是项目管理工作的基础。通过进行工作分解结构的制作，发现其中的“文档准备”活动的工作我们目前做的还不够全面。如果我们仅仅是提交了改造项目解决方案文档以及报价清单给客户方，那么我们可以换位思考站在对方角度来想一下可能会有的顾虑：他们的解决方案是否成熟？这样的组网以及功能设计是否在饭店的信息化网络中好用？是否还有哪些饭店行业特性的要求没有满足？提供的网络产品质量是否过关，性能是否能够满足实际需求？等等，而这些可能存在的疑问都可能会让客户不能放心的和我方合作，导致项目方案验收的一拖再拖，甚至不排除产生取消此次合作的严重后果。
4.3.3 基于范围具体工作分解的问题分析
工作分解结构中的“文档准备”活动中的文档主要是指两部分的内容：一部分是我方存档留存以便日后用于参考和追溯，主要包括产品文档以及项目管理文档，产品文档包括在产品规划、设计、制作、测试中的各类过程文档，项目管理文档包括在项目管理过程中产生的各类输出资料；另一部分是提交给客户的文档，包括技术资料、项目过程报告、验收报告等。
出现此活动工作做的不够全面的问题的主要原因还是在没有进行工作分解之前，对要做的项目工作考虑的不够周到和全面，几乎完全遗漏“文档准备”
这个环节。在此前项目方案设计中，虽然方案设计过程中的技术文档都已归类，但因为没有通过项目管理来进行此网络改造项目过程管理，自然项目管理文档就无从谈起。另外，提交给客户方的技术资料文档也严重不足，无法让客户能够很好的理解设计方案的行业可行性以及产品的可靠性。
4.4 基于范围变更管理的问题与分析
4.4.1 相关概念和成果
项目总是处在不断变化的情况中，所以，项目本身也难免会产生各种的变化。于是项目团队需要对项目进行对应的修改，这些变化和修改就是变更。其中，可能由各种类型的发起人来提出范围变更的请求并且以不同的形式出现。
包括口头的或文字的、直接的或间接的、项目团队内部提出的或外部提出的、可选择的或法律规定强制执行性的等等。
变更分为好变更（good change）和坏变更（bad change）。好变更只需要一点点的代价就能让项目变得更好。它不会多花进度表中的时间或预算，它不会让产品产生不稳定性，否则就会影响它的质量。那么坏变更会对时间、质量、费用造成或大或小的冲击，包括范围蔓延以及镀金：范围蔓延发生于首先你知道的变更，然后这个变更随后又引发了另一个变更，并且因为你已经做了第一个变更，所以只好做下一个，结果一个又一个变更不断产生，项目的范围难以控制；镀金是指在没有和任何人讨论的情况下，想当然进行一个自认为是好的变更改变（如新的功能），但最后很可能会为这并未被要求（超出范围定义）的变更付出代价。
既然项目本身会出现各种各样的变化，那么即使此前的项目范围计划制定的再好，也难免会出现范围变更。项目范围出现变更并不可怕，可怕的是缺乏对变更的规范控制和管理。为了正确的执行范围变更控制，必须建立有效的范围变更管理流程。
范围变更管理的简要操作流程：接受变更需求，提交变更申请（内部包括：变更提交人、变更内容、变更原因等）给所有相关项目干系人；评估变更对项目可能带来的影响，批准或否决提交的变更申请；在变更被批准的情况下进行项目基准（项目范围说明书以及工作分解结构都属于项目范围基准）偏差分析，并对工作进行更新；变更更新后，存档变更。
4.4.2 基于范围变更管理存在的问题
在了解项目范围变更流程后，发现此前我方在对此项目范围进行变更的操作并不规范。此前在和 JX 饭店多次沟通项目需求过程中，时常会被临时提出一些新的变化要求，导致我方对技术方案进行改动。因为作为产品经理的本人考虑到这些改动是我能通过修改方案就能实现的，所以很多的变更要求就直接进行了执行，并且未知会其他相关利益项目干系人，也未进行存档记录。虽然这样操作简化了变更流程，减少了工作量，但是这样不规范的操作势必会来带诸多的问题：是不是所有客户的变更要求我们都要在此项目中去满足？是否仅凭产品经理就能确认所有的变更是否被允许或被否决？需求的变化常伴随着项目预算的变化，那么对项目预算最为关心的客户经理是否能够认可这些变化，并且客户经理对此项目的客户关系维护工作是否会需要有对应的改变？是否仅凭产品经理就能对技术方案变更的可行性进行确认？在项目过程中曾经发生过哪些变更，如果新出现的问题是由其中的某一次变更引起的，该如何追溯？
以下几个例子说明了不同项目干系人对同一个变更会有着不同的看法：如果客户提出要求大幅度缩减项目规模，那么这种变更对于我方产品经理来说由于设备的减少和网络复杂程度的降低导致减轻了工作量，但这种变更对于我方客户经理来说自然是他不希望看到的（项目规模的缩减自然就带来项目预算的缩减），他可能就会想办法试图说服客户撤销变更或者减轻变更；如果客户提出变更希望增加一些新兴的前沿的但尚不成熟的技术功能或者在项目中做一些超出范围边界的事情，对于我们现场项目团队来说自然是希望尽量满足客户要求，但可能我方行业技术专家就会否决这个变更要求，因为他会认为这种变更存在很大的风险会导致出现范围蔓延的情况。
4.4.3 基于范围变更管理的问题分析
范围变更管理的目的是在变更产生的情况下对其进行规范的管理。如果在项目进行过程中可交付物发生变化（即项目范围发生变更），那么最初规划的成本、工作内容和持续时间也会随之而变化。
出现本人擅自做主进行变更实施的主要原因是本人对变更可能给不同干系人带来不同影响这点理解不深，通过上文的举例已经看到了不同干系人对项目成本、工作内容、时间等环节关注度以及所承担的责任不一样，任何个体干系人都不能独自裁定交付物的变化，这就是为什么在变更请求提交后需要所有相关干系人评估变更对项目的影响，并批准或否决提交的变更申请，否则将会影响到整体项目成果的交付。
4.5 基于范围验证的问题与分析
4.5.1 相关概念和成果
项目范围验证是指正式认定项目范围，在这个阶段里由项目干系人根据验收标准来正式接受项目的可交付成果。范围验证需要按照要求审查可交付成果，以保证项目中所有工作都已经正确的完成。范围验证可以贯穿项目始终，而并不只是指在最终项目验收时的检验，审查的内容可以是项目某个阶段的成果或者是整体范围的成果。
4.5.2 基于范围验证存在的问题
此前在完成 JX 饭店计算机网络改造设计方案后，范围验证的参与人基本上只是客户负责人以及我方产品经理和客户经理。但是，在此次通过制作项目干系人表以及明确验收标准后，发现此前的范围验证过程并没有涉及到所有相关的项目干系人，并没有让行业技术专家参与进行评审。而如果真的因为我们对饭店行业信息化特性理解不深导致方案中有不合理的设计该如何处理？如果等到了项目实施后期甚至新建网络已经运行的时候才发现需要进行调整修改，将会给客户方以及我方带来不必要的麻烦。
4.5.3 基于范围验证的问题分析
作为范围验证，无论是项目中某个阶段的确认还是整体的验收，一旦确认之后将不好再进行修改，所以这个环节就会显得尤其重要。
出现验收人员体系不完整的主要原因是此前浅显的认为只要能够让客户方通过验收就可以算是完成了验收任务，但没有考虑到如果存在客户方验收时没有发现的但却是实际存在的问题或风险，那么对项目而言仍然是潜在的隐患。
所以项目的验证不仅要关注验收内容，还需要关注验收人员的组成。验收人员的组成如果合理将很大程度提高验收的质量，通过具有不同专业能力的人站在不同立场来进行验收，将会通过多方面的角度来检测项目交付的成果，能最大程度避免验收后再进行发现问题的返工整改。
