4    目标管理

                             项目干系人目标不一致是导致绝大多数项目失败的主要原因。

　——经验总结

4.1   项目失败最大风险：目标模糊

目标管理是项目管理的核心思想之一，明确并统一项目目标是项目管理的首要任务。目标是前进的方向，是团结的旗帜，项目的一切活动都围绕项目目标展开。任何项目的目标都是由项目的一个或几个干系人因为某些原因提出来的，由于每个人的知识范围、语言、文化、性格等存在差异，导致每个人对项目目标的理解和期望迥异，所有项目的目标既有显性目标，又有隐性目标，往往隐性目标却又是真正的目标。高效挖掘隐性目标并把项目干系人统一到同一目标上是优秀项目经理必备的能力之一。

项目的大目标多数都是模糊的，准确识别真正的项目目标是项目成功的基础。只有对该目标进行分解并逐一细化，并不断调研分析，“渐进明细”，才能确定真正的目标。一个真正的项目目标必须符合“SMART”标准，即：

S—Specific（明确的）

M—Measurable（可测量的）

A—Action-oriented（行动导向的）

R—Realistic（务实的）

T—Time-related（有时间期限的）

例如建筑项目：为某企业盖一栋楼是一个项目的大目标，但大楼究竟要做什么用（写字楼、教室、住宅还是缩微景观），建在什么地方，什么材质，长宽高的要求，什么外形，防震等级要求，准备什么时候投入使用等等，必须用建筑学的知识进行详细分析，与相关干系人多次交流调研，才能确定“盖一栋大楼”的真正目标。

再例如软件项目，新编一套财务报销系统。该系统都能报销哪些科目，是只报销市内、国内的差旅费用，还是包含出国的差旅费用？如果要实现出国差旅费用报销，就还有汇率结算的问题，并且我们知道汇率是随时间不断变化的，差旅标准是否因之改变呢？还有在填单据的时候，是否允许代替别人报销？是否分多个页面分步填写？围绕着实现“财务报销系统”这个大目标，有诸多更详细的小目标，这些小目标不是一下就能明确的，需要“渐进明细”。

但如果老板给你下达一个任务：“明天你到火星上打一瓶矿泉水来”，尽管目标具体，有时限，可测量，并且行动导向，但显然不务实，这不是一个真正的目标。

由于有些项目的目标过于庞大而复杂，各种原因（技术、规模）限制项目目标难以短时间内完全明确，为了缩短工期，往往在部分目标明确后就开始实施，在实施过程中进一步对目标“渐进明细”，这类项目的风险就极高。例如航天项目（探月工程、登陆火星等）、全新产品的研发（新药、新软件、新车等等）等，规模越大，周期越长，风险越大。

4.2   需求调研：搜集与分析

项目提出者的不同项目干系人的需求构成了项目的目标，全面深入挖掘干系人的需求需要调研：调查并研究，即需求搜集与分析。需求搜集与需求分析一定要同步进行，因为二者相辅相成：“挖出萝卜带出泥”，收集需求时需要不断分析才能根据需求的相互关系搜集更多需求，使得需求充分而完整；“管中窥豹，只能见一斑”，“盲人摸象，必然不全面”，由于人手和工具方法的局限性，收集的需求总是有限的，有限的需求往往只能分析出有限的结果，收集的需求越多才能保证需求分析得更彻底更全面，这是最终交付的项目成果设计合理性的基础。

全面收集干系人需求的前提是对干系人的准确识别，关于如何识别干系人，将在《干系人管理》章节中再述。常用的收集需求的方法有访谈、焦点小组会议、引导式研讨会、群体创新、群体决策、问卷调查、观察、原型法、集中讨论、专家代表、调研搜集与干系人基本目标相一致的各类资料、调研搜集以往同类项目资料等等方法。

1．访谈 访谈是一种通过与干系人直接交谈，来获得信息的正式或非正式方法。访谈的典型做法是向被访者提出预设和即兴的问题，并记录他们的回答。通常采取“一对一”的形式，但也可以有多个被访者和/或多个访问者共同参与。访谈有经验的项目参与者、干系人和主题专家，有助于识别和定义项目可交付成果的特征和功能。

2．焦点小组会议 焦点小组会议是把预先选定的干系人和主题专家集中在一起，了解他们对所提议产品、服务或成果的期望和态度。由一位受过训练的主持人引导大家进行互动式讨论。焦点小组会议往往比“一对一”的访谈更热烈。

3．引导式研讨会 通过邀请主要的跨职能干系人一起参加会议，引导式研讨会对产品需求进行集中讨论与定义。研讨会是快速定义跨职能需求和协调干系人差异的重要技术。由于群体互动的特点，被有效引导的研讨会有助于建立信任、促进关系、改善沟通，从而有利于参加者达成一致意见。该技术的另一好处是，能够比单项会议更快地发现和解决问题。例如，在软件开发行业，就有一种被称为“联合应用开发（或设计）（Joint Application Development，JAD）”的引导式研讨会。这种研讨会注重把用户和开发团队集中在一起，来改进软件开发过程。在制造行业，则使用“质量功能展开（Quality Function Deployment，QFD）”这种引导式研讨会，来帮助确定新产品的关键特征。QFD从收集客户需求（又称“顾客声音”）开始，然后客观地对这些需求进行分类和排序，并为实现这些需求而设置目标。

4．群体创新技术 可以组织一些群体活动来识别项目和产品需求。下面是一些常用的群体创新技术： 

头脑风暴法。用来产生和收集对项目需求与产品需求的多种创意的一种技术。 

名义小组技术。通过投票来排列最有用的创意，以便进行进一步的头脑风暴或优先排序。名义小组技术是头脑风暴法的深化应用。 

德尔菲技术。由一组选定的专家回答问卷，并对每一轮需求收集的结果再给出反馈。专家的答复只能交给主持人，以保持匿名状态。 

概念/思维导图。把从头脑风暴中获得的创意，用一张简单的图联系起来，以反映这些创意之间的共性与差异，从而引导出新的创意。 

亲和图。这种技术可以将大量创意分类，以便审查和分析。

5．群体决策技术 群体决策就是为达成某种期望结果而对多个未来行动方案进行评估。群体决策技术可用来开发产品需求，以及对产品需求进行归类和优先排序。达成群体决策的方法很多，例如： 

一致同意。每个人都同意某个行动方案。 

大多数原则。获得群体中50%以上的人的支持。 

相对多数原则。根据群体中相对多数者的意见做出决定，即便未能获得一部分人的支持。 

独裁。某一个人为群体做出决策。

在需求收集过程中，几乎可采用上述任何一种决策方法进行群体决策。

6．问卷调查 问卷调查是指通过设计书面问题，向为数众多的受访者快速收集信息。如果受众众多、需要快速完成调查，并想要使用统计分析法，就适宜采用问卷和/或调查方法。

7．观察 观察是指直接观察个人在各自的环境中如何开展工作和实施流程。当产品使用者难以或不愿说明他们的需求时，就特别需要通过观察来了解细节。观察，也称为“工作跟踪”，通常由观察者从外部来观察使用者的工作。观察也可以由“参与观察者（Participant observer）”进行。“参与观察者”需要实际执行一个流程或程序，体验该流程或程序是如何实施的，以便挖掘出隐藏的要求。

 8．原型法 原型法是指在实际制造产品之前，先造出该产品的实用模型，并据此征求对需求的反馈意见。原型是有形的实物，它使干系人有机会体验最终产品的模型，而不是只讨论抽象的需求陈述。原型法符合渐进明细的理念，因为原型需要重复经过制作、试用、反馈、修改等过程。在经过足够的重复之后，就可以从原型中获得足够完整的需求，并进而进入设计或制造阶段。

不同行业需求分析的方法不同，这是一个偏重行业技术的工作，像软件行业常用的分析方法有大纲分类分析、业务流程分析、活动场景分析、时序图分析、优先级分析、可行性分析、需求关联关系分析等等，在此不再详述。

4.3   分解并定义目标

    创建工作分解结构（Work Breakdown Structure ，简称WBS）是项目管理用于分解并定义目标的方法。创建WBS是把项目可交付成果和项目工作分解成较小的、更易于管理的组成部分的过程。WBS是以可交付成果为导向的工作层级分解，其分解的对象是项目团队为实现项目目标、提交所需可交付成果而实施的工作。WBS每下降一个层次就意味着对项目工作更详尽的定义。WBS组织并定义项目的总范围，代表着现行项目范围说明书所规定的工作（见图5-6和图5-7）。 计划要完成的工作包含在WBS底层的组成部分中，这些组成部分被称为“工作包”。可以针对工作包安排进度、估算成本和实施监控。在“工作分解结构”这个词中，“工作”是指经过努力所取得的成果，如工作产品或可交付成果，而非“努力”本身。图5-6显示了创建工作分解结构过程的输入、工具与技术和输出，图5-7概述了本过程的基本数据流向。

分解就是把项目可交付成果划分为更小的、更便于管理的组成部分，直到工作和可交付成果被定义到工作包的层次。工作包是工作分解结构的底层，是能够可靠地估算和管理工作成本和活动持续时间的位置。工作包的详细程度因项目大小与复杂程度而异。要把整个项目工作分解成工作包，一般需开展下列活动： 

u  识别和分析可交付成果及相关工作； 

u  确定工作分解结构的结构与编排方法； 

u  自上而下逐层细化分解； 

u  为工作分解结构组成部分制定和分配标志编码； 

u  核实工作分解的程度是必要且充分的。

    图5-8显示了某工作分解结构的一部分，其中若干分支已经向下分解到工作包层次。 工作分解结构可以采用多种形式，例如：  把项目生命周期的各阶段作为分解的第一层，把产品和项目可交付成果放在第二层，如图5-9所示；  把主要可交付成果作为分解的第一层，如图5-10所示；  按子项目进行第一层分解。子项目（如外包工作）可能由项目团队之外的组织实施。然后，作为外包工作的一部分，卖方需编制相应的合同工作分解结构。

对工作分解结构上层的组成部分进行分解，就是要把每个可交付成果或子项目都分解为基本的组成部分，即可核实的产品、服务或成果。工作分解结构可以采用列表式、组织结构图式、鱼骨图式或其他方式。通过确认工作分解结构下层的组成部分是完成上层相应可交付成果的必要且充分的工作，来核实分解的正确性。不同的可交付成果可以分解到不同的层次。某些可交付成果只需分解一层，即可到达工作包的层次，而另一些则需分解更多层。工作分解得越细致，对工作的规划、管理和控制就越有力。但是，过细的分解会造成管理努力的无效耗费、资源使用效率低下以及工作实施效率降低。对于建筑行业，多数采用40小时法则，即把工作包细化到其活动持续时间约40小时即可；而软件项目则多采用8小时（或1人天）法则，把工作包细化到其活动持续时间约8小时，1人天的工作量；而某些明确而又紧迫的工作任务，可能会细化到1小时或者几分钟，例如银行的核心业务系统新版本更新的上线项目。这些都是在实践中的一些经验，推荐参考，而不是绝对的标准。工作包肯定要符合“SMART”准则，但不一定是以“SMART”为准则细化的最小单元。工作包细化的程度达到“能够可靠地估算和管理工作成本和活动持续时间，使项目可控”即可。

要在未来远期才完成的可交付成果或子项目，当前可能无法分解。项目管理团队通常要等到这些可交付成果或子项目的信息足够明确后，才能制定出工作分解结构中的相应细节。这种技术有时称做滚动式规划。 工作分解结构包含了全部的产品和项目工作，包括项目管理工作。通过把工作分解结构底层的所有工作逐层向上汇总，来确保没有遗漏工作，也没有增加多余的工作。这有时被称为100%规则。

4.4   统一干系人的目标

目标不一致是多数项目失败的主要原因，统一项目目标是项目经理的核心工作之一。由于项目对每个干系人的利益影响有差异，每个干系人的知识范围、语言、文化、性格及智商等有差异，使得同一项目中每个干系人的目标都不一致：既有对交付成果具体属性标准的期望差异，也有对实现交付成果方式方法的期望差异。

例如在建筑工程项目中，建造任何一栋大厦，设计者都须综合考虑该大厦的建设发起方、未来用户以及其他干系人的不同期望目标，如用途要求、风格要求、抗震要求、通风要求等等，设计图纸并建立模型，交付发起方进行讨论、专家论证，最终确定该大厦的交付标准。这就是一个明确目标、统一目标的过程。像奥运主体场馆——鸟巢，当初的设计方案就是向全球征集，经过多轮专家论证后才确定下来——因为这是公共项目，不仅仅是几个项目干系人的目标统一，而是几乎全民性的，因此需要很多业界各类专家共同论证。

而软件项目，尤其是应用软件项目，涉及的项目干系人多且对目标的要求繁杂不一，项目因目标不统一而造成失败的风险极大。相比而言，建筑的方法论已经基本成熟，如果没有设计图，没有明确的模型标准，建筑项目不会开工，而软件项目，尤其受“敏捷”思想影响较大的当代软件开发人员，用“成果”来摸索“目标”，边开发边与用户研讨确认，不符合用户期望则改代码重新来过，“前面修路，后面挖沟”，必然让各个不同的目标引导得东倒西歪，晕头转向。这是很多软件项目失败的根本原因，尤其一些较为大型的软件项目，就是因为尚未统一最终目标就开始了行动。借鉴建筑工程设计模型的思路，采用“原型设计”方法实施软件开发项目被证明是一条最佳实践。上一节讲到需求搜集时已经对“原型法”有描述，尽管软件是软体，无法像生产制造那样能造出棱角分明的原型，但一样可以造出原型：在正式编码前，将软件最终展示给用户的界面逐一设计好，并按照软件功能逻辑顺序将其组织起来，按照操作的先后次序逐一展示，并将每个界面对应的功能及约束要求用文字详细描述，展示给最终验收软件产品的用户，由其逐一确认，直到所有人对此达成共识，不再有异议，就形成了软件的“原型”。

“设计模型”实际就是把各个干系人的目标由心中的期望转化成了符合“SMART”标准的现实目标，项目干系人对此达成共识，并一一允诺（如果是有重大利害关系的项目，一定要有书面签字承诺），这其实就是“明确目标，统一目标”的过程。切记：只有得到“确认”的目标才是项目要实现的目标，切不可自以为是的猜测目标就付诸实施，这样的结果多数就是“出力不讨好”——难以通过验收。

项目经理对“统一目标”的意义一定要有深刻认识，在目标尚未统一的情况下，一定不能带团队盲目付诸项目的实施行动，此时唯一要做的行动就是与团队成员一起尽快“统一项目目标”。

“统一项目目标”只是统一目标的第一步，红军二万五千里长征的途中，遵义会议达成了这个目标，但直到红军到达陕北革命根据地之前，“前有堵截，后有追兵，内部还有破坏者”，如何将目标统一到每个项目执行者的心目中，统一人心，凝聚团队力量，并识别敌友，争取最多的支持者，一同达成项目目标是项目经理在从始至终的整个项目过程中都需要不断努力的工作。

多数商务项目都有这样的情况：项目提出者希望项目能如期保质保量地按照自己的期望实现；而他的“政敌”却希望这个项目搞砸了乘此机会能扳倒他；项目的承包商更关心花费最低的成本完成该项目以获得最高的利润；监理方要确保项目按照质量、安全等标准如期正常进行；工程师关心的是多干活能不能多拿奖金，或者反正薪水都是固定的，干多干少一个样，怎么才能少干点活；验收人员之前跟承包商有过节，想尽办法增加验收标准的难度……，如此林林总总，导致项目实施过程中总是“一波未平一波又起”。项目规模越大，干系人越多，不同的行动目标就越多，作为项目经理，“统一项目目标”只是做到了“统一共识”，明确了方向，但还需要“统一力量”——使用各种方法手段使更多的人心归属到支持达成项目目标上，凝聚越多的支持力量，成功的把握性才越大。关于如何做到这一点将在《干系人管理》章节中进行详述。

4.5   项目范围控制

项目发起方的干系人根据自己的期望需求会分别提出不同的项目目标，所有这些目标综合确定了项目的范围。模糊的项目目标很容易导致项目范围的扩散，如果想做好项目范围的控制，就必须做到如下两点：

一、全面搜集干系人的期望需求，并对所有需求进行综合分析，根据SMART原则对每一个需求核实细化为真正的项目目标。

二、建立项目范围变化控制管理机制，包括：范围变化审核负责人，工作流程，必要的沟通工具。

随着干系人的变化目标极可能随之变化，由于项目目标的变化会涉及到不同干系人的利益，究竟是按照谁提的目标来执行，一般不是项目经理能独断的，需要纳入各干系人共同认可的项目范围变化控制流程进行统一管理。有经验的组织一般在项目立项时就要由关键干系人（一般是合同双方/多方具有财物、技术等确定权的领导人）成立项目管理委员会（Project Management Office，简称PMO，关于PMO的构成将在《项目组织结构》章节中详述），遇到目标变化的情况项目经理可提交材料由PMO确定是否变更。对于内部项目，即使没有明确的PMO，项目经理也要根据项目干系人的关系，按照“有限授权，逐级申请”的原则，确定虚拟的PMO，出现目标变化时由各个干系人共同商讨确定。

相当多经验欠缺的项目经理在遇到目标变化时会犯独断专行的错误：要么坚决的一口回绝客户提出的新的要求，导致客户不满；要么软弱的完全答应客户提出的几乎任何要求，致使项目无限期后延，导致老板不满。前者是贸然扩大了自己的权力，后者是完全放弃了自己的权力，都属于极端表现。在组织项目管理制度不完善的情况下，作为执行代理人，项目经理一定要跟上级请示清楚自己能决策的范围，在实在难以说清楚的情况下，就以新增的工作内容是否会导致项目延期，是否超预算成本为标准：只要判断不超，就可自行决断，否则就请示上级领导来决策。

常用的项目范围控制流程如下图所示：

（图需更新）

在项目启动后，需要尽快调研项目需求，明确目标，并由各方共同书面确认（统一目标），定为项目范围基线。对于此后在设计、实施等阶段由各干系人提出的需求，均纳入PMO确定的统一变更流程进行审批控制，对于确认通过的新需求，与原需求进行归并，并形成新的项目范围基线，同时据此更新项目计划，依据新的计划继续实施项目。这将确保整个项目在受控范围内实施。

无论什么项目，越早明确目标，确定项目范围，项目就越容易控制，项目成功的机率就越高。强调三点：一、目标必须经关键干系人（不一定是目标提出者，但最好是项目验收者）确认；二、目标务必符合SMART标准，否则即使有确认，但理解差异大，在交付验收时必然是各执一词；三、尽早确定范围基线，避免没有基线带来的混乱变化影响项目的正常进展，把项目做成“无底洞”。项目目标是允许变化的，但变化必须受控——必须按照既定的流程规则由关键干系人共同管控。

4.6   小结