潜伏了N久，今天出来透一透气。从重庆回来后就感冒了，奉劝各位：保重身体，勿忘思考。古人推崇勤奋，是指自我的完善而不是自我的消费。当你的思虑所在与现实生活、工作严重错位，你就知道个中滋味了。

闲话少说，忙忙忙的借口之下，实际是无尽的废思（无用之思）。冒泡的目的乃是同大家分享一些我等或许关注的消息（聊胜于无的尴尬），请各位上眼：

央视大火案 新址外墙装修方15人被批捕

中新网报道，中国央视大火案又有新进展，新址外墙装修方15人被检察机关批捕，此次被批捕的人员大多是一家叫盛兴墙幕有限公司(下称盛兴公司)的员工。盛兴公司总部位于广东省中山市，是负责央视配楼外墙装修项目的单位。这些施工人员在央视配楼的建设中，有以次充好及把关不严等情况。目前这些人都已经因涉嫌工程重大事故罪被批准逮捕。这一说法尚未得到检方的公开证实。-《联合早报》

另外有消息说，央视过火大楼有可能卖给香港著名地产商。

人月网国内可以登录了

早上发现邮件：各位人月传奇成员，感谢人月刘健最新发现，国内已可以登陆人月传奇了，欢迎国内各位重返人月传奇。

这无疑是最令人振奋的消息，但愿这不是嫱在抽风。

AIA Documents online solution

熟悉AIA Documents的都知道，狡猾的AIA打包它的合同文本，并且出售一种可以定制工程合同的软件。这样AIA可以清楚地计算出你使用它的文本所应支付的费用。现在，据说有了online版（仅仅针对MAC计算机，使用windows的别想了）。

更牛的是，AIA发布了iphone可以浏览的“ Building codes and standards ” ！简直无话可说，与时俱进的了这个地步，不能不佩服人家的头脑。

ok，在这块 hive five 的领地中，知识共享是第一位的。

前一段作一个项目管理的指导，发现项目团队成员对于“里程碑”的理解存在问题，于是有了这篇post《里程碑 (milestone)》。

对里程碑的误解：

A、里程碑＝期限

期限（deadline）其实没有什么可讲的，那是强制性的约束条件，你必须遵守。但是里程碑不是，它充其量在约束方面算是参照系，而不是强制约束。存在这种误解是因为大多数项目会在项目期限处设置里程碑，因而混淆了这两种概念。

B、里程碑会议的滥用

里程碑的很主要的功能就是检查、度量（后面详述），因此里程碑会议成了很多团队必要的检查工具。实际上，会议作为检查工具的作用极其有限，真正完成检查任务的是管理平台或者专门的检验机制（如工程竣工验收体系）。因此“总结会”、“节点会”更多的是一个足够主要的里程碑事件，它将正式确定、认可、批准检验、测量体系得到的结果（如工程竣工验收合格）。

上述观点的另外一层意思就是：不要指望会议本身去完成繁杂的检验、测量工作。可悲的是很多领导恰恰乐于这么做。

里程碑的作用

在项目管理语境中，里程碑是一种项目进展的度量方法或者机制，用于度量项目的进展情况。那么，度量什么呢？

1、度量项目的实际进展。主要的度量方法就是进度管理的一些方法和技巧。在工程管理领域中检查CPM路径的时差 (float) 是一项常规任务，还有如工程计划完成工作量、实际完成计划工作量等等参数。具有可参照意义的是挣值 (EV) 它所反应的项目进展相对科学一点。这种度量是管理层面的。

2、里程碑条件。通常我们会定义里程碑达成的必要条件，诸如项目主要可交付成果的完成、项目阶段的达成等等。对于里程碑条件的度量和检验有必要细分为：

（1）产品、成果导向的条件。这通常需要领域的组织体系、产品、成果的检验方法、体系等等的支撑。（例如产品检验的标准、方法；成果的定义、需求的检查等等）。这项工作绝对不是一个节点可以完成的，它应该是过程检验、测量积累的结果。

（2）管理导向的条件。即对项目工作的检查，可能有：

• 本里程碑应完成却的未完成的剩余工作；
• 下一个阶段的准备工作；
• 目标、计划、范围的修订与变更；
• 以及必要的风险评估；
• 等等。

管理条件的检查分布于整个项目管理的绩效测量节点，因此其检验、测量的方法也依赖于检验内容和范围。这些方法应该记录于绩效测量计划或者项目计划中。

总体上，只有完成了所有里程碑条件，我们才可以宣布达成某个里程碑。现在，应该明确里程碑的作用了。提问：

设计工作完成是指：

1. 到了设计成果交付日；
2. 召开了设计评审会议；
3. 设计合同收尾结束；
4. 达成设计工作里程碑的所有条件。

很显然，设计工作的完成在不同领域、不同项目、不同角色下依然存在差距。我们也不能否认里程碑有着时间标尺的属性，它也是个项目进度管理术语。因此发挥里程碑的作用，就全然在于：

里程碑的定义

1. 目标导向。里程碑定义必然同项目目标以及目标分解联系在一起，这正是它参照系作用的核心价值。即，里程碑评价、测量的是项目目标的达成，而不是项目绩效的结果。
2. 里程碑的设置。基于不同的管理角色、不同的管理阶段，会有不同的项目里程碑。主要的是检查点必须附带必要的检查表（检查内容、方法、标准、必要的程序、资源、成本等等）。
3. 后续工作。归档、备案、付款、移交等等工作将在里程碑达成后展开，如果仅仅是一个“到了设计成果交付日”这样的里程碑，你也需要预先计划可能的后续工作（如变更、推迟、索赔以及必要的报告等等）

ok，对于里程碑，你需要有健壮的检验/测量机制、完善的计划以及灵活的运用。比如把里程碑的时间特性用足（投标截止日）、把付款同里程碑捆绑在一起（某工作的付款条件）、或者让某些人围着里程碑打转（性能测试与验收）……

管理成熟度模型

首先，五个等级的说法来自于克劳斯白crosby的《质量免费》 quality is free，所谓管理成熟度模型之父以及质量0缺陷之父。

其次，完美自实现了5个等级的行业恰恰是IT业，其他行业难当完美。比如工程业界，就很难找出3－5级企业，或者，1－5级别的企业呈现正态分布的格局。

而且，John Kotter在《领导变革》一书中指出，只有30％的企业变革计划最终获得了成功。即自发的管理升级成功律没有我们想象的高。

IT业的成功

获得最高管理成熟度的企业组织中，IT业占据了绝大多数。其实IT的成功有很多其他行业不能比拟的优势：

1、对其他行业、领域的依赖度很小。如铁矿业与建筑、汽车业的关系。你不太可能在封建社会制造出来一个“国家计委”，但是可以制造出来一个信访局。这种先天优势可以让IT业开展非常独立的自我升级，而不需要考虑社会因素的强大制约。

2、管理变革对产品的质量影响负面影响有限。IT业中bug（错误）的高度可度量性，IT有很健全的debug机制，这是一种非常系统的排查机制，使得任何参与人都可以清晰地发现、处理、应对错误。这保证了IT产品的质量相对而言非常好。比如word程序出现了故障，通常我们的第一反应是有病毒或者系统出问题了，很少去想word程序本身的问题。因此，有了debug系统，管理改革很少触动产品质量的负面飘移。

3、将人的因素限制到单一领域，比如创新。现代制造业的腾飞离不开流水线的发明，其实流水线本身就是限制人为因素的手段之一。IT业的工具完善程度不是我们可以比拼的。比如邱总说姗姗2000多分，我只有400多分，这种精确的度量机制我们在其他行业很难见到。那么当你工作的平台限制你的错误、限制你的延误、限制你的协作效率的时候，你剩下的就是小跑前进了。（实际上曾总在人月上给大家展现的就是这类工程管理领域的工作平台，只不过它是项目级别的，应该还有配套的企业级别平台）

制约因素

跳出IT视角，中国03年开始ERP、SOA火得很，但是能够实现管理飞跃的企业少的可怜。why？

社会i性因素，整个产业链条的效率摆在那里，你花上百万、千万运作出来的高效率却不能提升产业上下游的生产效率……所以很多企业家当下的做法是：做大并独裁，用独裁的效率替代企业管理升级的效率优势。现在西方学者拼命批评中国的企业家，但是他们忘记了自己也是那么过来的。只不过中国的进化速度比他们还快。

产品因素，相对而言，管理是软科学，对于产品的硬性影响很小，别说bug的高度可度量了，就连整个产品的生产性度量都未必测量的出来。对于产品控制的非精确管理模式直接屏蔽了管理升级的核心标尺，所以升级更多是领导的命令而不是员工的组织的整体行为。比如西化之后，中国的天气预报机构（观天司）被彻底的替代了，是因为其产品不具备比较优势。《领导变革》就提出，变革的有效前提是可见优势，这种优势可以是产品的、管理的、社会的等等。对于企业来说，增加一个大额订单，你的生产支出是增加还是降低？再如，绿色建筑需要度量排炭指标，这种指标是一种科学的能耗度量标尺，他可以使设计者、业主在未来的世界中获得更多的优势。我经常听到国内的设计人员说：LEED认证有什么用啊，不就是多一个名头吗？这就是典型的可度量标尺缺失造成的懈怠。

人与文化的因素，如果说企业有5个级别。那么孔子早就提到了人的级别：三十而立、四十不惑……有过西方生活学习经历的人都知道，东西方的同一词汇所包含的意义是不一样的（很多时候），这可以看作是思维模式的不同、文化的不同。重要的是，人作为个体以及整体对待事物的认知是不同的、对立的以及变化的。所以李熬谈胡适的时候认为胡适的新文化运动的核心就是思想革命，而不是政治革命。这种思路是有着非常现实意义的，任何变革必须考虑人以及文化背后的思想因素。

其他……我一直在寻找答案，到目前为止成熟的就这么多。拿出来暴晒，期望同大家探讨。

US & China: Global Centers for Green Building Policy

是的，为了我们自己也该是行动的时候了。而不是听别人怎样说，当然，他们说的很对。

很长时间没有更新blog了，要看要学的东西太多，有些招架不住了。在网上看到leed更新评价体系的news，忍不住拉过来作为博文应景。

LEED 实际上已经称为了可持续发展建筑评价的标准之一，但是问题还是存在的。这不，人家 U.S. Green Building Council (USGBC)就不是实际地推出了新的评价体系。根据construction.com的消息，新的评价体系有可能被称为LEED 3.0。与旧有体系相比，新的评价体系有如下变化：

基于13项人类活动后果的评估

新的评价体系采用了美国环保局（ EPA ）的 “TRACI.”评价工具，针对13项人类活动产生的化学或者其他环境影响进行评估。

LEED分类权重

看得出来，碳排放的权重最大。

满分变成100分

由于调整了权重，满分从原来的64变成了100。其中“可持续发展“和“能源与可再生资源利用“的权重提升很大。另外，水资源保护可以获得多达10分，分数比以前提供的多出一倍。

根据新的规则， 40 分为最低合格线， 50 分以上为银级， 60 分以上为金级，80 分以上为铂金级。

评分等级变化

认证专家体系的变化

随着评价系统的改革，LEED v3的认证专家体系也发生了变化。包括专家认证管理机构的变化，认证级别的增加（变为认证助理、认证专家和资深LEED专家三个级别）。

认证程序变化

主要是在线认证过程的实施，具体的细节请参考原文。

提供了三套指南

指南数量从原来的9个变成了3个。

leed指南

从感觉上看，LEED v3的科学性、适应性明显提高。应该加紧学习了！

违法燃放行为

依据国务院《烟花爆竹安全管理条例》(GB1995-2004)，对举办焰火晚会以及其他大型焰火燃放活动，实行许可证制度，分级审批。条例规定举办焰火晚会必须持有燃放地公安部门核发的《焰火燃放许可证》，显然，烟花公司在没有《焰火燃放许可证》前提下燃放烟花已经构成违法。但是必须注意到条例规定：

主办单位应当按照分级管理的规定，向有关人民政府公安部门提出申请……

根据公安部发布的《焰火晚会烟花爆竹燃放安全规程》，燃放公司必须向主办方提交“技术设计与组织实施设计方案”，主办方认可该方案后，必须向燃放地公安部门提出燃放申请并提交技术设计与组织实施设计方案。燃放地公安部门审核后，核发的《焰火燃放许可证》。因此可以推导出一个结果：烟花公司提交合格的技术设计与组织实施设计方案才是获得《焰火燃放许可证》充分必要条件。

从公开的信息看，显然北京市公安机关从未接到任何的燃放申请，因此才有“违规擅自燃放”的定性结论。虽然我们不知道业主方（主办方）是否接到了烟花公司提交的方案，但是从常理推测，业主方（主办方）没有必要在这方面知法犯法。

安全管理疏忽

《焰火晚会烟花爆竹燃放安全规程》规定的技术设计方案应包括下列内容：：

1. 焰火晚会规模概况，燃放时间、地点以及与晚会活动主题相应的编组燃放文字说明；
2. 所燃放烟花爆竹的种类与数量及礼花弹发射最大高度、爆炸覆盖面积等有关参数；
3. 燃放器材的基本情况及点火方式；
4. 安全距离与安全警戒范围。

组织实施方案应当包括下列内容：

1. 现场组织机构的设置，包括根据焰火晚会活动规模所设置的燃放技术、安全警戒、交通管制、消防、救护、事故应急处理等职能组的组成；
2. 现场人员分工、岗位、职责；
3. 烟花爆竹及有关器材的运输和储存、保管安全措施；
4. 实施燃放时的安全保卫措施；
5. 事故应急处理措施。

根据当前掌握的信息，显然烟花公司存在严重的安全管理疏忽行为。这些疏忽是火灾发生的直接原因之一。

故意逃脱运输检查

按照上述法律法规的规定，运输烟花爆竹需要《烟花爆竹道路运输许可证》，而据报道显然烟花公司存在故意违法运输烟花爆竹的行为，即刻意躲避安全执法检查，刻意规避法律规定的申报程序。

刑事责任

违法违规燃放烟花爆竹，造成人身、财产侵害的负有刑事责任；违规运输烟花爆竹、故意躲避安全检查的同样会被追究刑事责任。但是本文的重点不在这里。

民事责任

严重的安全管理疏忽应该是导致火灾发生的原因之一。在FIDIC条件下，烟花公司作为业主的雇佣人员进入现场，应遵守工程安全管理的一切规章制度、并保障工程的安全。（参照FIDIC2.3、4.6、4.8款的规定）

从民事侵权责任上分析，雇员在从事雇佣活动中因安全生产事故遭受人身损害，发包人、分包人知道或者应当知道接受发包或者分包业务的雇主没有相应资质或者安全生产条件的，应当与雇主承担连带赔偿责任。当然在FIDIC条件下，需要考虑工程保险的覆盖范围，能够被保险覆盖的，讨论民事在人的意义不大。关于保险的问题以后讨论。

在web2.0的时代，PM工具已经脱离了传统PM工具的模式，进化成了另外一种模式：team生产力工具。这类工具小巧而灵活，他们很好地适应了online工作的需求，为了更好地介绍后面介绍的工具，这里叫要阐述一下team生产力工具：

1、在线工作主要以沟通和共享为主，这类离散的信息不必结构化地管理，而只需要及时灵活地分享和发布。

2、传统的庞杂计划编制很分析工具不适合颗粒度如此细小的工作，也没有很好地解决沟通问题。

3、team内部成员的默契会比流程管理之类的模式化工具更富有敏捷、灵活的特性，这个时候，他们需要的就是互通有无。

有了上述认识，我们开始认识3款PM工具吧

1、Trikr

首先是国内的产品：趣客Trikr，我对这工具的试用感受是界面做得很舒服，人性化也很好，稍微有一点PM软件经验的人操作起来不会费力气。下图是trikr的界面截图：

2、Mangbar

忙吧Mangbar也是国内的产品，据我所知，忙吧比trikr要早。算起来忙吧应该是我认识的第一个国内free在线PM工具。忙吧除了在线PM外，他的群组功能也很有趣。从界面的角度而言，忙吧最接近传统PM的样子，比如任务分解结构：

还有项目变更记录这种称谓，都很传统。

3、Huddle

huddle是英国的web2.0站点，而且最近很有名气。上面已经分析过了，team生产力工具，在线PM工具的最大要素是及时的信息共享。huddle又比前2个应用多了一个功能：信息的推送，RSS。这正是web2.0网站最基本的功能。huddle通过小小的RSS和ical feed就解决了将team成员束缚与一个web站点的烦恼，进而进一步解放team 成员的个人生产力，这一点我很看好。

总结

如果我要一个team生产力工具，在线PM工具。我需要一下功能：

1、feed OR 项目状态页（如果没有feed的话）

2、简单的话题、讨论功能，或许还需要whiteboards

3、task

4、file share

5、contact list 或者CRM工具

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，不是吗？