PRINCE 2与PMBOK的比较

刀下留情

[项目管理]PRINCE 2与PMBOK的比较

R.Max Wideman著 侯煜红 编译 2003-10-21　　　　　　　　　　　　　　　　　　　　　　 　　　摘自：中国计算机报 　　项目管理领域目前有两个广为流行的知识体系：一个是英国商务办公室（OGC）开发的“受控环境下的项目管理（PRINCE，Projects In Controlled Environments）”，PRINCE 2是1996年推出的第2版；另一个是美国项目管理协会（PMI）开发的“项目管理知识体系（PMBOK，Project Management Body of Knowledge）”，目前最新的版本是2000年推出的“PMBOK指南2000”。 　　PRINCE 2和PMBOK在世界范围内都有十分广泛的应用。这两个知识体系虽然有很多共同点，但区别也十分显著。 　　一般而言，PMBOK提供了丰富的“项目管理的知识”，但并未告诉人们如何使用这些知识。并且，PMBOK中虽然也包含流程与流程间的关系，以及所需要的技术和工具，但并未指出“如何做”。与此不同的是，PRINCE 2则是完全基于流程的，而且是基于业务实例（Business Case）开发的。 　　为了能全面地对二者进行比较，首先来看看二者所包涵的主要内容，具体如图1与图2所示。    　　下面将具体从项目生命周期和流程、管理等级与责任、授权文档等七个方面来对二者进行比较。 　　项目生命周期及主要流程 　　如图2所示，PRINCE 2描述的是完整的项目生命周期，它包括8个主要流程，其中的6个，即从“项目启动”到“项目收尾”构成了项目生命周期的主体。其余的两个，“计划”和“项目指导”则是对这6个流程的全程持续支持。在PRINCE2的8个流程中，每个主要流程都包括一系列的子流程，总共45个子流程。驱动项目管理进程的是6个文档化的“组件（Components）”。PRINCE2表达了3个技术概念：“基于产品的计划（Product Based Planning）”、“质量评价（Quality Review）”和“变革控制（Change Control）”。 　　从图1可以看出（译注：图1中包括PMBOK的9大知识领域），PMBOK指南包括12个章节基于功能的知识域描述，并给出相关的项目管理流程的说明，表述了输入、工具与技术以及输出等等。 　　因而，可以看出，在PRINCE 2和PMBOK之间有诸多不同。在PRINCE 2中，提到的是项目的“阶段（stages）”，而不是PMBOK所给出的项目知识的“构成（phases）”。 　　PRINCE 2同时区分了项目管理的技术性阶段和管理阶段。技术阶段由一系列特定的技能构成，此时管理阶段则表达了对所消耗的资源的责任和授权。 　　另一个显著差别是，PRINCE 2的所谓“项目生命周期”并非是从原始需求、方案筹划和可行性研究开始的—这些都被看作项目生命周期的输入。比如，PRINCE 2将产品的生命周期表述为5个阶段：概念、可行性、实施（或实现）、运营和结束。然而，只有实施阶段为PRINCE 2的项目管理所覆盖。因此，PRINCE 2是实施方法论，而PMBOK则认为项目的需求评估或者说可行性研究是项目的第一个阶段。 　　管理等级与责任 　　PRINCE 2有4个等级的管理：公司管理（Corporate or Program Management）；项目督导（如由项目指挥长领衔的项目委员会，在北美常称作项目总监，Project Director）；项目管理（即项目经理层面，project manager）和产品提供管理（即团队级技术管理，team-level technology management)。 　　PMBOK定义的项目经理较为简单，“对项目管理独立承担责任的个体”。软件工程师协会（Software Engineering Institute）将这个定义进一步扩展为，“对整个项目负有全责的角色，需要承担指导、控制、管理和协调项目的责任，并且项目经理最终要向端用户负责。” 　　从这里可以看出，在PRINCE 2下面，项目经理是“在项目委员会的领导和约束下，得到授权并承担项目日常管理责任的人员。”“约束”实际表述的是项目经理在得到的授权下，对项目范围、质量、进度和成本所拥有的责任和可接受的范围。任何超出这些限制的趋势，都会成为一个“问题”并被提交到项目委员会，引起委员会的关注。 　　相比之下，PMBOK并不区分项目指挥长或者项目督导，而是使用 “发起人”（sponsor）的概念。发起人实际是一个项目的利益相关者（stakeholders），它的定义是：内部或者外部的个体或者组织，形成某种组织形态，以现金形式或者其他方式为项目提供财务资源。所以，发起人包含在指南的规定之下，完全为项目经理所控制。 　　授权文档 　　PRINCE 2通过很细致的文档来实施管理。一个项目就是一系列人们需要跟踪的流程、作业序列的集合，也是一系列确保项目顺利进展的管理文档。 　　按PRINCE 2的表述，项目委托文档可以来自任何方面，但必须至少来自某些管理等级，这样就可以按照项目规模和类型，对成本和资源使用进行授权。这就要求有足够的信息来触发“项目启动（Starting up a Project，SU）”流程，并且这个流程可以转化成“项目概要（Project brief）”。PMBOK对业务实例域和项目概要域的内容未加区分。 　　SU流程一般持续较短，它的主要功能是确认所有必须的参与者以及参与内容，并且在项目真正开始之前就位。它假定“业务实例（Business Case）”是存在的，尽管在项目开始之前并不存在真正的业务过程，但可以在SU阶段设立一个业务模型。 　　业务模型用来评估项目，并从原因、利益、成本、进度、风险和来自项目要求或者项目概要、项目计划或者来自客户的信息等内容进行评估。业务模型是一个动态的文档，为反映项目条件的变化，将在项目进程中按需要更新。在项目准备（Initiating a project，IP）的时候，业务实例将作为项目的基准（baseline）。 　　SU流程的输出是“初始阶段计划（Initiation Stage Plan）”，该计划将确认所需要的人员，以及在项目概要中所包含的必要信息。项目概要是相对简化的文本，描述项目背景、项目定义（如项目要实现的目标），业务大纲，用户的质量预期，项目验收条件和任何已知的风险。 　　这个文本将向触发“项目准备”流程，它的结果是“项目准备文档（Project Initiation Document，PID）”。 　　与业务实例不同，业务是适时更新的，而PID则相对稳定，除非业务对象的背景有重大变更。PID试图给出有关的定义，如项目是什么、为什么、对象是谁、时间以及如何做等问题。这个文本是项目委员会评估项目进展、跟踪项目变更事项的基础文档。与准备PID文档同时，项目第一阶段的计划工作中，最重要的是确立项目委员会对项目的授权。 　　在PMBOK中，与PID相对应的是项目章程（Project Charter），该章程是基于PMBOK的领域知识，在项目准备阶段之后形成的文本。它的定义是：项目高级经理拟订的对现存项目的正式批准文件。该文件授权项目经理利用组织资源开展项目活动。 　　特定项目管理角色 　　PRINCE 2中没有定义管理职位，而是定义了角色（Roles），它可以根据项目的需要设置、分享、拆分和合并。除项目委员会、项目经理、团队经理等等，PRINCE 2引入大量别具特色的角色，来实践其方法论。例如： 　　项目支持办公室（Project Support Office，PSO），是各种资源的核心“池（Pool）”，如职员、资料和PRINCE2顾问。PSO对协助行政事务管理、确保整个项目良好体现PRINCE2的指导，是有益处的。除上述人员外，PSO还包括计划与日程、评估、预算和项目会计等专业人士。事实上，很多其他专业性的职责，需要加入到角色定义中来。 　　项目指挥长是项目委员会的主席。在高级用户和高级供应商的支持下，指挥长作为项目最终责任的承担者，确保项目满足所设定的目标。 　　高级用户（Senior User）是项目委员会的成员，其职责是详细陈述项目使用者的需求，与项目团队和用户之间联络，以便监督项目方案满足业务在质量、功能和易用性方面的约束。 　　高级供应商（Senior Supplier）同样是项目委员会的成员，代表项目设计、开发、设施、采购、实施、可能的运维方面的人员。高级供应商对作为供应商提供的产品质量承担责任，并需要取得供应商的授权。 　　项目检验人员（Project Assurance）覆盖项目的有关方面，包括业务、用户和供应商。PRINCE2要求该项服务独立于项目经理，不能由项目经理代替。项目检验是项目执行者、高级用户和高级供应商共同的责任。 　　配置文档管理者（Configuration Librarian）是所有项目重要文件归档的保管人。尽管这个角色的主要职责，是管理文档、生成文档，而不是保存物理实体，毫无疑问对大多数项目而言并非琐碎的任务。它包括对文件收发、签认、保存、修补等工作，以便为项目提供有价值的信息，还包括编码、记录、发布和维护项目进程信息。这个角色是项目支持的一部分。 　　文档描述大纲 　　PRINCE 2包括33个标准管理“产品”，作为PRINCE 2的方法论。这些标准包括各种计划和报告，可以利用这些文档做出有用的内容细节。除了这些用途之外，为确保项目成功，这些文档提供了一致的版本。比如： 　　验收准则（Acceptance Criteria）：对影响客户的最终产品，定义了客户可接受的、可度量项目。这个内容，既可由工程管理者提供，也可在项目启动阶段完成。需要提醒的是，这个重要的基础工作，往往在很多项目中忽略掉了。 　　配置记录（Configuration Item Record）：配置管理给出项目资产的精确控制（包括项目产品），包含计划、鉴订、控制等。配置记录提供参照产品分解结构（product breakdown structure）、阶段和团队计划、相关工作包、质量日志和变革控制等每个项目所需的细节信息。 　　记录日志（Issue Log）：是所有需要在项目中引起注意，并需要解答的事项的整体记录。事项的范围从问题或者关注的陈述，到未定义事项，到范围变革请求。这些事项可以由任何人在任何时间提出。在PRINCE2中，通过捕获各种询问、问题和类似的事件来形成记录日志，它是项目阶段控制的重要组成部分。每个记录事项可以跟踪，直到采取相应的行动后，事项才可以取消。 　　风险日志（Risk Log）：是对所有项目风险确认的收集，包括对这些风险的分析、对策和状态。PRINCE2认为风险是项目管理过程中的重要组成部分，并且是所有关键流程的重要因素。项目管理必须控制和包容风险，才能最终取得成功。 　　课程学习日志（The Lessons Learned Log）：是任何学习内容的汇集，覆盖管理体验或者专业产品和工具的使用等等。这样可以进一步用到其他项目上。在项目进展中捕获这些知识，在项目结束的时候就可以按照一定的报告格式，形成课程学习文件。这是学习型组织（Learning Organization）的基本特征。 　　计划与进度 　　基于产品的计划是PRINCE2的一大特色。它提供了从产品角度看项目交付和项目质量的观点。这样就把计划流程与其他通用技术整合到了一起，如网络计划技术和Gantt甘特图等。它提供了基于产品的框架，从而可以用于任何项目，在任何水平下给出项目作业的逻辑序列。“产品”是一个实实在在的概念，如机器、文档或者软件，也可以是无形资产，如文化变革或者不同的组织结构。 　　Prince 2给出了计划技术的3个步骤：1）规划产品分解结构（Product Breakdown Structure ，PBS）；2）书写产品定义；3）给出产品流程图（Product Flow Diagram），每个步骤都有大量细节，并且以图形方式提供样例。 　　由于需要在产品和产品流图所表示的活动之间建立联系，初始的PBS非常详尽。每个产品都必须包括在捕获每个活动中。如果活动对最终产出没有贡献，就不应当包含在产品中。因此，正确的产品流图，并非只是为了确认应包含的活动，也是为了导出网络图或Gantt图。PRINCE2提供了很好的技术说明，并定义了文档。 　　在PMBOK中，计划通常是关键的通用管理技能的一部分，是贯穿项目管理过程始终的。在项目整合管理中所讨论的计划，是为了建立一贯的、紧密的文档以便用于指导项目执行和基准线，这样使得风险得到控制。然而，计划同样在每个知识领域中出现，指南的各个内容都试图涉及计划部分。 　　控制 　　在PRINCE2中，项目作业的控制是通过作业包（work package）的授权进行的。根据手册，控制意味着全方位的决策，也是项目管理的中心内容。它是目的是：生产所需要的产品，满足一定的质量标准；根据进度、资源和成本计划执行作业；按照业务需要维护可用性。 　　由于业务实例是动态的过程，需要随时更新，所以我们需要在全程关注可用性的问题。这样，将会在整体趋势上使业务需求与当前进展相适应，并且按照业务需要控制当前进展。 　　作业包控制用来将作业分配给个体或团队，包括质量、时间和成本的控制，以及认可报告和需求说明。个体或团队通过检查点报告形式向项目经理汇报，或者其他含义清晰的方式，如触发机制，以更新质量日志。 　　PMBOK中，诸如计划、变革控制是在项目整合管理中讨论的，与计划相仿，可以在指南的其他章节中找到此类内容。 　　从而可以看出，PRINCE2和PMBOK在表达方式上有很大的差异。PMBOK对它所涉及到的每个知识领域的内容都进行了描述，是很好的学习材料，但当真正运作一个具体的项目的时候，未必能给出实际的指导。反之，在以项目生命周期为基础的PRINCE 2中，则很难体现对每个知识领域的全貌。 　　此外，PMBOK将项目解释为“项目是实现组织战略计划的手段”，以及“项目可以在组织的任何层次得到执行”。PMBOK在如此宽泛的层面上表述项目，实际上说明它是从项目所有者，而不是从项目供应商的角度来看待项目的。因此，PMBOK的基础比PRINCE2宽泛得多。

郑俊雅策划

有意义的帖子总会受到大家的拥护，俺正在思考这篇帖子的意义呢？

豆苗查查

沙发

豆苗查查