可交付成果在PMBOK中有比较清晰的定义，Airstorm这里就不在背书了。直接谈谈容易出现的误解，对于可交付成果的误解集中在2各方面：一是可交付成果的概念本身；二是可交付成果在WBS中的作用。

误解一：可交付成果就是“工程”

工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有97％的共性）。因此，工程领域向来有范例式的WBS构建方法。而这个范例就是工程领域的“定额编码体系”，在建筑领域就是（工程量清单），这种编码体系本身就容易被误解为项目的完整WBS。关于这一点我们稍后讨论。这里仅仅说说其分解特点，“定额编码体系”（工程量清单）的特点就是以可交付成果为导向的分解体系，其大部分分解节点都是以名词为主的（例如钢筋工程，钢筋、预制构件、钢筋笼），即可交付成果通常被理解为有形的工程实体。

在工程领域人员学习WBS的时候，经常会完成一个工程实体分解的WBS。持有这类观点的不在少数，他们在概念里倾向于将工程的PBS替代WBS，其中不乏技术人员和管理者。如果将工程设计WBS分解为：

设计图纸，结构设计图纸，建筑设计图纸，市政工程设计图纸，电气工程设计图纸……

恐怕很难识别设计工作的一些任务，例如，设计前现场勘查，施工过程的现场监督，二次设计图纸的审核等等工作。如果说WBS是一种“范围管理”工具，那么基于产品的分解方法通常比较容易遗漏“过程服务”的成果，这些成果大部分情况下是“无形”的。我们知道产品需求差异会导致设计工作范围的不同，因此在进行设计管理工作的时候就不能仅仅围绕设计的可交付成果展开，还要兼顾面向任务或者活动的部分。实际上，借鉴软件工程的WBS可以看出，设计领域中在项目开始之前进行较为精确的产品分解是不切实际的，所以通常使用任务分解的方式分解WBS。

再有，工程中的采购也难以使用有形的采购产品分解WBS，更多的是采用面向过程的WBS。过程管理对于项目管理是非常重要的，很多时候基于过程的分解更加贴近OBS，或者在更高的WBS层级与OBS匹配。其实过程分解的下一级就是任务分解，而任务分解的下一级就到了工作成果。正如Airstorm在上面所述，服务和产品的叠加才是“工作（works）”，这显然与传统的工程领域知识相矛盾（工程领域中，works专指“工程”或者“永久工程”，参见FIDIC条件），在《系统》一书中介绍WBS概念的时候，特地强调了CWBS【合同分解结构】一词，其概念核心就是是基于产品分解的WBS要通过CWBS（合同分解结构）的方式建立一种管理项目任务的渠道，使得项目工作范围被完整地管理起来。

总结

WBS中的works是一个“包”的概念，是工作任务与工作成果的集合

对待WBS的时候，不应该仅仅将其看作是PBS（产品分解结构），如果必须如此，则需要界定任务分解结构，比较成熟的有合同分解结构CWBS，或者组织分解结构OBS与PBS相结合。

CSI（Construction Specifications Institute）的官方网站上的消息，CSI正在公开征集对新版UniFormat II草案的意见。新版UniFormat II将于2008年底正式发布，这个版本将替代1998年的版本，并与MasterFormat 2004相协调。这次征集的部分仅仅包含建筑工程部分的修改，CSI的工作组将于一年后将修订的范围扩展到所有行业。而征集意见的截止日期是2008-6-15。

对于我等来说，可以下载的学习资料能够再丰富一下喽： （阅读全文……）

这个题目的确有些虚张声势，不过，身边的一些朋友不久前讨论过早期“完美”计划的必要条件。最后归结为两点：

• 合理性 时间安排合理、成本支出合理、资源使用合理、风险预控合理等等
• 可实施性 各项活动张弛有序，资金链不会断裂、资源不会过于短缺等等

那么如何做到上述高度概括的要点呢？

首先是合理分解WBS，这部分已经讨论很多了，这里不再赘述。 分解的同时将要根据WBS子项识别出关键实施任务（仅含实施部分）这很容易，原因下面大家会知道。

（阅读全文……）

在之前的visio Vs. project的WBS转换工具中，提到了当时visio 2007内建的WBS图形工具，不过感觉还是很不好用。MS公司还推出了一款由bVisual和CPS公司开发的visio插件“WBS Modeler”，开发者给它冠以“visual project planing and reporting tools”的美名。试用了一下，感觉用在建模阶段还算方便。

（阅读全文……）

如果你搜索国外的工程项目WBS，那么一定会找到Uniforamt和Masterformat这两种建筑工程WBS格式。实际上Uniforamt和Masterformat是两种不同的建筑信息组织分类方法产生的编码系统，而功能上它们都可以成为工程项目管理的WBS。

起源

早在1969年英国皇家特许估算师协会(RICS)颁布了第一个房屋建筑的分 类标准，之后许多国家都在制定自己 的分类标准，欧盟制定了CEEC分类。（建设工程项目工作分解结构(WBS)的思考）Uniformat是由美国AIA与美国GSA联合开发的，美国ASTM基于Uniformat制定了ASTM E 1557-05分类标准，名称为 Uniformat II。最早在1989年颁布，最新版本为2005版 。MASTERFORMAT是由美国建筑标准学会CSI 和加拿大建筑标准学会CSC 最早在1972 年颁布，最新版本为2007版。是美加两国八个工业协会和专业学会共同倡导和努力的结果,在北美地区具有深远影响，历史悠久，应用广泛。 （阅读全文……）

先看看这张图片，这是一个四阶魔方。之所以用魔方来做题目，主要是要介绍wbs编码以及wbs应用方面的概念。魔方有复原或者还原之说，就是将魔方恢复成下图的状态。期间会使用很多数学技巧。我们在使用wbs的时候虽然不会使用复杂的数学技巧，但是对于wbs的架构特征的多重性还是与魔方有着相近的地方。

Technorati Profile

（阅读全文……）

不久前陷入了一次关于WBS工作分解结构设计规则的论战，争论到底应该面向可交付成果分解项目工作还是面向活动。

其实，这要看你在什么层面，从什么角度去使用WBS；以及你的项目所具有的一些特征。这些将决定你如何有效地使用WBS工具去管理你的项目。

下面谈谈我对这个问题的看法：

（阅读全文……）

随着对ofiice project 2007的持续关注，我找到了一些新版project关于WBS创建工具的文章：Integrating Visio 2007 and Project 2007 。里面详细介绍了新版office在PM领域有关WBS的创建方案.

在2002版的office里面，MS曾经提供了一个visio Vs. project的转换工具。它可以提供功能相对粗糙的WBS图形编辑模版，但是借助于visio的强大编辑功能，我们可以更自由地编辑整个项目复杂的wbs结构。相对而言，visio的排版/图形处理以及形状编辑比起project原有的（网络视图）图形排版工具要耗用多了。但是最大的问题是，功能上，仍然不能满足最普通的wbs编辑/创建需求。所以在那个时候，这个转换工具更像一个组织机构图的模版。

在2007版里MS升级了这个visio Vs. project的转换工具。最大的变化是wbs工具现在集成了工期等wbs元素信息。而这些信息的集成将有利于在visio中独立编制WBS。

相反地，这个转换工具还可以提供从project导出wbs视图。下图变色的WBS元素表示该部分任务已经完成了。

与上一版本的转换工具相比，这次的进步在于进一步提高了集成度。2002版的工具有时候在转换过程中会出现错误，如导入的数据不完整、遗漏任务信息等。相信新版工具在这方面会有进步。

但问题是wbs的编制需要很多数据支撑的，而不仅仅是一个绘图工具可以替代的。这一点上不敢与MS苟同。试想一下，在编制WBS时大部分是自上而下的编制过程，这时也许会需要成本数据的支撑，甚至是集成；以便直接将WBS元素定义和成本分解结合起来。 另外，在编制WBS时我能引用WBS字典吗？—这些都不是visio这个绘图工具所能解决得了的。

总结

还是一个绘图工具，在其内部集成方面应该解决得很好，但是与WBS pro相比 ，好像也没有高明到哪里去啊？唉~~~什么时候可以看到一个真正完整的WBS工具呢！

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

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

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

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

另外一个我没有在官方网站上找到答案：WBS chart pro 声称支持project server。但是又没有明确是以什么样的方式与project server衔接的。是web part吗？这个功能我没有机会用，但是与server的集成应该是很好的功能。
无论如何，这个WBS小工具对于初学者和一些需要图形展示的应用情况还是相当有用的。

更新

很多人要下载地址，我也只用过预览版的，地址：http://www.download.com/WBS-Chart-Pro/3000-2076_4-8668211.html

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

工程实体

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

工程服务成果

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

项目管理

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

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

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

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

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

• 对工程服务成果的管理

这些工作成果有两个界面：

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

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

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

• 对项目不同阶段的管理

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

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