项目管理的核心思想之一目标管理 项目管理的核心思想之一:目标管理项目干系人目标不一致是导致绝大多数项目失败的主要原因。经验总结4.1 项目失败最大风险：目标模糊目标管理是项目管理的核心思想之一，明确并统一项目目标是项目管理的首要任务。目标是前进的方向，是团结的旗帜，项目的一切活动都围绕项目目标展开。任何项目的目标都是由项目的一个或几个干系人因为某些原因提出来的，由于每个人的知识范围、语言、文化、性格等存在差异，导致每个人对项目目标的理解和期望迥异，所有项目的目标既有显性目标，又有隐性目标，往往隐性目标却又是真正的目标。高效挖掘隐性目标并把项目干系人统一到同一目标上是优秀项目经理必备的能力之一。项目的大目标多数都是模糊的，准确识别真正的项目目标是项目成功的基础。只有对该目标进行分解并逐一细化，并不断调研分析，“渐进明细”，才能确定真正的目标。一个真正的项目目标必须符合“SMART”标准，即：SSpecific（明确的）MMeasurable（可测量的）AAction-oriented（行动导向的）RRealistic（务实的）TTime-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”为准则细化的最小单元。工作包细化的程度达到“能够可靠地估算和管理工作成本