从售前投标到项目初始化阶段中与计划相关的几个事情

这将是一篇不是对所有人都那么有用的文章,但是作为将近一年来的心得体会,还是有必要记录一下。不打算展开记录太多的细节,作为一个纲要简单写写吧。

题目写的有点大,先在此限定一下背景:深海油田所需的设备制造项目,售前面对的主要是油田区块运营商和总包项目承包商。如此一来,这个话题就有了比较具体的环境。先从一个简单列表开始:

  • 产品(结构)定义(PBS)
  • 工作结构定义(WBS)
  • 成本结构定义(CBS)
  • 工程可交付物(Engineering Deliverables)
  • 采购可交付物(Procurement Deliverables)
  • 制造可交付物(Construction Deliverables)
  • 项目管理可交付物(Administration Deliverables)
  • 工艺流程(Process)
  • 限制与假设(Limitations & Assumptions)
  • 公司或第三方供应 / 接口信息列表(3rd Party or Client Provided Items / Interfaces)
  • 风险(Risks)

对于工艺流程相对固定,交付成果定义一般较为清晰的EPC制造项目来说,尤其应当将上述各项标准化。在这个行业中,一个售前团队在投标过程中往往会花费总计上千小时的人工,对于工时成本普遍上千的挪威,更是一笔不小的开支。在参与售前工作的过程中,往往存在大量的沟通与假设,而由于投标预算有限,投标团队往往很难依靠自己的力量把项目的来龙去脉都研究透彻,因此各种假设构成了投标团队非常主要的工作基础。当然,经验是非常重要的,完全没有EPC经验的团队恐怕就是拥有了标准化的资料,也难以作出正确的判断。

在这一系列的列表中,我打算多写几句说说PBS,WBS和CBS。

我所希望看到的是在投标阶段,最主要的工作是解读客户的需求,首先应在定义好的PBS中进行裁剪,通过减法得到一份产品结构定义(PBS),这样一份通过减法获得的定义,我希望将其称为Scope of Supply / Scope of Work,这将成为项目执行计划和成本测算的基础,同时这样一份SoS/SoW也将对项目的边界做出清晰的定义。当然,除了明确的SoW定义外,还可能存在可选件,可选件也应明确定义。如果客户的需求在预定义的PBS中无法找到,那么这可能是一个新的需求,对于新的需求,应组织相应人员研究确定其工作量,成本,工期等信息,避免低估造成损失或高估增加客户成本负担。对于EPC项目,PBS的重点是描述硬件交付物,但是对于其他形式的交付物,也应当进行定义。

WBS可以跟PBS比较相近,但是WBS的定义是工作结构定义,顾名思义,WBS并非针对可交付物结构设计的工具,WBS可以包含项目过程中的任何活动,但是对于EPC项目,我更倾向于让WBS尽可能接近PBS,因为PBS中的项通常是可度量的。但是出于项目执行过程中的需要,WBS可能需要包含一些没有明确交付物的活动(里程碑不在讨论之列),我的建议是越少越好。

在投标过程中,投标团队一定会对项目成本进行评价和测算,不管是通过Benchmarking还是精确询价/测算,终究要建立在一定的基础上,暂且不讨论是以Lump Sum报价还是Reimbursement报价,成本结构在团队/公司内部应尽可能与PBS保持一致,这在将来对Budget在计划中进行分配和权重调整过程中非常重要,一致的结构不仅能简化这个过程,还能形成细节更加丰富的可比较数据,对于未来的Benchmarking有非常大的帮助。同时由于这个行业中的项目执行过程中出现补充付款/变更的可能性非常大,良好的定义有助于降低对项目中某项工作变更时由于早起不准确报价所带来的风险。对于项目执行过程中的计划控制来说,一个准确的S-Curve是比较重要的,尤其是按进度付款的项目。

其他的就不多说,可交付物的明确定义也是为了帮助确定项目边界,不管是PMI还是Prince2,对项目边界的定义都是非常重要的。工艺流程的定义可以帮助我们建立正确的计划网络,对于投标过程中的多种情形分析有重要意义,这个以后我应该会单独再写文章讨论。限定与假设,没有这个列表的计划,或者说投标,几乎就等于自杀,我们建立在某些限制与假设上的判断,极有可能在假设发生变化的时候失去意义,而明确的限制与假设可以让这种变化visible,风险更加可控。接口信息或公司提供的设备,因为不在或不完全在项目组的控制范围之内,因此应更加小心,明确的定义有助于降低风险,在必要的时候有助于像客户提出补偿或免责声明。风险应当尽早鉴别,设定应对策略,建立相应的Margin以避免风险发生导致的损失,这也是一个比较大的topic,在这里就也不展开说了。

这一切,都应该是定义好的,在投标过程中,都应该是做减法的,从标准模板中找出相关项,不仅节省人力,还能减少出错的概率。而这些定义应当在投标过程中和项目初始化阶段复用,尽可能避免重复劳动。

我承认本文收尾有些草率,本文暂且做一个提纲,日后再展开讨论吧,要早点睡觉了,晚安!

EPC项目初体验

工作的最初3年,我做软件开发,后来做上了小lead,再后来做上了PM。经过了比较苦逼的一段时间,也经过了相对逍遥的一段时间,我竟然离开了IT。过去我曾以为我会在IT行业中进行一次创业,现在却踏入了一个全新的领域。曾几何时从未想过自己会从IT行业转入石油行业,更未想过会做深海石油相关的项目。于是2013年,我开始真正接触了EPC项目过程。

关于EPC是什么,采用互动百科的一段解释:

EPC就是设计采购施工(交钥匙)工程总承包,即工程总承包企业按照合同约定,承担工程项目的设计、采购、施工、试运行服务等工作,并对承包工程的质量、安全、工期、造价全面负责。

Engineering,Procurement 和Construction,说的细点,还可以包括测试(Testing)和安装(Installation)。和以往我所做过的独立IT项目不同,目前我所接触的项目规模小则2、3亿,大则十几亿,工厂开工后停工一天的损失就会高达近百万,因此在这样的项目中项目管理的投入可谓是四两拨千斤,毕竟一个全职的项目经理在这样规模的项目中成本很难超过1%,成本控制、计划控制、风险控制、QHSE等的投入也不会超过1%,良好的计划和控制会为整个EPC过程带来卓越的成效。

E(设计)是EPC项目的关键,设计能力直接决定了项目成败,所有的采购和建设全部依赖于设计的成果。而施工过程往往决定了最终的交付时间点,因为施工过程中可能由于关键资源(有限数量和固定时间表、产能)的限制,不能通过增加资源的方式加快进展(增加人手的方法在IT项目中是非常常见的),因此早期的良好计划直接决定了施工资源的使用效率。介于设计与施工中间的采购部分,也叫做供应链,通常要在设计达到一定程度时开始,并在施工开始前到位。这部分有时候会out of control,因为供应商的生产制造情况,有时很难获得详细状态。因此采购交付的延迟是经常发生的事情。

我现在所接触的EPC项目周期通常为20个月左右,一般在排定计划的时候,会在E/P之间保留2周左右的Contingency,P/C之间保留2周左右的Contingency,C后,最终交付日前保留4周左右的Contingency。常听大家谈起的LD(Liquid Damage)是真金白银的赔偿,如果错过了客户交付日期,LD通常都是无法避免的,所以项目初期做计划的时候,通常会做比较保守的计划。

今年就先写到这里,本博的项目管理系列权当一份学习笔记,偶尔记录一些心得体会,于己是个备忘,于人是个分享。