前一段作一个项目管理的指导，发现项目团队成员对于“里程碑”的理解存在问题，于是有了这篇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

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

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

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

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

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

图片来源：Archpaper.com

(全文…)