一般在IT企業管理外包項目和平衡責任交付中通常會出現項目管理挑戰。PMO顧問正與一客戶一起共事來開發項目管理流程，這些項目大量地依賴外包。每一個項目涉及啟動該項目啟動、定義問題、跟著報價申請單流程來評估、獲得以及實施解決方案。對于每一項實施，執行供應商都會在提供技術資源之外還提供工程管理人員來交付該工程。該客戶同樣也配備了項目管理者來實施該工程。正如你可以想像的，在整個產品組合中了解具體的角色和整體的問責迅速成為一個混亂的根源。

　　該形勢對組織和支持的PMO引起了許多問題。下面是一些問題，如果您正處于相似的形勢中，您可能也會遇到這些問題，與之一起的還有關于我對解決這些復雜問題的建議。

　　項目范圍說明書和工作說明書 (SOW)的可交付性對于內包和外包的工程有何不同？誰應為完成這些交付負責？

　　在一項單純的內購項目中，項目管理者開發項目章程、范圍說明書以及支持的工作分解結構 (WBS)。在外包項目中一般要開發 SOW 來交付WBS的一部分或整個的項目。在外包時SOW包含具體的可交付性，執行供應商將制定包括假設、約束以及期望的服務水平的協議。

　　執行供應商將會進行SOW的談判，但是最終公司的項目管理者需要擁有這些可交付性。某些情況下，項目章程、范圍說明書、WBS以及其他的項目可交付成果可能要作為執行供應商提供的SOW的一部分。在該情況下公司的項目管理者仍然需要協調和提供對這些項目可交付成果的總體批準。

　　誰持有、開發和管理工程計劃？

　　關于這個問題，我聽到了很多爭論。在我所工作的外包項目中我管理綜合項目的計劃表，在外包的供應商在管理整個的項目計劃的地方我一直都在項目中。有些項目團隊，內、外部都有，拒絕提供詳細的計劃表而只是依靠時間表。其他的項目團隊想要公用資源池的徹底綜合的日程表。

　　我偏向于與供應商一起共同地開發綜合項目計劃表，這樣關鍵的時間表、檢查點、核心可交付成果以及企業項目管理流程就可以得到支持。供應商可以詳述他們具體的工程任務來交付承包工程。每周我們進行綜合進度計劃的審查，這樣每個人就掌握了工程的透明度和開放式通信。

　　如果我外包項目，我會依靠供應商的項目管理人員來交付和管理項目的技術性細節。作為一名客戶端項目管理者，我仍然要負責對外包的可交付成果整合公司。與供應商建立信賴和透明度以及展示靈活性是很重要的。這些都是通過一起共事而不是將項目扔到墻外”同時期望供應商交付所有的工作來形成的。

　　工資單供應商可能會同意為公司處理工資單問題，甚至向既有舊系統提供新界面；然而這是客戶端項目管理者的工作來確保既有舊系統能夠支持新變化，與下游系統進行溝通，以及提供適當的組織變革管理。供應商仍然可以幫助處理這些技術性細節，但是您不可能外包領導權。

　　誰為該項目負責？公司還是執行供應商？

　　供應商為在SOW 中鑒定的可交付成果負責。當與供應商有良好的工作關系時，雙方在范圍和責任方面都將是靈活的。當出現合同糾紛時，雙方都需遵守合同中的文字。供應商也許為具體的可交付成果負責，但是最終還是客戶端項目管理者來負責交付項目。

　　項目產生于業務需要。企業業務消費者依靠項目管理者來交付項目。如果項目管理者選擇外包該項交付，其仍然要為業務消費者和頗大的投資負責。當項目變得艱難時，很容易就說出這是供應商的問題”，但是作為有效的項目管理者，我們需要幫助供應商成功。

　　項目管理類產出和可交付性成果如何改變來采取外包的方法？

　　核心的項目文件仍然需要存在，包括項目范圍說明書、WBS、詳細的工程計劃、風險記錄單、問題登記簿、變更日志等等。公司杠桿外包策略的同時需要為特定的項目交付性開發驗收準則。

　　如果供應商只提供10項任務的工程計劃表，會發生什么？如果供應商制造了不好的可交付成果像是糟糕的代碼、糟糕的培訓材料或是沒用的測試案例會怎樣？通過為每一個主要的項目管理和系統開發生存周期的可交付性成果確立驗收準則，這樣公司和供應商就會有共享的質量定義。

　　公司可以冒險定義大量的造成收益遞減的驗收準則。我們是否真的需要在合適地格式化的項目問題登記簿上的驗收準則？需要實施靈活性，因為供應商想在不招致額外的管理負擔（供應商在提議的反應階段可能對這些負擔沒有計劃）的前提下交付給客戶端。

　　獨立于內購或外包，客戶端項目管理者仍然需要受限于時間、范圍和成本的三維限制。外包僅僅是為了成功完成交付而采用的一種額外的工具。項目管理方法，項目產出、作用、責任以及期望需要在之前定義，這樣雙方就可以在共同信任、透明和靈活性下完成交付。