conceptdraw是一个非常不错的项目管理策划分析与报告工具。其强项是图形报告功能，非常的出色。这里要说明的是，conceptdraw是做不出那种P3E/C才有的专业化数据报告，而是很漂亮的图形风格的报告，如饼图、状态图、仪表图等等。相比较而言，P3E/C的报告专业、翔实，图形功能也非常出色，比较适合做纸质的专业项目报告；conceptdraw更加适合PPT演示或者概念性展示的电子文档格式的项目报告（这是个人的体会）。

需要了解详情的可以直接去官网，我就个人感兴趣的功能做一个介绍：

mindmap to project plan

这个功能很有与时俱进的味道，他是一种mindmap（思维导图）与project plan（进度计划）双向转换的工具。即：你可以使用思维导图工具进行的项目策划与分析，并且将这一分析结果转换为项目计划。

至于这个功能有多大使用价值就看你对这两种工具的掌握与使用程度了，比如在项目实施阶段，思维导图模式的计划图或许会给你一种系统性思维的方法。

导出WBS

导出为WBS是一个“时髦”的功能了，很多PM工具软件都已经默认地提供这一功能。conceptdraw的这一功能好就好在采取了微软的方式：将WBS做成可编辑的“流程图”（参见WBS建模工具）类似于visio的编辑环境、良好的WBS模板和靓丽的效果会让善于展示作品的人心动的。

不过对我来说，WBS导出功能有一个很大的问题：基本上这是一个“任务分解结构”导出模板，而不是工作分解结构的导出模板。

图片报告

非常漂亮图片报告，这个就不需要文字介绍了，直接上图片吧：

（需要说明的是，我没有对图片中的项目信息进行必要的设置，因此报告图片缺乏必要的细节）

这些图片可以做成PDF格式、HTML格式、各类图像格式、SWF动画格式、PPT格式以及XML格式等等……

24日收到邮件，原来PMI准备在年底之前放出一整套项目管理标准(官方称为“New Editions of Four PMI Global Standards” 或者PMI 2008 staandards)，这套标准包括：

• PMBOK® Guide—Fourth Edition
• The Standard for Program Management – Second Edition
• The Standard for Portfolio Management – Second Edition
• Organizational Project Management Maturity Model (OPM3 ® ) – Second Edition

我最关注的自然是PMBOK的第四版了，官方的FAQ列举了一些新旧两版之间的差异：

• 所有进程的名称是在动-名词形式
• 企业环境因素有更明确的界定，以避免与组织过程组资源混淆。
• 采用一个标准的过程改进方法：阐述对“需求变更，采取预防性行动，纠正行动和缺陷修复“的管理。
• 过程减少到44至42 。两个进程被删除；在采购知识领域将原有的4个进程改组为6个。
• 为了提高清晰度，论述了项目管理计划和项目文件的区别。
• 澄清了项目章程和项目范围说明之间的区别。
• 在4-12章节前面的过程流程图已被删除，取而代之的数据流程图。
• 为每个过程创建一个数据流图。
• 增加了一个新的附录补充说明，用来描述项目经理主要的人际沟通技巧。

第四版的改进主要在于提高了概念清晰度和流程的关联度，尤其是数据流程图的引入，加强了过程之间的关联，使读者在理解项目管理过程的时候可以有更清晰的认知。当然最前面的改版说明要看正版文章的附件了，这里提供一个整套文件征求意见稿（Exposure Draft）的下载地址：来源IEPMI知识共享中心

pmbok2008初稿（PMBOK(R) Guide–Fourth Edition Exposure Draft）
The Standard for Program Mgmt–Second Edition Exposure Draft
The Standard for Portfolio Mgmt–Second Edition Exposure Draft
OPM3(R)–Second Edition Exposure Draft

与此同时，ISO组织也计划发布项目管理guid标准：ISO 21500 《Project management — Guide to project management》，该标准计划于2010年发布。期待项目管理方面能够有类似ISO 9000系列标准那样的标准出现，既可以与时俱进，又可以世界通用。

很久没有更新了，主要在读书和思考，以便于更好地整顿头脑。先把最近想到的一点体会放在这里吧。

stakeholder 概念

对于已经知道其意义的可以跳过这一段，不过看看“非主流”也有好处。那么何为“stakeholder”呢？在很多翻译词库以及来自教科书的定义虽然不同，但是大体上是一致的：利益相关者 OR 利害相关者。然而什么是利益相关者呢？我这里采用经济学对于所有权的解释来阐述它的含义：

经济学在阐述“所有权”的时候分析的异常透彻：所有权并非同那些矿产、地产等等物质相关，而是同利益相关。当某人取得某地的矿产开发权的时候，或许会造成对邻近农民收益的伤害、会造成对邻近居民健康的伤害……因此所有权获取成本是所有利益损害的总和。也就是说，当你声称拥有某所有权而采取行为的时候，这些行为本身会对其他人的利益造成损害，这些因为你的行为而受到利益侵害的团体、组织、个人被称为Stakeholder。同时你为了行使所有权就必须付出代价，这个代价是由Stakeholder的利益共同作用产生的。因此，从工程管理的角度理解，Stakeholder意指所有与某个项目、某个事件相关的利益群体或个体的总和。更为关键的是，当你听到Stakeholder的时候就应该立即想到“代价”OR“成本”。

另外，还要探究一下stakeholder一词的来源，据说是来自于16世纪的英国赌博业。那个时候，stakeholder是指持有筹码，参与赌博game的人。这里面就包含了这样的意思：从game程序上，你无法永远绕过一个“玩家”，他是game的一部分；同时，由于其手中的筹码，你绝对不可以忽视他的行为，这些筹码和行为也许会成为game的关键。正如05年小布什在第二个任期开始后不久派人到北京来宣布其对华新政时，美国人就巧妙地要求：

We need to urge China to become a responsible stakeholder in the international system（我们应该要求中国成为一个负责任的stakeholder）

这篇当时的时事评论充分说明：stakeholder存在非常浓厚的博弈色彩。

那么，在工程管理工作中如何管理和对待stakeholder呢？

理性、客观、科学

对待stakeholder的问题，科学是最恰当的解决方案。比如对待健康诉求和农作物保护诉求来说，准确地评估其利益损害是首要问题。这方面，客观、理性的数据，以及对问题科学的解析能够迅速让stakeholder明确合理的诉求，也有助于各方冷静理性地预计整体的的“代价”，而不是紧紧盯着自己的利益。在工程领域，系统完整地识别stakeholder是很困难的，而识别项目可能造成的损害却是可行的，科学地管理项目损害是应对stakeholder的问题的关键。

经济与博弈

有些问题却不是科学或者科技可以解决的，比如现在正在进行的气象问题国际谈判，N多科学论文恐怕也很难改变各方的立场。这个时候，在追求和谐、共赢的社会背景中，在寻求stakeholder之间的利益平衡过程中，博弈与经济方法是非常有效的手段。

这方面最有力的案例就是拆迁，有很多成功的，也有很多失败的。灵活的经济手段绝对是方法之一，简单粗暴肯定得不到好的结果。

写在最后：

逆水行舟。早在90年代FIDIC就出版了《project sustainability management guidelines》，其第一句话就提到了stakeholder。说起来有些形而上学：行业进步的动力也来源于stakeholder，不是吗？

建筑是一个系统，而不是一个简单的构筑物。因此当我们完成建造过程，准备使用建筑物的时候，首先需要对建筑进行必要的测试和调整，确保它可以按照当初的设计运营。当然，最后的移交工作也非常重要，因为建筑的运营和维护工作将在移交的时候正式启动。

应该承认国内工程管理中竣工移交方面还存在非常多的缺陷和不足，尤其是民用建筑工程领域。下面airstorm将从几个方面探讨这个问题，看看一个信息模型可以在那些方面给我们更好的帮助和体验：
(more…)

可交付成果在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。

对于我等来说，可以下载的学习资料能够再丰富一下喽： (more…)

之前简单介绍了BIM在建筑、结构方面的应用，这次简单介绍BIM在机电设备方面的应用:

图片来源：Archpaper.com

(more…)

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

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

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

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

(more…)

建筑信息模型BIM在4D领域的应用不如普通3D模型应用那样广泛，这主要还是4D领域的应用还比较“软”。大量的4D应用成果都集中在visual plan方面，这类能让大家看到plan结果的可视化模拟的确威力非凡。

还有一类4D应用就需要大量的建筑构件实体数据参与4D模拟：施工过程分析。很多工程必须对施工过程的结构特性进行必要的分析，看看下图就知道这样做的必要性了： (more…)

之前曾经介绍过用excel手工绘制精确gantt图的方法，实际上这种办法完全是权宜之计。任何人不可能天天使用如此繁琐的操作去制作一个并不复杂的图表，虽然图表所包含的数据很多。

如果使用excel绘制gantt图，就需要一款适于自己的excel模板。这个模板应该有下列功能：

• 可以根据格式化的数据直接生成 gantt图
• 可以为任务条着色
• 可以批量更改数据
• 可以重新分级

那么也许应该试一试这种工具：

(more…)