2006-04-21

比较PRINCE2与PMBOK

项目管理向来就是一个充满挑战的管理,管理人员必须在有限的人力、物力、财力、时间基础上,在变化多端以及风险频出的环境中,产出预期质量的项目结果。如何有效和高效地管理项目一直是官、产、学界研究的重要课题。

  各国在对项目管理方法、知识体系的不断探索中逐渐形成了PRINCE2与PMBOK两套不同的标准体系。作者正是基于深入理解了 PRINCE2--英国政府、公共部门、私有部分广泛接受的事实上的项目管理标准--和美国项目管理协会的PMBOK,同时综合国内外对二者探讨的相关论 著和项目管理大量实践的基础上写作本文,希望对我国政府的项目外包、企业的项目实施提供有价值的参考。  

  在对PRINCE2和PMBOK具体比较之前,读者必须清楚二者作为通用的项目管理方法论,在实际应用中不能全盘照搬,必须依照具体项目的特点进行剪 裁以适合应用的需要。由于二者都是基于项目管理的最佳实践(best-practices)的基础上的标准体系,会随着组织的实际应用经验的总结而不断更 新。本文对PRINCE2和PMBOK的比较基于:

  " PRINCE2:Managing Successful Projects with Prince2,Reference Manual,英国商务部OGC,1998版。

  " PMBOK:A Guide to the Project Management Body of Knowledge,美国项目管理协会PMI,2000年版

  1 内容体系

   PRINCE2

  早在20世纪70年代,英国政府就要求所有政府的信息系统项目必须采用统一的标准进行管理。1979年CCTA采纳Simpact Systems公司开发的PROMPT项目管理方法作为政府信息系统项目的项目管理方法。在PROMPT项目管理方法的基础上,20世纪80年代年英国政 府计算机和电信中心(CCTA)(后来并入英国政府商务部(OGC))出资研究开发PRINCE,1989年Prince正式替代PROMPT成为英国政 府IT项目的管理标准。

  PRINCE,一种对项目管理的某些特定方面提供支持的方法。它是PRojects IN Controlled Environments(受控环境中的项目)的首字母缩写,是组织、管理和控制项目的方法。自从Prince的引进,Prince就广泛的被用于公共和 私人部门。虽然开发Prince的原意是用于IT项目,但实际运用中,许多非IT项目也采纳了该标准。

  1993年,OGC又将注意力转移到Prince新改版Prince2的开发。通过整合现有用户的需求,同时提升该方法成为面向所有类型的项目的、通 用的、最佳实践(best-practices)的项目管理方法。在OGC的组织下,大量项目管理的专家和学者组成设计和开发团队,超过150家公共和私 人组织参加评审委员会为开发工作提供有价值的输入和反馈意见。1996年3月开发工作正式结束。

  目前,PRINCE2已成为了英国政府、公共部门、私有部分广泛接受的项目管理事实上的标准,PRINCE 2 已风行欧洲与北美等国家。Sun、Oracle等将PRINCE2作为实施项目的标准管理方法;香港特别行政区政府资讯科技署将PRINCE2作为政府项 目管理的标准指南;"大中华客户关系管理咨询公司"的合伙人及Tri Dynamics的创办人David Childs建议所有的CRM项目都使用Prince 2作为标准方法。

  Prince2是基于过程(process-based)的结构化的项目管理方法,适合于所有类型项目(不管项目的大小和领域,不再局限于IT项目)的易于剪裁和灵活使用的管理方法。

  PRINCE2手册介绍了PRINCE2中涉及的8类管理要素(component)、8个管理过程(process)以及4种管理技术(technology)。如图1所示:

  图1 PRINCE2手册的结构

  其中管理要素包括组织(Organisation)、计划(Plans)、控制(Controls)、项目阶段(Stages)、风险管理 (Management of Risk)、在项目环境中的质量(Quality in a project environment)、配置管理(Configuration Management)以及变化控制(Change Control)等8类管理要素。这些管理要素是PRINCE2管理的主要内容,它们的管理贯穿于8个管理过程中。

  图2 PRINCE2管理要素

  Prince2提供从项目开始到项目结束覆盖整个项目生命周期的基于过程(process-based)的结构化的项目管理方法,共包括8个过程,每 个过程描述了项目为何重要(Why)、项目的预期目标何在(What)、项目活动由谁负责(Who)以及这些活动何时被执行(When)。它们是:指导项 目Directing a Project (DP),开始项目Starting up a Project (SU),启动项目Initiating a Project (IP),管理项目阶段边线Managing Stage Boundaries (Sblack eye, 控制一个阶段Controlling a Stage (CS),管理产品交付Managing Product Delivery (MP),结束项目Closing a Project (CP),计划Planning (PL)。其中,DP和PL过程贯穿于项目始终,支持其他六个过程。

   图3 PRINCE2管理过程

  PRINCE2手册还介绍了在项目管理过程中常用到的一些技术:基于产品的计划(Product-based planning)、变化控制方法(Change Control approach)、质量评审技术(Quality Review technique)以及项目文档化技术(Project filing techniques)。有效使用这些技术为项目管理的成功提供了有力的保障。

  PRINCE2将8类管理要素(component)、8个管理过程(process)以及4种管理技术(technology)进行了整合,勾画出项目管理的全部视野。如下图所示:

  图4 PRINCE2管理视野

   PMBOK

  项目管理知识体系PMBOK(A Guide to the Project Management Body of Knowledge)是由美国项目管理协会PMI1996年综合大量专家和会员的意见开发完成的,2000年PMI对PMBOK进行了版本更新,本文正是 基于这一最新版本向大家介绍相关的知识。

  PMI开发PMBOK的主要目的是为项目管理提供通用的词汇,确定和描述项目管理中被普遍接受的知识,用于在职业和实践中谈论和书写关于项目管理方面的内容。

  PMBOK指南的主要内容有两部分构成:项目管理框架(The Project Management Framework)和项目管理知识域(The Project Management Knowledge Areas)。在项目管理框架中,除介绍项目管理的概念、生命周期等概念外,重点提到了项目管理的五大过程组:立项(或启动)过程(Initiating processes)、计划过程(Planning processes)、控制过程(Controlling processes)、执行过程(Executing processes)以及收尾(或结束)过程(Closing processes)。

  图5 PMBOK过程组相互间的关系

  PMBOK指南的第二部分主要介绍项目管理的9大知识域,以及5大过程组在9大不同的知识域中细分为的39个不同的过程。相互间的关系如下表所示:

  表1 PMBOK知识域、过程组以及细化的过程

  2 项目的概念、以及项目管理涉及的知识领域

  PMBOK和PRINCE2对项目概念的定义基本一致。

  PRINCE2定义项目:根据一个特定的业务状况(Business Case),以生产交付一个或多个商业产品为目的而建立的临时性组织。

  PRINCE2项目具有以下特点:

  " 有限的和定义明确的生命周期

  " 定义明确、可测度的商业产出(business products)

  " 为获得商业产出定义了一系列相应的活动(activities)

  " 明确定义了资源总量

  " 为高效地管理项目,定义了组织结构,明确了组织结构中人员的角色及其相应 的职责

  PMBOK定义项目为:为完成一个唯一的产品或服务的一种一次性努力。在PMBOK指南中明确将项目(Project)与业务(Operation) 作了区分。"项目通常作为实现组织战略计划的一种手段来实现。业务和项目从本质上是不同的:业务是连续和重复的而项目则是临时和唯一的。一个项目可以用其 特有的性质来定义,项目是创建一个唯一产品或服务的临时性努力。临时是指每个项目都有一个明确的开始和结束。唯一是指产品或服务均有其区别于其它产品或服 务的特点。"

  PRINCE2和PMBOK中都对项目与计划/方案(Programme)作了区分,PMBOK认为"Programme是以一种相联的方式管理的一组项目",PRINCE2认为"Programme是按照协调原则选择、计划和管理的项目组合。"

  PMBOK管理项目所需的许多知识是专用于项目管理的(如关键路线法和工作分解结构)。但PMBOK 也同其它学科交叉,并且考虑了项目管理对社会、经济、环境的影响。

  图6 PMBOK项目管理知识与其他领域知识的交叉

  对比而言,PRINCE2指出由于具体项目管理的技术和需要的工具依照项目的类型和公司的环境的不同而不同。PRINCE2并不打算包括传统意义上所 说的项目管理的所有领域,如项目可行性研究、项目采购管理、项目人力资源管理等(*进一步的讲解见第四和第五部分)以及一些常用的技术,如预算控制和挣得 价值分析(EVA,earned value analysis)。当然,PRINCE2也指出,如若需要,可行性研究等过程也可单独作为一个项目进行管理,一些常用的技术,可以由项目专家团队(或称 为项目支持办公室PSO,Project Support Office)来完成。因此,PRINCE2项目管理知识领域为:

  

  图7 PRINCE2与其它知识领域的关系

  3 组织(Organization)与角色(Role)

PRINCE2

  PRINCE2详细定义了项目组织,指出项目管理包含4个层次:

  " 项目指导(direction of the project)

  " 日常管理(day-to-day management of the project)

  " 项目团队管理(team management)

  " 产品制造工作(the work to create the products)

  前三个管理职责归为项目管理团队(project management team),最后一个管理职责由项目团队(project team)本身负责。项目团队指具体实施项目的团队。作为项目管理方法,PRINCE2将重心放到项目管理团队的各个角色及其相应职责的定义上:项目委员 会(又称为项目董事会Project Board)、项目执行官(Project Executive)、高级用户(Senior User)、高级提供者(Senior Supplier)、项目经理(Project Manager)、项目团队经理(Team Manager)、项目保证组(Project Assurance)以及项目支持组(Project Support)等。

  PRINCE2定义项目委员会对项目最终结果负责,是项目与外界接口,项目的"声音"、外部的变化以及项目信息都是通过此接口交流、发布。PRINCE2要求项目委员会始终要满足如下所示的三方利益:

  图8 PRINCE2项目委员会必须满足的三方利益

  " 商业(业务)Business

  项目产品(*具体阐述见第7部分)应该满足业务需要,项目结果应该收回对项目的投资,因此项目应始终关注业务状况(Business Case)3。项目执行官(Project Executive)通常代表客户(*为项目支付费用,委托项目并将从最终结果中得益的个人或团体)关注商业(业务)利益得到满足。

  " 用户User

  PRINCE2定义用户为满足下列条件的个人、组织:使用最终产品;通过产品获得目标;使用最终产品来为利益服务;受输出结果的影响。 有时用户(User)和客户(Customer)是同一人或同一组织。

  用户的利益应在项目委员会中得到体现。通常通过高级用户代表用户的利益。

  " 供应者Supplier

  在创造最终产品的过程中可能需要一定资源和技能,这些提供资源和技能的个人和组织称为提供者。提供者可能来自于组织内部或组织外部。

  提供者的利益应在项目委员会中得到体现。通常通过高级提供者代表提供者的利益。

  除此之外,PRINCE2对其他角色及其职责也做了详细的定义。

  项目经理:被授予权力和责任管理项目的个人,他负责项目的日常性管理,按照同项目委员会达成的约束条件交付必需产品。在需要时提交风险报告、问题报 告,定期向董事会提交重要报告(highlight report)以反映项目的执行情况,在阶段结束时提交阶段结束报告、在项目结束或必须中途终止时提交项目终止建议等。大多数文档工作由项目经理完成,项 目经理由项目委员会任命,为委员会实行例外控制(Exception Control)提供方便。

  项目团队经理(有时又称为项目小组长,Team Manager):项目经理指派管理项目小组成员工作的人。根据项目实际情况,该角色可有可无。

  项目保证组(Project Assurance):项目委员会为避免项目管理信息不对称,委派人员监督项目管理,确保自己正确管理项目的职责。项目保证组必须保证与项目经理独立。

  项目支持组(Project Support):项目委员会委派协助项目经理管理项目的小组或专家,主要避免项目经理对某些专业知识的缺乏造成项目的管理不善。有时执行项目的组织设立 项目支持办公室(PSO, Project Support Office)为项目经理提供必要的支持服务,通常它们同时为许多项目提供服务,如:计划、控制工具的使用,报告技巧,变化控制,配置管理等。

  需要注意的是,PRINCE2指出项目可能是方案(*Program,按照协调原则选择、计划和管理的项目组合。)的一部分。如,建设一个学校这一方 案中,教学楼的建设作为一个项目实施,信息系统的建设作为一个项目。这时,项目必须和项目执行组织方案管理保持一致,必须确保项目管理符合业务需要,在这 种环境下,项目组织结构图如下:

  图8 PRINCE2项目作为方案的一部分的组织结构图

  PMBOKPMBOK对组织结构和角色定义远不如PRINCE2明确,推荐项目结构和角色随实际项目而变化。PMBOK指南指出项目办公室(Project Office)对项目管理结果,但项目管理办公室具体如何构成并没有进行说明。

  比较而言,PMBOK指南没有区分供应者、用户、客户,以及他们在项目管理组织结构中的角色如何分配,只是用发起人(sponsor)指一切利益相关者,定义为"提供支援(无论以资金或其他方式)的组织内、外的个人或团体"。

  关于项目经理PMBOK只是简单指出:"负责管理项目的个人"。所以我们可以推论,在PMBOK中项目经理对项目负主要责任,其权力显然要大于PRINCE2中项目经理的权力。

  虽然PMBOK没有具体定义项目的组织结构,但却指出具体的项目管理受到项目执行组织结构的影响,典型的项目型组织结构为:

  图9 PMBOK项目型的组织结构

  4 项目生命周期、项目阶段

PRINCE2

  PRINCE2非常重视项目阶段的划分,将项目阶段作为项目管理的8大要素之一加以管理(见图2),要求将项目切分成一些可供管理的阶段,以便高效地控制资源的使用和在整个项目周期执行常规的监督流程。

  PRINCE2用"stages"来表示项目阶段,并且将"stages"与传统项目管理和产品周期中表示阶段的"phases"作了比较。指出产品生命周期阶段"phases"一般包括:

·构思conception

·可行性研究feasibility

·实施(或实现)implementation (or realization)

·产品使用(或操作)operation

·终止产品使用termination

  而PRINCE2的项目阶段"stages"并不与上述"phases"对应,上述的后两个阶段不包括在PRINCE2项目之内,通常情况下, PRINCE2项目阶段是对产品"实施(implementation)"阶段的进一步细分。PRINCE2项目生命周期一般不开始于"产品构思"、"可 行性研究"--这些通常作为一个单独的项目实施,以"项目委任书(Project Mandate)"的方式作为PRINCE2项目的输入。因此我们亦可以将PRINCE2在某种程度上看作"项目实施方法论",而并不是一般意义上的项目 管理方法论。这也反映了现实中很多项目由"顾客"委派开发,项目开发周期中并不需要可行性研究等前期工作,如接纳信息系统外包的项目。当然我们说可以将 PRINCE2在某种程度上看作"项目实施方法论",但要注意与具体的传统意义上项目"实施阶段"相区别。在PRINCE2项目开始之前为确保以"有组织 的和可控的方式"开始一个项目,PRINCE2用"开始项目Starting up a Project (SU) "和"指导项目Directing a Project (DP)"(见第五部分的阐述)过程来完成这方面的工作,让项目委员会确保项目满足业务状况,项目是"可执行的"和"需要执行的"。同时在PRINCE2 项目结束时必须要制定项目后评审计划(*Post-Project Review Plan,项目结束后举行的一次或多次的检查,以便确定项目所期望的结果是否达到。)以及后续行动建议(Follow-on Action Recommendations)等。因此PRINCE2生命周期是不包括产品项目开发的全部周期,但它要比项目实施周期要长,覆盖项目实施周期再加上项 目前的准备阶段,以及部分项目后的阶段。产品项目周期、项目实施周期、以及PRINCE2项目周期相互间的关系如下图所示。

  图10 PRINCE2项目周期与产品项目周期、项目实施周期比较图

  同样,PRINCE2项目阶段也没将"合同""采购"包括在项目周期中,建议将"合同""采购"等专家活动(specialist activities)同上面介绍到的"可行性研究"一样可单独用该方法进行管理。

  除此之外,PRINCE2区分了技术阶段(technical stages)和管理阶段(management stages)。技术阶段典型地需要使用专家技术。而管理阶段集中于资源和权力的分配上。技术阶段和管理阶段可能一致也可能不一致,不一致时可将技术阶段 分拆或整合为管理阶段进行管理。PRINCE2强调对"管理阶段"的管理。

  为确保项目的可控性,必须确保各个项目阶段的可控,PRINCE2专门用"管理项目阶段边线Managing Stage Boundaries (Sblack eye" 过程(见第五部分的阐述)来对项目各个阶段有效性的控制。项目经理在项目即将结束和结束时必须提交 "下阶段计划书"、"业务状况更新报告""风险更新报告"、"阶段结束报告"等,若项目由于某些原因不能继续执行,必须提交"项目终止建议"报项目委员会 批准。项目委员会必须始终确保项目各个阶段的可控,在一个阶段没结束前,PRINCE2不建议开始下个阶段。

PMBOK

  PMBOK指南定义项目阶段"phases"为:"逻辑上相关的项目工作的总和。通常结束在一个主要的可交付成果完成时"。 PMBOK没有对"phases"和"stages"作任何区分。PMBOK指出在实际项目中各阶段往往存在重迭(overlap)和交互 (interaction)。

  图11 PMBOK项目阶段交互图

  另一方面,指南承认项目需要评估和可行性研究,但评估和可行性研究是否作为项目的第一阶段,可根据具体项目而定。与PRINCE2明显不同的是,PMBOK将"采购"和"合同"的管理纳入了项目管理的阶段(见表1项目采购管理知识域)。

  某些情况下,如为了进度的要求,而风险又较小时,允许在前一阶段结束前开始下一个阶段(称之为快速跟进Fast Tracking),但承认这样做会增大项目的风险。

  PMBOK没有明确指出项目周期如何确定,但指南通过有代表性的例子说明不同项目的周期的情况。同时还指出项目各个阶段资金成本和人员的消耗情况。

  图12 PMBOK项目各个阶段资金、人员消耗图

  5 项目管理过程

  PRINCE2和PMBOK都是基于过程的项目管理方法论,在PRINCE2手册和PMBOK指南中对项目过程(process)的讲解都是"重头戏",所有的项目管理活动都是围绕着过程而展开。

  PRINCE2明确指出项目管理基于从"开始项目Starting up a Project (SU)"到"结束项目Closing a Project (CP)"的六大过程,剩下的"计划Planning (PL)"和"指导项目Directing a Project (DP)"作为持续不断的过程支持其他6大过程。(见图三PRINCE2管理流程)PRINCE2进一步将8大过程细分为45个子过程加以管理, PRINCE2的8大管理要素就贯穿于这些过程进行管理。(见图4 PRINCE2管理视野)

  每个(子)过程按涵盖以下内容:

  " 基本原则(Fundamental principles)表述: 为何要有该过程?过程目标何在?该过程为何对成功的项目管理起着基础的作用,因此作为PRINCE2的最低要求?

  " 过程背景(Context):将每个PRINCE2过程置于其他过程的背景下讲解,通过图示具体表明该过程与其他过程和子过程间的相互联系,包括该过程的 输入(input)来源和该过程的输出(output)走向或更新的输出信息。下图显示了指导项目(DP)中Authorising Initiation (DP1)的过程背景。

  图13 PRINCE2-DP1的过程背景图

  " 过程描述(Process description)讲述:该过程旨在实现的目标,以及执行的具体步骤。按逻辑顺序推荐的步骤并不一定需要严格按照该顺序进行执行。具体情况由实际项目本身决定。

  " 职责(Responsibilities):表明谁应该为该过程的成功执行负责任。让责任与角色具体挂钩。

  " 需要的信息(Information needs)具体说明:该部分所需的重要信息(输入)和取得的目标(输出和更新)。

  " 关键标准(Key criteria):通过一系列疑问句提示管理者如何审视该过程的完成情况,确定该过程的成功与否。

  " 技巧(Hints and tips):表明用于该过程常用的技巧,以及在具体项目中如何变通实施该过程。

  PMBOK指南通过9大知识域将5大过程组细分为的39个不同的过程进行管理。相互间的关系见表一。

  PMBOK通过对过程的输入、过程涉及到的工具和技术以及输出来具体讲解各过程。

  " 输入(Inputs):说明该过程所需的输入信息、文档等一切需要的东西。

  " 工具和技术(Tools and Techniques):推荐成功实现该过程的工具和技术手段。

  " 输出(outputs):表明该过程成功实施的产出。

  为加深读者对PMBOK过程的了解,下图作为范例表明综合管理子过程--项目计划建立(4.1 Project Plan Development)的内容。

  图14 PMBOK-"4.1项目计划建立"过程内容

  尽管PRINCE2和PMBOK都对过程进行了详细的讲解,但我们需要注意二者的不同之处。PRINCE2在讲解过程中没有推荐相应的实现工具和技 术,具体实施技术和工具PRINCE2建议根据具体情况确定,项目经理可以要求项目支持组支持相应的技术和工具。PMBOK虽然表明各过程间存在交互,一 个过程的输出可能是另一过程的输出,但没有用图式具体表明各过程间的相互联系。

  PRINCE2和PMBOK都表明某些过程会相互重叠,如PRINCE2的PL和DP过程贯穿于项目的执行活动的始终。PMBOK对过程重叠情况用图示更加清楚地表明了。

  图15 PMBOK过程交互图

  二者都比较重视对计划、风险、控制的管理,PRINCE2将计划过程贯穿项目管理的始终,将风险和控制作为两大管理要素在各个具体的管理过程中进行管 理。PMBOK强调风险管理为管理的重要知识域,将控制作为一大过程进行管理,而计划的管理则贯穿于项目的始终。PRINCE2、 PMBOK强调项目"计划、风险、控制"的管理作为项目管理的核心,反映了它们作为广为传播的项目管理标准优秀的一面。

  PMBOK作为美国项目管理协会提出的项目管理的标准指南,将北美等国广为重视的"人力资源管理"作为一个知识域进行管理, PRINCE2对这方面没有具体涉及,只是指出"项目角色分配时合适的人应分配合适的职责",强调角色的可用性和胜任性。如前所述,采购管理在 PRINCE2中没具体讲解,建议采购管理作为专家知识或单独用PRINCE2进行管理,而不包括在PRINCE2项目中。

  PMBOK、PRINCE2都比较重视交流管理(Communication Management)。PMBOK中将交流管理贯穿项目始终,用以协调各利益相关者间的利益,发布项目进行情况。PRINCE2强调项目内的交流通过项 目经理与项目管理委员会之间进行,或在项目小组内进行;与外界的交流统一通过项目委员会实现。

  配置管理(configuration management)在PMBOK和PRINCE2中都得到了应有的重视,PRINCE2定义配置管理"一种为加强管理层对财产(如项目产品)严格监控 实施的规范,它包括项目产品的计划、鉴定、控制、检验等。该规范一般受工具软件支持。"二者在很多过程中都对配置管理作了讲解。配置管理强调产品(*关于 产品的内容读者可参见第6部分的讲解)的版本控制,经过批准的产品状态不能轻易改变,所需的改变必须得到项目管理层的批准,并且同一时间只能有一人对此进 行改变。进入配置管理的产品状态就成为基线(Baseline)。在软件开发项目中配置管理的作用尤为重要(读者可参阅美国SEI的CMM)。

  概览PRINCE2和PMBOK对过程的讲解,我们可以发现PRINCE2对过程的讲解更加详细,而PMBOK对过程的讲解涉及面更广,视野也更为广阔。

  6 项目产品和项目重要文档

  PRINCE2定义产品(products)为"项目的任何输入和产出"。PRINCE2 将产品区分为:管理产品(由项目的管理生成,如各种管理过程产生的文档),特定产品(组成最终交付物的产品),质量产品(为了质量过程或由质量过程生 成)。同时指出一个产品可能本身就是其它产品的一个集合。PRINCE2通过产品分解图(PBS,Product Breakdown Structure)将项目产品进行细分。用产品流程图(Product Flow Diagram)显示产品分解图中列出的产品其生产序列和相互间关系的图表。

  PMBOK对产品更多地用"可交付成果(Deliverable)""工作work/activity"等词汇来描述。可交付成果 (Deliverable)定义为"为了完成一个项目,或项目的一部分,必须产生的可以度量的,有形的,可验证的任何成果,结果或事项。在涉及到外部的可 交付成果时,更狭窄地使用这个术语,它是由项目业主或客户批准和控制的交付成果"。工作work/activity被定义为"在一个项目期间执行的一项工 作元素。一项工作通常有一个预计的时间,预计的成本,和预计的资源需求。工作经常被划分成单个任务。"

  PMBOK也承认工作需要不断细化,与PRINCE2的PBS相对应,PMBOK对工作的细化用WBS(Work Breakdown Structure)来表示。

  综上可见,PRINCE2与PMBOK对项目产品的描述基本一致。

  PRINCE2非常强调文档的使用,每一过程的有大量的文档输入、产生或者更新。PRINCE2如此强调文档的原因在于通过文档对项目实施情况进行控 制(如检查点报告Checkpoint Report),对计划的履行情况进行检查(如Project Plan),对环境的变化作出反应(如Request For Change ),对项目管理的各种经验得失进行总结(如Lessons Learned Report)。

  尽管PRINCE2指出项目文档应和具体项目情况相适应,但大量的文档常常使得项目管理人员无所适从。PRINCE2为避免该情况的发生,特意在附录 中列出了27个PRINCE2产品描述的大体框架(Product Description Outlines),并且给出了相应的文档模板下载,供项目管理人员参考使用。

  PMBOK指南也定义了大量的文档,但对文档的使用没有做太多强制地要求。值得注意的是PMBOK和PRINCE2有许多文档是一致的。如:沟通计划 (Communications Planning)、项目计划(Project Plan)、项目经验报告(Lessons learned report)。

总结

  PRINCE2与PMBOK作为项目管理两套不同的标准体系,受到了广泛的使用。但由于二者基于不同的目的,我们必须承认二者不可能在平行的角度去完全对比二者,当然也不能完全用一种方法代替另一种方法。

  通过深入了解二者,笔者认为PMBOK更加适合对项目管理知识的教学,适合让那些对项目管理感兴趣的人对项目管理各个知识域的理解,在特定的项目中应用该方法时我们必须和其他的项目管理方法(如PRINCE2)相结合。

  而PRINCE2作为为政府项目采购和外包而开发的项目标准,对项目管理的具体实践有着重要的指导。PRINCE2通过提供强健的易于实施的方法步骤 (easy-to-follow)适于在大多数的项目中实施。PRINCE2通过DP、SB等过程确保项目管理高层实行例外控制,让他们用有限的时间完全 熟悉项目的状态。通过项目委员会将项目管理和组织的方案管理(programme management)联系起来,通过业务状况与公司利益保持一致,可以说是从组织的战略层面确保项目的正确实施。同时PRINCE2对参与项目的角色的 细分以及在项目周期中不包括可行性研究等专业知识的使用,而专注于管理过程等非常适合项目外包以及政府项目采购和外包,体现了PRINCE2开发的初衷。

  总之,笔者认为将PMBOK定位于知识架构,PRINCE2定位于实施指南比较合适。

  随着我国政府项目采购与外包计划的日益巨大,如何确保我国政府项目外包的透明度以及高效地管理项目外包计划,我们认为PRINCE2 非常值得我们借鉴。通过借鉴PRINCE2和PMBOK希望我国政府能够在项目外包时有自己的标准可循,企业在实施项目过程中能更加有效地管理项目,促进 项目的成功。

2006-04-19

WBS最佳实践--构成

WBS构成


WBS在大多数教科书以及出版物中基本以“组织机构图”的形式出现,这种简单的图示能够清晰的展示WBS的结构特性。但是很不幸,它不能展示WBS的全部内涵。那么WBS的全部内涵是如何体现的呢?


首先看PMI的定义:工作分解结构。他们是由3个关键元素构成的名词:工作--可以产生有形结果的工作任务;分解--是一种逐步细分和分类的层级结
构;结构--按照一定的模式组织各部分(pratice standard for WBS,PMI)。根据这些概念,WBS有相应的构成因子与其对应:


结构化编码


编码是最显著和最关键的WBS构成因子,首先编码用于将WBS彻底的结构化。通过编码体系,我们可以很容易识别WBS元素的层级关系、分组类别和特
性。并且由于近代计算机技术的发展,编码实际上使WBS信息与组织结构信息、成本数据、进度数据、合同信息、产品数据、报告信息等紧密地联系起来。


工作包


工作包(work
package)是WBS的最底层元素,一般的工作包是最小的“可交付成果”,这些可交付成果很容易识别出完成它的活动、成本和组织以及资源信息。例如:
管道安装工作包可能含有管道支架制作和安装、管道连接与安装、严密性检验等几项活动;包含运输/焊接/管道制作人工费用、管道/金属附件材料费等成本;过
程中产生的报告/检验结果等等文档;以及被分配的工班组等责任包干信息等等。正是上述这些组织/成本/进度/绩效信息使工作包乃至WBS成为了项目管理的
基础。基于上述观点,一个用于项目管理的WBS必须被分解到工作包层次才能够使其成为一个有效的管理工具。


WBS元素


WBS元素实际上就是WBS结构上的一个个“节点”,通俗的理解就是“组织机构图”上的一个个“方框”,这些方框代表了独立的、具有隶属关系/汇总
关系的“可交付成果”。经过数十年的总结大多数组织都倾向于WBS结构必须与项目目标有关,必须面向最终产品或可交付成果的,因此WBS元素更适于描述输
出产品的名词组成(effictive WBS,Gregory T.
Haugan)。其中的道理很明显,不同组织、文化等为完成同一工作所使用的方法、程序和资源不同,但是他们的结果必须相同,必须满足规定的要求。只有抓
住最核心的可交付结果才能最有效的控制和管理项目;另一方面,只有识别出可交付结果才能识别内部/外部组织完成此工作所使用的方法、程序和资源。工作包是
最底层的WBS元素。


WBS字典


管理的规范化、标准化一直是众多公司追求的目标,WBS字典就是这样一种工具。它用于描述和定义WBS元素中的工作的文档。字典相当于对某一WBS
元素的规范,即WBS元素必须完成的工作以及对工作的详细描述;工作成果的描述和相应规范标准;元素上下级关系以及元素成果输入输出关系等。同时WBS字
典对于清晰的定义项目范围也有着巨大的规范作用,它使得WBS易于理解和被组织以外的参与者(如承包商)接受。在建筑业,工程量清单规范就是典型的工作包
级别的WBS字典。


上述构成因子是最基本的组件,而这些组件的定义是结构化、概念化的。至于WBS必须包含的信息则是见仁见智的事情,因为其与编制WBS的组织的管理需求有关。

WBS最佳实践-概念

如何编织有效的WBS?PMI的WBS最佳实践标准,

WBS概念

实际上WBS的概念很容易理解:为了管理整个项目,就应该管理和控制它的所有组成部分(Garold D. Oberlender, 1993)。国外许多项目管理的经典教科书在介绍WBS概念时都使用了“如何吃掉大象”的典故。它说明了WBS是阐述项目是如何由一项一项的工作或工作成果构成并实现的。

WBS最大的特点在于它是结构化的项目内容分解结构。这种“解构”框架将项目目标逐步分解为包含成果和活动的最小工作包(工作包与责任矩阵末端直接关联),它不仅适用于纵向的目标管理、整体管理,更由于工作包的具有资源、成本估算和活动定义,使成本和进度信息也被WBS结构有效的组织起来。正因为如此,WBS技术跟随PERT技术被广泛传播和应用,目前绝大部分项目管理系统的基础都是基于WBS技术的,尽管他们在不同层次上对该技术进行了革新。

项目管理理论指出:项目管理的核心是项目计划,而项目计划的基础就是WBS。由于PMI出于对PMBOK结构化的需要,将WBS放在范围定义中阐述。但是这不应该使读者产生WBS仅仅是范围管理工具的错觉。实际上WBS是项目管理的核心工具,本站将在以后展示WBS在项目管理生命周期的作用和地位。
总结
至此,我们对WBS有了如下认识:

由项目目标、产品和服务结果解构的管理框架
提供了清晰定义范围的工具
具备与OBS及其RAM关联的接口
具备与成本、进度信息关联的接口
反映活动、工作和成果如何实施的结构框架
为绩效测量提供了基础