<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Airstorms &#187; contracts</title>
	<atom:link href="http://www.airstorm.org/blog/category/fidic/contracts/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.airstorm.org/blog</link>
	<description>Building Project Management knowladgement weblog</description>
	<lastBuildDate>Mon, 09 Nov 2009 05:39:53 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.5</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>央视TVCC火灾-烟花公司责任</title>
		<link>http://www.airstorm.org/blog/2009/03/09/tacc-fire-duty-of-fireworks/</link>
		<comments>http://www.airstorm.org/blog/2009/03/09/tacc-fire-duty-of-fireworks/#comments</comments>
		<pubDate>Mon, 09 Mar 2009 05:08:16 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[火灾]]></category>
		<category><![CDATA[违规]]></category>
		<category><![CDATA[违法]]></category>
		<category><![CDATA[TVCC]]></category>
		<category><![CDATA[央视]]></category>
		<category><![CDATA[安全]]></category>
		<category><![CDATA[法律责任]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/2009/03/09/%e5%a4%ae%e8%a7%86tvcc%e7%81%ab%e7%81%be-%e7%83%9f%e8%8a%b1%e5%85%ac%e5%8f%b8%e8%b4%a3%e4%bb%bb/</guid>
		<description><![CDATA[违法燃放行为
依据国务院《烟花爆竹安全管理条例》(GB1995-2004)，对举办焰火晚会以及其他大型焰火燃放活动，实行许可证制度，分级审批。条例规定举办焰火晚会必须持有燃放地公安部门核发的《焰火燃放许可证》，显然，烟花公司在没有《焰火燃放许可证》前提下燃放烟花已经构成违法。但是必须注意到条例规定：
主办单位应当按照分级管理的规定，向有关人民政府公安部门提出申请……

根据公安部发布的《焰火晚会烟花爆竹燃放安全规程》，燃放公司必须向主办方提交“技术设计与组织实施设计方案”，主办方认可该方案后，必须向燃放地公安部门提出燃放申请并提交技术设计与组织实施设计方案。燃放地公安部门审核后，核发的《焰火燃放许可证》。因此可以推导出一个结果：烟花公司提交合格的技术设计与组织实施设计方案才是获得《焰火燃放许可证》充分必要条件。
从公开的信息看，显然北京市公安机关从未接到任何的燃放申请，因此才有“违规擅自燃放”的定性结论。虽然我们不知道业主方（主办方）是否接到了烟花公司提交的方案，但是从常理推测，业主方（主办方）没有必要在这方面知法犯法。
安全管理疏忽
《焰火晚会烟花爆竹燃放安全规程》规定的技术设计方案应包括下列内容：：
   

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

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

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

根据当前掌握的信息，显然烟花公司存在严重的安全管理疏忽行为。这些疏忽是火灾发生的直接原因之一。
故意逃脱运输检查
按照上述法律法规的规定，运输烟花爆竹需要《烟花爆竹道路运输许可证》，而据报道显然烟花公司存在故意违法运输烟花爆竹的行为，即刻意躲避安全执法检查，刻意规避法律规定的申报程序。 
刑事责任
违法违规燃放烟花爆竹，造成人身、财产侵害的负有刑事责任；违规运输烟花爆竹、故意躲避安全检查的同样会被追究刑事责任。但是本文的重点不在这里。
民事责任
严重的安全管理疏忽应该是导致火灾发生的原因之一。在FIDIC条件下，烟花公司作为业主的雇佣人员进入现场，应遵守工程安全管理的一切规章制度、并保障工程的安全。（参照FIDIC2.3、4.6、4.8款的规定）
从民事侵权责任上分析，雇员在从事雇佣活动中因安全生产事故遭受人身损害，发包人、分包人知道或者应当知道接受发包或者分包业务的雇主没有相应资质或者安全生产条件的，应当与雇主承担连带赔偿责任。当然在FIDIC条件下，需要考虑工程保险的覆盖范围，能够被保险覆盖的，讨论民事在人的意义不大。关于保险的问题以后讨论。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p><strong>违法燃放行为</strong></p>
<p>依据国务院《烟花爆竹安全管理条例》(GB1995-2004)，对举办焰火晚会以及其他大型焰火燃放活动，实行许可证制度，分级审批。条例规定举办焰火晚会必须持有燃放地公安部门核发的《焰火燃放许可证》，显然，烟花公司在没有《焰火燃放许可证》前提下燃放烟花已经构成违法。但是必须注意到条例规定：</p>
<blockquote><p>主办单位应当按照分级管理的规定，向有关人民政府公安部门提出申请<font style="background-color: #ffffff" color="#333333">……</font></p>
</blockquote>
<p>根据公安部发布的《焰火晚会烟花爆竹燃放安全规程》，燃放公司必须向主办方提交“技术设计与组织实施设计方案”，主办方认可该方案后，必须向燃放地公安部门提出燃放申请并提交技术设计与组织实施设计方案。燃放地公安部门审核后，核发的《焰火燃放许可证》。因此可以推导出一个结果：<strong>烟花公司提交合格的技术设计与组织实施设计方案才是获得《焰火燃放许可证》充分必要条件。</strong></p>
<p>从公开的信息看，显然北京市公安机关从未接到任何的燃放申请，因此才有“违规擅自燃放”的定性结论。虽然我们不知道业主方（主办方）是否接到了烟花公司提交的方案，但是从常理推测，业主方（主办方）没有必要在这方面知法犯法。</p>
<p><strong>安全管理疏忽</strong></p>
<p>《焰火晚会烟花爆竹燃放安全规程》规定的技术设计方案应包括下列内容：：</p>
<ol>   </ol>
<ol>
<li>焰火晚会规模概况，燃放时间、地点以及与晚会活动主题相应的编组燃放文字说明； </li>
<li>所燃放烟花爆竹的种类与数量及礼花弹发射最大高度、爆炸覆盖面积等有关参数； </li>
<li>燃放器材的基本情况及点火方式； </li>
<li>安全距离与安全警戒范围。 </li>
</ol>
<p>组织实施方案应当包括下列内容：</p>
<ol>   </ol>
<ol>
<li>现场组织机构的设置，包括根据焰火晚会活动规模所设置的燃放技术、安全警戒、交通管制、消防、救护、事故应急处理等职能组的组成； </li>
<li>现场人员分工、岗位、职责； </li>
<li>烟花爆竹及有关器材的运输和储存、保管安全措施； </li>
<li>实施燃放时的安全保卫措施； </li>
<li>事故应急处理措施。 </li>
</ol>
<p>根据当前掌握的信息，显然烟花公司存在严重的安全管理疏忽行为。这些疏忽是火灾发生的直接原因之一。</p>
<p><strong>故意逃脱运输检查</strong></p>
<p>按照上述法律法规的规定，运输烟花爆竹需要《烟花爆竹道路运输许可证》，而据报道显然烟花公司存在故意违法运输烟花爆竹的行为，即刻意躲避安全执法检查，刻意规避法律规定的申报程序。 </p>
<p><strong>刑事责任</strong></p>
<p>违法违规燃放烟花爆竹，造成人身、财产侵害的负有刑事责任；违规运输烟花爆竹、故意躲避安全检查的同样会被追究刑事责任。但是本文的重点不在这里。</p>
<p><strong>民事责任</strong></p>
<p>严重的安全管理疏忽应该是导致火灾发生的原因之一。在FIDIC条件下，烟花公司作为业主的雇佣人员进入现场，应遵守工程安全管理的一切规章制度、并保障工程的安全。（参照FIDIC2.3、4.6、4.8款的规定）</p>
<p>从民事侵权责任上分析，雇员在从事雇佣活动中因安全生产事故遭受人身损害，发包人、分包人知道或者应当知道接受发包或者分包业务的雇主没有相应资质或者安全生产条件的，应当与雇主承担连带赔偿责任。当然在FIDIC条件下，需要考虑工程保险的覆盖范围，能够被保险覆盖的，讨论民事在人的意义不大。关于保险的问题以后讨论。</p>
<hr /><small> <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-sa/2.5/cn/80x15.png"/></a><br/>本<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" rel="dc:type">作品</span>采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/">知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议</a>进行许可。Copyright &copy; 2008 作者<a href="http://www.airstorm.org/blog/about/"> clockwork59 </a> at <a href="http://www.airstorm.org/blog/">Airstorm</a> (数字指纹:<br /> 24fed2e143ca40ef26657495da818d48)</small>]]></content:encoded>
			<wfw:commentRss>http://www.airstorm.org/blog/2009/03/09/tacc-fire-duty-of-fireworks/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>WBS概念误区 (一)</title>
		<link>http://www.airstorm.org/blog/2008/06/03/mistakes-concept-about-deliverable-of-wbs/</link>
		<comments>http://www.airstorm.org/blog/2008/06/03/mistakes-concept-about-deliverable-of-wbs/#comments</comments>
		<pubDate>Tue, 03 Jun 2008 03:08:07 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[BIM]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[Software]]></category>
		<category><![CDATA[WBS]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[deliverable]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PBS]]></category>
		<category><![CDATA[可交付成果]]></category>
		<category><![CDATA[合同分解结构]]></category>
		<category><![CDATA[工程量清单]]></category>
		<category><![CDATA[工作分解结构]]></category>
		<category><![CDATA[产品分解结构]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=60</guid>
		<description><![CDATA[可交付成果在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相结合。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>可交付成果在PMBOK中有比较清晰的定义，Airstorm这里就不在背书了。直接谈谈容易出现的误解，对于可交付成果的误解集中在2各方面：一是可交付成果的概念本身；二是可交付成果在WBS中的作用。</p>
<h3>误解一：可交付成果就是“工程”</h3>
<p>工程领域中，项目产品的不确定性没有超出合同双方的经验范围。所以建筑工程承包商可以闭着眼睛告诉客户他们建造的项目产品大体上是什么，客户也基本认可这个大体的范围，即便在细节问题上会有自己的要求（在物理构成上建筑物有97％的共性）。因此，工程领域向来有范例式的WBS构建方法。而这个范例就是工程领域的“定额编码体系”，在建筑领域就是（工程量清单），这种编码体系本身就容易被误解为项目的完整WBS。关于这一点我们稍后讨论。这里仅仅说说其分解特点，“定额编码体系”（工程量清单）的特点就是以可交付成果为导向的分解体系，其大部分分解节点都是以名词为主的（例如钢筋工程，钢筋、预制构件、钢筋笼），即可交付成果通常被理解为有形的工程实体。</p>
<p>在工程领域人员学习WBS的时候，经常会完成一个工程实体分解的WBS。持有这类观点的不在少数，他们在概念里倾向于将工程的PBS替代WBS，其中不乏技术人员和管理者。如果将工程设计WBS分解为：</p>
<blockquote><p>设计图纸，结构设计图纸，建筑设计图纸，市政工程设计图纸，电气工程设计图纸……</p></blockquote>
<p>恐怕很难识别设计工作的一些任务，例如，设计前现场勘查，施工过程的现场监督，二次设计图纸的审核等等工作。如果说WBS是一种“范围管理”工具，那么基于产品的分解方法通常比较容易遗漏“过程服务”的成果，这些成果大部分情况下是“无形”的。我们知道产品需求差异会导致设计工作范围的不同，因此在进行设计管理工作的时候就不能仅仅围绕设计的可交付成果展开，还要兼顾面向任务或者活动的部分。实际上，借鉴软件工程的WBS可以看出，设计领域中在项目开始之前进行较为精确的产品分解是不切实际的，所以通常使用任务分解的方式分解WBS。</p>
<p>再有，工程中的采购也难以使用有形的采购产品分解WBS，更多的是采用面向过程的WBS。过程管理对于项目管理是非常重要的，很多时候基于过程的分解更加贴近OBS，或者在更高的WBS层级与OBS匹配。其实过程分解的下一级就是任务分解，而任务分解的下一级就到了工作成果。正如Airstorm在上面所述，服务和产品的叠加才是“工作（works）”，这显然与传统的工程领域知识相矛盾（工程领域中，works专指“工程”或者“永久工程”，参见FIDIC条件），在《系统》一书中介绍WBS概念的时候，特地强调了CWBS【合同分解结构】一词，其概念核心就是是基于产品分解的WBS要通过CWBS（合同分解结构）的方式建立一种管理项目任务的渠道，使得项目工作范围被完整地管理起来。</p>
<p><strong>总结</strong></p>
<h3>WBS中的works是一个“包”的概念，是工作任务与工作成果的集合</h3>
<p>对待WBS的时候，不应该仅仅将其看作是PBS（产品分解结构），如果必须如此，则需要界定任务分解结构，比较成熟的有合同分解结构CWBS，或者组织分解结构OBS与PBS相结合。</p>
<hr /><small> <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-sa/2.5/cn/80x15.png"/></a><br/>本<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" rel="dc:type">作品</span>采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/">知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议</a>进行许可。Copyright &copy; 2008 作者<a href="http://www.airstorm.org/blog/about/"> clockwork59 </a> at <a href="http://www.airstorm.org/blog/">Airstorm</a> (数字指纹:<br /> 24fed2e143ca40ef26657495da818d48)</small>]]></content:encoded>
			<wfw:commentRss>http://www.airstorm.org/blog/2008/06/03/mistakes-concept-about-deliverable-of-wbs/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>开工日期 (Commencement Date)</title>
		<link>http://www.airstorm.org/blog/2007/05/10/commencement-date/</link>
		<comments>http://www.airstorm.org/blog/2007/05/10/commencement-date/#comments</comments>
		<pubDate>Thu, 10 May 2007 18:18:28 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[NEC]]></category>
		<category><![CDATA[工程合同]]></category>
		<category><![CDATA[开工日期]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=38</guid>
		<description><![CDATA[本文试图澄清关于“开工日期”的一些误解，以便加强工程管理的分析和判断能力.
开工日期的多重意义
一直以来，业界有许多人对于“开工日期”都有着错误的理解。一方面是由于对工程合同的熟悉程度不够，另一方面也是由于国内在开工问题上的程序相对复杂。当然，开工日期本身也有多种性质：具有法律意义的开工日期和实际开工日期。具有法律意义的开工日期实际上就是根据工程合同定义或生成的开工日；而实际开工日期更多地指向承包商根据他的进度计划而设定的开工日。通常，实际开工日在承包商实际占有工程现场之后。
实际上在合同角度看，开工日期有两个意义：一个是承包商正式、全面履行合同的起始日期，自此日期起合同双方活动受合同约束。另外一个就是工期的起算时间，虽然对合同双方竣工日期更为重要，但是工期作为合同履行时间仍然从很多方面制约双方利益。
对于开工日期的误解主要有下面几个：

建设工程开工许可证注明的日期，这个错误是很明显的但是还是有很多人有这样的误解。建设工程施工许可证是建设工程开工的法律凭证。取得了施工许可证，表明该建设工程的前期准备工作已经完成，具备开工条件，并享有开工的权利。即，建设工程施工许可证是合法开工的凭证，建设工程施工许可证注明的日期即具有指明证书颁发日的作用，没有确立开工日期的作用。
批准的开工申请书/进度计划声明的开工日期这实际上就是实际开工日期。更多的误解就是将此日期与合同定义的开工日期相混淆。开工日更多的是承包商在工程现场经过筹备和计划实际展开工程施工的日期，其中有两个先决条件：承包商实际占有工程现场，并取得管理权；承包商准备工作完成（诸如施工设备到场等等）。
由总监/工程师颁发的开工令日期，这个误解普遍存在于业界，很多人认为“监理方发布开工令是工程正式开工、合同正式实施的标志。”这个观点的错误在于：漠视承包商的施工准备工作。总监/工程师颁发开工令是承包商提交开工申请后的批复，是施工准备完成后才能通过的动工申请。而施工准备也是履行合同义务的一部分。如果以开工令日期作为“合同正式实施的标志”，那么承包商的施工准备工作就不受合同保护；取得工程现场占有权和使用权的承包商也不受合同约束。
开工日期的定义
FIDIC 对“开工日期”的定义为：承包商收到“中标函”后42天内，或者工程师提前7天向承包商发出开工通知的日期，当中较早的一个。
通常情况下，尽早开工对于合同双方均有利，因此FIDIC采用了“当中较早的一个”这一表述。同时应注意“或者工程师提前7天向承包商发出开工通知的日期”这一表述，但是应注意这里的开工通知不是总监/工程师颁发的开工令。这里的开工通知内容FIDIC有规定：
“我们在此通知，根据合同条件第XXX款，开工日期应为。。。。。”
由此可以看出，FIDIC的开工通知明确的是合同开工日期，总监/工程师颁发的开工令则是明确的实际开工日。
NEC合同对于开工日期的处理则更为灵活：
开工：承包商从第一个工程现场占有日起开始施工作业，并应在竣工日或竣工日前竣工。
承包商的工程进度计划应提交项目经理认可，并表明：开工日、现场占有日和竣工日。。。。。
这也体现了另一种对于开工日期的的处理方式，即第一个工程现场占有日作为双方合同正式实施日期。而对于开工日即实际动工的日期，承包商有权做出自己的计划并根据工程师的批准实施；而工程师也有权审核或制定动工日期。它表明实际动工的日期是需要双方确认具备实际开工的所有前提条件。
总结
开工日期是一个法律概念，它表明双方履行 合同义务的起始日期。而开工日/动工日/实际开工日则是经过双方确认的开工日期，它通常是在承包商占有现场并完成施工准备之后的某个日期。工程师有义务确认开工日，有义务检验承包商施工准备和其他开工条件，并维护雇主利益。
 本作品采用知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议进行许可。Copyright &#169; 2008 作者 clockwork59  at Airstorm (数字指纹: 24fed2e143ca40ef26657495da818d48)]]></description>
			<content:encoded><![CDATA[<p>本文试图澄清关于“开工日期”的一些误解，以便加强工程管理的分析和判断能力.</p>
<p><strong>开工日期的多重意义</strong></p>
<p>一直以来，业界有许多人对于“开工日期”都有着错误的理解。一方面是由于对工程合同的熟悉程度不够，另一方面也是由于国内在开工问题上的程序相对复杂。当然，开工日期本身也有多种性质：具有<strong>法律意义</strong>的<strong>开工日期</strong>和实际开工日期。具有法律意义的开工日期实际上就是根据工程合同定义或生成的开工日；而<strong>实际开工日</strong>期更多地指向承包商根据他的进度计划而设定的开工日。通常，<strong>实际开工日</strong>在承包商实际占有<strong>工程现场</strong>之后。</p>
<p>实际上在合同角度看，开工日期有两个意义：一个是承包商正式、全面履行合同的起始日期，自此日期起合同双方活动受合同约束。另外一个就是工期的起算时间，虽然对合同双方竣工日期更为重要，但是工期作为合同履行时间仍然从很多方面制约双方利益。</p>
<p>对于开工日期的误解主要有下面几个：<br />
<span id="more-38"></span><br />
<strong>建设工程开工许可证</strong>注明的日期，这个错误是很明显的但是还是有很多人有这样的误解。建设工程施工许可证是建设工程开工的法律凭证。取得了施工许可证，表明该建设工程的前期准备工作已经完成，具备开工条件，并享有开工的权利。即，建设工程施工许可证是合法开工的凭证，建设工程施工许可证注明的日期即具有指明证书颁发日的作用，没有确立开工日期的作用。</p>
<p>批准的<strong>开工申请书/进度计划</strong>声明的开工日期这实际上就是实际开工日期。更多的误解就是将此日期与合同定义的开工日期相混淆。开工日更多的是承包商在工程现场经过筹备和计划实际展开工程施工的日期，其中有两个先决条件：承包商实际占有工程现场，并取得管理权；承包商准备工作完成（诸如施工设备到场等等）。</p>
<p>由总监/工程师颁发的<strong>开工令日期</strong>，这个误解普遍存在于业界，很多人认为“监理方发布开工令是工程正式开工、合同正式实施的标志。”这个观点的错误在于：漠视承包商的施工准备工作。总监/工程师颁发开工令是承包商提交开工申请后的批复，是施工准备完成后才能通过的动工申请。而施工准备也是履行合同义务的一部分。如果以开工令日期作为“合同正式实施的标志”，那么承包商的施工准备工作就不受合同保护；取得工程现场占有权和使用权的承包商也不受合同约束。</p>
<p><strong>开工日期的定义</strong></p>
<p>FIDIC 对“开工日期”的定义为：承包商收到“中标函”后42天内，或者工程师提前7天向承包商发出开工通知的日期，当中较早的一个。</p>
<p>通常情况下，尽早开工对于合同双方均有利，因此FIDIC采用了“当中较早的一个”这一表述。同时应注意“或者工程师提前7天向承包商发出开工通知的日期”这一表述，但是应注意这里的<strong>开工通知</strong>不是总监/工程师颁发的<strong>开工令</strong>。这里的<strong>开工通知</strong>内容FIDIC有规定：</p>
<blockquote><p>“我们在此通知，根据合同条件第XXX款，开工日期应为。。。。。”</p></blockquote>
<p>由此可以看出，FIDIC的开工通知明确的是合同开工日期，总监/工程师颁发的开工令则是明确的<strong>实际开工日</strong>。</p>
<p>NEC合同对于开工日期的处理则更为灵活：</p>
<blockquote><p>开工：承包商从第一个工程现场占有日起开始施工作业，并应在竣工日或竣工日前竣工。</p>
<p>承包商的工程进度计划应提交项目经理认可，并表明：开工日、现场占有日和竣工日。。。。。</p></blockquote>
<p>这也体现了另一种对于开工日期的的处理方式，即第一个工程现场占有日作为双方合同正式实施日期。而对于开工日即实际动工的日期，承包商有权做出自己的计划并根据工程师的批准实施；而工程师也有权审核或制定动工日期。它表明实际动工的日期是需要双方确认具备实际开工的所有前提条件。</p>
<p><strong>总结</strong></p>
<p>开工日期是一个法律概念，它表明双方履行 合同义务的起始日期。而开工日/动工日/实际开工日则是经过双方确认的开工日期，它通常是在承包商占有现场并完成施工准备之后的某个日期。工程师有义务确认开工日，有义务检验承包商施工准备和其他开工条件，并维护雇主利益。</p>
<hr /><small> <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-sa/2.5/cn/80x15.png"/></a><br/>本<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" rel="dc:type">作品</span>采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/">知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议</a>进行许可。Copyright &copy; 2008 作者<a href="http://www.airstorm.org/blog/about/"> clockwork59 </a> at <a href="http://www.airstorm.org/blog/">Airstorm</a> (数字指纹:<br /> 24fed2e143ca40ef26657495da818d48)</small>]]></content:encoded>
			<wfw:commentRss>http://www.airstorm.org/blog/2007/05/10/commencement-date/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>从西方判例看工程项目管理经理的职责</title>
		<link>http://www.airstorm.org/blog/2006/12/24/project-managers-duties/</link>
		<comments>http://www.airstorm.org/blog/2006/12/24/project-managers-duties/#comments</comments>
		<pubDate>Sun, 24 Dec 2006 13:29:29 +0000</pubDate>
		<dc:creator>clockwork59</dc:creator>
				<category><![CDATA[AEC]]></category>
		<category><![CDATA[FIDIC]]></category>
		<category><![CDATA[PM]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[职责]]></category>
		<category><![CDATA[project manager]]></category>
		<category><![CDATA[判例]]></category>

		<guid isPermaLink="false">http://www.airstorm.org/blog/?p=31</guid>
		<description><![CDATA[ “项目经理”一词本来就是舶来品，我们或许可以从西方判例中看出在AEC领域项目经理PMr.有着怎样的责任和义务。
project manager &#8211;新生事物
随着建设项目日益复杂，提供建设项目的人员的分工日益专业化，在大多数项目中，由于大家都需求有另外的专业人士去协调咨询工程师和承包商的工作，项目经理 应运而生。但是，项目经理的准确的角色和责任仍在不断发展完善。 但到目前为止，尚没有被行业认可的PMr（项目经理一词在国内建筑行业另有含义，因此本文以&#8221;PMr&#8221;作为Project Manager的缩写替代）的定义，也没有正式的工程PMr协会或组织团体。
不同类别的其他专业团体出版的指南为项目经理承担相关的项目任务提供了帮助，RISC和CIOB都出版了相应的工程项目管理指南，但是PMr的职责范围和 管理任务并没有被完整清晰地定义出来。相反，关于PMr在工程项目各个阶段的具体任务都给出了长长的列表，而在列表中有很多任务与建筑师、合同管理师和工 程师的任务有一定程度的重叠。
职业谨慎和职业技能
虽然对项目经理这个特殊的职业没有达成像其它建筑行业所要求的职业谨慎和职业技能共识的标准，PMr的主要义务应该在明示或默示在合同条款规定中。 同时，其他咨询工程师的雇用合同条款对定义项目经理的任务范围也有相当大的影响。事实上，管理工程的任务并没有因为PMr的出现而增加多少，因此PMr更 多地分担了建筑师、工程师在工程管理方面的任务，从而将建筑师、工程师从琐碎的管理工作解放出来，确保其更好地完成专业工作和技术管理工作。在法庭上，当 确定项目经理有关的职业技能和职业谨慎义务时要看项目经理所属的专业协会,并且职业技能和职业谨慎的标准将是期望他作为一个有能力的称职的专业工程师来履 行项目管理等工作应达到的合理的职业谨慎和职业技能。正是由于项目管理是新兴的专业领域，其专业工作的定义尚未得到准确的界定，在判别PMr所要求的谨慎 的标准时，更多的取决于雇用合同具体条款规定和具体项目的要求。
针对PMr的诉讼主张
项目经理的角色被广泛地认为是监督与协调，多数对项目经理失职行为的诉讼主张有：项目经理没有控制好某方面的成本；没有确保其他建筑行业专业人士得到正确的信息；没有预防/防止建筑行业专业人士造成重大失误等等。
1 合同管理
作为工程项目的管理者，不可避免的要涉及工程合同的管理。无论PMr的雇佣合同是否对此明确租出界定，PMr的管理工作多不可能脱离开工程合同的管理。这 与工程项目的行业特征有关。在Royal Brompton Hospital NHS Trust 诉 ZHammond (2003) 88 Con. L.R.1.案例中，法官Lloyd.得出了一些关于项目经理角色的基本看法：
(a) 项目经理是业主的总代表，这点应该被其他咨询人员以及业主清除认识这一点。
(b) 毋庸置言，项目经理角色的核心任务是 &#8220;协调和保护业主的利益是毫无疑义的。&#8221;
(c) 当建筑行业专业人士履行合同管理或者项目管理的角色时，必须同时具备建筑法律基本的原理、准则方面的知识，并且具备将知识应用到建筑合同工程管理和建筑项目管理中。在许多案例中，所需要的不一定是基本的法律知识，而是很好的理解运用建筑合同的标准文本。
这些看法足以说明PMr具有潜在的合同管理责任，判例Great Eastern Hotel Co. Ltd v John Laing Co. Ltd [2005] 99 Con LR 45，是第一个报道的施工管理合同（construction management contract）违约案，业主成功地控告CMr.疏于对分包合同的协调管理。
在Royal Brompton Hospital NHS Trust 诉 Hammond (No.7) 76 Con. [...]]]></description>
			<content:encoded><![CDATA[<p><strong> </strong>“项目经理”一词本来就是舶来品，我们或许可以从西方判例中看出在AEC领域项目经理PMr.有着怎样的责任和义务。</p>
<p><strong>project manager &#8211;新生事物</strong></p>
<p>随着建设项目日益复杂，提供建设项目的人员的分工日益专业化，在大多数项目中，由于大家都需求有另外的专业人士去协调咨询工程师和承包商的工作，项目经理 应运而生。但是，项目经理的准确的角色和责任仍在不断发展完善。 但到目前为止，尚没有被行业认可的PMr（项目经理一词在国内建筑行业另有含义，因此本文以&#8221;PMr&#8221;作为Project Manager的缩写替代）的定义，也没有正式的工程PMr协会或组织团体。</p>
<p style="text-indent: 27pt; line-height: 150%">不同类别的其他专业团体出版的指南为项目经理承担相关的项目任务提供了帮助，RISC和CIOB都出版了相应的工程项目管理指南，但是PMr的职责范围和 管理任务并没有被完整清晰地定义出来。相反，关于PMr在工程项目各个阶段的具体任务都给出了长长的列表，而在列表中有很多任务与建筑师、合同管理师和工 程师的任务有一定程度的重叠。</p>
<p><strong>职业谨慎和职业技能</strong></p>
<p>虽然对项目经理这个特殊的职业没有达成像其它建筑行业所要求的职业谨慎和职业技能共识的标准，PMr的主要义务应该在明示或默示在合同条款规定中。 同时，其他咨询工程师的雇用合同条款对定义项目经理的任务范围也有相当大的影响。事实上，管理工程的任务并没有因为PMr的出现而增加多少，因此PMr更 多地分担了建筑师、工程师在工程管理方面的任务，从而将建筑师、工程师从琐碎的管理工作解放出来，确保其更好地完成专业工作和技术管理工作。在法庭上，当 确定项目经理有关的职业技能和职业谨慎义务时要看项目经理所属的专业协会,并且职业技能和职业谨慎的标准将是期望他作为一个有能力的称职的专业工程师来履 行项目管理等工作应达到的合理的职业谨慎和职业技能。正是由于项目管理是新兴的专业领域，其专业工作的定义尚未得到准确的界定，在判别PMr所要求的谨慎 的标准时，更多的取决于雇用合同具体条款规定和具体项目的要求。</p>
<p><strong>针对PMr的诉讼主张</strong></p>
<p>项目经理的角色被广泛地认为是监督与协调，多数对项目经理失职行为的诉讼主张有：项目经理没有控制好某方面的成本；没有确保其他建筑行业专业人士得到正确的信息；没有预防/防止建筑行业专业人士造成重大失误等等。</p>
<p><strong>1 合同管理</strong></p>
<p>作为工程项目的管理者，不可避免的要涉及工程合同的管理。无论PMr的雇佣合同是否对此明确租出界定，PMr的管理工作多不可能脱离开工程合同的管理。这 与工程项目的行业特征有关。在Royal Brompton Hospital NHS Trust 诉 ZHammond (2003) 88 Con. L.R.1.案例中，法官Lloyd.得出了一些关于项目经理角色的基本看法：</p>
<blockquote><p>(a) 项目经理是业主的总代表，这点应该被其他咨询人员以及业主清除认识这一点。<br />
(b) 毋庸置言，项目经理角色的核心任务是 &#8220;协调和保护业主的利益是毫无疑义的。&#8221;<br />
(c) 当建筑行业专业人士履行合同管理或者项目管理的角色时，必须同时具备建筑法律基本的原理、准则方面的知识，并且具备将知识应用到建筑合同工程管理和建筑项目管理中。在许多案例中，所需要的不一定是基本的法律知识，而是很好的理解运用建筑合同的标准文本。</p></blockquote>
<p>这些看法足以说明PMr具有潜在的合同管理责任，判例Great Eastern Hotel Co. Ltd v John Laing Co. Ltd [2005] 99 Con LR 45，是第一个报道的施工管理合同（construction management contract）违约案，业主成功地控告CMr.疏于对分包合同的协调管理。</p>
<p>在Royal Brompton Hospital NHS Trust 诉 Hammond (No.7) 76 Con. L.R. 148的案例中，由总承包商提出高额索赔，理由是PMr.监督建筑师未按时审核延期申请时存在职业疏忽。索赔建筑师的签证疏忽的同时附带索赔项目经理和其他项目管理团队成员。法官判定对PMr提提的索赔是由于对PMr的职责范围存在误解，PMr的职责是确定合同管理的确定被有效地实施，而不是判别他们是否完全正确。项目经理处理建筑师未按时审核延期申请时的角色，是判定建筑师是否在合理的时间内处理完这类申请。法官判定PMr需要判定是否在合理的时间内完成其任务，事实上就是要求PMr必须具备相应的合同管理技能和知识。</p>
<p>下面的两个判例也同样与合同管理有关：</p>
<ul>
<li>判例Costain Ltd v Bechtel [2005] TCLR 6 在合同管理的公正性方面引起了广泛的争议。合同管理师在与PMr会晤后更多地驳回了承包商的索赔。承包商索赔主张由于PMr不正确的干预导致业主违约，但 是PMr 辩称在NEC合同下，PMr没有公平行为的义务。事实上，承包商并未收到禁令禁止其获得由于任何事件而导致的合理损失的赔偿。</li>
<li>判例Scheldebouw v St James Homes [2006] BLR 113中, 法官判定业主不能利用CMr替代他们自己去管理商务合同，这不符合一个决策者的客观公正责任。</li>
</ul>
<p><strong>2 监督其他工程服务者的绩效</strong></p>
<p style="margin-left: 40px; text-indent: 27pt; line-height: 150%">在Chesham Properties Ltd 诉 Bucknall Austin Project Management Services Ltd (1996) B.L.R. 92的 案例中，原告就批准了额外的工程延期以及承担承包商的费用和损失，同时指控建筑师和PMr。法官认为称职的项目经理应该在发现建筑师、工程师或者工料测量 师等专业人士没有履行各自的职责时，有义务将上述情况通知业主。法官Hicks 裁决书中指出：&#8221;在实际的建造合同中对于具体的组织建立具体的关系方面项目经理有明确的职责，即项目经理有义务在被告履行各自职责时，向原告汇报他们的绩 效缺陷。&#8221; 即作为工程项目组织的管理者，PMr将有义务监控这些组织的绩效，并将他们的绩效缺陷告知业主。</p>
<p><strong>3 沟通协调</strong></p>
<p style="margin-left: 40px">在Royal Brompton Hospital NHS Trust 诉Hammond (2003) 88 Con. L.R. 1.案例中，法官清楚地指出PMr的沟通与协调职责：&#8230;实际上项目经理(虽然是一个素质高的项目经理) 也要一直接受他们的建议。尽管建议的本质基础可能被认为是显而易见的，也要完全的给出，否则项目经理的知识和专家的意见将会影响建议的清楚表达。即要求 PMr必须及时有效地沟通，并且保证各种意见和建议清楚、正确的表达，并被及时的传递。</p>
<p><strong>4 工程经验</strong></p>
<p style="margin-left: 40px">适当的工程管理经验也是必不可少的，在大型工程项目中，PMr的职责更多地履行沟通、协调和更高级别的控制与管理职能，专业技术管理和决策都会有相应的专 业技术工程师或者专业技术服务机构承担，他们有义务向PMr报告各自职责范围内的工作绩效和项目情况。相反，小型项目的项目经理要监督合同本身的运行，直 接接触承包商，完成项目的全部任务，更像工程总干事。但是无论如何，雇主在聘用PMr时，不会无视PMr的工程经验，下面两个判例说明了这一点：</p>
<ul>
<li><span style="font-size: 10.5pt; line-height: 150%"><span style="font-size: 10.5pt; line-height: 150%" lang="EN-US">在Pozzolanic Lytag Ltd诉 Bryan Hobson Associates [1999] B.L.R. 267的案例中:被告工程师被指定为燃料粉末存储库房工程的设计师和工程项目经理。一部分由承包商设计的工程倒塌。法官Dyson认为该工程师作为项目经 理，有义务确定项目投保工程保险并且因此对原告负有责任。他认为事实上项目经理缺乏必要的职业经验去评估承包商提供的工程保险协议的完善性，所以不能减轻 项目经理应该承担的责任。他们不能简单地履行类似&#8221;邮箱&#8221;的职责。</span></span></li>
<li><span style="font-size: 10.5pt; line-height: 150%">在Palermo Nominees Pty Ltd and Micro Bros Pty Ltd诉 Broad Construction Service Pty Ltd [1999] 15 B&amp;CL 20的案例中：项目经理由于没有完全履行合同约定的义务和约定而败诉，原因是没有要求一个外部的顾问（external consultant）提交关于夜总会内部噪音对于项目设计和建造的影响。<br />
</span></li>
</ul>
<p><strong>总结</strong></p>
<p>综上所述，从西方的判例看，PMr的职责除了&#8221;项目管理&#8221;理论所赋予的沟通、协调等职责外，在工程项目领域还需要PMr具有一定的工程合同管理知识、技能 和实际的工程管理经验。从实际的案例看，更多的业主倾向于将PMr看作是整个工程项目组织的管理协调者，因此监控整个组织的绩效并汇报他们的绩效缺陷是 PMr的责任。</p>
<hr /><small> <a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-nc-sa/2.5/cn/80x15.png"/></a><br/>本<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" rel="dc:type">作品</span>采用<a rel="license" href="http://creativecommons.org/licenses/by-nc-sa/2.5/cn/">知识共享署名-非商业性使用-相同方式共享 2.5 中国大陆许可协议</a>进行许可。Copyright &copy; 2008 作者<a href="http://www.airstorm.org/blog/about/"> clockwork59 </a> at <a href="http://www.airstorm.org/blog/">Airstorm</a> (数字指纹:<br /> 24fed2e143ca40ef26657495da818d48)</small>]]></content:encoded>
			<wfw:commentRss>http://www.airstorm.org/blog/2006/12/24/project-managers-duties/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

