EPC工程总承包项目实施过程管理细则

●工程总承包项目实施过程控制●

1、工程总承包的组织应在受控条件下提供生产和服务

生产和服务提供过程，直接影响产品或服务的质量。组织应确定要求，针对产品或服务的性质，对所有与生产服务提供过程相关的活动进行考虑和有效控制，以满足组织或顾客的各种要求。

2、工程总承包项目实施过程控制

控制是项目管理的重要活动之一，控制的目的就是使产品和服务质量满足顾客以及法律法规等方面提出的要求。控制的对象包括产品和服务形成全过程各个阶段的活动。

项目控制是项目管理者根据项目跟踪提供的信息，对比原计划 ( 或既定目标 )、找出偏差、分析原因、研究纠偏对策，实施纠偏措施的全过程。工程总承包项目实施过程控制主要包括综合变更控制、范围变更控制、质量控制、风险控制、费用控制和进度控制等内容。

3、工程总承包项目实施过程控制的原则

工程总承包项目部应对工程总承包项目实施的全过程进行控制，确保项目实施过程始终处于受控状态。工程总承包项目实施过程包括项目启动、策划、实施、控制和收尾等，项目管理内容包括项目进度、质量、安全和环境、费用、资源、沟通和信息、合同、风险、收尾等。

4、工程总承包项目实施过程控制的要求

一是项目经理应行使项目管理职能，实行项目经理负责制；

二是项目部应获得适用的法律法规、技术标准规范及验收规范、作业指导书、工程图纸、工程总承包合同、设计分包合同、采购合同、施工分包合同等文件，并按要求实施；

三是应配置与项目适宜的监视和测量资源，并实施监视和测量。对于工程总承包中过程结果不能由后续的检查、试验加以验证的过程，在策划时应予以确定，并明确对所使用的设备认可和人员资格的认定，使用的特定方法和程序等，必要时实施再确认；

四是在工程勘察、设计阶段，工程总承包企业应按照合同要求进行深化设计，做好投资控制，并控制施工图设计进度。施工图应进行设计可施工性分析，确保工程质量。施工图设计完成后，设计应配合项目变更进行施工图审查及修编工作；

五是在项目采购（分包）工作中，组织签订采购（分包）合同，进行采购（分包）合同交底，执行采购（分包）合同，进行采购 ( 分包 ) 总结及评价等；

六是在施工和试运行管理过程重点做好质量控制、安全、职业健康和环境保护控制、进度控制、合同及费用管理、档案（信息）管理、风险管理和沟通协调管理等；

七是项目进入收尾阶段后应进行现场清理、项目竣工结算、竣工资料移交、项目总结、项目团队绩效考核、EPC项目部解散、工程保修与回访等工作；

八是应进行工程划分并报批，根据工程划分确定质量控制点、级别及检验批；

九是项目部应对原材料、设备、构配件进行进场检查验收，有复试要求的材料按规定要求进行复验；

十是应正确使用监视和测量资源，实施监视和测量；

十一是应采取措施防范人为错误。措施可包括：增加标识；设置警示、联动、限位装置；改进工器具的性能；用自动化代替手工作业；实行班前培训、班后检查，必要时实施样板引路；创造良好的作业环境和人文环境，安排合理台班时间，防止操作人员过度疲劳等；

十二是应对过程工序、最终产品的验收交付和交付后活动按规定要求实施控制。

5、工程总承包项目实施过程控制关注的重点工作

在项目实施控制过程中，应关注：项目施工管理；施工与设计、采购和试运行的接口控制；项目试运行管理；试运行与设计、采购和施工的接口控制；项目风险管理；项目质量管理；项目职业健康安全和环境管理；项目进度管理；项目费用管理；项目资源管理；项目沟通与信息管理；工程总承包合同管理；项目收尾；标识和可追溯性管理；顾客或外部供方的财产的控制；工程总承包项目的防护；工程总承包项目移交后的服务；工程总承包项目更改的控制；工程总承包项目放行的控制；工程总承包项目不合格品的控制等。

●工程总承包项目绩效评价●

1、绩效评价

组织应通过监视、测量、分析和评价、内部审核以及管理评审活动对绩效进行评价，确定和选择改进机会，并采取必要措施，以满足顾客要求和提升顾客满意度。工程总承项目应明确检查的内容、范围和频次，应分阶段、多维度地组织对项目实施的中间成果和最终成果实施检查。采取总结、统计分析、调查对标等方式，确定改进的需求并实施改进，以不断提升顾客的满意度。

2、检查

（1）项目策划阶段的检查

工程总承包企业生产管理部门应依据项目策划的有关规定，对工程总承包项目的策划过程和策划文件进行监督检查，重点检查策划的及时性，策划文件的适宜性、完整性，以及策划要求实施的有效性，确保策划过程和策划结果满足要求。

（2）项目实施过程的监督检查

工程总承包企业生产部门应根据项目具体情况制定监督检查计划，根据项目特点及实施的不同阶段，确定检查内容和检查重点。监督检查人员按照监督检查计划实施监督检查，监督检查结束后编制并下发监督检查报告。监督检查报告应包括检查内容、检查发现的问题及整改要求，应跟踪确认问题整改到位。相关职能部门应按照与项目部签订的项目管理目标责任书，对项目部进行考核。

（3）中间成果和最终成果的检查

工程总承包企业应建立设计成品质量检查和评定制度，对设计成果进行抽查或复查，及时发现设计文件存在的质量问题，减少对工程质量的影响。

对检查结果进行评定和通报，减少同类设计错误的重复发生。应在项目竣工验收前，组织相关设计人员参加工程的“三查四定”，对已完工程与设计要求的符合性进行检查。项目部在项目竣工验收前组织施工分包单位“三查四定”，查找工程质量隐患并及时整改。工程完工后，项目部应向建设单位提出竣工验收申请，并配合其组织的工程竣工验收。

发包方、监理、质量检查机构或政府主管部门对项目质量检查发现的问题，应组织相关施工分包单位或供应商进行整改或处理，保留相关记录。项目实施过程中对检验批、分项、分部（子分部）工程的质量要求验收，应按工程总承包项目的放行的控制要求进行。

3、改进

（1）工程总承包业务的改进需求

工程总承包企业应建立工程总承包业务改进机制，采取总结、统计、分析、调查、对标等方式，确定改进的需求，并实施改进。

一是收集、整理各层面、各类检查发现的工程总承包项目管理的典型问题，进行归类、统计和原因分析，确定需改进的内容；

二是收集工程总承包项目发生的各类采购、施工质量不合格、质量事故、事件，进行原因分析，确定改进需求；

三是在项目实施过程中通过与外部相关方沟通，收集与项目管理有关的意见和建议，确定改进的需求；

四是通过工程项目回访、顾客意见调查收集顾客或相关方的意见，进行统计分析，确定改进的需求；

五是通过调研、交流、学习，或开展同行业先进企业对标，查找本企业工程总承包管理的差距，确定改进的需求；

六是通过工程总承包项目总结，对项目运行管理中的经验、创新点予以总结和积累，对出现的问题或教训认真分析原因，确定改进的需求；

七是对合同履行情况进行总结和评价，查找问题，确定改进需求等。

（2）确定质量改进措施

一是对设计成果质量抽查或复查发现问题、设计文件外部审查、设计回访、设计原因导致的设计变更等设计质量问题进行统计、分类，分析原因，确定改措施；

二是对工程总承包项目质量事故、事件的调查分析，确定原因，制定改进措施；

三是对工程总承包项目施工过程中和验收过程中发现的质量不合格进行原因分析，确定改进的措施；

四是对采购的设备、材料、构配件在进厂检验或安装、使用后发现的不合格品进行统计分析，确定改进措施；

五是在工程保修期内收集发生的保修事项，分析故障原因，确定改进措施等。

4、实施改进

工程总承包企业应根据确定的改进内容制定有针对性的改进措施，确保改进措施的实施能够实现改进的效果：

一是改进管理方法；

二是采取措施提高管理人员、技术人员的能力、水平；

三是调整或增加项目资源配置（人员、软件、标准规范、作业指导文件、测量设备等）；

四是完善管理体系、项目管理制度、管理流程、管理界面、技术和管理接口等；

五是改进知识管理程序；编制设计模板、标准化设计等；

六是必要时，可考虑业务的调整等。应实施确定的改进措施，并验证措施的有效性和实施效果。

5、绩效评价

（1）工程总承包业务的经营绩效评价

工程总承包企业应通过以下方面的内容，评价工程总承包业务的经营绩效：

一是工程总承包业务年度经营目标的制定及完成情况；

二是制定和完成的年度经营指标应适应企业中长期发展规划的目标；

三是一年来工程总承包业务新市场的开辟情况，总承包业务的增长情况；

四是一年来工程总承包业务的中标率增长情况；

五是工程总承包业务人均产值指标增长情况；

六是工程总承包业务的盈利能力、利润率指标在同行中所处的位置等。

针对上述绩效指标与竞争对手、同行标杆企业进行对比分析，找出优势、劣势和差距。

（2）工程总承包业务的管理绩效评价

工程总承包企业应通过以下方面的内容，评价工程总承包业务的管理绩效：

一是本企业项目管理体系、绩效考核体系、激励机制、人才培养机制等对工程总承包业务发展的支撑作用；

二是工程总承包项目获得的相关方的赞扬、表扬，以及获得的优质工程奖、鲁班奖、专利，或其他奖项；

三是工程总承包项目应用新材料、新设备、新工艺、新技术成果的情况；

四是管理人员队伍建设、人员培养等方面取得的成效；

五是通过学习、培训、项目管理实践，培养工程总承包管理的高素质人才的情况；

六是对项目管理体系、管理流程的改进情况；

是工程总承包业务的外部评价情况等。

（3）工程总承包项目的绩效

工程总承包企业可通过对已完成的工程总承包项目，通过以下方面评价项目的绩效：

一是项目管理目标责任书的完成情况；

二是项目绩效指标的完成情况；

三是项目知识管理取得的成效；

四是项目风险控制的效果；

五是项目进度控制、费用控制的效果；

六是工程质量状况，主要包括工程竣工验收、试运行、开车及性能考核的情况；

七是对分包方实施控制的效果：对分包方重复发现同类问题的情况、分包方问题整改的及时性、效果等；

八是项目实施过程中是否发生质量、职业健康、安全和环境事故的情况；

九是保修责任期内出现故障的情况；

十是项目资料的完整性及整理归档的及时性；

十一是发包方或监理单位对项目部的评价等。

在资源不足的情况下，如何将项目做好?

资源不足

项目管理十大知识领域中，项目资源不足或许是最常见。

巧妙应对

很多项目经理习惯性地认为会哭的孩子有奶吃，一方面项目可以得到领导的重视，另一方面资源充足的团队就相对轻松一些。你会说，要明确现状，获得理解和支持。但这是一句废话，没有任何的驱动意义，也没法以结果为导向实现项目的交付。而且，你的潜台词还在说，领导眼瞎。拜托，一个项目的规划和实施，你的领导比你心里更清楚。他不是看不到这样的现状，而是人力资源缺乏的现状并不是他一时半会就能立马解决的问题。所以，你的预防针变成温馨提醒和进度汇报就足够了。

重要的是，基于这样的现状，作为项目经理，你能做点什么或者应该做点什么让这眼前的浓雾散开，可以窥得见一缕美好的阳光呢?项目经理需要站在企业的角度去思考问题，运用灵活变通的理念做好项目管理，切切实实为企业解决问题，可采取的具体措施如下。

简化项目的解决方案

也许你从一开始就设计了比较完善的项目建议书，这里面包含了一个巨大的项目工作范围，你的SOW和WBS可能也写得很详尽。但此刻，你的团队里只有2个后端开发人员，没有前端工程师和数据库开发工程师，也没有测试人员来保证项目的质量。这是一个多么悲伤的话题啊，就像你选定了要演奏的曲目，确定了音乐会的时间和场地，但仅有2个音乐师能够出席。所以，那个音乐指挥家挥舞着指挥棒在想，可不可以把这场音乐演奏会变成音乐独奏会?

这样的情况下，你依然需要淡定地把项目方案建议书和需求规格说明书重新审视一遍。结合用户需求思考和权衡，哪些功能是目前比较关注的，而哪些功能是未来系统需要关注的。这个其实并不难，如果你和用户开放地沟通过，项目功能的轻重缓急，你应该心里有数。所以，你很有必要在此基础之上，整理出项目当前阶段的需求规格说明书来。不要一味地喊叫资源不足，这样的方式只会引起领导对你做事能力的怀疑，而不能解决根本问题。

确定核心功能的优先级

关于个人工作效率的经典之作《高效能人士的七个习惯》一书里依据纵坐标(重要性)和横坐标(紧急性)来划分任务，有如下四种组合：

(1)重要且紧急，迅猛龙式出击。

(2)重要但不紧急, 准备好未来的方案、策略和计划。

(3)不重要但紧急，学会说不，拒绝任何承诺。

(4)不重要也不紧急，可以研究下隔壁的妹纸为何每次遇见你都会笑得很好看。

一个大型的项目，利益相关方会很多。常常会有很多年轻而对项目管理知识无知的利益相关方从方便个人利益的角度出发，突然过来很莫名地给你讲，XX报表要放在你的系统里实现而且某大领导非常重视。这时，你需要做的就是果断拒绝，不要给任何承诺。很明显，这是不重要也不紧急的事情。因为凡是重要且紧急的任务，领导都会在需求讨论会上明确地强调多次。项目经理心里要有一杆秤，哪些人的需求是需要理会的，哪些人的需求是不用过多关注的。

整理完核心功能和关键任务的优先级列表后，你会发现项目一半的范围进行了裁剪。这是一个好的趋势和结果，因为缩减和明确项目范围永远对项目的如期交付是有利的。而一个项目的实施，10个人有10个人的计划和结果，2个人也有2个人的计划和结果。当你无法争取标配的资源获得对这个项目的足够支持时，只能关注核心功能并在核心功能范围内进行任务的优先级排序。

制定可行的迭代计划

迭代这个词现在很泛滥，但很多人都不明白需要迭代什么。项目经理首先要明确，在这些核心功能清单中，哪些是需要放在持续的迭代计划当中的。不是项目所有的功能都需要迭代，成熟的功能基本都是一次开发就落地实现，如果你说要迭代设计登陆和退出功能就显得非常逗比和无知。通常需要迭代的任务都是那些比较复杂的，业界技术不是很明确或者用户未来期望也不是很明确的功能，比如权限体系、报表体系等。

迭代周期不要过短(团队Hold不住，时间都会浪费在代码分支合并冲突检测、各种测试、Bug修复、上线发布中)，也不要太长(否则失去了敏捷开发的意义)，为了给不成熟的团队留出充分的容错时间，所以需要具体情况具体分析。这时作为项目经理的你，需要和开发人员探讨每个里程碑的实现程度。

设计前瞻的系统架构

如果你有幸遇到一个有全局观、有前瞻性的系统架构师，项目会顺利很多。系统的架构就像交通工具的骨骼，你需要和架构师进行密切的沟通。开发未动、架构先行的准则是保证系统未来不会宕机和崩溃的重要准则。所以你不要期望“老牛破车”的架构和框架之上，能继续朝里面添加或者迭代什么功能，也不要指望它能够跑得有多快、有多远。甚至，更多的可能是，你在项目功能进行迭代的时候，它已经无法兼容和承受这么多的负荷，变得支离破碎，牵一发而动全身，瞬间就宕机挂起。系统架构和框架的前瞻性、灵活性、兼容性是分布式开发、多用户并发环境里必须要考虑的重点和难点问题之一。

明确系统的关键逻辑

前面已经很明确了，留给开发团队仅有的2个人员的开发时间没剩下多少啦。如果你还不主动出击，驱动关键业务方，明确系统逻辑和规则，就会导致后续再多的开发人员都需要无休止地熬夜加班。尽早地确定系统逻辑和规则，本质上是为了给开发人员、测试人员节省更多的时间，从而保证系统的质量和性能。系统逻辑和规则的确定，最好的方式是最终都能够用正式的邮件确认和统一过。

业务方不会明确地告诉你业务规则和逻辑是什么样子的，所以需要你主动牵引，按照需求会议的讨论内容，结合你对业务的理解、对用户的研究整理出符合当前的系统逻辑和规则，并请业务关键人员进行确认回复。因为只有明确了逻辑和规则，你才真正地为开发人员扫除了顾虑和障碍，才能在有限的时间内聚焦在业务逻辑和规则的实现当中，而不是写一行代码出现一个疑问，然后朝你问十万个为什么，之后仅有的时间又会浪费在解释和思考当中。所以一个合格的项目经理对项目的思考和规划需要是最全面的，并且都能够是前瞻性的，至少比团队当中任何一个成员都需要有超前的思考。

需要强调的是，项目经理需要调整心态，控制好自己的情绪。无论是什么原因造成的资源不足，你一旦接手了项目，就必须想尽一切办法来克服困难，把项目做成功。同时，你必须学会最大限度地保障自己的利益，不必过分委屈求全。你不可能令所有的利益相关方都满意，但你能做到的是，用自己的努力让自己满意，保持内心的平衡。