PM-2031

Building Infomation Modeling 建筑信息化模型

2007-03-29T13:14:00.000+08:00

Building Infomation Modeling 建筑信息化模型的概念事实上已经有很长的历史了。但是它的重要性也是最近才逐渐被国内业界知晓，之前我也对BIM做过粗浅的评论：时髦话题 Building Infomation Modeling，其中包含了太多轻率和肤浅。随着学习和认识的深入，BIM的概念逐渐清晰了起来。在NBIMS 1.0中有这样一段描述：

A Building Information Model (BIM) is a digital representation of physical and functional characteristics of a facility. As such it serves as a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle from inception onward.

如上所述，BIM有几个特点：

是一个集成了建筑对象物理和功能的数字模型；
整合了建筑业所有干系人在项目生命周期全过程中对建筑对象信息的修订、扩展和更新，使BIM成为实时的建筑对象的数字虚拟模型；
是基于知识资源共享机制的，可以所有项目干系人提供可靠的决策依据的模型工具；
他是一个开放的标准，有利于激发创新。

BIM有什么用呢？

知道全球气象模拟、预测平台吗？现在人类有能力整合全球地理信息和气象信息，并在超大规模计算机上对气象数据进行分析运算来预测天气。同样的有地质信息系统、水利信息系统等等。但是反观建筑业，有很多结构分析软件、能耗分析软件等等，但是他们各自是独立的，他们还不能整合在一起；虽然当今的计算能力可以将它们整合在一起。BIM的目标之一就是成为一个单一的，多功能的建筑物实体综合信息模型，并且可以和天气系统、地质系统、水利系统连接用于建筑物实体的全面分析和建造；
现在的建筑业是由投资人驱动的，但是在西方很长时间都是由建筑是驱动的，建筑师对根据自己的意愿和需求引导产业下游提供设计、生产、制造、服务。现在由于信息不对等现象的减少，投资人的意愿和需求成为引导市场的主要因素，这样的话产业下游所提供的设计、生产、制造和服务可以借助BIM平台快速实现这一目的，即向干系人全方位展示自己的产品。并且通过BIM了解干系人的需求趋势，为扩展市场份额作贡献。
最有效率的信息传递载体。以往作为传统工业的建筑业，有很多落后的机制，包括成本核算体制、变更处理机制等等。这些机制都有着相当悠久的历史却在今天成为了阻碍建筑业成长的因素。有了BIM这种建筑实体的信息化数字全息模型，所谓的3D--4D--5D正在显示威力。我们不仅可以作设计方案研究，还可以不断地/前瞻性地计算建造成本、记录建造过程、并实现对项目的多目标优化和控制。
太多优点了，先罗列这些吧

BIM的威力

对于BIM的重要性，我一直认识不足甚至是片面：整合的力量，不过我还是给出了自己的预测：从信息管理看建筑业的产业效率。

根据美国劳工部的报告，美国建筑产业效率竟然在下降。一个人的见解，还是没有整合产业链的核心要素，以至于这种松散的产业机制制约了建筑业的进步。现在BIM作为一个可以为产业链所有要素提供整合和更新动力的工具，为产业链上的所有业者提供了整合的平台。如果BIM真的如开发者描述的那样，BIM必然会影响产业格局。那么，BIM，整个超级整合工具也许会带来产业革命。

从西方判例看工程项目管理经理的职责

2006-12-25T23:13:00.000+08:00

project manager --新生事物

随着建设项目日益复杂，提供建设项目的人员的分工日益专业化，在大多数项目中，由于大家都需求有另外的专业人士去协调咨询工程师和承包商的工作，项目经理应运而生。但是，项目经理的准确的角色和责任仍在不断发展完善。但到目前为止，尚没有被行业认可的PMr（项目经理一词在国内建筑行业另有含义，因此本文以“PMr”作为Project Manager的缩写替代）的定义，也没有正式的工程PMr协会或组织团体。

不同类别的其他专业团体出版的指南为项目经理承担相关的项目任务提供了帮助，RISC和CIOB都出版了相应的工程项目管理指南，但是PMr的职责范围和管理任务并没有被完整清晰地定义出来。相反，关于PMr在工程项目各个阶段的具体任务都给出了长长的列表，而在列表中有很多任务与建筑师、合同管理师和工程师的任务有一定程度的重叠。

职业谨慎和职业技能

虽然对项目经理这个特殊的职业没有达成像其它建筑行业所要求的职业谨慎和职业技能共识的标准，PMr的主要义务应该在明示或默示在合同条款规定中。同时，其他咨询工程师的雇用合同条款对定义项目经理的任务范围也有相当大的影响。事实上，管理工程的任务并没有因为PMr的出现而增加多少，因此PMr更多地分担了建筑师、工程师在工程管理方面的任务，从而将建筑师、工程师从琐碎的管理工作解放出来，确保其更好地完成专业工作和技术管理工作。在法庭上，当确定项目经理有关的职业技能和职业谨慎义务时要看项目经理所属的专业协会,并且职业技能和职业谨慎的标准将是期望他作为一个有能力的称职的专业工程师来履行项目管理等工作应达到的合理的职业谨慎和职业技能。正是由于项目管理是新兴的专业领域，其专业工作的定义尚未得到准确的界定，在判别PMr所要求的谨慎的标准时，更多的取决于雇用合同具体条款规定和具体项目的要求。

针对PMr的诉讼主张

项目经理的角色被广泛地认为是监督与协调，多数对项目经理失职行为的诉讼主张有：项目经理没有控制好某方面的成本；没有确保其他建筑行业专业人士得到正确的信息；没有预防/防止建筑行业专业人士造成重大失误等等。

1 合同管理

作为工程项目的管理者，不可避免的要涉及工程合同的管理。无论PMr的雇佣合同是否对此明确租出界定，PMr的管理工作多不可能脱离开工程合同的管理。这与工程项目的行业特征有关。在Royal Brompton Hospital NHS Trust 诉 ZHammond (2003) 88 Con. L.R.1.案例中，法官Lloyd.得出了一些关于项目经理角色的基本看法：

(a) 项目经理是业主的总代表，这点应该被其他咨询人员以及业主清除认识这一点。
(b) 毋庸置言，项目经理角色的核心任务是 “协调和保护业主的利益是毫无疑义的。”
(c)
当建筑行业专业人士履行合同管理或者项目管理的角色时，必须同时具备建筑法律基本的原理、准则方面的知识，并且具备将知识应用到建筑合同工程管理和建筑项目管理中。在许多案例中，所需要的不一定是基本的法律知识，而是很好的理解运用建筑合同的标准文本。

这些看法足以说明PMr具有潜在的合同管理责任，判例Great Eastern Hotel Co. Ltd v John Laing Co. Ltd [2005] 99 Con LR 45，是第一个报道的施工管理合同（construction management contract）违约案，业主成功地控告CMr.疏于对分包合同的协调管理。

在Royal Brompton Hospital NHS Trust 诉 Hammond (No.7) 76 Con. L.R. 148的案例中，由总承包商提出高额索赔，理由是PMr.监督建筑师未按时审核延期申请时存在职业疏忽。索赔建筑师的签证疏忽的同时附带索赔项目经理和其他项目管理团队成员。法官判定对PMr提提的索赔是由于对PMr的职责范围存在误解，PMr的职责是确定合同管理的确定被有效地实施，而不是判别他们是否完全正确。项目经理处理建筑师未按时审核延期申请时的角色，是判定建筑师是否在合理的时间内处理完这类申请。法官判定PMr需要判定是否在合理的时间内完成其任务，事实上就是要求PMr必须具备相应的合同管理技能和知识。

下面的两个判例也同样与合同管理有关：

判例Costain Ltd v Bechtel [2005] TCLR 6 在合同管理的公正性方面引起了广泛的争议。合同管理师在与PMr会晤后更多地驳回了承包商的索赔。承包商索赔主张由于PMr不正确的干预导致业主违约，但是PMr 辩称在NEC合同下，PMr没有公平行为的义务。事实上，承包商并未收到禁令禁止其获得由于任何事件而导致的合理损失的赔偿。
判例Scheldebouw v St James Homes [2006] BLR 113中, 法官判定业主不能利用CMr替代他们自己去管理商务合同，这不符合一个决策者的客观公正责任。

2 监督其他工程服务者的绩效

在Chesham Properties Ltd 诉 Bucknall Austin Project Management Services Ltd (1996) B.L.R. 92的案例中，原告就批准了额外的工程延期以及承担承包商的费用和损失，同时指控建筑师和PMr。法官认为称职的项目经理应该在发现建筑师、工程师或者工料测量师等专业人士没有履行各自的职责时，有义务将上述情况通知业主。法官Hicks 裁决书中指出：“在实际的建造合同中对于具体的组织建立具体的关系方面项目经理有明确的职责，即项目经理有义务在被告履行各自职责时，向原告汇报他们的绩效缺陷。” 即作为工程项目组织的管理者，PMr将有义务监控这些组织的绩效，并将他们的绩效缺陷告知业主。

3 沟通协调

在Royal Brompton Hospital NHS Trust 诉Hammond (2003) 88 Con. L.R. 1.案例中，法官清楚地指出PMr的沟通与协调职责：...实际上项目经理(虽然是一个素质高的项目经理) 也要一直接受他们的建议。尽管建议的本质基础可能被认为是显而易见的，也要完全的给出，否则项目经理的知识和专家的意见将会影响建议的清楚表达。即要求PMr必须及时有效地沟通，并且保证各种意见和建议清楚、正确的表达，并被及时的传递。

4 工程经验

适当的工程管理经验也是必不可少的，在大型工程项目中，PMr的职责更多地履行沟通、协调和更高级别的控制与管理职能，专业技术管理和决策都会有相应的专业技术工程师或者专业技术服务机构承担，他们有义务向PMr报告各自职责范围内的工作绩效和项目情况。相反，小型项目的项目经理要监督合同本身的运行，直接接触承包商，完成项目的全部任务，更像工程总干事。但是无论如何，雇主在聘用PMr时，不会无视PMr的工程经验，下面两个判例说明了这一点：

在Pozzolanic Lytag Ltd诉 Bryan Hobson Associates [1999] B.L.R. 267的案例中:被告工程师被指定为燃料粉末存储库房工程的设计师和工程项目经理。一部分由承包商设计的工程倒塌。法官Dyson认为该工程师作为项目经理，有义务确定项目投保工程保险并且因此对原告负有责任。他认为事实上项目经理缺乏必要的职业经验去评估承包商提供的工程保险协议的完善性，所以不能减轻项目经理应该承担的责任。他们不能简单地履行类似“邮箱”的职责。
在Palermo Nominees Pty Ltd and Micro Bros Pty Ltd诉 Broad Construction Service Pty Ltd [1999] 15 B&CL 20的案例中：项目经理由于没有完全履行合同约定的义务和约定而败诉，原因是没有要求一个外部的顾问（external consultant）提交关于夜总会内部噪音对于项目设计和建造的影响。

总结

综上所述，从西方的判例看，PMr的职责除了“项目管理”理论所赋予的沟通、协调等职责外，在工程项目领域还需要PMr具有一定的工程合同管理知识、技能和实际的工程管理经验。从实际的案例看，更多的业主倾向于将PMr看作是整个工程项目组织的管理协调者，因此监控整个组织的绩效并汇报他们的绩效缺陷是PMr的责任。

WBS小工具

2006-12-15T09:28:00.000+08:00

之前用过的WBS小工具：WBS chart pro

这个小工具最吸引人的地方在于它可以与MS project 很多版本无缝集成。这是官方网站的贴图：

第一张图不用解释了，第二章则是由WBS chart pro 生成的。看起来工作的很好。

事实上如何一个project management软件都应该含有WBS组件，只不过MS project刚好缺乏一个像WBS chart pro 这样的图形开发WBS模版的工具。MS project的WBS功能模块应该是在大纲级别里面，在那里可以建立基于列表的WBS。

无论如何，这个WBS小工具对于初学者和一些需要图形展示的应用情况还是相当有用的。

WBS最佳实践--适用于工程项目管理的架构

2006-11-26T16:56:00.000+08:00

适用于工程项目管理的架构主要由三部分组成：

工程实体

所指的“产品”就是最终的工程实体。对于项目管理者来说，工程实体属于外部因为工程实体不是项目管理的直接产出。但是对于工程实体的定义却是项目管理工作的基础。站在项目管理的角度上看，只有系统完善地了解工程实体的架构和实际内容才能明确管理什么、如何管理。

工程服务成果

所指的“工作成果”（项目管理工作成果除外）。主要是指设计成果、工程咨询成果等等完成工程必须的工作成果。事实上项目管理人员在很大程度上是在管理、协调和控制这些成果及其产出的过程。

项目管理

即项目管理服务及其成果。就是项目管理公司和业主所确立的项目管理服务的范围、内容和形式。项目管理实际上是一种特殊类型的横向关联元素，因为它具有支撑、整合并管理项目的职能，所以单独列为一种特殊的元素。这部分是项目管理人员重点编制的部分，其内容的深度、广度与项目管理服务的范围和服务细致程度直接相关。

下图展示了项目管理、工程服务和工程实体的关系。以及工程项目管理需要管理的界面。

项目管理最直接的管理内容就是上图左侧的接口部分，他代表工程项目管理单位对其他工程服务单位的管理，这种管理大多数属于合同管理。而其他的管理接口则属于隐性管理范畴，其中最不明晰的管理就是工程实体在工程项目的各个阶段验收时的接口，虽然很多规范规定了设计图纸深度标准、施工验收标准甚至设备调试运行标准，但是却没有工程实体在各个阶段应如何完成并交付的标准。因此管理这类接口是深层次项目管理的关键。其他的接口则是项目管理人员通过协调和组织由其他一些专业化组织和机构实现的，如：用于检验设计质量的施工图审查，用于检验工程施工质量的工程监理等等专业化服务。这些服务可用于检验设计服务、施工服务的工作成果和具体产品。

根据工程项目管理的服务特性，其需要管理的界面有：

对可行性研究、工程设计勘查、监理等工程服务的管理

如工程咨询、设计、监理服务的合同管理、进度管理、成本管理等等，其管理对象是提供工程服务的企业或组织。

对工程服务成果的管理

这些工作成果有两个界面：
工作成果与工程实体之间的界面，例如可研报告所确立的工程功能定义；工程设计对工程实体的全方位规划与设计等等；
工作成果与工作成果之间的界面，例如立现批复与方案设计的界面、一次设计与二次设计的界面等等。

对工程服务成果所定义的工程实体的管理

工程实体是工程项目管理最重要的可交付成果，从项目全寿命周期的角度看，工程实体的定义和规划是项目启动阶段进行的，而实际建造工程实体是在施工阶段。因此在项目全寿命周期对工程实体进行全方位管理是有别于工程监理等其他管理服务最重要的特点。

对项目不同阶段的管理

阶段性管理是工程管理的一项重要工作，工程项目管理也必须组好这项工作，其中审批管理是容易被忽视的管理内容。

能够充分实现上述界面管理和内容管理的结构应是将项目管理、工程实体和工程服务分别管理和解构的框架形式。同时这种结构还能适应工程项目生命周期的控制需要，即随着工程项目的进展，工程实体的内容、范围和形象将越来越清晰，工程实体框架也随之丰满；进而产生更过的内容管理、界面管理需求，其他分支也将必然扩充以满足管理和控制要求。

原文来自我的WPblog：WBS最佳实践--适用于工程项目管理的架构

WBS最佳实践-核心准则

2006-11-21T11:48:00.000+08:00

编制WBS必须明确其核心准则，以便把握编制整个架构的要领。这些核心准则是：

——100%准则
——项目组织的OBS/RAM
——目标分解

100%准则

100%准则即WBS必须定义项目范围内的所有工作，包含项目管理工作外部、内部和接口部分的项目工作，以确立项目工作模型。100%准则是衡量WBS编制合格与否的重要指标。
100%准则的具体规则包括：

WBS必须涵盖工程项目工作的所有范围；
所有的可交付成果和输出都必须在WBS中进行定义；
任何元素的工作都等于其下一级元素的工作总和；

项目参与各方的工程管理格局

项目工作是由参与项目的各个组织及其资源完成的，因此规划和定义参与项目的各个组织职责和任务则是编制高质量WBS的重要因素。尤其作为项目管理组织编制的WBS，规划和定义项目的各个组织职责和任务就显得尤为重要。更重要的是由于工程项目的特殊性，其整体的、全方位的管理并不是由某一个组织独立实现的，而是在项目管理的框架内，互相配合协调，各自实施与其提供服务相适应的工程管理职能。典型的工程管理包括总包的工程管理、专业分包的工程管理等。

目标分解

在编制WBS时可能会遇到大量的可交付成果和过程产出，因此很容易陷入如何组织这些成果的尴尬。并且可能忽略重要的可交付成果。因此有必要强调“目标分解”准则。
目标分解当中的目标有两层含义：项目目标；管理目标。项目目标主要区分类似永久建筑/临时建筑、独立工程/分部分项工程等等目标，以便确立WBS元素的实体特征。管理目标主要区分类似受控对象/非受控对象、独立过程/协作过程等等管理目标，以便确立WBS元素的管理地位与层次。
对于工程项目管理WBS来说，管理目标分解有助于提高项目管理人员分析和发现项目OBS/RAM的不足与缺陷。而项目目标的管理是项目成功的关键。

原文来自我的WPblog：WBS最佳实践-核心准则

welcome Back!

2006-08-15T13:34:00.000+08:00

最近，blogger又可以在大陆境内访问到了。真是无法用语言表达其中滋味。不知道这次是否是永久的，而不是暂时的。本来应该好好写些东西，无奈压力太大，暂时作罢，以后补上吧。

续：由于BETA的出现，或许是个解决问题的好办法。如果可行将用ftp发布把blog迁移出blogspot这个禁地。

搬家通知

2006-07-26T17:26:00.000+08:00

众所周知，中国大陆的政策原因，blogspot域名被屏蔽了。虽然我已经坚持了很长时间，但还是因为不方便而转投WP了。并且自己找了一个空间，在那个小地方自己说了算。。。。。。

新blog的地址是：http://www.airstorm.org/blog/.

项目管理搜索趋势

2006-05-15T12:13:00.000+08:00

google推出了 Goolge Trends 看看用它分析一下项目管理被搜索的趋势：

作为词汇搜索，PM被搜索的频率杂逐步低。也许是因为PM的概念不再新鲜了吧。相反，作为新闻PM被搜索的频率有逐步增多的迹象。正如，K. Hammer 所说的，项目管理在经历了几十年的发展已经成为一种普遍、通用的管理技术与理念。

再看看国家，把PM概念炒作的N火的中国排在语言搜索榜的第四位。估计其中news ssearch的贡献率要远大于volum search的贡献度。

项目管理关注度

2006-05-15T10:36:00.000+08:00

比较PRINCE2与PMBOK

2006-04-21T19:45:00.000+08:00

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

　　各国在对项目管理方法、知识体系的不断探索中逐渐形成了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 (S，控制一个阶段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 (S" 过程（见第五部分的阐述）来对项目各个阶段有效性的控制。项目经理在项目即将结束和结束时必须提交 "下阶段计划书"、"业务状况更新报告""风险更新报告"、"阶段结束报告"等，若项目由于某些原因不能继续执行，必须提交"项目终止建议"报项目委员会批准。项目委员会必须始终确保项目各个阶段的可控，在一个阶段没结束前，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希望我国政府能够在项目外包时有自己的标准可循，企业在实施项目过程中能更加有效地管理项目，促进项目的成功。

WBS最佳实践--构成

2006-04-19T19:45:00.000+08:00

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最佳实践-概念

2006-04-19T12:33:00.000+08:00

如何编织有效的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关联的接口
具备与成本、进度信息关联的接口
反映活动、工作和成果如何实施的结构框架
为绩效测量提供了基础

WBS 最佳实践

2006-01-18T18:44:00.000+08:00

WBS概念
功能特性：
Deliverables：可交付成果
Design：设计（1）包含scope；（2）清晰定义；（3）与OBS以及（RAM）相对应
Management：管理
Organizational：组织
Levels：层次

总结
WBS

1、定义project scope必要的工作、产品（可交付成果）
2、层次化、结构化
3、全生命周期
4、提供计划与成本衔接的平台
5、提供包含所有干系人的RAM
6、为项目报告和分析提供便利
7、为检查项目绩效提供平台

WBS的编制
高层次的WBS可以被模板化或者在项目前期编制，而低层次的WBS则需随着项目的深入而不断完善。
STEP：
1、识别项目最终产品，通过高层次的WBS的scope document来确认WBS框架（定义高层次的sow （工作说明书）和应执行的程序。
2、定义主要的产品可交付成果。
3、将可交付成果放入适当的管理和整体控制层次，WBS元素与这些独立的可交付成果。
4、审核并调整WBS，直到team认为项目计划的可行性和成功性。

WBS必须注意的事项
1、每个WBS节点必须是单一、独立和可测量的可交付成果。
2、每个WBS节点必须能够包含某子WBS的所有范围。
3、每个子WBS只能与父WBS范围相容。
4、可交付成果应按其产生过程分解，如设计、采购、分包、建造，从高层到低层的WBS必须具有一定的逻辑关系。

工程项目管理服务范围参考

2006-01-05T14:46:00.000+08:00

参考《客户/咨询工程师（单位）协议书指南》，FIDIC阐述了TOR(term of reference)委托服务范围的定义和scope of service的相关论述，并在其附录中提供了一个（基于合同文本的）咨询服务范围。其内容来自Mr. Michael Lewis 的文章:perparing the conslutant's terms of reference. 作为协议书（agreement）的立场和角度，FIDIC认为TOR(term of reference)以及scope of service应该针对服务的时间和成本性质进行分类，以便与费用支付条款对应。

这里引用FIDIC的咨询服务范围scope of service论述和TOR(term of reference)委托服务范围的定义，主要是为大家提供研究咨询工程师工程项目管理服务范围的范例。

典型的正常服务内容：
1 inception stage of project 项目开始阶段
2 project definition stage 项目定义阶段
3 alternative proposals 被选建议书
4 feasibility anlysis 可行性分析
5 detailed design 详细设计
6 tender document 招标文件
7 tending and award 招标和授标
8 construction supervision 施工管理
9 take-over and commissioning移交和联合调试
10 defects liability period 缺陷责任期

典型附加服务内容（主要指环境、卫生、安全方面的管理）：略

-----------------------------------------------------------------------------------------------------

阶段

fidic的对于服务阶段划分, 采用了典型的自然时间顺序分类法.
即:投资前\详细规划\设计\采购\实施\运行. 值得注意的是上述阶段数量恰好是大多数项目管理实践和理论所推荐的6个.
这些理论认为阶段划分与可交付成果和项目执行的程序有关, 过多的划分项目阶段有可能拆分可交付成果和项目程序及其对应的任务,
使具有多重目标的可交付成果和项目程序被人为地割裂而不便于管理. 因此个人认为上述典型正常服务阶段应将2,3,4 合并, 使其更加具有管理特性.
当然从提供菜单式服务和给予费用支付的角度考虑划分项目阶段也是非常实际的方法.

职责

FIDIC将职责分为3类：任务、建议和培训。培训被fidic作为单独的职责单独阐述，而且在传统上咨询工程师有为客户提供运营/维护培训的义务，这被视为一种惯例。对于任务和建议，《白皮书指南》指出职责习惯被分为任务和建议，任务含有管理提供的服务绩效性质，建议则必须履行相应的任务建议义务。
这一点提醒了我们：项目管理职责除了基本的管理职责之外，项目管理经理/组织还应该具有一定的技术管理职责。根据duties of pm的论述，目前在英国已知的工程项目管理案例中关于项目经理的争议主要是项目经理是否应作为专业咨询工程师或履行专业顾问而提供相关服务。大多数判例明显支持项目经理应具有相应的专业素质，以满足工程整体管理的需要。

根据《白皮书指南》的论述：

...仅负责运用其技能、谨慎而勤奋地履行其服务。这就是检验标准

这将是司法层面界定项目管理职责的绝对准绳。

primavera 5.0 预览有感

2006-01-05T14:24:00.000+08:00

前天拿到上海普华邮寄过来的 primavera 5.0 的升级包，用于对已购买的 P3 e/c 4.0 升级。该软件被重新命名为 primavera 5.0，而不是P3 5.0。虽然这个升级我在04年的11月就已经获得确切的消息，并作了一些了解。但是真正开始研究他的时候，还是令我吃惊不小！

首先是全新的组织形式，schedule 引擎被后台化；项目分析、管理和协作被空前地放大；并且出现了myPrimavera （项目管理信息中心）具体细节稍后描述。这意味着 primavera 向项目管理高端跨了一大步，基本摆脱了一个schedule软件的面貌。

其次WBS和EPS被完全整合到软件的方方面面！多元化的管理和分析可以借助于WBS和EPS等实现了。

最后，居然看见了bentely的影子！primavera 5.0 为navagator 提供了一个WBS recode 模版，用于与3D建模的 visual object 建立对应关联。

====================================================
myPrimavera （项目管理信息中心）
====================================================
这个“项目管理信息中心”是我的个人理解，按照官方的解释为：browser-based project management for massses。从其功能设置上看，基本上是为owner、client、or anyone work for owner/client 提供WEB方式的项目信息的平台。它是对外的！portfolio analysis 不包含在内！其中的信息包括：项目状态（可以使基于EV的，基于cost、schedle的，以及WBS的），风险状态，针对浏览着角色而变化的项目日历、项目当前需处理的工作以及其中的关键工作、协作通告、事件触发器提醒（如工程师应在48小时内给予答复）等等。

感觉一：IT方面

微软于2003年中推出了基于项目团队协同和企业内部协同的产品 sharepoint 2003，同时它将 project sercer 2003 也纳入其中。使项目管理软件的远程协同、多元管理变得可行。与其竞争的有IBM 的 wabu，但其市场定位是企业内部，而不是横向的项目管理应用。直到 myPrimavera 出现，微软的 project server 2003 将彻底失去其原来的优势。因为 project server 2003 的任何数据共享都需要网络的 administrator 手动定义。而 myPrimavera 则是根据完善的EPS/WBS和相应的角色机制自动定义共享数据，并且数据设置形式也经过模版的预定义，这比起微软来简直无法形容。myPrimavera 不需要IT人员的过多参与，更不需要IT人员夜以继日的维护。

Primavera 还将项目管理业务应用在管理关系层面进行了划分，并且细致地定义了内部管理与外部管理的模版和工具。在充分利用WEB和局域网络的各自优势的前提下（WEB应用主要是状态展示、信息协同，目标是业主和客户；局域网络应用主要是内部企业管理决策和项目管理绝大部分职能实施，目标是项目管理团队和公司管理层），使项目协同的水平和效率以及项目内外部的平衡达到了新的高度。

感觉二：核心管理技术方面

看似简洁的界面背后，都是相当核心的管理技术在支撑着。EV技术我们还基本停留在学的阶段，风险评价和相关技术就更加落后了，WBS与EPS同样不能正确应用，事件触发器实际上需要参数设定的有很多参数则来源于管理实践而不是理论数据。。。。。。。如此巨大的差距实在有些可怕！

但是话说回来 myPrimavera 的应用也使管理者可以从真正的统计、管理的角度而不是编辑、计划的角度分析项目。因为在传统的编辑状态下虽然有分析工具使用，但是难免有身在其中不知何处的问题。

同时通过 myPrimavera 为每个角色和个人提供各自的数据入口和编辑范围将个人应用与主数据库剥离，在实现共享的同时也增加了系统的安全性。这一变化是P3 e/c 4.0 不能比的，那时候的角色和WBS绝对没有现在的深入完善，那时过滤出某个角色的相应数据仍然是很麻烦的。而且工具也没有与WBS连接，当时理论上可以对任意一级的任务实施portfolio分析，这简直就是笑话。

另外我注意到：完成百分比模式由原来的0/100，20/80，50/50 减少到0/100，50/50。20/80不见了，询问普化工程师后得知20/80这种典型的预付款方式并不适用于WBS形式的管理方法。这是因为当代的WBS某一级别下可能含有纯服务型子项，还有劳动/建造型子项等等，
这些不同类别、不同阶段完成的子项与20/80理论的基础相违背。由此可见 Primavera 的进步是值得学习和研究的。

------------------------------------暂时写这些，随时补充-----------------------------

图书列表

2005-12-19T17:20:00.000+08:00

Colin Qary，University of Reading : building design managment 建筑设计管理

FIDIC: client/construction agreement guide 客户/咨询工程师协议书指南

CIOB: code of practice for project management for construction development 项目管理实用规程

PMI: construction extension to PMBOK 项目管理知识体系指南之工程业扩展

ICE: NEC专业服务合同与使用指南第二版

PMI: PMBOK 项目管理知识体系指南

Harold Kerzner: 项目管理：计划、进度和控制的系统方法第7版

有条件担保与无条件担保

2005-10-31T00:53:00.000+08:00

有条件保函简述
有条件保函要求担保公司的赔付必须基于承包商的违约责任。它体现了保证担保的本来含义。它的特点是：

保额高，采用有条件保证担保的美国，其保额为100%投标保函和100%履约保函
承包商违约后，保证人在保函规定的总担保额的范围内对承包商尚未履行的合同责任负责，但同时也继承了承包商的合同权利。
保证人有权选择履行合同义务的方式，包括：对原承包商提供支持使其继续履约；引入新的承包商；将尚未完工的工程另外发包并向业主支付因此增加的合同金额；向业主直接支付一笔业主能接受的赔偿金以买回保函。

由于有条件保函的赔付必须有承包商的书面同意，或者是法院、仲裁机构的裁决认定承包商违约，并规定赔偿额度。同时有条件保函的赔付以承包商的合同责任为限，如果业主不履约，担保公司就可以免除担保责任，这迫使业主也要严格履行合同责任。所以有条件保函被认为是更加公平的保证担保形式。

同时，与无条件担保那种“兑票”式的风险处理方式不同，高保额的有条件保险需要承保公司严格地评估其承保风险，并且更多地针对承包商而不是项目进行风险评价以避免担保公司由于承包商的原因承担风险，因此有条件担保具有“资格预审”的作用。

其缺点主要是索赔效率低下，这与工程合同裁决诉讼程序繁琐，时间漫长不无关系。近年来工程法律界一直在努力降低其繁琐程度、提高时效，例如英国推行的新的工程合同争议裁决方法与程序。而美国则采用另一解决方式，即高保额，高信用风险。担保公司处理索赔的效率将是其信用的关键指标之一，低效赔付将导致其信用的大大降低，业主将对其进行排斥（不接受其开具的保函）；同时一旦承包商违约，索赔成立。由担保公司继续履约，但是其合同责任不以原合同价100%为限，出于以最小代价完成工程的目的，迫使担保公司积极主动地介入工程，避免损失进一步扩大。

无条件保函简述

无条件保函就是“见索即付（on-demand）”保函，当发生保函索赔时，业主无需证明承包商违约，只需保函规定的程序和要求出示相应文件，保证人就应付款，就如同承兑票据一样。保证人的赔付以担保函写明的担保总额，并不承担实际合同责任。

保证人在提供这类保函的同时往往采取严格的反担保措施，如收取100%的保证金、等额抵押物及资产，或者将其赔付视同承包商的信贷等方式。将风险转移给承包商自己。

这种模式有如下特点：

由于不承担实际合同责任，所以保证人无需分析承包商的合同风险，只要考察其反担保的可行性即可；
低保额不一定保证业主完全免予由于承包商违约造成的经济损失，其意义在于由于业主掌握了随时可以发挥作用的保函，迫使承包商增强其履约意识。
在实践中业主进行保函索赔的成功率还是很高的，而承包商抗诉/抗辩胜率偏少。因此承包商通常会受到来自业主的额外要求，这显然是不合理的，不公平的。

保证担保与保险的区别

2005-10-31T00:06:00.000+08:00

1.风险种类与赔付条件不同。
工程保险所赔偿的只能是由于自然灾害或意外事故引起的；而工程保证担保的是人为因素，换句话说，其保证的对象是因资金、技术、非自然灾害、非意外事故等原因导致的违约行为，是道德风险。保险人履行保险责任是以收取保险费为前提；而保证人履行保证责任则无需对价条件。

2.风险方式不同。
保险合同是在投保人和保险人之间签订的，风险转移给了保险人。提供保证担保的保证担保人一般会采取以代理加反担保的方式将风险最终转移给委托人自己。

3.风险责任不同。
依据担保法律，委托人对保证人为其向权利人支付的任何赔偿，有返还给保证人的义务；而依据保险法律，保险人赔付后是不能投保人追偿的。另外，在保证担保中，保证人承诺的责任通常属"第二性"赔付责任。

4.风险选择不同。
同样作为投保人，保险没有选择性，只要投保人愿意，都可以被保险。保证担保则不同，它必须通过资信审查评估等手段选择有资格的委托人。因此，在发达国家，能够轻松地拿到保函，是有信誉、有实力的象征。也正因为这样，通过保证担保可以建立严格的建设市场准入制度。

5.风险预期不同。
保险业对于风险损失是有预期的，而保证担保在理论上却不希望发生风险损失，这可能是不现实的，但却是保证担保的原理。由于保证担保人在出具保函前要对委托人的各种有关情况进行调查，进行充分的可行性研究，所以，一旦决定保证担保，基本上能确信不大可能发生委托人不履约行为。换句话讲，保险建立在实际可计算的预期损失基础上，而保证担保则建立在委托人的信用等级和履约能力基础上。保险造就的是互助机制，保证担保造就的是信用机制。形成信用机制是建立工程保证担保制度的主要目的所在。

6.合同的性质不同。
保证保险合同一经成立便产生独立的权利义务关系，属于双务有偿合同。保证担保合同则表现为单务无偿合同。保证担保合同作为主合同的附属合同，与主合同之间存在着主从关系。保证担保合同以主合同的存在为前提，其本身不能独立存在。

7.保证的范围不同。
保证保险合同中，被保险人履行保证保险责任仅限于保险合同约定的保险金额限度内的贷款本金和利息，对于违约金、逾期利息、罚息等均不属于赔偿范围。保证担保的范围包括主债权及利息、违约金、损失赔偿金以及实现债权的费用。当事人对保证担保的范围未做约定或约定不明确时，保证人应当对全部债务承担责任。

“chapter 5 范围管理”的例子---前述部分

2005-10-17T23:05:00.000+08:00

格式：黑色字体为例子的正文部分，而蓝色字体为例子的说明部分。

chapter 5 范围管理

PMI对于项目管理的定义为：“。。。”（范围管理定义，此处省略）。范围管理主要关心的是识别与控制为完成项目目标必须还是不须进行的工作。

工程行业通常有在合同中定义或描述项目范围的惯例，例如《客户/咨询工程师（单位）服务协议书》就对“项目、工程和服务”的范围作出了定义，他们分别界定了“项目范围”、“工程范围”和咨询工程师（单位）的“服务范围”，并允许合同双方根据情况对在合同专用条件部分对其进行更加详细的描述和定义。客户/咨询工程师（单位）服务协议书的服务范围参见附件5-1 工程项目咨询工程师服务范围。（有需要看的我给大家发fax）该协议书中的服务范围与PMI的产品范围的概念范畴大致相同。在合同中明确范围定义的这一做法也在其它范围变化可能导致较大风险的合同模式（用词不准确，待推敲）使用。

正如PMI所述，项目管理具有“逐步完善”（progressive elabration）的特点，范围管理也一样。虽然单一的工程合同定义了项目范围，但是站在项目生命周期的角度看，工程项目的范围是通过各个阶段的专业服务不断明确和完善的。对于整个工程，只有到了施工阶段工程项目的范围才能准确定义下来。因此从项目周期的角度看，工程项目管理可以分成2个阶段：决策阶段到施工准备阶段的范围管理（即在工程没有完全确定阶段的范围管理）；施工阶段的范围管理（范围已经明确界定的范围管理）。在第一个阶段各个参建方实际上是在为最终明确工程项目范围而努力；而在第二个阶段各个参建方实际上是按照定义的范围工作并确保范围不蔓延。

如图fig 5-1（code中文.2. P46页图6.1）所示，（此处按照各个业务方向写各自的范围管理）设计管理服务的范围管理在各个阶段的工作性质为：（绿色为组织/监督设计单位的咨询服务；红色为对设计单位实施设计管理服务；蓝色为组织/监督设计单位的后期服务）

---------------------------以下为“设计管理”业务的范围管理-----------------------------------------
在设计前期的各个阶段，设计单位主要是提供各类咨询服务，其范围管理的任务是分析/明确工程范围和相应的范围控制。一般的设计管理服务并不包含设计前阶段的管理工作；在施工阶段以及之后的各个阶段，设计单位主要是提供设计后期服务，其范围管理的任务是按照设计成果对工程施工、调试等实施范围控制和范围核实。大部分的设计管理服务包含这些阶段对设计服务的组织和监督工作；而设计管理服务在设计阶段的范围管理工作则是根据各类范围管理依据对设计工作实施全面系统的范围管理。不同的合同模式（用词不准确，待推敲）的范围管理可参考fig 5-2 （building design manament. P53页图12）

本章的重点将论述工程项目设计阶段设计管理服务的范围管理内容、方法和程序。在设计阶段，设计管理的任务和目标是：（引用code. 3.相关内容<列表。。。。>）
为达到此目标，必须完成的工作、程序为：（引用code. 3.相关内容，第一版设计管理相应内容以及设计管理<列表。。。。>）
设计管理和设计服务在项目各个阶段的任务和主要成果参见tab 5-1（building design manament. P53页图8）<放在这里是否适合有待商榷