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

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相结合。

刚刚还在讨论工程采购的“透明度”问题，期间突然想到了前一段时间网上很流行的“晒工资”。觉得也许对于公共工程领域，也许“晒清单”是个“办法”。也就是说“晒”出来的更多是其内部翔实的子目、子项构成，而非总数，这些子目具有更强的可比性，更能够说明问题。

这会儿一则消息映入眼帘：Complementary studies of scope of service definitions launched。FIDIC将展开针对项目9个阶段的服务范围定义研究。中文原文：

为了使采购更加透明、减少甚至消除公开招投标的技术壁垒、消除以价格为主导的选聘程序，FIDIC范围界定工作组正 在制定项目不同阶段咨询工程师提供服务范围的标准定义，这些定义将有助于客户理解所提供的优质服务的种类。该工作组正在与欧洲工程咨询协会联合会 （EFCA）在欧盟资助的一个项目的基础上，共同制定咨询服务的标准化问题。拟议中的项目九个阶段的定义将通过成员协会征求咨询公司的意见。（来自FIDIC中国培训中心）

在当今需要“透明”的领域，FIDIC看来很会与时俱进。但作为我们来说，工程咨询领域的全生命周期服务范围详细定义绝对有着非同一般的意义。你难道不想知道造价咨询服务全生命周期的服务范围及其详细定义？

所以期待早日见到可以给我们带来指导和透明的 全生命周期服务范围详细定义。

本文试图澄清关于“开工日期”的一些误解，以便加强工程管理的分析和判断能力.

开工日期的多重意义

一直以来，业界有许多人对于“开工日期”都有着错误的理解。一方面是由于对工程合同的熟悉程度不够，另一方面也是由于国内在开工问题上的程序相对复杂。当然，开工日期本身也有多种性质：具有法律意义的开工日期和实际开工日期。具有法律意义的开工日期实际上就是根据工程合同定义或生成的开工日；而实际开工日期更多地指向承包商根据他的进度计划而设定的开工日。通常，实际开工日在承包商实际占有工程现场之后。

实际上在合同角度看，开工日期有两个意义：一个是承包商正式、全面履行合同的起始日期，自此日期起合同双方活动受合同约束。另外一个就是工期的起算时间，虽然对合同双方竣工日期更为重要，但是工期作为合同履行时间仍然从很多方面制约双方利益。

对于开工日期的误解主要有下面几个：
(more…)

参考《客户/咨询工程师（单位）协议书指南》，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的论述，目前在英国已知的工程项目管理案例中关于项目经理的争议主要是项目经理是否应作为专业咨询工程师或履行专业顾问而提供相关服务。大多数判例明显支持项目经理应具有相应的专业素质，以满足工程整体管理的需要。根据《白皮书指南》的论述：

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

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