一般在IT企业管理外包项目和平衡责任交付中通常会出现项目管理挑战。PMO顾问正与一客户一起共事来开发项目管理流程，这些项目大量地依赖外包。每一个项目涉及启动该项目启动、定义问题、跟着报价申请单流程来评估、获得以及实施解决方案。对于每一项实施，执行供应商都会在提供技术资源之外还提供工程管理人员来交付该工程。该客户同样也配备了项目管理者来实施该工程。正如你可以想像的，在整个产品组合中了解具体的角色和整体的问责迅速成为一个混乱的根源。
该形势对组织和支持的PMO引起了许多问题。下面是一些问题，如果您正处于相似的形势中，您可能也会遇到这些问题，与之一起的还有关于我对解决这些复杂问题的建议。
项目范围说明书和工作说明书 (SOW)的可交付性对于内包和外包的工程有何不同？谁应为完成这些交付负责？
在一项单纯的内购项目中，项目管理者开发项目章程、范围说明书以及支持的工作分解结构 (WBS)。在外包项目中一般要开发 SOW 来交付WBS的一部分或整个的项目。在外包时SOW包含具体的可交付性，执行供应商将制定包括假设、约束以及期望的服务水平的协议。
执行供应商将会进行SOW的谈判，但是最终公司的项目管理者需要拥有这些可交付性。某些情况下，项目章程、范围说明书、WBS以及其他的项目可交付成果可能要作为执行供应商提供的SOW的一部分。在该情况下公司的项目管理者仍然需要协调和提供对这些项目可交付成果的总体批准。
谁持有、开发和管理工程计划？
关于这个问题，我听到了很多争论。在我所工作的外包项目中我管理综合项目的计划表，在外包的供应商在管理整个的项目计划的地方我一直都在项目中。有些项目团队，内、外部都有，拒绝提供详细的计划表而只是依靠时间表。其他的项目团队想要公用资源池的彻底综合的日程表。
我偏向于与供应商一起共同地开发综合项目计划表，这样关键的时间表、检查点、核心可交付成果以及企业项目管理流程就可以得到支持。供应商可以详述他们具体的工程任务来交付承包工程。每周我们进行综合进度计划的审查，这样每个人就掌握了工程的透明度和开放式通信。
如果我外包项目，我会依靠供应商的项目管理人员来交付和管理项目的技术性细节。作为一名客户端项目管理者，我仍然要负责对外包的可交付成果整合公司。与供应商建立信赖和透明度以及展示灵活性是很重要的。这些都是通过一起共事而不是将项目扔到墙外”同时期望供应商交付所有的工作来形成的。
工资单供应商可能会同意为公司处理工资单问题，甚至向既有旧系统提供新界面；然而这是客户端项目管理者的工作来确保既有旧系统能够支持新变化，与下游系统进行沟通，以及提供适当的组织变革管理。供应商仍然可以帮助处理这些技术性细节，但是您不可能外包领导权。
谁为该项目负责？公司还是执行供应商？
供应商为在SOW 中鉴定的可交付成果负责。当与供应商有良好的工作关系时，双方在范围和责任方面都将是灵活的。当出现合同纠纷时，双方都需遵守合同中的文字。供应商也许为具体的可交付成果负责，但是最终还是客户端项目管理者来负责交付项目。
项目产生于业务需要。企业业务消费者依靠项目管理者来交付项目。如果项目管理者选择外包该项交付，其仍然要为业务消费者和颇大的投资负责。当项目变得艰难时，很容易就说出这是供应商的问题”，但是作为有效的项目管理者，我们需要帮助供应商成功。
项目管理类产出和可交付性成果如何改变来采取外包的方法？
核心的项目文件仍然需要存在，包括项目范围说明书、WBS、详细的工程计划、风险记录单、问题登记簿、变更日志等等。公司杠杆外包策略的同时需要为特定的项目交付性开发验收准则。
如果供应商只提供10项任务的工程计划表，会发生什么？如果供应商制造了不好的可交付成果像是糟糕的代码、糟糕的培训材料或是没用的测试案例会怎样？通过为每一个主要的项目管理和系统开发生存周期的可交付性成果确立验收准则，这样公司和供应商就会有共享的质量定义。
公司可以冒险定义大量的造成收益递减的验收准则。我们是否真的需要在合适地格式化的项目问题登记簿上的验收准则？需要实施灵活性，因为供应商想在不招致额外的管理负担（供应商在提议的反应阶段可能对这些负担没有计划）的前提下交付给客户端。
独立于内购或外包，客户端项目管理者仍然需要受限于时间、范围和成本的三维限制。外包仅仅是为了成功完成交付而采用的一种额外的工具。项目管理方法，项目产出、作用、责任以及期望需要在之前定义，这样双方就可以在共同信任、透明和灵活性下完成交付。
