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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　业务方不会明确地告诉你业务规则和逻辑是什么样子的，所以需要你主动牵引，按照需求会议的讨论内容，结合你对业务的理解、对用户的研究整理出符合当前的系统逻辑和规则，并请业务关键人员进行确认回复。因为只有明确了逻辑和规。